When to use decision model services

In Decision Center, you can create decision services by using one of two different, distinct approaches.

The different approaches are:
  1. The development team creates the underlying Java™ or XML model in Rule Designer, and the business expert authors the decision logic in Decision Center based on this model.
  2. The business expert creates both the model and the logic of the decision service in Decision Center. The term decision model service distinguishes this second case from the first one.
The main reason for choosing a decision model service is to make the business expert completely autonomous in:
  • Creating from scratch, maintaining, and deploying the decision service to the execution environment.
  • Editing the decision model directly by using a relatively non-technical language, with the flexibility of trying out, validating, and adjusting the model before deployment is considered.
In addition to the autonomy provided to the business expert, use the decision model service approach when:
  • You want to understand the underlying model of a decision service, in preparation for larger Operational Decision Manager projects.
  • The decisions provided by the decision service are not too complex. A general rule of thumb is a maximum of 50 nodes in the diagram.
Some other considerations for using a decision model service:

Conceptual differences

Creating a decision model service is conceptually different from the standard approach. The decision model service:
  • Starts from the final decision required and assumes that the data will be passed according to what is needed. This is different from the developer-driven model, where the final decision is made in accordance with an object model that already exists.
  • Does not use a ruleflow to control the flow of execution of rules. Instead, a decision model service makes use of a diagram to link decision and data nodes. The diagram does not represent a flow, but rather the dependencies between the final decision and all the sub-decisions and data points. The dependency links do not compete, but rather contribute to the final decision.
  • Is a functional model, with no side effects or inference. A node sees only the variables that are below it. You cannot use a rule to change these variables or those from another dependency.

See Decision modeling basics for information on how a decision model service makes use of data and decision nodes in a diagram, as it is presented to a business expert.

Differences in usage

The following table summarizes some of the main differences in how a decision model service is used:
Decision model service Description
Only the English verbalization is available. The decision model service is available in only the English locale of Decision Center.
The model is developed and maintained in the Business console. Complete autonomy for the business expert to create, maintain, test, and deploy, all from the Business console.
No synchronization with Rule Designer. The project containing the decision model service can be exported as a .zip for sharing, but is not usable in Rule Designer.
Does not use a ruleflow to control the flow of execution.

A decision model service makes use of a diagram to link decision and data nodes, which all contribute to the final decision.

Decision Center generates an empty ruleflow for integration with other Operational Decision Manager features, but the ruleflow is not visible in the Business console.
The decision model works as one versionable element.

Changes to individual business rules, decision tables, and the diagram can be consulted through the version of the decision model itself.

Test suites and simulations are versioned separately.
Cannot create a decision operation manually. The decision operation on which a deployment is based is automatically created/updated every time you save the project. The decision operation references all the rules of the decision model, and uses the input and output parameters of the diagram.
Separate users cannot modify the decision model simultaneously. The decision model is locked to other users as soon as you edit. You need to take this into account when assigning change activities.
You can validate the coherence of the project as you go. A decision model service can access an embedded engine that validates a data set.
You cannot implement dynamic domains. An important aspect of decision modeling is to create custom types, which include enumerations.
Continuous deployment. To use the Build Command on a decision model service, use the jar located in resources/xom-libraries for the xom-classpath property.
Customization and automation.

All the REST API endpoints are supported to automate rule deployment. However, the Java API is not supported for decision model services.

You should also consult the Known Limitations.