Covering New Cases
We need to add the appropriate rules for cases where the supporting decision Inventory Level yields a value that is equal to or greater than the threshold for each storage tier.
Because the storage tiers have different thresholds, we need multiple new rules.
For now, we’ll return the order amount 0 when nothing needs to be ordered.
Add the new rules to the table, then test with the following command (this is the same as the previous test 
).
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"}}}'Contracting the Table
It’s likely you chose to add precisely 4 rules in the previous step; one for each storage tier’s threshold value. However, there’s a way we can contract the table further.
Did you notice, that even though tiers T2 and T3 have different order amounts, their threshold is the same? So we needed 2 rules to cover the cases where items need to be ordered. But for the "0 items to order" cases, the inputs are checked against the same value of 50 and result in the same outputs.
Replace the input entry of one of the two new rules with the following expression:
"T2","T3"This expression means: the value is equal to either "T2" or "T3". As we saw, even though the various inputs of a decision are always AND-ed together, the input entries of a rule may contain ORs in the values they compare with. This is possible in order to cover these kinds of cases and to allow contracting the table to the minimum number of rules required to capture the decision logic.
Delete the other rule that matches for a threshold of 50 items, now that the table has a contracted rule that already covers it. Your table should now have 7 rules.
Save, deploy, then test the contracted table with the following two tests.
The result should be 0 for both.
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" : 70, "type": "Integer"}, "Orders" : {"value" : 5, "type" : "Integer"}, "Spare parts reserve" : {"value" : 15, "type" : "Integer"}, "Storage Tier" : {"value": "T2", "type" : "String"}}}'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" : 70, "type": "Integer"}, "Orders" : {"value" : 5, "type" : "Integer"}, "Spare parts reserve" : {"value" : 15, "type" : "Integer"}, "Storage Tier" : {"value": "T3", "type" : "String"}}}'Verifying Matched Rules
If you’re wondering about the results of your test and want to be absolutely sure that the contracted table is matching on the rule you want it to, you can easily verify it.
A simple way to check the matching rule(s) is to change the output entry of the rule you want to match to a recognisable and unique value (temporarily of course). In this case, instead of returning 0 from the rule, change it to 1, for instance. There’s no other rule in the table that would return that value, so if that’s the value you get as a result, you know that the correct rule matched.
Using Camunda Cockpit to Verify Matched Rules
As an alternative way to check the matching rules, go into Camunda’s Cockpit application and go to Decisions in the top menu. Select the Order Amount items in the list and look at the pane at the bottom of the screen called Decision Instances. Select the instance you just executed (based on the Evaluation Time) and you’ll see that Camunda shows which rules matched when the decision was evaluated by highlighting the rules matching the Inputs (shown at the bottom).