Rules & Rule Sets
Consistent rule layout.
The way rules are layout in a rule set is a matter of preference. There is no "best" style that everyone should be following.
The best style is a consistent style.
If you are part of a team or if you are contributing to a project, you should follow the existing style that is being used in that project.
Avoid overly complex & large rule sets.
As a rule of thumb, rule sets should not have more than a dozen rules in them, for the sake of clarity and readability.
Modularize rule sets
Keep your rule sets modularized and specialized. It is tempting and easy to write one rule set that does everything. However, as you extend the functionality you will find that you do the same things in several sequences of rules.
To prevent that, make sure to write smaller, generic helper rule sets that fulfil one specific task rather than do all tasks.
At a later stage, you can also expose these rule sets to other repositories.
Rule sets can also be extended by new rule sets that include them and add more functionality. Well-designed rule sets should be easy to extend without redesigning the core.
Reusability
A sequence of rules that achieve the same outcome should not exist multiple times. These repeatable rules should be grouped into rule sets, where the same logic can easily be reapplied.
Parameterized included rule sets (rule sets as extensions) are advised, as they are similar to the X Agent’s rules in that they have clearly defined input/output parameters and can be included in other repositories for reuse.
Below is an example of a parameterized include rule set (rule sets as extensions).
You can access the input/output parameters under the “Rule Info” tab, on the left pane of a rule set page.
Rule set exit rules
Exit rules in any given rule set determine what chain points will be available for that rule set when it is embedded into another page.
Exit rules for success and failure should be included in rule sets for error handling and easier debugging.
The below example shows checks the user’s status and appropriately exits either with success or failure.
Below you can see the resulting chain points “OK” and “Fail”, of the “CheckUser.xml” rule set that is included in the “ProcessLogon” rule set.
Platform Independent
The goal is interoperability. Operating system, database or environment specific logic like the usage of AutoID in MySQL, for example, should be avoided.
The “Next Number” rule creates cross platform next numbers
The environment to which we have deployed your solution should be irrelevant to the rules.
Error handling
Error handling logic should be incorporated in the rule set flow, and ideally a single rule set should handle and output all errors, with appropriate error identifiers/messages.
Optimize Loops
Loops can get unnecessarily slow if you’re doing things in them that could be done one time before entering the loop. Like setting a variable in a loop whose value doesn’t change.
If possible, computation-heavy code should be kept outside of loops.
Native rules
Only use rules (extensions) that are available and supported within Tomorrow Software.
Last updated
