Model, Evaluate and Deploy a Decision Requirements Graph

In this step, we extend the previous example by a second decision Beverages which uses the Dish decision table as input. We model this dependency between the decisions within a Decision Requirements Graph (DRG) using the Camunda Modeler. Then, we adjust the Application class to evaluate the Beverages decision, deploy the web application to Apache Tomcat and verify the result in Cockpit.

Decision Requirements Graph vs. Decision Requirements Diagram

The visual representation of a Decision Requirements Graph (DRG) is called Decision Requirements Diagram (DRD). In the context of the Camunda Modeler, we name it DRD because we use the visual representation to model the DRG.

Switch from Decision Table to DRD

Open the Dish decision table from the previous step. Click on the button “Show DRD” to see the Decision Requirements Diagram (DRD). It contains a single decision with the name Dish.

Set the Name and the Id of the DRD

Click on the top left field and replace the default name “definitions” by “Dinner Decisions”.

Next, click on the field below and set the id to “dinnerDecisions”.

Create a new Decision in the DRD

Click on the decision icon of the palette to create a new decision. Then, double-click on the decision and type Beverages to set the name. Change the type of the decision to Decision Table.

Next, connect the Dish decision to the Beverages decision to indicate that the Dish decision is a required decision of the Beverages decision. That means that it is used as an input for the decision and the output value “desiredDish” can be accessed there.

Click on the top left icon of the Beverages decision to open the decision table.

Configure the Decision Table and add the Rules

Configure the Beverages decision table so that it has:

  • the id: “beverages”,
  • one input with label “Dish”, input expression “desiredDish” and type “string”,
  • second input with label “Guests with children”, input expression “guestsWithChildren” and type “boolean”,
  • an output with label “Beverages”, name “beverages” and type “string”,
  • the hit policy “COLLECT” (with collect operator LIST).

Then, fill the table with the rules.

Save your changes and replace the existing DMN file in the src/main/resources folder.

Catch up: Get the Sources of Step-5.

Download as .zip or checkout the corresponding tag with Git.

You can checkout the current state from the GitHub repository.

If you have not cloned the repository yet, please execute the following command:

git clone https://github.com/camunda/camunda-get-started-dmn.git

To checkout the current state of the process application please execute the following command:

git checkout -f Step-5
Or download as archive from here.

Evaluate the Decision

To evaluate the Beverages decision, we extend the existing method in your Application class and add a new variable “guestsWithChildren”.

package org.camunda.bpm.getstarted.dmn;

@ProcessApplication("Dinner App DMN")
public class DinnerApplication extends ServletProcessApplication
{

    @PostDeploy
    public void evaluateDecisionTable(ProcessEngine processEngine) {

      DecisionService decisionService = processEngine.getDecisionService();

      VariableMap variables = Variables.createVariables()
        .putValue("season", "Spring")
        .putValue("guestCount", 10)
        .putValue("guestsWithChildren", false);

      DmnDecisionTableResult dishDecisionResult = decisionService.evaluateDecisionTableByKey("dish", variables);
      String desiredDish = dishDecisionResult.getSingleEntry();

      System.out.println("Desired dish: " + desiredDish);

      DmnDecisionTableResult beveragesDecisionResult = decisionService.evaluateDecisionTableByKey("beverages", variables);
      List<Object> beverages = beveragesDecisionResult.collectEntries("beverages");

      System.out.println("Desired beverages: " + beverages);
    }

}

Catch up: Get the Sources of Step-6.

Download as .zip or checkout the corresponding tag with Git.

You can checkout the current state from the GitHub repository.

If you have not cloned the repository yet, please execute the following command:

git clone https://github.com/camunda/camunda-get-started-dmn.git

To checkout the current state of the process application please execute the following command:

git checkout -f Step-6
Or download as archive from here.

Build and Deploy the Web Application

Build the web application with Maven and replace the dinner-dmn-0.1.0-SNAPSHOT.war in the $CAMUNDA_HOME/server/apache-tomcat/webapps folder.

Check the log file of the Apache Tomcat server. If you see the following log message, the deployment was successful:

INFO org.camunda.commons.logging.BaseLogger.logInfo
ENGINE-07015 Detected @ProcessApplication class 'org.camunda.bpm.getstarted.dish.DishApplication'
INFO org.camunda.commons.logging.BaseLogger.logInfo
ENGINE-08024 Found processes.xml file at ../webapps/dinner-dmn-0.1.0-SNAPSHOT/WEB-INF/classes/META-INF/processes.xml
INFO org.camunda.commons.logging.BaseLogger.logInfo
ENGINE-08023 Deployment summary for process archive 'dinner-dmn':

        dinnerDecisions.dmn

Desired dish: Stew
Desired beverages: [Guiness, Water]

INFO org.camunda.commons.logging.BaseLogger.logInfo
ENGINE-08050 Process application Dinner App DMN successfully deployed

Verify the Evaluation with Cockpit

Now, open Cockpit and go to the “Decisions” section.

Then, click on the decision Beverages and select an id to see the historic data of the evaluation.

Verify that both rules were matched and the output value for the beverages is “Guiness” and “Water”.

Note that the Dish decision is evaluated as part of the evaluation of the Beverages decision. It provides the value “Stew” for the input expression “desiredDish”.

Next Steps

Next,

  • learn more about DRG by reading the DMN Reference,
  • learn more about DMN in Cockpit and specialized views for DRGs (Enterprise Feature)

On this Page: