Test the Decision

We’re now ready to test the decision in its current form.

Deploy the Model

In Camunda Modeler, save your model with Ctrl+S or File  Save File. As before, use the rocket to deploy the new model to the running Camunda engine. You can leave the default values of the pop-up dialog as they are.

Test the Model

The following curl command tests the decision model. As you can see, we need to pass in all of the input elements at once and the decision we instruct the engine to evaluate is the overall decision (here, it’s called order_amount). The engine is smart enough to know how to interpret the dependencies in the DRD and execute the decisions in the correct order, using the correct input data elements.

Request 2.1: Evaluate decision `order_amount`; T1, Below threshold, Expected outcome: 250
curl \
  --request POST \
  --header "Content-Type: application/json" \
  http://localhost:8080/engine-rest/decision-definition/key/order-amount/evaluate \
  --data '{"variables" : { "Warehouse stock level" : { "value" : 132, "type": "Integer"}, "Orders" : {"value" : 20, "type" : "Integer"}, "Spare parts reserve" : {"value" : 20, "type" : "Integer"}, "Storage Tier" : {"value": "T1", "type" : "String"}}}'

If your rules are correct, the response should indicate that 250 items need to be ordered. This is because the current inventory level is 132 - 20 - 20 = 92, the threshold for T1 is 100 items and the order size is 250.

Similarly, the following request should yield an order amount of 50 for T4 items.

Request 2.2: Evaluate decision `order_amount`; T4, Below threshold, Expected outcome: 50
curl \
  --request POST \
  --header "Content-Type: application/json" \
  http://localhost:8080/engine-rest/decision-definition/key/order-amount/evaluate \
  --data '{"variables" : { "Warehouse stock level" : { "value" : 72, "type": "Integer"}, "Orders" : {"value" : 38, "type" : "Integer"}, "Spare parts reserve" : {"value" : 5, "type" : "Integer"}, "Storage Tier" : {"value": "T4", "type" : "String"}}}'

Edge Cases

Let’s perform another test where the edge case of the threshold for one of the storage tiers is in play. Can you predict what will happen?

Request 2.3: Evaluate decision `order_amount`; T3, At threshold, Expected outcome: ???
curl \
  --request POST \
  --header "Content-Type: application/json" \
  http://localhost:8080/engine-rest/decision-definition/key/order-amount/evaluate \
  --data '{"variables" : { "Warehouse stock level" : { "value" : 60, "type": "Integer"}, "Orders" : {"value" : 5, "type" : "Integer"}, "Spare parts reserve" : {"value" : 5, "type" : "Integer"}, "Storage Tier" : {"value": "T3", "type" : "String"}}}'

You’ll get an error in this case. If it’s not obvious to you why this happens, perhaps the log of the Camunda engine will help you to understand. If not, read on wink

Our decision table has four rules currently and a hit policy of Unique. Try to imagine which rules match if the Inventory Level decision returns a value that is equal to or greater than the order threshold for that storage tier.

As you can see, no rules will match. If no rules match in a decision table with a unique policy, the decision returns an empty or null result.

Let’s improve the decision.