If I change the alias being used in a rule statement, does it change the way Corticon would loop through the rules or the order in which it would execute the rules ? I found some discrepancies and hence wanted to confirm.
The Dependency Graph will show you the logical dependencies of the data used in the Rulesheet. This is different than the Execution Sequence Diagram (also available in the RS menu) in that it does not show the sequence of rule execution. Corticon will use this dependency network to figure out how to optimally run the rules by respecting all dependencies. Rules are defined declaratively in Corticon. In other words, the order in which they are defined by the rule author in the rulesheet doesn't matter. It is the Corticon engine that sequences how the rules are being run. Take a look at attached screenshot. Rule 1 is actually executed last as Corticon first needs to do a risk assessment BEFORE being able to calculate the price based on risk. I hope this clarifies.
If you are not changing the rules, changing aliases in rule statements shouldn't change the execution order UNLESS it causes a change in the dependencies between the rules. This might affect the order in which they are executed. Please have a look at the dependency diagram before and after you change the aliases in your rule statements (Menu: Rulesheet --> Logical Analysis). Please
Thank you for the help Harold. In the answer above what is exactly meant by changes in dependencies between the rules ? Is it something related to the entity hierarchy getting updated/added or does it relate to which actions should be completed before posting the message for which the alias has been changed ?
When Corticon has a rule that operates on a collection of objects it is free to process those objects in any order it chooses.That means if a rule is run several times it may choose a different order to process the objects each time.
Depending on how the rules are written that could cause you to get a different result each time.
This is different from the way java processes elements in a list or array.When explicitly iterating through a list in java , we always get the elements in predictable order.
Sometimes , it is necessary to process the elements in a particular order , for example we may want to fill customer orders in date order (oldest first). In such circumstances orderBy operator can be used to sort the collection in conjunction with the ->next operator to process the elements in order.
(Note that the rulesheet will be set to iterate , so if there are 10 elements in the collection, the rule sheet will be executed 10 times ,once for each element , in the order specified. )
The normal behavior for a rulesheet is to execute once, but process all the elements of the collection in an arbitrary order. Each rule in the rule sheet will examine ALL instances to see if it applies before moving on to the next rule.
Corticon does not process each instance through all the rules in a rule sheet before moving to the next instance (unless ->next is used).Even the order of application of the rules is chosen by Corticon based on the dependencies between the rules.
The Execution Sequence Diagram (under Rulesheet --->Logical Analysis) gives the order Corticon has chosen. Usually it will be the order in which the rules are written but not always.Modifying the rules may change the order in which Corticon tries them, though Corticon does not arbitrarily change the order of the rules from execution to execution.
So in Corticon what is called a collection is actually an unordered set .There should be no expectation that the engine will process the members of a collection in the same order every time unless we enforce the order in our rules. Use of a sorted alias and ->next is one way (Rulesheet iteration) to do this, using advanced inferencing (rule looping) is another.
One other outcome of switching aliases is that you might get a rule to fire multiple times. For a collection containing 3 items, if you have 2 aliases and reference alias1 in a condition or action and reference alias2 in the rule statement you most likely see the rule fire 9 times. This is the cross product of the two aliases. This might cause an issue if you are doing any type of increment/decrement logic in your actions.
Also know that you may have different filters applied to the multiple aliases, and this could also cause unexpected behavior.