In this article you will learn:<\/h2>\n\n- Why you should consider nesting decision tables<\/li>\n
- How decision tables nesting can help structure your value mappings<\/li>\n
- What BRFplus catalogs can do to pass ownership of solution towards business<\/li>\n<\/ul>\n<\/div>\n
\n<\/div>\n
Introduction<\/h3>\n
You probably know BRFplus<\/strong><\/span><\/a> 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.<\/p>\nLet’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.<\/p>\n
<\/p>\n
Nesting Decision Tables<\/h3>\n
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.<\/p>\n
![\"Simple](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/09\/Simple-BRFplus-function.png\")
<\/a><\/p>\nPic.1 Simple BRFplus function <\/em><\/p>\n
\nSource 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.<\/p>\n
Now let’s have a look at the “Get Result Table”, which is a decision table used as a Top Expression.<\/p>\n
![\"Get](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/09\/Get-Result-Table-decision-table.png\")
<\/a><\/p>\nPic.2 Get Result Table decision table<\/em><\/p>\n
\nYou 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.<\/p>\n
![\"Get](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/09\/Get-Result-S1-Source-decision-table.png\")
<\/a><\/p>\nPic.3 Get Result S1 Source decision table<\/em><\/p>\n
\nDecision 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.<\/p>\n
For the other two combinations we are also calling nested decision tables looking like on pictures below. The key word here is flexibility.<\/p>\n
![\"Get](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/09\/Get-Result-S2-I2-decision-table.png\")
<\/a><\/p>\nPic.4 Get Result S2\/I2 decision table<\/em><\/p>\n![\"Get](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/09\/Get-Result-S2-I3-decision-table.png\")
<\/a><\/p>\nPic.5 Get Result S2\/I3 decision table<\/em><\/p>\n
\nHow catalogs can make it better<\/h3>\n
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<\/a> 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.<\/p>\n
- \n
- Why you should consider nesting decision tables<\/li>\n
- How decision tables nesting can help structure your value mappings<\/li>\n
- What BRFplus catalogs can do to pass ownership of solution towards business<\/li>\n<\/ul>\n<\/div>\n
\n<\/div>\n
Introduction<\/h3>\n
You probably know BRFplus<\/strong><\/span><\/a> 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.<\/p>\n
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.<\/p>\n
<\/p>\n
Nesting Decision Tables<\/h3>\n
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.<\/p>\n
<\/a><\/p>\nPic.1 Simple BRFplus function <\/em><\/p>\n
\nSource 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.<\/p>\n
Now let’s have a look at the “Get Result Table”, which is a decision table used as a Top Expression.<\/p>\n
<\/a><\/p>\nPic.2 Get Result Table decision table<\/em><\/p>\n
\nYou 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.<\/p>\n
<\/a><\/p>\nPic.3 Get Result S1 Source decision table<\/em><\/p>\n
\nDecision 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.<\/p>\n
For the other two combinations we are also calling nested decision tables looking like on pictures below. The key word here is flexibility.<\/p>\n
<\/a><\/p>\nPic.4 Get Result S2\/I2 decision table<\/em><\/p>\n
<\/a><\/p>\nPic.5 Get Result S2\/I3 decision table<\/em><\/p>\n
\nHow catalogs can make it better<\/h3>\n
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<\/a> 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.<\/p>\n
![\"Catalog](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/09\/Catalog-for-S1-Users-contains-only-table-for-S1-Source-mappings.png\")
<\/a><\/p>\n![\"Catalog](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/09\/Catalog-for-S2-Users-contains-two-tables-for-S2-Source-mappings.png\")
<\/a><\/p>\n