I’ve worked with the BizTalk Rule Engine and various rule systems using Windows Workflow Foundation with varying degrees of success, so I was interested in seeing InRule’s solution, billed as “The Premier .NET Solution for Authoring, Managing and Executing Business Rules”. The company has been around since 2002, and lists AirTran Airways, Trane and Experian among its customers.
Product Components of InRule
InRule has multiple components for authoring, storing and executing rules, each of which can be installed separately or together:
- irAuthor – The main rule authoring application.
- irVerify – A real-time test environment. You can test your rules by entering the data directly (no need to have a fully completed application), as well as do step-by-step traces.
- irWord – Allows business users to manage rules directly from Microsoft Word.
- irCatalog – Database storage for your rules with source control and search capabilities.
- irSDK – The software development kit that allows developers to integrate InRule into their apps.
- irStudio – Allows rule authoring within Visual Studio.
- irServer – The “central nervous system” of InRule.
- irSOA - Makes it easier for InRule users to access the InRule rule engine as a service.
InRule has so many different features and uses that I could never cover them all in a single blog post (at least, not in one that folks would read to the end…) so I decided to work with the Visual Studio integration of rules, and take a quick look at how InRule integrates with BizTalk.
Calling InRule from a .Net app
I started by working with one of InRule’s video tutorials (the web site has a ton of good developer resources) – a simple rule for authorizing employee travel via a .Net console app. First, I created some basic classes to hold Employee and Trip data:
Now it’s time to write the actual rule with irAuthor. You can point irAuthor at your compiled .Net DLL to import all your objects as Entities:
Now we can define the rules. I’m going to create a simple rule saying that if an employee who is not a Manager or Executive (remember our EmployeeLevel enum above) submits a trip request where the budget is over $3000, we want to send them a notification message saying that the trip requires executive approval. This is expressed in simple English like this:
… and “ApprovalNeededMessage” looks like this:
I can test the rule inside irAuthor by entering my own data and getting the notification displayed:
At this point you’d normally save your rule to irCatalog, but I didn’t install that feature on my test system. Fortunately, inRule allows you to save to rule to a physical file and access it the same way. The rule is saved as an xml file; notice the snippet below with the condition and the notification message:
Now that the rule is created, let’s wire up a .Net app to the rule engine. First, I created a new Employee object and gave him two trips:
According to the rule, the Seattle trip should be approved, but the London trip will get a notification that executive approval is needed.
Now I’ll use a simple console app to load the rule (new FileSystemRuleApp(<rule name>);), create a new RuleSession, apply the rules, and list any notifications that were returned:
Running the app shows me the London approval message, as expected:
Since the rules are not compiled with the .Net app (but rather saved separately in irCatalog or on disk…) I can go in and modify the dollar amount that fires the notification message, click “y” to run again (without re-compiling) and immediately see new results!
Using a Decision Table
Let’s say you need to create a complicated rule that depends on several variables. In this case, we’ll decide whether to approve or deny a person’s seat selection (First Class/Coach) based on their Employee Level (Employee/Manager/Executive) and Destination (US/Europe). That’s a total of 12 possible combinations (3 * 2 * 2). In other systems you may have to use multiple nested If/Then statements, or maybe a Case statement if you’re lucky… With InRule you can create a Decision Table – a matrix showing every possible input combination and allowing you to pick a specific action for each one:
Visual Rule Flow
You are also able to control the execution flow of a rule via a visual method, similar to a Visio diagram:
Another feature I was interested in was InRule’s integration with BizTalk server. You can call InRule from BizTalk three ways:
- Create a custom, static .NET method and call it from an Expression Shape.
- Use irAdapter for BizTalk Server, a BizTalk adapter that is included with InRule.
- Generic static methods callable from the Expression shape available in InRule.
I immediately saw several advantages to using InRule over BizTalk’s built-in Business Rules Engine (BRE):
- The BRE has no If/Then/Else logic – you’re stuck using multiple nested If/Then loops.
- No source control in the BRE – you have to figure out a manual process.
- Larger footprint -you must install more components of the BizTalk Server Developer Edition just to get the Rules Editor. With InRule you have the option of only installing irAuthor.
- Don’t expect a non-technical business analyst to be able to change rules in the BRE, that’s going to require a developer.
Of course, one thing that could be considered a downside to using InRule with BizTalk is that you’re purchasing an additional product on top of your BizTalk license. But if you’re going to be working heavily with rules you’ll probably find it well worth it.
InRule was easy to set up, and I was able to create a simple rule and hook it up to a .Net application in under 20 minutes. The rule authoring seems to be simple and straightforward enough that I’d be comfortable turning it over to a non-technical business analyst. After seeing some of the power of the authoring tool and how it can integrate with BizTalk, I may try to push my bosses away from thoughts of using the BRE to using this product instead.
Technorati Tags: Review