In preparing to write this blog post, I did some research on the internet and learned that a blog post should be somewhere between 400-600 words. That got me wondering what the word count was for my previous (and first ever) blog post. I felt at the time that it was a bit too long.
I opened up the blog post in Microsoft Word, and confirmed my suspected verbosity, by using a nifty little feature called “Word Count”:
Wouldn’t it be nice to have a similar type of “Word Count” feature in InRule? But instead of showing the total number of components that make up a document (i.e. words, characters, paragraphs, etc.), it would show the total number of components used in a rule application (i.e. entities, fields, rule sets, language rules, syntax rules, etc.).
Introducing…. The Rule App Analyzer!
Although this feature is not built into irAuthor, I have taken advantage of the extensibility of irAuthor to write an irAuthor extension called the Rule App Analyzer. This extension adds a new button to irAuthor’s home ribbon, which when clicked, lists out the total count for each type of component that makes up a rule application.
I have uploaded this extension (including the source code) to our ExtensionExchange™, which is accessible from the home page of the InRule Support website. You can visit this page to download this and many other irAuthor extensions that we have created. If you have access to the InRule Support website, we would encourage you to try these out.
If you want to learn more about irAuthor extensibility, check out Jeff Key’s “Extensibility Overview” blog series, as well as the “Customizing irAuthor with Extensions” section of the InRule SDK Developer guide.
Before I demonstrate the Rule App Analyzer, I will briefly explain how it works.
InRule’s Authoring API
In addition to creating, maintaining, and navigating through rule applications using irAuthor, developers have the option to use irSDK, which is the InRule API and includes both authoring and runtime libraries.
Each component in InRule has a corresponding class, which defines the properties and methods of that component. For example, the class for the rule application definition is the RuleApplicationDef, and it contains a collection of entities, each of which is an EntityDef. Each EntityDef contains a collection of fields, each of which is a FieldDef.
Here is a simple example that shows how to list all of the entities and fields from the CustomerInvoice sample rule app:
static void Main(string args)
RuleApplicationDef ruleAppDef = RuleApplicationDef.Load(@"C:\Temp\CustomerInvoice.ruleapp");
foreach (EntityDef entityDef in ruleAppDef.Entities)
Console.WriteLine("Entity " + entityDef.Name);
foreach (FieldDef fieldDef in entityDef.Fields)
Console.WriteLine(" - Field " + fieldDef.Name);
- Field CustID
- Field CustName
- Field SubTotal
- Field Tax
- Field Total
- Field LineItems
- Field ProductID
- Field ProductName
- Field Quantity
- Field UnitPrice
- Field LineItemTotal
The Rule App Analyzer also makes use of the same authoring API, by instantiating a RuleApplicationDef, and then recursively navigating through all of its children Def’s (i.e. EntityDef, FieldDef, RuleSetDef, etc.).
Demonstration of the Rule App Analyzer
After copying the Rule App Analyzer DLL into irAuthor’s extension folder, I launched irAuthor, opened the CustomerInvoice sample rule app, and there is now a new button added to the home ribbon:
Clicking that button runs the Rule App Analyzer and opens up a dialog windows with the results:
The Rule App Analyzer just scratches the surface on the kinds of rule application interrogation and analysis that can be done using the irSDK. For example, we could add additional stats to show which data types are being used, or how many explicit versus auto rule sets there are.
Let us know if there is anything in particular that you would like to see added to the Rule App Analyzer.