| Prev | Next |
Decision Service
Portions of this topic have been used verbatim or are freely adapted from the DMN Specification, which is available at: https://www.omg.org/spec/DMN. This site contains a full description of the DMN and its capabilities.
A Decision Service exposes one or more decisions from a Decision model as a reusable element, which might be invoked internally by another decision in the Decision model, or externally by a task in a BPMN process model.
When the Decision Service is called with the necessary input data and input decisions, it returns the outputs of the exposed decisions.
The Interface of a Decision Service
The interface to the Decision Service consists of:
- Input data - instances of all the input data required by the encapsulated decisions
- Input decisions - instances of the results of all the input decisions
- Output decisions - the results of evaluating (at least) all the output decisions, using the provided input decisions and input data
When the Decision Service is called with the necessary input data and input decisions, it returns the outputs of the exposed decisions.
This figure shows a Decision model that includes six decisions and three items of input data.
For DecisionService1, the:
- Output decision is {Decision1}
- Input decision is {Decision5}, and
- Input data is {InputData1}
As Decision1 requires Decision2, which is not provided to the service as input, the service must also encapsulate Decision2; therefore the encapsulated decisions are {Decision1, Decision2}.
It is obvious from the figure that Decision6, Decision3, Decision4 and InputData3 are not required by any decisions from DecisionService1. What about InputData2? Although it is required by Decision5, which is required by DecisionService1, InputData2 is actually not required by DecisionService1. This is because Decision5 is defined as the Input Decision. From the point of view of a Decision Service, we ignore any decisions or input data required by an Input Decision.
For DecisionService2, the:
- Output decision is {Decision3}
- Input decision is {Decision5}, and
- Input data is {InputData3}
As Decision3 requires Decision4, which is not provided to the service as input, the service must also encapsulate Decision4; therefore the encapsulated decisions are {Decision3, Decision4}.
It is good practice to create a separate diagram for each Decision Service. In this way, the diagram will only contain the interface elements and encapsulated decisions for the Decision Service; the elements that are not relevant will not appear on the diagram.
Modeling a Decision Service
We can create a Decision Service element from the DMN pages of the Diagram Toolbox, and toggle [output] and [encapsulated] partitions from the context menu.
You can only show an [encapsulated] partition when an [output] partition is shown.
Once the decisions and input data are put in the correct partition(s), you must run the 'Update DecisionService Interface" command from the context menu to update the model.
Important: in order for the DMN simulation to work properly, please update the Decision Service interface whenever you:
- Show/Hide the decision service partition(s)
- Add a decision to the decision service
- Remove a decision from the decision service
- Move a decision between partitions
- Add/Remove Decision Service Inputs: Input Data or Input Decisions