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 “View 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 somewhere on the canvas and open the Property Panel on the right. Change the id of the DRD to “dinnerDecisions”. Next, change the name of the DRD to “Dinner Decisions”.
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 by clicking on the wrench icon next to the “Beverages” decision and selecting “Decision Table”. Use the Property Panel on the right side again to set the id to “beverages”.
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:
- 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/cibseven/cibseven-get-started-dmn.git
To checkout the current state of the process application please execute the following command:
git checkout -f Step-5Or 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 de.cibseven.getstarted.dmn;
@ProcessApplication("Dinner App DMN")
public class DinnerApplication extends ServletProcessApplication
{
protected final static Logger LOGGER = Logger.getLogger(DinnerApplication.class.getName());
@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();
LOGGER.log(Level.INFO, "\n\nDesired dish: {0}\n\n", desiredDish);
DmnDecisionTableResult beveragesDecisionResult = decisionService.evaluateDecisionTableByKey("beverages", variables);
List<Object> beverages = beveragesDecisionResult.collectEntries("beverages");
LOGGER.log(Level.INFO, "\n\nDesired beverages: {0}\n\n", 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/cibseven/cibseven-get-started-dmn.git
To checkout the current state of the process application please execute the following command:
git checkout -f Step-6Or 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 $CIBSEVEN_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 'de.cibseven.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
INFO de.cibseven.getstarted.dmn.DinnerApplication.evaluateDecisionTable
Desired dish: Stew
INFO de.cibeven.getstarted.dmn.DinnerApplication.evaluateDecisionTable
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,