Test the Model

Let’s test the decision model to see it in action.

When evaluating a decision, you need to pass in all of the information requirements in the request and specify which decision to execute.

The following curl command evaluates the inventory_level decision. The input data is passed with --data flag - in the case of Camunda, it’s a JSON structure containing the names and values along with their types, for each of the input requirements.

Request 1.1: Evaluate decision `inventory_level`; Expected outcome: 169

curl \
  --request POST \
  --header "Content-Type: application/json" \
  http://localhost:8080/engine-rest/decision-definition/key/inventory_level/evaluate \
  --data '{"variables" : { "Warehouse stock level" : { "value" : 233, "type": "Integer"}, "Orders" : {"value" : 14, "type" : "Integer"}, "Spare parts reserve" : {"value" : 50, "type" : "Integer"}}}'

Take a close look at the output. In the JSON that’s returned, the inventory_level variable should be 169.

The formula is not very complex, obviously. Still, we’ve now defined and executed a standardised calculation of the inventory level, to be used in Bolt Bike’s business processes. See if you can change a value and see the result change.

Even though DMN allows using spaces in variable names and Camunda supports this (to some extent), the examples and instructions that follow will use snake_case instead. This is done to be consistent and to avoid the need for surrounding the variables with backticks (`), which is the way Camunda requires you to mark the variable names so it can figure out the start and end of each. Our requests will also change in the following, using the snake cased variants of inputs, for instance.