Chapter 28. Hit policies for guided decision tables Hit policies determine the order in which rules (rows) in a guided decision table are applied, whether top to bottom, per specified priority, or other options. The following hit policies are available: None: (Default hit policy) Multiple rows can be executed and the verification warns about rows that conflict. Any decision tables that have been uploaded (using a non-guided decision table spreadsheet) will adopt this hit policy. Resolved Hit: Only one row at a time can be executed according to specified priority, regardless of list order (you can give row 10 priority over row 5, for example). This means you can keep the order of the rows you want for visual readability, but specify priority exceptions. Unique Hit: Only one row at a time can be executed, and each row must be unique, with no overlap of conditions being met. If more than one row is executed, then the verification produces a warning at development time. First Hit: Only one row at a time can be executed in the order listed in the table, top to bottom. Rule Order: Multiple rows can be executed and verification does not report conflicts between the rows since they are expected to happen. Figure 28.1. Available hit policies 28.1. Hit policy examples: Decision table for discounts on movie tickets The following is part of an example decision table for discounts on movie tickets based on customer age, student status, or military status, or all three. Table 28.1. Example decision table for available discounts on movie tickets Row Number Discount Type Discount 1 Senior citizen (age 60+) 10% 2 Student 10% 3 Military 10% In this example, the total discount to be applied in the end will vary depending on the hit policy specified for the table: None/Rule Order: With both None and Rule Order hit policies, all applicable rules are incorporated, in this case allowing discounts to be stacked for each customer. Example: A senior citizen who is also a student and a military veteran will receive all three discounts, totaling 30%. Key difference: With None , warnings are created for multiple rows applied. With Rule Order , those warnings are not created. First Hit/Resolved Hit: With both First Hit and Resolved Hit policies, only one of the discounts can be applied. For First Hit , the discount that is satisfied first in the list is applied and the others are ignored. Example: A senior citizen who is also a student and a military veteran will receive only the senior citizen discount of 10%, since that is listed first in the table. For Resolved Hit , a modified table is required. The discount that you assign a priority exception to in the table, regardless of listed order, will be applied first. To assign this exception, include a new column that specifies the priority of one discount (row) over others. Example: If military discounts are prioritized higher than age or student discounts, despite the listed order, then a senior citizen who is also a student and a military veteran will receive only the military discount of 10%, regardless of age or student status. Consider the following modified decision table that accommodates a Resolved Hit policy: Table 28.2. Modified decision table that accommodates a Resolved Hit policy Row Number Discount Type Has Priority over Row Discount 1 Senior citizen (age 60+) 10% 2 Student 10% 3 Military 1 10% In this modified table, the military discount is essentially the new row 1 and therefore takes priority over both age and student discounts, and any other discounts added later. You do not need to specify priority over rows "1 and 2", only over row "1". This changes the row hit order to 3 1 2 ... and so on as the table grows. Note The row order would be changed in the same way if you actually moved the military discount to row 1 and applied a First Hit policy to the table instead. However, if you want the rules listed in a certain way and applied differently, such as in an alphabetized table, the Resolved Hit policy is useful. Key difference: With First Hit , rules are applied strictly in the listed order. With Resolved Hit , rules are applied in the listed order unless priority exceptions are specified. Unique Hit: A modified table is required. With a Unique Hit policy, rows must be created in a way that it is impossible to satisfy multiple rules at one time. However, you can still specify row-by-row whether to apply one rule or multiple. In this way, with a Unique Hit policy you can make decision tables more granular and prevent overlap warnings. Consider the following modified decision table that accommodates a Unique Hit policy: Table 28.3. Modified decision table that accommodates a Unique Hit policy Row Number Is Senior Citizen (age 65+) Is Student Is Military Discount 1 yes no no 10% 2 no yes no 10% 3 no no yes 10% 4 yes yes no 20% 5 yes no yes 20% 6 no yes yes 20% 7 yes yes yes 30% In this modified table, each row is unique, with no allowance of overlap, and any single discount or any combination of discounts is accommodated. 28.1.1. Types of guided decision tables Two types of decision tables are supported in Red Hat Process Automation Manager: Extended entry and Limited entry tables. Extended entry: An Extended Entry decision table is one for which the column definitions specify Pattern, Field, and Operator but not value. The values, or states, are themselves held in the body of the decision table. Limited entry: A Limited Entry decision table is one for which the column definitions specify value in addition to Pattern, Field, and Operator. The decision table states, held in the body of the table, are boolean where a positive value (a marked check box) has the effect of meaning the column should apply, or be matched. A negative value (a cleared check box) means the column does not apply.

Commands: