In 2015 we introduced the decision service project in ODM v8.8.
With release v8.10 ODM is now mostly focusing on the decision service project and the Business Console is dedicated to managing this new type of project.
Not familiar with the Business Console yet see the side by side comparison with the Enterprise Console.

If you have not yet made the move to decision services, it is time to consider it.

Decision service vs decision engine

It is important to realize decision engine and decision service are not the same thing.
A decision service is a type of rule project that can be used to generate a ruleset. This ruleset is either using the classic rule engine or the decision engine. If you want to know more about decision engine you can start here.
It is recommended to upgrade your engine and make use of the decision engine. However, the recommendation is to not perform both conversion at the same time so that you can verify after each step that your rules continue to work as expected. The suggestion is to convert your classic rule projects into decision services and once you are satisfied with this transformation, proceed with changing the classic rule engine to decision engine.

What is a decision service and why use it?

The decision service shows explicitly the relation between projects, there is one main decision service that can reference standard rule projects. The main decision service is the project that you synchronize and manage. The referenced projects are included automatically in the synchronization and branch management. It makes the project organization visible and simpler.
For example this the decision service AutoQuote that depends on the following projects: AutoinsuranceQuotingBOM, DataValidation, Eligibility and Pricing.

The decision service allows to describe the ruleset that is going to be generated.
In the Classic Rule Project the ruleset definition is mostly hidden:

• Ruleset parameters, extractors and properties are defined in the rule project properties.
• Ruleset parameters inherited from sub projects are convenient for sharing but difficult to maintain.
• The main ruleflow is a property of the ruleflow.
  
  With a classic rule project you see this and it is only accessible in Rule Designer
• 

Furthermore the decision service contains the ruleapp definition itself. For classic a rule project you had to create a different project with no direct relation with the rule project. This ruleapp project could not be synchronized with the Decision Center.

This is what you have in Rule Designer and need to recreate in Decision Center

The decision service project is an extended rule project that brings two new artifacts: the decision operation to manage the ruleset and the deployment configuration to describe the ruleapp definition. As business artifacts they can be edited in Rule Designer as well as in Decision Center.

The decision operation

In a Decision Service you can edit a decision operation, this is possible both from Rule Designer and Decision Center


The decision operation is the definition of the ruleset. You can select what is the source project, the main ruleflow and which parameters this ruleset uses.
The source project is the top project that contains the rule artifacts you need in your ruleset. It can be the main decision service or a sub project depending on your project architecture.
The main ruleflow is any ruleflow that is accessible from the source project.
In the decision service you write your rules using variables defined in variable sets. Then in the decision operation you select the variables you need to expose as parameters and their direction. They will define the signature of the ruleset.

You can already see the flexibility: the same decision service may contain multiple decision operations so in effect multiple rulesets!
You can create test rulesets, and define different executions based on the same rules and different ruleflows.
You can change the signature of the rulesets by selecting the variables you wan to expose as parameters directly in the operation.

The deployment configuration

In a decision service  you create a deployment configuration to define your ruleapp


The deployment configuration is used to assemble one or more decision operations into a ruleapp. It is synchronized with Decision Center.
In the same decision service, you are able to create many deployment configurations and you can specify on which Rule Execution Server each will be deployed, giving you the flexibility you need for creating development ,testing and production ruleapp directly in the Business Console.

Summary

Comparing side by side how you can define your ruleset in a classic rule project and a decision service.

What’s next?

I hope you now see the value in the decision service and are ready to convert your Rule Projects.

Still wondering about the migration, read this guide

Ready to convert your projects you can start here

If you have already converted your classic rule projects  and found more advantages to the switch I would love to hear from you!