Setting up a project hierarchy

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

You can use rule project hierarchies to spread 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.

Also, in Decision Center, branches or releases apply to all the projects in the hierarchy. Organizing an efficient project hierarchy allows for management of rule change and deployment according to specific projects.

Organizing the rule project structure

To avoid having to manage numerous business rules in one project, spread the rules among several rule projects. You can then set up the projects to refer to one another.

To do this, create the different types of projects in the Decision Service Rule Project section of the New Rule Project wizard as follows:

Select Rule Project with a BOM to create a project to store the BOM.
Select Standard Rule Project to create one or more projects to store your rules.

Note: For classic rule projects, use the Classic Rule Project section of the New Rule Project wizard

Then, define the hierarchy between the projects.

For classic rule projects, set dependent projects on the Project References tab of the Rule Project Properties dialog.

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 of the rule project hierarchy, by selecting Main Rule Project from the New Rule Project wizard. The wizard has a step to establish the dependencies with the other projects.

Note:

It is possible to change the type of a project to upgrade a rule project or downgrade a main rule project, 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.

The following diagram shows a diamond-shaped organization with a top-level main project and two dependent rule projects that are linked to the BOM project:

Diagram shows a diamond-shaped project organization.

In a diamond-shaped rule project organization, the top project contains a ruleflow that uses rule from projects in the hierarchy, and the projects share a BOM that is kept in one of the projects.

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. Rule Designer performs better with this diamond-shaped organization.

Organizing the project structure for multiple rulesets

If the client application calls different decision points, you should organize your project structure for multiple rulesets. Package each decision operation and its ruleflow, along with its unique rules, in a project that does a specific task.

Also, 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.

The following diagram shows a decision service designed to distribute the decision points in separate rule projects. It also shows a strategy for splitting the BOM for efficiency.

The following diagram shows how to set up classic rule projects to obtain the same results: