When I first used irAuthor to solve a business problem (before I worked for InRule), I had not attended any rule authoring training. I received a "sample" Rule Application from a developer so I could use that as a template (I was writing rules that were very similar but differed slightly for each U.S. state). I put "sample" in quotes because the dang thing didn't even compile. The Rule Application had an Entity structure and one User Defined Function (UDF). I merrily went about my way creating about 50 UDFs for my rules, varying them all slightly based on the template. I tested my rules, and called my project complete.
Thankfully, a different developer who was familiar with InRule caught wind of this "All UDF" monstrosity and raised a red flag. He noted that some of the main reasons to use InRule are so that non-developers can read, understand and update the rules. Duh! UDFs can get the job done and are great when you want to write a rule that can't be written in Syntax or Business Language (BL), but they look and feel like code and should really only be used when Syntax or BL doesn't cut it. So, I had the pleasure of refactoring all of my rules. It was annoying for sure, but in the end I'm very glad I did.
For some reason, it became more obvious to me during the refactoring effort that I seemed to be writing the same rule over and over again. Was I just having a bad case of deja vu? No. I needed to modularize my logic, and the answer was Vocabulary.
I wished I had some better training up front because I would have more thoughtfully planned out my rule organization. I refactored it as much as time permitted and moved on. Now I have more empathy when I hear developers talk about refactoring and technical debt.
The bottom line? Well, I guess there are two:
(1) Authoring training is not required, but it is extremely helpful. (Contact our ROAD Services group for information!)
(2) Vocabulary templates are awesome. They allow you to modularize and parameterize rules for re-use, hide potentially complex logic from business users, all while enabling them to author rules using the specific language that is meaningful to them.
Here is a very simple example of how I used this in my refactored Rule Application.
I kept writing a long, unwieldy rule within my if conditions to check for errors. "If no members exist in Exceptions filtered by ExceptionType is equal to "Error""... Ick.
So, I hid that boolean expression behind a Vocabulary template and allowed business users to write "If there are errors, then ...." Much more readable and easy. Plus, if I ever have to refactor that rule, I do it in only one place, not many!
Here is another example of a template, where I'm using Placeholders to allow the user to input parameters which impact the rule.
In this case, the meat of the rule is the same, but some variables differ based on where the template is referenced.
A more detailed example that shows some good uses of Vocabulary in action can be accessed via the Support Site under the "Vocabulary Template Examples" zip.