Blog

How to transpose a string into a table using…

You are probably aware that Excel has a great function to convert a row of data into a column. This action is called “transpose”. In some cases you might want to do the same in BRF+, for example converting words within a sentence into individual words in a single column.

There are no standard solutions within Business Rule Framework to transpose. This means that you have to build this functionality yourself.

It makes sense to create a separate application in BRF+ that contains core functions that replicate functionality, such as the transpose requirement. The aim is to collect functions that can be used in any other application that is linked to a specific object (e.g. sales order, production order or purchase order). This system application will contain functions that is not meant to be called in ABAP code, but only called within other BRF+ functions in other applications. It is probably best to call this the application containing support functions.

These support functions are stored in a system application to make them immediately available in all clients within a SAP system. Obviously has the impact that the signature for these support functions have to be stable when they are going to be used in other BRF+ functions. Normally that should not be a problem because these support functions should not be complex.

For example, you want to transpose the text “Business Rule Framework” into a table with one column containing three rows with the words “Business”, “Rule” and “Framework”.

How do you do that within BRF+?

You can achieve this goal by having two support functions:

• GET_SUBSTRING, and
• CONVERT_STRING_TO_TABLE

The GET_SUBSTRING function uses sentence and to derive the first word.

That sounds a very straightforward task, but you will discover that the formula functions within BRF+ cannot use the pace as a delimiter.

So you need to build a loop to scan the sentence from left to right and find the first character that is identified as a delimiter.

You stop as soon as you have found a single word.

The CONVERT_STRING_TO_TABLE puts words into a table.

That requires a loop to call the support function GET_SUBSTRING.

Every time a word is found then this needs to be removed in your original sentence, else you trigger an endless loop.

There will be obstacles along the way, but eventually you end up with a very efficient support function that is universal.

When you have created your first support function, you find out that these will be valid in any SAP system, irrespective which SAP client and independent to what extend this client has deviated from standard SAP.

You will start collecting these universal support functions. Who knows, you might even be able to monetize them or trade them for support functions other BRF+ consultants have made.

Most popular BRF+ expressions

When you get hands-on experience with BRF+, it is likely that you will get very familiar with the following expressions:

• Decision tables
• Table operations
• Formulas
• Decision trees
• Cases
• Loops
• Function calls
• Database lookups

The most common expression is probably going to become the decision table in which you can derive a result based on multiple parameters. Those familiar with the SAP condition technique (as used in pricing and output determination), the decision table can be seen as a merged set of condition tables. Each ruleset will read this decision table with a specific key, just like hierarchical access.

Quite often you supply a table in a signature. Then it is very likely that you need to use a table operation to select a specific row in that table for decision making.

There is a wide range of functions available to determine a result using a formula. For example, adding subtracting days to a date, manipulating a string value, count number of rows in a table or calculating a cosine. You will be surprised how many functions exist and in most cases it will be sufficient to perform the task you desire.

Sometimes you have a set of IF-THEN-ELSE statements to determine a specific result. Most BRF+ consultants tend to use a decision table, but eventually have to conclude a decision tree is easier to understand. Quite often the decision tree will be more efficient and faster than a decision table.

A good alternative to a decision tree is a case when a specific result is based on a specific value. For example, the system stores the factory calendar per year. Then you have twelve fields for each month to identify whether to is a working day. You can use a formula to get the month based on the current date and then use that as input to select the workday information from the factory calendar with the case expression.

Continuing of the working days within a calendar month, you can use a loop to find the next or previous working day. Just decision whether the loop is based on a while or until condition. Be careful that you avoid triggering an infinite loop, but that can be assured by performing good simulations.

Sometimes it makes sense to call functions within functions. You can do this with a function call. You will discover that you will use this technique a lot, as result of the modular design. It is also useful to have multiple functions to keep specific decision making separate.

Finally, the database lookup should be avoided. Understanding decision making will be complicated when some data is supplied via the signature whereas other data is collected via a database lookup. Also, using the database lookup will limit the ability to test your functions in a system that has poor data quality.

BRF+ and variant configuration with IBase

Many businesses running SAP will use the variant configuration functionality to limit the number of materials in the system while offering a wide range of options how to configure the material at sales order entry.

For example, you can have one material representing a car and decide upon the module, engine size and colour when the customer places its order.

The variant configuration is based on classes and characteristics and stored in the database using Installed Base Management (IBase).

You can easily retrieve the details of the IBase via the function module CUCB_GET_CONFIGURATION, which is advised to use when you are not collecting data from the SAP database within BRF+ functions.

But when you are using the database lookup expression, then you need to know which tables to access and how to get specific characteristic values.

Here a list of IBase tables:

• IBIB: Basic data
  Identifies for what purpose the IBase is used, e.g. variant configuration.
• IBIN: Instance
  Provides the link between the IBase data and  the variant configuration of a sales order item.
• IBINOWN: Owner of the instance
  Identifies whether the instance is linked to a sales order item (Make-to-Order) or plant (Make-to-Stock), etc.
• IBINVALUES: Characteristic values of an instance
  The overview of values associated to the instance, e.g. the characteristics with values for a configurable sales order item.
• IBSYMBOL: Characteristic value combinations
  List of values linked to characteristics.

Imagine you want the value of a specific characteristic maintained for a material in the sales order item and you want to use the database lookup expression in BRF+.

Then you need to approach the database from two angles.

First, you use the internal reference of the configuration of the sales order item to access the IBase instance (VBAP-CUOBJ = IBIN-INSTANCE). Be aware that multiple IBase records can exist for the same instance when you make changes to the configuration in the sales order item. If you want the most recent configuration details, then select the IBase record with the end date set to infinity (IBIN-VALTO = 31-DEC-9999). This allows you to access the characteristic values of an instance (IBINVALUES).

Next, use the specific characteristic name (CABN-ATNAM) to get the internal reference of that characteristic to match the IBase symbol (CABN-ATINN = IBSYMBOL-ATINN). If such a match is found, then you can try to access the characteristic values of an instance (IBINVALUES).

When you are successful in accessing the characteristic values of an instance (IBINVALUES) via the sales order item (VBAP) and characteristic (CABN), then you found the characteristic value used in the variant configuration of the material in the sales order item (IBSYMBOL-ATWRT). You can then store this result in a BRF+ element as input for decision making.

When to create a BRF+ function

Many decisions are being made in the SAP system and Business Rule Framework is the ideal tool to control complex decision making without having any coding skills. However, that does not mean that BRF+ should be used for all decision making.

There are 5 main reasons why BRF+ would be a logical choice:

• Business rule that can be re-used on different platforms
  Validation of master data could be valuable when executing transaction codes, Fiori apps, data load using the migration cockpit or when processing an inbound interface. As soon as you can access ABAP code then you can use same BRF+ function, allowing you to assure one version of the truth.

• Business rule that is likely to change in time
  A phased introduction of new functionality will trigger new rules for decision making after deployment. In those circumstances you save time when using BRF+ functions, especially when the signature anticipates all data required for future decision making.

• Single complex business rule
  When a single decision requires hundreds lines of code, then it makes more sense to create a BRF+ function. The simulation capability within Business Rule Framework would be more user friendly compared to debugging ABAP code.

• Set of business rules to define a specific result
  A decision can be based on preceding decisions sequentially. You can replicate this within Business Rule Framework by calling BRF+ functions within BRF+ functions. This can also be easily simulated how you derive to the final decision, which is much more user friendly than ABAP debugging.

• Set of business rules influencing each other
  A decision can be based on preceding decisions in parallel. This complex set of cause and effect are by definition a minefield when you try to do this with ABAP code. It can happen that you have to execute one specific BRF+ function multiple times because the results can influence other BRF+ functions. The need to construct this complex set of rules is very rare, but when they exist then trying to code this cause and effect in ABAP quickly becomes a mission impossible.

This is a great checklist to decide when to use Business Rule Framework.

The advice is to use BRF+ when the business requirements hint that at least 2 of the reasons listed above apply.

When you decide to incorporate Business Rule Framework in the solution design, then building a prototype for decision making should start as soon as business requirements are known. This prototype can be used to check whether these requirements are accurate and complete. If so, then the prototype can already be used to check if the decision making process offers the expected results. If the prototype is approved by the business users performing the acceptance testing, then the most complex part of development is already under control before a functional specification is written. An approved prototype also builds the trust at a very early stage that the final solution would be fit for purpose.

How to simulate the condition technique with BRF+

The SAP condition technique allows you to control decision making via configuration and master data.

It will be a set of condition types, access sequences and condition tables and a vital part of pricing and output determination.

Depending on the complexity of pricing, you could run out of the available condition tables. You might decide in those circumstances to use Business Rule Framework.

The SAP standard condition tables for the price condition type PR00 has the access sequence PR00 with the following condition tables:

• #1: Condition table A005 = Sales organisation, distribution channel, sold-to party, pricing reference material
• #2: Condition table A006 = Sales organisation, distribution channel, price list, document currency, pricing reference material
• #3: Condition table A004 = Sales organisation, distribution channel, pricing reference material

When using hierarchical access, then you do not need three condition tables because you merge them into one. Then you configure the sequence in reading this single table to get the correct pricing master data.

Hierarchical access can be replicated in BRF+ using a single decision table and three rulesets within a function.

The first step within Business Rule Framework is to create a data element for the pricing result for the price condition type PR00.

When you want to return 5 pound sterling per 1 piece, then:

• Rate = 5
• Currency = GBP

The rate and currency are linked when creating a element that is linked to the SAP data dictionary data element KBETR.

In this example we assume that all prices will be per 1 piece.

Then you create decision table with the following columns:

• Sales organisation (VKORG)
• Distribution channel (VTWEG)
• Price list (PLTYP)
• Document currency (WAERS)
• Sold-to party (KUNNR)
• Pricing reference material (MATNR)
• Price (KBETR)

Notice that the last column is the result. There can only be one result that can be returned by the decision table.

You now can fill the decision table with data.

Next step is to create a BRF+ function that will contain three rulesets. Each ruleset will refer to the same decision table, but uses a different key to find a price.

Ruleset #1 looks in the decision table where the Sales organisation, distribution channel, sold-to party and pricing reference material matches the values received in the BRF+ function signature.

If no match was found, then ruleset #2 will try to get a price using sales organisation, distribution channel, price list, document currency and pricing reference material.

When that also failed, then ruleset #3 examines the decision table using the sales organisation, distribution channel and pricing reference material.

Obviously no result will be returned when all rulesets did not find a price.