Five Things I’ve Learned About InRule


ROAD Services + Support Teams


It only seems like an eye blink since that day in November when I first walked into InRule’s Chicago offices as a newly minted InRulian. At first, I thought I’d be overwhelmed by the number of different things to learn and patterns to recognize in this completely new product, but I quickly found that learning InRule isn’t as complicated as I had feared. Just like any even moderately complex piece of software, InRule has its own nuances that need to be mastered as part of effectively using the product.

The assistance and support of the other ROAD team members helped me greatly in these first few months, and since no one else can *possibly* be as lucky as I in having colleagues as generous, intelligent, and dedicated, I thought I’d share (in no particular order) with other folks just getting started with the InRule product offerings some of my hard-earned nuggets of knowledge.

    1. Treat irAuthor like an IDE (Integrated Development Environment), because that is what it is. irAuthor is the IDE, and the rule application is the program created using the IDE. By the same token, don’t forget to make use of irVerify. It’s an incredibly powerful tool for exercising a rule application. Bottom line: coding is coding, and rule applications are code. All the same concepts apply even though things may look different. Consider the intention that you want to express in a rule application as if you were writing a regular ol’ C# program to perform the task, then find equivalent ways to express your logic.
    2. Understand the entity context your ruleset is operating under. Rules are generally authored against entities (exception: independent rulesets, a different topic), but when object graphs have multiple entities referring to each other as properties or in collections, it can be tough to know what object a particular ruleset operates against. Figure 1 (below) shows a side-by-side of the rules and entity schema in a simple setup which demonstrates this concept. Note the dotted path notation of RootEntity.ChildProp3. 
    3. Know the tools in your toolbox. Here’s a table that maps some top-level concepts to familiar programming terms. It’s a loose mapping, so you should not take this literally.
    4. Anything that irAuthor can do, the SDK can do, as well. Want to validate and compile a rule application in your integration code? No problem. Use this code snippet:
      const string RuleAppFileName = @"< put path to rule app here >";        
      var ruleAppRef = new FileSystemRuleApplicationReference(RuleAppFileName); // or catalog, inmemory, etc...
      var def = ruleAppRef.GetRuleApplicationDef();
      var validationErrors = def.Validate();
      var compileErrors = new List();
      try {
      catch (CompileException cex) {
      compileErrors.AddRange(cex.Errors); // capture the compilation error details
      foreach (var cErr in compileErrors) {
    5. With great power comes responsibility AND complexity: no one should expect to become a Rules Master (a term I just made up) without a little bit of help from their friends. Don’t be afraid to ask if you don’t know something. This may be the most helpful tip of them all. The team at InRule is one of the most competent, intelligent, and responsive teams around, and we’re all more than willing to help someone get to the bottom of their particular issue. Have a problem? Post on InRule’s Support Forums (login required: talk to your company’s designated InRule support person for access or send an email to our support team – directly (

I realized when I was writing this that I could probably make an endless list containing infinite amounts of advice. The possibilities that InRule unlocks are only limited by the scope of the rule author’s imagination. My time and attention, unfortunately, are not infinite, so I am cutting this list short here.

What types of things have YOU learned about InRule that you think may help someone just getting the hang of the product?