Performance Improvement Guideline
– IBM ODM
This document basically highlights the various parameter configurations which when set optimally, maximum benefit and performance can be expected from the same.
Components & Parameters Consideration
- The XOM is the model used to execute the rules.
- You can build the XOM from different data sources.
- The execution object model (XOM) is the model against which you run rules. It references the application objects and data, and is the base implementation of the business object model (BOM). Rule projects reference the XOM.
- Through the XOM, the rule engine can access application objects and methods, which can be Java™ objects, XML data, or data from other sources. At run time, rules that were written against the BOM are run against the XOM.
- JAVA XOM provided better performance and scalability
- XML XOM is easy to use
- When we import XOM ensure only the classes which supports the rules execution to be imported against the whole application as such
- Business Object Model
- Every BOM element (business element) must have a corresponding XOM element (execution element).
- The correspondence between execution elements and business elements does not need to be one-to-one.
- If a business element originates from an execution element, you do not need to specify an explicit mapping.
- If a business element does not originate from an execution element, you must specify a BOM-to-XOM mapping.
- Some internal rules exist for the implicit BOM-to-XOM mapping when you generate a BOM from a XOM.
- BOM and VOC should be limited for quick rule suggestions
- If Reteplus is selected as preferred algorithm, then do limit the usage of “Update Object State” property
- Diamond-Shaped Organization of rules will help better readability, maintenance and performance as well
- By organizing your rule application as modular rule projects, you can improve the performance of Rule Designer for large rule applications, and facilitate the assignment of permissions in Decision Center.
- To avoid having to manage many rule artifacts in your projects, try to break down your application into several rule projects.
- These rule projects must then reference each other. If possible, distribute the rule projects between multiple workspaces.
- Divide the business object model (BOM) among the multiple rule projects. Start the build process incrementally for each project, instead of building them all at the same time.
- In Rule Designer, many operations take place at the rule project level, such as build, queries, refactoring, and ruleset extraction.
- Other operations, such as Content Assist and debugging, require browsing through all the rule project items. If you have many business rules in your rule project, these operations become slower.
- If you decide to use a diamond-shaped organization, make sure that you define the ruleset parameters in the rule project that contains the BOM: if you define the same ruleset parameters in the child rule projects, these parameters appear as duplicates in the parent project
- Orchestration of rules are achieved using ruleflows
- With Classical Rule Engine ruleflows are interpreted so it would be good to limit the size and complexity of ruleflows
- Limit the usage of dynamic filter in rule tasks, Use static list of rules instead
- Preferably use single algorithm throughout and avoid different algorithms to save memory
- Based on the logic to be executed, selection of rule engine plays a vital role in performance
- Better for Rule Chaining
- Use when we have small number of rules with many objects scenario
- Performance is impacted by number of rules present
- Use when we have more number of rules with less objects
- Efficient in multi-threaded applications
- Default algorithm after ODM 8.7
- Use when we have more rules and more number of objects
- Faster at run-time
- More efficient in multithreaded applications
- Optimal for decision table
- Easily scalable when the number of rules increases
- IBM ODM Documentation
- Performance Reports on ODM