|"Hit policies" describe different ways standardized by DMN to evaluate the rules contained in a decision table. Different hit policies do not only lead to different results but typically also require different modes of thinking and reason about the meaning of the whole table. It is therefore crucial to not just "know" the different DMN hit policies, but to also understand the motivations for their existence and the most typical cases for using them.|
A decision table consists of several rules, typically represented as rows. When reading such a row we look at certain input values and deduct a certain result represented by output values. When using the simplest hit policy "unique" (U), such rules do not overlap: only a single rule must match.
|1||We define an "input" value season here. For every single season …|
|2||… there is a jacket defined we want to use, the "output" of the rules here.|
|3||The hit policy "Unique" (indicated by the character U) enforces that rules do not overlap: only a single rule must match.|
Now consider that we build a decision table with overlapping rules. In other words that means more than one rule may match a given set of input values. We then need one of the alternative hit policy indicators to unambiguously understand the decision logic according to which such rules are interpreted.
The hit policy indicator is a single character shown in horizontal decision table’s top left cell right beneath the decision’s name. The character is the initial letter of one of the defined seven hit policies
Output order and
Rule order. Furthermore, the hit policy 'Collect' may also be used with one of four aggregation operators, actually giving us four more hit policies
C< (Maximum) and
Eight of those eleven hit policies evaluate a decision table to a single result. Three hit policies evaluate a decision table to multiple results.
Such tables either return the output of only one rule or aggregate the output of many rules into one result. The hit policies to be considered are
Unique: Rules do not overlap. Only a single rule can match.
First: Rules are evaluated from top to bottom. Rules may overlap, but only the first match counts.
Priority: Rule outputs are prioritized. Rules may overlap, but only the match with the highest output priority counts.
|As of Camunda 7.12 hit policy priority is not yet supported. In essence priorities are specified as an ordered list of output values, in decreasing order of priority. Such priorities are therefore independent from rule sequence! Even though not yet supported, you can mimic that behavior by using hit policy "(C)ollect" and determining a priority yourself, e.g. by means of an execution listener attached to the end of your business rule task.|
Any: Multiple matching rules must not make a difference: all matching rules must lead to the same output.
Collect and aggregate: The output of all matching rules is aggregated by means of an operator:
C+Sum: Add up all the matching rule’s distinct outputs.
C<Minimum: Take the smallest value of all the matching rule’s outputs.
C>Maximum: Take the largest value of all the matching rule’s outputs.
C#Number: Return the number of all the matching rule’s distinct outputs.
Multiple result tables may return the output of multiple rules. The hit policies for such tables are:
Collect: All matching rules result in an arbitrarily ordered list of all the output entries.
Rule order: All matching rules result in a list of outputs ordered by the sequence of those rules in the decision table.
Output order: All matching rules result in a list of outputs ordered by their (decreasing) output priority.
|As of Camunda 7.12 hit policy output order is not yet supported. In essence output orders are specified as an ordered list of output values, in decreasing order of priority. Such priorities are therefore independent from rule sequence! Even though not yet supported, you can mimic that behavior by using hit policy "(C)ollect" and determining an output order yourself, e.g. by means of an execution listener attached to the end of your business rule task.|
Most situations can be addressed by using different hit policies. In that case, the hit policy will have an effect on the readability and maintainability of the table. Often it is worth trying different varieties until you have a feel for what will work best. In practice, we often use the free Online Simulator to play around with various alternatives.
Hit policy "Unique" will typically make it easy to build a decision table which make sure that your rules are "complete" - in the sense that the rules do not just not overlap but cover all possible input values - so that you do not "forget" anything.
|1||The input area of each row specifies a certain segment of possible input values.|
|2||This row e.g. expresses that long time silver customers receive a 9% discount.|
Such a use case fits to the hit policy "Unique". For such use cases it is an advantage that this hit policy make your decision logic invalid in case you violate its requirement that your table rules never "overlap": after all you must not produce ambigious results.
Having said that, the hit policy "First" can sometimes make it easier for an organisation to reason about decision logic dealing with some criteria that are "harder" (more "clearcut") than others. Furthermore it can help to make a decision table layout more compact and therefore easier to interpret.
|1||Assume that everybody in the organisation knows that first rule: "Once on the blacklist, never again accepted". The layout and the hit policy of the decision table therefore supports the organisation’s way of doing business: once we know that single fact about a customer, we don’t need to think further.|
|2||The following rules from row 2 to 4 are expressed in an "Accept" manner and might change more often over time. The organisation’s way of thinking is literally "from top to bottom". Once we find an acceptance rule, we can deal with the customer.|
|3||For execution in a decision engine, don’t forget to a add a rule not accepting any other customers as a last row.|
In scenarions dealing with hard exclusion and inclusion criteria, we often don’t care that much whether the rules overlap or not, but prefer to argue about very clearcut cases first and about more sophisticated ones later on. Furthermore, the organisation’s way of thinking and doing business might be better supported by a decision table using the Hit Policy First.
|Our experience so far tends to show that it can be more tricky and error prone to argue about a First Hit Policy decision table than it might occur to you at first sight. Therefore be especially careful and always test your logic in case you are dealing with sensitive business!|
With hit policy priority you do not need to order your rules within the decision table, but assign a priority to an output value. This can sometimes make it easier for an organisation to maintain sets of many different rules which point in a similar direction from a business perspective.
Imagine a scenario in which orders flagged "red" are automatically rejected, while "yellow" orders are reviewed and decided by humans. The following decision table could serve as a starting point to collect the rules for "red", "yellow" and "green" cases:
|1||We define an ordered list of risk levels here. With such a prioritized output (and hit policy "priority") the most severe risk found will be returned as the result of a decision table.|
|2||We can therefore define more or less independent rules, many e.g. leading to a risk level "yellow", as here e.g. defined for a certain relatively low income as well as …|
|3||… for a relatively high number of household members depending on an income.|
In scenarios with manyfold evaluation criteria, it is often an advantage that the rules do not need to be ordered. The organisation can therefore read such a table and reason about a single line without needing to understand the interdependencies to other lines.
|As of Camunda 7.12 hit policy priority is not yet supported. Therefore, we "misused" the mappings cell in this example to display a priority order.|
With hit policy collect you do not care about the order or any interdependencies in between your rules at all. Instead you just "collect" independent rules and just care about the question which rules are applicable to your specific case.
Consider e.g. the question of "who is allowed" to carry out some action, as e.g. reviewing and deciding about incoming orders:
As a result of this decision table we will either get
["Management"] or a list of both groups
We could use this information to route the order into the applicable group’s task lists or control access rights of a configurable software solution etc. Of course you could at any time introduce more rules and eventually also differentiate in between more groups without changing your software solution.
Hit policy "collect" may be combined with operators such as Sum (C+), leading to very different use cases. A very typical one is the requirement to evaluate a case based on manyfold factors influencing the overall result.
Assume e.g. we want to deal with customers we know nothing about. They receive a score of 0. But in case we know something about them we also weigh in our knowledge:
|1||The overall creditworthiness is deducted by throwing in many factors.|
|2||Here we give e.g. credit in case we made good experiences with the customer in the past.|
|3||A very low current income does not matter as long as the customer is not a stranger to us!|
|4||On the other hand, as soon as a customer has proof for a good income, s/he receives 5 points for "reasonable" income as well as 10 points extra for good income.|
So even if we had bad experience with a customer (which means s/he starts from -15), we end up with an overall score of 0 in case the customer has good income now and start to accept the customer again.
In scenarions dealing with soft exclusion and inclusion criteria, we need a mechanism to associate a weight to different scenarios. This is ideally supported by Hit Policy Sum (C+).
No guarantee - The statements made in this publication are recommendations based on the practical experience of the authors. They are not part of Camunda’s official product documentation. Camunda cannot accept any responsibility for the accuracy or timeliness of the statements made. If examples of source code are shown, a total absence of errors in the provided source code cannot be guaranteed. Liability for any damage resulting from the application of the recommendations presented here, is excluded.
Copyright © Camunda Services GmbH - All rights reserved. The disclosure of the information presented here is only permitted with written consent of Camunda Services GmbH.