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.
What did I learn from this experience? Two main things:
(1) Authoring training is not required, but it is extremely helpful. (Contact our ROAD Services group for information!)
(2) Vocabulary is awesome! It offers a way to create Business Language Rule templates. Vocabulary allows you to modularize and parameterize rules for reuse, hide potentially complex logic from business users, all while enabling them to author rules using the specific language that is meaningful to them.
Let's talk through the benefits of Vocabulary in more detail.
Ability to modularize your logic
- This is the tie-in to the “Deja Vu All Over Again” title of this post. If you find yourself essentially writing the same rule over and over again, think about using Vocabulary. Vocabulary is equivalent to using a method or function in programming. You can use the template with different parameters (placeholders) in various parts of the Rule Application, but if you ever have to change the logic of the rule, you only have to do it in one place – the Vocabulary template. The meat of the rule is the same, but the parameters can differ based on where the template is referenced.
Ability to use domain specific business language that is meaningful for your business problem
- When you define a Vocabulary template, you define the text that will display when authoring a language rule using that template. You define the placeholders and where in the Business Language text those will be placed. For example, “Add the $item$ to the order as a bonus gift” will be more meaningful and easier to author than having to say “Add Collection Member…” every time you need to perform that action.
Add Collection Member Template
Use of this template in rules
Ability to hide complex logic from less technical rule authors
- Perhaps you have a complicated rule that is cumbersome to write. You can use Vocabulary to hide the complex logic. Because you can write your own Business Language verbiage for these template, the only thing your rule authors will see when writing that language rule is the Business Language portion of the template. The messy expression part will be hidden.
Use of this template in rules
A more detailed example that shows some good uses of Vocabulary templates in action can be accessed via samples.inrule.com under Authoring Samples > Vocabulary Templates.