It’s been a couple of days since I’ve begun the Unit 6. Authoring rules of the ZB300 Developing Business Rule Applications with IBM WebSphere ILOG JRules V7.0 course, however I am still digesting its content and am following it over and over again. Perhaps it’s my…no, it’s indeed my 11th take (!) if the screenshot tells me right.
I think it’s now easier for me to say what ILOG JRules can and cannot do. I feel I fully grasped the differences between XOM and BOM and technical vs business rules. No more scratching my head when I hear IRL, vocabulary, verbalization or such. It’s getting easier to work with the software as the time progresses. I think the time I’ve spent on my learning pays off very well. I may even provide the ZB300 course for a customer (you hear it right).
The unit 6. Authoring rules is right on time in which rule artifacts are fully explained…finally. Even if I faced troubles understanding the innerworkings of ILOG JRules and Rule Studio, the unit 6 wraps it all up so the pain’s over. Very well laid down. Nothing left out and out of the sudden everything seems so easy 🙂 I do like the feeeling (and wish you could feel it some day). The notes are sparse.
BOM and vocabulary lay down a foundation for rule artifacts from which (business) rules are developed/built upon.
There’re two kinds of rule artifacts – technical and business ones.
Technical rules are written in ILOG Rule Language (IRL) and the group consists of technical rules, functions, ruleflows, ruleset variables and ruleset parameters. If you think about technical rules as decision services which accept input parameters (ruleset parameters – IN, OUT or IN_OUT), which work on rule variables (local variables) orchestrated as ruleflows, you’ll get the picture. I like thinking about technical rules as small applications (perhaps functions). Nothing unusual for newcomers if they’re Java programmers.
Technical rules are based upon Business Object Model (BOM).
Business rules are written in Business Access Language (BAL) and the group consists of business rule, decision table and decision tree. The constructs are more business people-oriented. They’re based upon vocabulary.
Business and technical rules use rule set variables and parameters.
There are some other supporting features like business rule template and queries, and are used for ease rule development, be it in Rule Studio (developers) or Team Server (more business-oriented people).
You use Rule Studio as a primary development environment, however Rule Team Server (RTS) and Rule Solution for Office offer similar development functionality for business users.
A business-oriented people use RTS to transform/turn business policies into business rules. A rule developer with Rule Studio can create a rule project off the one created in RTS.
To distill rules from business policies (recommended approach) you first discover, analyze, author and eventually deploy them to execution environment – Rule Execution Server (RES).
BAL (Business Action Language) is a kind of a natural language and is used to write rules, decision tables and trees. They can also be written in ILOG Rule Language (IRL) – a rule implementation language. BAL translated into IRL at Rule Engine runtime.
You use BAL while authoring rules whereas IRL is used behind the scenes at runtime. You can write rules in IRL directly.
Rule artifacts work on business data: rule set params, variables and objects in working memory
Rule set parameters are specified as a rule project property; manipulated in IRL by name and in BAL by their verbalization
Rule set variables are a means to exchange data between rules and rule flow tasks; grouped into variable sets; manipulated by name in IRL and by verbalization in BAL.
Rule vars defined in definitions section of business rule and used only within a scope of a defining rule.
Something worth remembering (so repeating it here): member verbalization of a setter is an action whereas of a getter is a navigation. Nothing unusual once you’ve gotten used to it, isn’t it?
While doing the ZB300 course’s opening workshop decision tables in ILOG JRules posed a big challenge to me. It doesn’t take long to consider the workshop a must for anyone wishing to become JRules pro. When I had to create a decision table and a business rule for the first time switching between workspaces – mine and the solution’s – was very productive. I could compare the solution and my attempts very easily and fix errors as I went on.
As an aside note: just announced – IBM WebSphere ILOG Business Rule Management Systems V7.1 offers new capabilities for authoring, managing, and deploying automated decision logic. A month away before ILOG JRules V7.1 goes public.