Modeling Decision Services

The Decision Services button on the DMN ribbon presents the Decision Service Wizard. This is the preferred way to define a properly configured decision service.

Here you see the wizard definition for the Whole Model Decision Service. When defining a service manually, you begin by selecting the Output Decisions from a list of all decisions in the model. The wizard populates the Input list with the information requirements of the Output Decisions. Typically these include decisions, not just input data. You can then selectively promote Inputs to Encapsulated Decisions and the wizard then recalculates the Input list. You can repeatedly promote Inputs to Encapsulated until all Inputs are input data… but this is not required. You may want to test a fragment of the model by supplying values of the direct information requirements rather than input data. The promotion mechanism in the wizard also lets you move decisions from Encapsulated to either Output or Input. Using the wizard ensures that all of the Encapsulated Decisions for a selected set of Output Decisions and Inputs are listed correctly.

When the service contains multiple Output Decisions, the value is a structure containing those decisions as components. Currently the tool does not create a datatype for the service output automatically, so you need to create one manually.

An alternative way to define a decision service is to create a new DRD page using the + button next to the list of pages and drag onto that canvas an expanded decision service shape.

This shape is a bold rounded rectangle bisected by a thin horizontal line. The service name is the label at the top. Decisions placed above the line are Output Decisions, those placed below the line are Encapsulated. Inputs to the service, whether input data or decisions, are drawn outside the rounded rectangle, as are any BKMs invoked by service elements. Here, for example, Encapsulated Decision Mortgage Payment invokes a BKM, which is hidden (indicated by the three dots).

Frequently a decision service intended to be invoked by other DMN models is saved in a separate model and dragged into the invoking model from the Digital Enterprise Graph. In the invoking model, the decision service is shown as an opaque collapsed shape with a knowledge requirement linking it to the invoking decision. There should be no information requirements leading into the collapsed decision service shape. In the invoking DRD, if you click on the [+] marker on the collapsed service, you will create a DRD page that shows the service definition using the expanded shape.

The expanded decision service shape should be used only in DRDs that define the decision service, and that page should contain no other elements.

If you have the Automation feature enabled, you can Test the logic of your model from Decision Modeler and Deploy it as a REST service in production. Both Test and Deploy actions require you first to specify a particular decision service. Often this is one you have defined manually, not the Whole Model Decision Service. The choice of service determines the parameters you must provide and the service output.

For Test on the Execution ribbon, the list of available services to choose from includes several temporary services defined automatically by the tool: one per decision in the model, with its information requirements as inputs, and Whole model, in which all decisions in the model are Output Decisions, all input data are Inputs, and there are no Encapsulated Decisions. This is useful for seeing the values of all decisions for testing and debugging. These temporary services are not available for deployment unless you re-create them manually.