Back to part 1.
One of the cons of the "Iterating over Input Parameters - Pattern matching using parameter navigation" approach is that the definitions blocks can become quite lengthy and repetitive if you have many related rules. To overcome this you can "shred" your data and insert it into working memory. You now no longer write your rules against parameters but instead pattern match against working memory. The rules look something like... [Continue Reading]

Back to part 1.
In this implementation we use BAL language constructs to directly pattern match against the collection that we can navigate to from the input parameter. The business rule looks something like this:
While the generated IRL looks like:
package test {
rule parameterRule {
property ilog.rules.business_name = "parameterRule";
property ilog.rules.package_name = "test";
when {
... [Continue Reading]

Back to part 1.
I often see programmers implement iteration using a ruleflow and conditional guards.
The ruleflow contains a condition node, a guard and a ruleflow task with an initial action.
2 variables are required per loop, one to store the current index in the loop, one to store the current value (AddressType in this case).
The initial action for the ruleflow task uses the current index to set the current value.
... [Continue Reading]

I spoke to two customers during IBM Impact, as well as helping an IBMer this week. They all had the same question: "How do I iterate over a collection accessible from an input parameter?" This question is fairly common for people with a procedural programming background as iteration is a mainstay of programming languages like Java/C etc. Business rules, BAL and rule engines in general strive to be more declarative hence it is not always... [Continue Reading]