I don’t usually do a product profile unless I either really like the product and use it myself, or I’m genuinely curious about the product and what it can do for me. While I haven’t used InRule before, it does fit the latter of those criteria because of my interest in similar products I have used in the past.
A Quick Intro to my Life in Rules…
Flash back to my college years (when 5.25” floppies were king) and you’d see a young guy in an Artificial Intelligence class learning about a Knowledge Based Expert System known as CLIPS (C-Language Integrated Production System) which was developed by NASA for rules processing.
This class fascinated me, and when I got out of college I started my first job in St. Louis at a certain regional telecommunications company who would later trade in their three-letter acronym for their mother company’s “death star” logo.
Here I honed my C++ skills, and also worked more with a retail version of the CLIPS language that ran on the AIX platform for handling the aforementioned RBOC’s Order Service. Why ordering telephone service may sound trivial to you, there were myriad rules that had to be reconciled with every new order based on the region the order was placed in, distance from the central office, conflicting products on the same line, products needing to be applied to all lines, and so on.
Naturally, we were using a rules engine to process the 500+ order rules in as efficient manner as possible and they worked quite well. If there was any shortfall to using a rules-based expert system, it is that there are very few people trained in the technology or that can program well in a non-sequential form.
After a few years, I left that company for greener pastures, though I did miss working with rules engines due to the uniqueness of the opportunity. So when I heard about InRule, I decided to give it a look and see how it stacked up to what I remembered from my past experiences.
From Expert Systems to Business Rules Management Systems
Expert Systems were originally fairly closed systems that attempted to be the end-all-be-all of decision making services. They were, in essence, designed to replace or supplement human experts and didn’t tend to integrate into larger solutions easily. As such, they tended to get a bad rap, somewhat unfairly, especially when they were misused in situations that didn’t fit the need.
Business Rules Management Systems, in contrast, seek to make it easy to manage and integrate rules into a larger programming model and make it easy to author and maintain those rules. Roughly speaking, a BRMS seeks to enable a solution, instead of trying to be the solution. I know it sounds like a semantic argument, but the main point is that while both can be used to author rules, BRMSs tend to focus more on the full rules lifecycle and integrating with other components.
InRule – A .NET Business Rules Mangement System
InRule is a .NET solution for authoring, managing, and executing business rules and is a product of InRule Technologies, Inc. The InRule suite has multiple components that make for a very impressive set of applications. I won’t discuss them all in this post, but the core components I wanted to explore were:
- irAuthor – The application that makes it easy to construct rules.
- irSDK – An SDK that allows you to develop .NET applications to interact with the rules engine.
- irSever – The rules execution engine for InRule
The suite is too big to examine every product in the detail it deserves, so I’ll stick with the ones that were most relevant to my past experience so I’d have a better basis of comparison. I wanted to see how easy it was to author rules, assert facts from a C# program, run the rules, and get back the results.
Importing Entities into irAuthor
InRule gives you many ways to create entities (which form the facts) and author rules. You can either create the entities manually in irAuthor, or import them from a database schema or a .NET assembly. Given the C# developer that I am, I opted to take this approach, and create my entities using a .NET Assembly.
So let’s say we’re going to make a stock market order processing service. So, let’s define some POCOs to be our entities to import into the rules.
First, we’ll define a Security to represent a stock, bond, mutual fund, etc.:
1: public sealed class Security
2: {
3: public string Symbol { get; set; }
4: public double CurrentPrice { get; set; }
5: }
Then, we’ll define a Position to represent a holding of a particular security for an Account:
1: public sealed class Position
2: {
3: public Security Security { get; set; }
4: public double PurchasedPrice { get; set; }
5: public int Quantity { get; set; }
6: }
Then, we’ll define an Order to represent buying or selling a Security to either increase or decrease a Position:
1: public enum OrderAction
2: {
3: Unknown,
4: Buy,
5: Sell
6: }
7:
8: public sealed class Order
9: {
10: public string OrderId { get; set; }
11: public OrderAction Action { get; set; }
12: public Security Security { get; set; }
13: public int Quantity { get; set; }
14: }
Finally, we can define an Account which ties together what securities a person already owns (Positions), how much money they have (Equity), and any pending orders that have yet to complete (OpenOrders):
1: public sealed class Order
2: {
3: public Account Account { get; set; }
4: public string OrderId { get; set; }
5: public OrderAction Action { get; set; }
6: public Security Security { get; set; }
7: public int Quantity { get; set; }
8: }
Seems pretty straightforward. Not adding any advanced logic here, these are just simple POCOs (Plain Old CLR Objects) to be containers of data.
So, let’s fire up irAuthor and import these entities. When you start irAuthor, you get the option of loading a rules application from file, database, or create a new one. We’ll go ahead and create a new one which will give us a blank canvas to create new entities, or import some:
We’ll name our rules applicat IrRulesTest (yes, I’m creative today). From here, we can use the [+] to add new entities if we wanted (such as Entity1 above, or right click on the entity to add new fields, calculations, or collections. A field is just a basic piece of data attached to an entity (like a property or field in .NET), a calculation is a calculated value as opposed to a value you set directly, and a collection allows you to specify relationships between entities.
So we’ll click on the [Import] button in the upper right of the ribbon:
Which gives us a properties page to use to fill out data on our assembly to import. The import process will read a class library and attempt to find any public classes in it, and then give you the option as to which entities (and which fields per entities) you’d like to import:
This is a lot like defining a proxy to a web service, in that whenever the entities change in the .NET source, you’d you need to use the [Reload] button to get the entities back in sync. Once we’re done, we hit the [Apply] button and our entities have been imported!
Now that these entities are imported, we can begin authoring some basic rules.
Adding Rules to irAuthor
Once we have our entities defined, we can begin creating rules that either operate on just the entities (Entity Rule Sets), operate on relationships between entities (Context Rule Sets), or rules that operate independently from the entities (Independent Rule Sets).
So let’s start with some entity rules to verify that the entities are correct. For example, we could add a rule to Order to make sure that the Symbol field is not blank. We do this by selecting the Order entity in the navigator, and then clicking on the Create Rules for this Entity link:
This will create a Rule Set under the Order entity, which we can then add rules to. Once we create the Rule Set, we rename it appropriately (say, to MustSpecifySymbol) and then click on the [+] button to add a rule to this Rule Set. For the first rule, we’ll explore the Language Rule format, which reminds me most of working with rules in CLIPS (though without the Lisp-ish format):
The great thing about rules authoring in InRule is how easy it is to formulate your rules. When I used to write rules in CLIPS, it was very much a programmer’s language in the order of Scheme or Lisp right down to prefix operations. With InRule, however, it gives you very easy to understand constructs where you select the best template, then click on the parts to begin building your actions visually.
By clicking on [build condition], then selecting Security, the context then changes to allow me to select fields from Security. After selecting Symbol from Security, the context changes to show me operations I can then perform, including a handy check for “is null or empty”:
So now I have my If condition filled out, I can now either add more conditions (by default multiple conditions are all AND-ed together unless you explicitly specify an OR), or I can move on to an action to take, which could either be to generate an error message, or perhaps to fill in a field. In this case, if Symbol is null, we will add an error message.
For your Then actions, you can specify many actions from executing database commands, the executing other rule sets, to sending emails, etc.:
Because this rule is a validation, we will use it to fire a notification which will give a message that the data is invalid:
Okay! We can go ahead and add more rules to validate our other entities as well, then we can move on to rules that actually do more complex, inter-entity checking. Let’s say that when an order is placed, if the order is a buy order, we want to make sure the quantity of shares times the current price for the security are less than the existing equity in the account.
If there is sufficient equity, it will deduct the equity and put the order into the open orders collection in the account, otherwise we’ll get a notification. Complex rules such as this are easy to build using the context-sensitive rules builder, so we’ll build a pair of rules, one that modifies the equity if the order is good, and one that prints a warning if not.
And so on, using this pretty intuitive rules builder, we could easily allow developers or even business analysts to author the rules.
Testing the rules in irVerify
We can [Verify] our rules from the toolbar of irAuthor which will show us if there are any errors in rule construction, then click on the [Test] button to bring up irVerify. Here we can add sample data and [Apply Rules] and see the results.
As you can see from this run, our rule to make sure the Symbol is not blank triggered. We can also make sure that our validation for equity triggers on buy orders, but not on sell orders and so on.
In addition, there is a Rule Engine Feedback tab which is handy for seeing the rule activiations. I love this tab because it reminds me of the CLIPS rules tracing files where you can see when conditions trigger on each of your rule and then when the rules fire.
Keep in mind that Rules Engines keep track of all the rule conditions and evaluate the conditions as affecting facts change to see if a rule is satisfied or not. Once all the conditions of a rule are satisfied, it may fire.
Putting it all together – invoking rules from InRule SDK
So, let’s say we’ve gone through and implemented all of our rules, and we wish to execute them on a series of entities in our program. This is actually very easy to do using InRule’s .NET SDK.
So, let’s assume we have some method for getting the next order to be processed (either via a queue, web service, database call, etc.). For the purposes of this call we’ll just return some canned data:
1: public static IEnumerable<Order> GetOrders()
2: {
3: return new Order[]
4: {
5: // order with equity issue
6: new Order
7: {
8: Account = new Account { AccountId = "11111333", Equity = 5000 },
9: OrderId = "1313",
10: Action = OrderAction.Buy,
11: Quantity = 1000,
12: Security = new Security { Symbol = "ZZZ", CurrentPrice = 50.0 }
13: },
14:
15: // order with null security
16: new Order { OrderId = "2222", Action = OrderAction.Sell, Quantity = 2000 }
17: };
18: }
Now, we can invoke the rules engine in our program to run the rules against the order. All we need to do is to reference the InRules.Common.DLL and the InRules.Runtime.DLL and to load our rules, and start a rules session:
1: var rulesEngine = new InRule.Runtime.FileSystemRuleApp("InRulestest.ruleapp");
2:
3: // sesions are IDisposable, so use in using blocks or remember to Dispose()
4: using (var session = new InRule.Runtime.RuleSession(rulesEngine))
5: {
6: // load entities into the engine
7: foreach (var order in GetOrders())
8: {
9: session.CreateEntity("Order", order);
10: }
11:
12: // apply the rules
13: var result = session.ApplyRules();
14:
15: // get any notifications
16: foreach (var message in session.State.GetActiveNotifications())
17: {
18: Console.WriteLine("Notification: {0}", message.Message);
19: }
20: }
As you can see, executing the rules against these two entities gives us the expected errors:
Obviously, this is a fairly simple example, but it gives you an idea of how you can separate your business rules from your application to allow them to be easily maintained and modified by business analysts.
Summary
InRule is a Business Rules Management System with a very intuitive, easy-to-use authoring system which makes it easy for developers or even business analysts to create rules to be applied against a system. The tools that come with InRule are very extensive and intuitive, it was fairly simple for me to hop in and produce a sample application with very little time studying the product.
In addition, the choice of different rule repositories, the integration with databases and web services, and the debugging and verification tools make InRule a very complete system.
This is a good solution for application development shops where there are an extensive number of business rules that need to be applied to application entities. Situations like this where maintaining the business rules can become hard to manage in traditional code structures would benefit most from InRule.