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 
).
{
"decisionId": "order_amount",
"variables": "{ \"warehouse_stock_level\": 60, \"orders\": 5, \"spare_parts_reserve\": 5, \"storage_tier\": \"T3\" }"
}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.
{
"decisionId": "order_amount",
"variables": "{ \"warehouse_stock_level\": 70, \"orders\": 5, \"spare_parts_reserve\": 15, \"storage_tier\": \"T2\" }"
}{
"decisionId": "order_amount",
"variables": "{ \"warehouse_stock_level\": 70, \"orders\": 5, \"spare_parts_reserve\": 15, \"storage_tier\": \"T3\" }"
}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 Operate to Verify Matched Rules
As an alternative way to check the matching rules, go into Camunda’s Operate application and go to Decisions in the top menu. Select the Order Amount decision from the dropdown menu and look at the pane at the bottom of the screen called Order Amount. Select the instance you just executed (based on the Evaluation Date) 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).
Verifying Matched Rules for Supporting Decisions
For supporting decisions, you can select the DRD which is shown to the right of the main decision. If it’s not shown, there is a Open DRD button at the top right (in blue) to make it pop up. Click a supporting decision to see how that particular decision instance was evaluated and which output it produced.
|
Supporting decisions are also in the dropdown of deployed decisions and when they are executed, their evaluations are also shown in Operate.
In our case, since we added the logic of the Inventory Level decision to the Order Amount decision during this assignment, the definition inside Order Amount deployed over the original decision definition from its own file (thereby replacing it), because the decision IDs were the same, namely |