Setting up a project hierarchy

You can organize your content as a hierarchy of rule projects.

You create a hierarchy by establishing dependencies between projects. Use rule project hierarchies to separate and share the rules and the BOM among different projects, especially as your application becomes more complex. Using different rule projects allows for easier maintainability, lets you test different parts of the logic independently, and organize for various decision points. You can then set up the projects to refer to one another.

The project organization that you set up in Rule Designer also impacts how you manage these projects in Decision Center.

Table of contents

Organizing the rule project structure
Organizing the project structure for multiple rulesets

Organizing the rule project structure

Decision services are designed to facilitate the creation of the project structure. When you create a decision service, you create a main rule project that serves as the top-level project of the rule project hierarchy. If the project contains many rules, you create other types of projects to group these rules by domain and to store the BOM. Then, you set dependencies between the projects. All projects that are directly or indirectly referenced by the main project become part of the decision service. For example, a main decision project might reference two standard rule projects, which in turn both reference a project that contains the BOM. All four projects form the decision service.

You can create the different types of projects in the Decision Service Rule Project section of the New Rule Project wizard as follows:

Select Main Rule Project to create a project that is the entry point of the decision service and that might reference other projects.
Select Standard Rule Project to create one or more projects to store your rules.
Select Rule Project with a BOM to create a project to store the BOM.

Note:

It is possible to change the type of any project to transform it into a main project or vice versa, in Properties > Decision Service. You can change a rule project to a main rule project when the rule project is not referenced by another project. Changing a project can require changes to the way projects reference each other, and can affect the deployment and synchronization of the project.

In Rule Designer, many operations take place at the decision service level, such as build, queries, refactoring, and ruleset extraction. As a consequence, grouping rule projects in separate decision services limits the scope of these operations.

The following diagram shows a possible rule project organization in a decision service. The main project contains a ruleflow that uses rules from projects in the hierarchy, and the projects share a BOM that is kept in one of the projects. All four projects are part of the same decision service because rule projects 2, 3, and 4 are directly or indirectly referenced by the main rule project.

Diagram shows a simple project organization with a shared BOM in a decision service.

Organizing the project structure for multiple rulesets

If the client application calls different decision points, you should organize your project structure for multiple rulesets.

If an operation and its rules require only part of a BOM, you can keep those rules and that part of the BOM in a separate rule project hierarchy that specifies the vocabulary that is available to those rules. The size of the BOM can result in usability and performance issues. To reduce the number of completion entries in the rule editors, and to make them more relevant to your rules, use categories to organize your vocabulary into subsets.

You can package all decision operations, ruleflows, and rules in the same decision service. The following diagram shows a decision service that is designed to distribute the decision points in separate rule projects. It also shows a strategy for splitting the BOM for efficiency.