Throughout our new book 'the Microguide to Process and Decision Modeling in DMN and BPMN' we treat DMN as an integral notation for process modeling in BPMN. Even though decision model notation is a separate domain within the OMG, the DMN spec provides an explicit way to connect to processes in BPMN. DMN provides a schema model in XML format that includes two connection points. First, there is an explicit list that denotes the processes and tasks that use the decisions. Next, DMN provides an input and output data type that implicitly corresponds to the rule activity that invokes the knowledge bases of the decision.
In table 7 of the proposed Decision Model and Notation (DMN) Specification, the class model for the decision defines the BPMN processes and tasks that require the decision to be made (usingProcesses and usingTasks).
Appendix B of the DMN specification says:
“The interface to the decision service will consist of:
- Input: a list of contexts, providing instances of all the Input Data required by the encapsulated decisions
- Output: a context, providing (at least) the results of evaluating all the decisions in the minimal output set, using the provided instance data.
When the service is called, providing the input, it returns the output.
In its simplest form a decision service would always evaluate all decisions in the encapsulation set and return all the results.”
Here we are assuming that the decision is created by business rules from input processes and accessed through a decision service. Other decision can be manual or can require user input. The business rule task shape can denote the place within the process model that calls up a DMN model with the needed input and obtains the decision output.
As seen in the figure below, most DMN decision modelers utilize the rule shape to denote a connection to DMN. The inputs of a rule task are processed by the logic defined in the DMN model and then output for use in downstream gateways, participants, events and activities.
The customer is the input for the decision and the output is the customer discount. The process in the diagram can be made explicit according to the execution semantics. The figure shows the usage of the message shape. The association lines (dotted) are used to create the relationship between the message and the data type that is used in the process schema. When decision for a customer discount is requested a customer message is sent to the decision service. This is an initiating message, so the envelope is white. After the decision is completed, the BRMS returns the customer discount. The message is shown as a non-initiating message with light shading.
To summarize: the DMN spec explicitly defines how a BPMN process is connected to the decision through the usingProcesses and usingTasks metadata for the decision shape. The input and output are attributes of the decision and created by expressions and decision table. (more on that latter).