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

Organizing business rules into rule projects

In Rule Designer, many operations are carried out 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 a large number of business rules in your rule project, these operations become slower. The following diagram shows one rule project with two sets of business rules, Set A, and Set B.

To avoid having to manage a large number of rule artifacts in your projects, you can try to break down your application into several rule projects. These rule projects must then reference each other. The following diagram demonstrates this modular organization. Here, you work with the Set A business rule artifacts separately from the Set B business rule artifacts as they are in separate rule projects.

Organizing rule projects based on Decision Center permissions

In the Decision Center console, you can define permissions at the rule project level while defining permissions at the rule package level requires you to specify the permissions programmatically. Therefore, if you organize your rule projects according to how you plan to define permissions, you do not need to define these permissions programmatically.

By default, in Decision Center, queries, branches, and extractors only cover the current project. However, you can modify this behavior in the Decision Center console to include referenced rule projects. Deployment baselines include all referenced projects that are necessary for deployment.

Organizing the BOM into rule projects

If a set of rules uses only a part of the business object model, you can consider isolating this set of rules and the part of the business object model into a separate rule project. Then, when you work with the rules, you have visibility only on the required BOM classes.

You can also split a large BOM entry into several smaller ones for more flexibility, as illustrated in the following figure.

When you work with a very large business object model, the completion menus in the Intellirule and Guided editors can become quite large. The size can both be usability and a performance issue. To reduce the number of completion entries, and to make them more relevant to your rules, use categories. Categories are a good way to organize your vocabulary into subsets.

If you decide to use a diamond-shaped organization, as illustrated in the figure above, with a rule project that defines a ruleflow and references child rule projects, which share a single rule project for the BOM, make sure you define ruleset parameters in the rule project that contains the BOM. Be aware that if you define the same ruleset parameters in the child rule projects, these parameters appear as duplicates in the parent project.

Happy learning! Happy Exploring!!

 

Sources: