In this article you will learn:
- Why you should consider nesting decision tables
- How decision tables nesting can help structure your value mappings
- What BRFplus catalogs can do to pass ownership of solution towards business
You probably know BRFplus for its ease of usage and business logic handling capabilities. It is very often used to provide value mapping for various kinds of interfaces and backend applications. In this blog, I will present you BRFplus nesting capabilities and how they can be leveraged to give your BRFplus developments proper structure and reusability. You will also learn how to incorporate catalogs along with decision tables, to pass ownership of the mappings towards the business.
Let’s imagine a generic scenario where you have multiple sender systems, with multiple interfaces. In all of them you need to determine one Result field. It can be Company Code, Material or any other commonly used element in your real life project. You would like to have a generic solution to fetch the Result, no matter what is the source of the message, the issue is that those determinations need to be handled differently for different sources or even interfaces.
Nesting Decision Tables
At the beginning you can build a frame which will be a BRFplus function with generic input structure and the Result as result data object, like in the below picture.
Pic.1 Simple BRFplus function
Source and Interface fields will indicate from where you’ve got a call and other three fields will help to get the Result out of the mapping. Such a model can be easily adjusted to needs of any mapping exercise. It is also extendable, which is a very important factor when you are considering future usage and generic solutions.
Now let’s have a look at the “Get Result Table”, which is a decision table used as a Top Expression.
Pic.2 Get Result Table decision table
You can see here, that Source and Interface columns will work as condition columns, to get the Result. This time we won’t just simply place fixed values in the Result, we would like to have separate logic for determining the Result based on the input Source and Interface. For example, if Source is S1, we will always call the nested “Get Result S1 Source” decision table, no matter what interface it is. Then it will use Field1 and Field2 to fetch the Result value.
Pic.3 Get Result S1 Source decision table
Decision Tables are flexible enough to allow you to combine nested calls, fixed values and context input in one result column. Thanks to that for Source S2 and Interface I1, we can simply point to Field3 from input context to be the Result value.
For the other two combinations we are also calling nested decision tables looking like on pictures below. The key word here is flexibility.
Pic.4 Get Result S2/I2 decision table
Pic.5 Get Result S2/I3 decision table
How catalogs can make it better
You have nested decision tables, you have good control over the mapping and solution is flexible. How can you make it even better? Solution for that is simple, you should leverage capabilities of the BRFplus catalogs. You probably noticed that thanks to nesting in our example we have 4 simple tables instead of one big BRFplus decision table. Such a split should be done in a way that the bottom level table contains only business relevant fields that should be understandable by end users. Now you can create catalogs, for each group of users, with only tables that are relevant for them.
Pic.6 Catalog for S1 Users contains only table for S1 Source mappings
Pic.7 Catalog for S2 Users contains two tables for S2 Source mappings
One group of users will use the “S1 Users” catalog, as it contains a table that is in their area of interest and the other group will use the “S2 Users” catalog that contains mappings that they should have under their control. It’s much easier to pass responsibility and ownership of such simple business value mappings to the users, rather than ask them to work with one complex logic. What is more it is usually appreciated that you see only things that are there for you. It is simplifying the work and making it much easier to control.
Catalogs and tables can be organised in many different ways. It’s important to understand in what process mappings are used and what would be the most natural and beneficial type of split. Splitting Cost Center mappings per Company Code is a good real life example, as you can create Company Code specific Cost Center mapping tables and allow each Company Code to take ownership of the local business logic.
Why should you consider nesting?
There are few key points, why you should consider nesting decision tables:
- Thanks to nesting decision table calls, you have one common interface towards the Result mapping, you can implement this one call to the common BRFplus function in a class and ask all developers to fetch the Result in this way via a common method
- You are gaining control of the mappings and you are ensuring everybody is doing it the same way
- Your mappings are well organized, so by looking at the “Get Result Table” you can identify how the Result is determined without checking ABAP code
- Solution is flexible, so when you are adding new sources or interfaces, you can simply extend current BRFplus logic
- Adding catalogs and thoughtful decision tables split, allow you to pass ownership of the business logic towards the business, where it belongs
Read my SAP PRESS book “Mapping with BRFplus Decision Tables and SAP AIF”.