Skip to Content
Technical Articles

TM Conditions: Prevent huge decision tables by splitting them up by market

Problem: Large Decision Tables

When working with conditions it can happen that decision tables grow to many columns & lines, e.g. if the same document type is used for different markets/usages and the condition to be used is maintained in the document type.

In this case it makes sense to split up the maintenance into distinct decision tables. The determination of the relevant decision table (e.g. by market) should be done in a separate step.

This can be achieved with the tools available within BRFplus.

Basic Idea: TM only provides the input in form of data access definitions to BRFplus, as usual, but instead of generating a decision table only the basic structure of a BRFplus function is created. The rest is modeled within BRFplus.

 

Let´s go through the process step by step.

  1. Create the condition with “Condition based on BRFplus Expression” as Origin of Condition. This settings makes sure, the BRFplus Application and function is created and provided with the so called data objects (which are the data access definitions in TM):
  2. Maintain the Data Access Definitions as usual, this should include the Data needed to determine the decision table within BRFplus (e.g. org unit), but also the data needed within the decision table for the different markets. In our example the Org Unit of the root node is used to find the decision table, in the decision table we use the fixation and the subcontracting status as input. The result is the “Readiness for Execution”
  3. Save the condition. This creates the BRFplus application and Function, but no decision table yet. Leave the screen or change to display mode, otherwise the BRFplus objects are locked from the condition.
  4. Enter BRFplus, e.g. using transaction code BRF+ This opens a separate brwoser window, should look like the following screenshot. The name of the BRFplus application is identical to the condition name.
  5. Expand the Application, we can see that 3 Data Objects (based on our DADs) and a function (this is what we technically call from the conditions) are created, but nothing more. We are creating the actual logic now. Double-click on the function (in my example ZBD_DEMO_MULTI_DECTAB)
  6. The function should look something like this. So far no so called top Expression is assigned.
  7. Switch to “Event Mode” and create a Ruleset.
  8. In the Rule-Set, insert a rule. In the example modeling we create one rule and one decision table per Org-Unit. First, define the validity of the rule(The IF-Condition):
  9. Now define and create the Decision Table to be processed:
  10. Give a name to the decision table, select the Result Data Object (which is the reuslt of the condition, in our case the “Ready for Exec” Data Object) and create the decision table, Save the Rule when asked for it.
  11. The decision Table now looks similar to the decision table we use to see in the conditions, but the Input is missing, it only has the Result column. This can be changed by going into the table settings (Top right button)
  12. In the table settings press the insert column button to select the data access definitions you want to use for the specific decision table
  13. In the example we choose the Fixation and the Subcontracting Status
  14. Now the Decision table can be maintained with the specifics for OrgUnit1. This specific decision table will also only be called for this org unit. The values can be maintained for the decision table, don´t forget to activate the decision table.
  15. Navigate back to the ruleset using the navigation panel on the left.
  16. Create a rule and a decision table for Org Unit 2 similar to the steps before, as a result your Rule set should look similar to what is shown in the screenshot. The context data used in this decision table can be completly different from the values in the other decision table. Don´t forget to activate the Ruleset, use the deep activation if asked for it.
  17. We are done! You can now navigate to the function and call a simulation, where you check if the right decision table is picked (and if the decision table returns the correct results):
  18. Now the different users responsible for the applications can add the decision table to their favorites (right mouse click on the decision table opens context menu) and see their decision tables when opening BRFplus and selecting their favorites:

 

Some more info about conditions and BRFplus can be found e.g. in this and this TM podcast episode. There is also a set of postings starting here.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.