priority in Decision Table rows in IBM ODM

Question

If i have 10 rows in my decision table, out of which i want to execute only row 6 and row 4 without disabling the remaining row. How can we achieve this functionality? However, in Action Rule we can set the priority, but we cannot set priority for each row in Decision Table. I've tried searching any option available in Decision Table properties but there's non. Please help with this.

Answer 1

You may need to implement a logic like this : this is a called rule chaining. a rule(row) makes a modification, and then another rule(row) gets activated, and so on.

This needs the RETE mode to work, please look at ODM documentation for RETE, and keep in mind to set the method "SET NEXT" to update the RETE, in the BOM settings.
This example shows a chaining mechanism with different options based on the initial value of NEXT.

|  NEXT ?   | CONDITION 2| ACTIVE ? | ACTION 1  | SET NEXT  |
|    aa1    |    bb1     |  true    | do this1  |    aa2    |
|    aa2    |    bb2     |  true    | do this2  |    aa3    |
|    aa3    |    bb3     |  true    | do this3  |    aa7    |
|    aa4    |    bb4     |  false   | do this4  |    aa6    |
|    aa5    |    bb5     |  true    | do this5  |    aa1    |
|    aa6    |    bb6     |  false   | do this6  |    xxx    |
|    aa7    |    bb7     |  true    | do this7  |    aa8    |
|    aa8    |    bb8     |  true    | do this8  |    aa9    |
|    aa9    |    bb9     |  true    | do this9  |    aa10   |
|    aa10   |    bb10    |  true    | do this10 |    xxx    |

But this is last measure solution!

I don't know your model, the conditions, etc... out of the blue, you may want to rework your conditions because selecting rule in a DT with a priority like is not needed in usual cases, that is to say 99.9% of the time!

However, if the DT conditions columns are all exclusive as a partition, you may have only one rule(row) among the 10 rows that matches provided data at once.Then no need to order the rule execution.

But its not always the case, sometimes some rules(row) in a DT may match, then few row may execute on the same data, this because some condition may overlap.

For example: lets consider this DT with two conditions columns and two rows(rules) and one actions columns.(there is no verbalization, just the logic)

|  <= age >=  | Date after  |  action  |
|   18 ,   21 | 07-MAY-2020 | do this  |
|   16 ,   20 | 12-MAY-2020 | do that  |

In this case, rule condition overlaps and for data with age = 19 and date = 12-JUNE-2020, this two rules(rows) will match, and "do this" and "do that" will be executed.

If the 10 rules(rows) of your DT, are matching with provided data at runtime, the conditions are not exclusive enough, and you may need to change/rework the DT conditions's design: add new condition columns for example, to discriminate rules(rows). Or correct overlapping conditions

Let's take the previous sample and add a new discriminating condition column: GENDER for example

|  <= age >=  | Date after  | GENDER |  action  |
|   18 ,   21 | 07-MAY-2020 |   M    | do this  | 
|   16 ,   20 | 12-MAY-2020 |   F    | do that  | 

In this case, the new column will allow to have only one rule to be matched at once. Or rework the initial conditions

|  <= age >=  | Date after  |  action  |
|   18 ,   21 | 07-MAY-2020 | do this  |
|   22 ,   24 | 12-MAY-2020 | do that  |

Now, even though second condition overlaps,for data with age = 19 and date = 12-JUNE-2020, only first rule(row) will match, and "do this" will be executed.

I am quite puzzled by the fact you want to order things with priorities. Priorities may help in some peculiar cases(again), but its always a problem if it is used all over the place(e.g. more than 5 priorities in rules) and it becomes a nightmare to maintain because priorities will never convey why a rule should apply before another. Instead, as a best practice, use a workflow to group rules in ruletask with a sequential tasks ruleflow, whereas a ruletask name conveys the semantic of grouping/separating. e.g. Init data, data check, data validation, data transformation, etc...

Whenever you need to order rules, use ruletasks in a ruleflow! Then if you need to do so, you may split your DT into 2 decision tables, so that some rule in the first table may apply before other rule in the second decision table.