IDOC monitoring triggering BRF+ requirements

When you are in the middle of a project go-live, providing first-line hyper care support, within the chaos surrounding you, requirements for BRF+ complex decision making will emerge.

Many clients are not aware of the Business Rule Framework, therefore not considering this tool to prevent chaos mainly because the focus is on “going live” as fast as possible, often bypassing proper user acceptance testing and cut-over testing. Especially interfacing will be difficult to test as it requires assistance from the third parties connecting their test environments to yours. The more external systems and different types of interfaces, the more likely all pray that “all will be fine” in a production environment. The level of panic will only emerge when customer orders cannot be registered, and you need to hire temporary staff to process them manually. Also, manual activities in the system will be required when communication to and from the distribution centres are triggering loads of errors.

The faults when processing interfaces can have root causes in many, sometimes unexpected, areas. Here a list of potential reasons why interfaces cannot be processed successfully:

1. Missing system configuration
2. Incomplete master data
3. Incorrect mapping rules
4. Misaligned transactional data between sending and receiving system

When moving stock from A to B, then you need to configure the system these locations are set-up to store the inventory. You might initially point to missing master data, but also system configuration requires attention. Absent customising probably emerges when you want to execute intercompany billing transactions. These are easy to fix, but requires immediate action and testing in quality assurance environment before deploying into the production system. This delay might prevent solving the blocked transactions before month-end closing. So you can avoid this obstruction by analysing sales orders, purchase orders and production orders and predict the required system configuration to allow flawless completion of the end-to-end business process. You can use BRF+ to design an early warning system to enhance missing settings before the stoppage in processing the intercompany billing will occur. This usage of BRF+ will only add value within a rapidly expanding business.

Almost all SAP ERP system will struggle with incomplete master data, so the power of the Business Rule Framework comes into its own. Preventive master data checks based on transactional data is easy to implement. You can run overnight batch jobs to analyse the recorded transactions in the system and check if potential issues could occur soon. Think of missing packing material for an end product, allowing creating the sales order and delivery but blocking post goods issue and customer billing. Also, you can expect problems with batches when you perform a stock transfer when no batch master data exists for the receiving distribution centre, preventing goods receipt.

Unnecessary complex mapping rules within interfaces can occur when doing mergers and acquisitions. No SAP system is the same, because you can easily extend the standard with custom-built solutions. When you buy a division within a large organisation, you also inherit complex decision making within the legacy SAP system. This complex decision making will be within the mapping of the interfaces. When you do not allow sufficient time to analyse the existing legacy mapping rules, then you can get some surprises. These issues are especially challenging to interpret because the decision making within those mapping rules is not related to your SAP system configuration. Integrating BRF+ within the interface mapping rules can add value, allowing you to be flexible to re-evaluate the inherited mapping rules. In time you can construct the BRF+ functions in such a way that the old mapping rules become obsolete.

A common issue is the misalignment of stock data between the ordering system and the stock storage systems. It is not always that clean-cut to assume that the stock storage system will have the most reliable data, even though you expect that data to be accurate and complete. You also struggle with an always moving target, as stock movements happen throughout the day, especially on a 24/7 operating warehouse. You can take snapshots of stock between two systems and then validate the stock levels, assuming that all goods receipt interfaces are processed successfully. Keep a close eye on those products for which less stock is available for sales in the ordering system, as that is the most likely reason for goods issue interfaces to fail. The Business Rule Framework is an ideal tool to analyse the snapshots of stock levels from both systems. You can quickly react to new insights when interpreting the available data. You can also identify products in high demand and isolate them to fix potential stock differences, avoiding interface failures.

The robust simulation capabilities within the Business Rule Framework, and the ability to collect data directly from the SAP database, allows you to build programs very quickly to test the complex decision making. You do not need a lot of resources from developers to create prototypes. You can quickly transform these prototypes in stable definitive deliverables you can deploy into the production system.

Visualising BRF+ configuration

The Business Rule Framework functions can become quite complicated. You can call functions within a function, build various cases, loops and table operations to get to your final result. When you perform a simulation and show all processing steps, then you quickly lose the area where a specific intermediate result is incorrect. Especially those new to BRF+ will get lost and get discouraged from spending the necessary time to master the tool.

Even the simplest function can benefit from a visual representation of the configuration. Also, such a visualisation might help when you want to prototype new business requirements.

Those familiar with workflow will often use the user-friendly visualiser to understand when to execute which step. Such functionality is not available within the Business Rule Framework.

That means that you need to find a method to document how all the BRF+ building blocks fit together to execute a function. It makes sense to use the Business Rule Framework icons as much as possible and to use different colours to make a distinction between the function, ruleset and rule.

You can see an example below.

You notice three sections:

• Blue: The BRF+ function with the signature.
• Green: The ruleset with optional precondition or variables
• Amber: The rule with the IF-THEN-ELSE statement

An additional pink colour highlights expressions, such as a function call, table operation or database look-up.

The example in this blog explains the configuration for the function SET_PACKING_MATERIAL.

It has the table PACKING_RULES and structure GENERAL_DATA_INPUT in the signature.

The table PACKING_RULES is bound to the SAP data dictionary table ZPACKING_RULES, whereas GENERAL_DATA_INPUT is bound to MARA.

The structure GENERAL_DATA_OUTPUT is returned and linked to the MARA table.

There are two rulesets, INITIALISATION and PACKING_MATERIAL.

The INITIALISATION moves the data from GENERAL_DATA_INPUT to GENERAL_DATA_OUTPUT when input data exists.

The PACKING_MATERIAL ruleset has an additional PACKING_MATERIAL variable and gets its value via the function call GET_PACKING_MATERIAL.

You can view the details for the function call separately because many rulesets can use it. That makes it out of scope to explain in this overview.

Finally, you have the rules within the rulesets.

This approach to visualise the functionality within a BRF+ object has been proven quite popular with consultants. It is relatively easy to document using these rules and gives a quick overview of the steps to get to a result.

Of course, every SAP client using BRF+ will have different ideas on how to visualise the deployed functionality. This example in this blog can be a good starting point to discuss how to document BRF+ configuration.

LSMW with BRF+

Most consultants with Legacy System Migration Workbench (LSMW) experience have never added ABAP code within their projects. As soon as you realise you can include complex decision making within data migration loads then a new world of possibilities emerge.

Before diving into the wondrous world of LSMW, this tool is not recommended on the S/4 HANA platform. Still, everything discussed in this blog post can also be applied in the new Data Migration Cockpit, allowing you to add your own data validation rules with BRF+. You need to realise that Business Rule Framework can be applied as soon as you execute ABAP code.

The LSMW step “Define Field Mapping and Conversion Rules” allows you to see the various locations to add ABAP code when you press Control+F7 and select all the “Determine Layout” checkboxes.

You see that every LSMW project has the following sections:

• Global data: Ideal for declaring constants, local variables, internal tables as well as adding parameters on the selection screen when you execute the “Convert Data” step.
• Begin of processing: Code that you can execute before processing any transactions, which is perfect for opening the application log.
• Begin of transaction: Use BRF+ to validate the data to prevent that bad data is processed and add messages into the application log.
• End of record: Save the individual record data to be processed within a single transaction. Normally you do not change any code in this section.
• End of transaction: Save the transaction data to be processed. Normally you do not change any code in this section.
• End of processing: Close the application log and display the application log after all transactions have been processed.
• Form routines: Location to maintain forms that can be called using the PERFORM statement.

Adding code within LSMW projects is extremely effective when you have to load a very high volume of IDocs with a high potential for failure during processing.

Imagine you need to migrate 1 million pricing master data records using IDocs triggered by the LSMW project and 1% will fail. Then you manually need to verify, update and reprocess 10 thousand IDocs. This is not humanly feasible at a project go-live. Instead, you need to make sure that only good data is processed and bad data is returned with specific instructions about why the data failed the validation step.

Handling this volume of data also requires the ability to run the “Convert Data” step in test mode and collect all warnings and errors without generating IDocs. That is why it is useful to all the test mode parameter to the selection screen when executing the “Convert Data” step, which is possible in the global data section of the LSMW project.

Integrating BRF+ functions within LSMW projects will allow you to scan the data and return messages that can be saved in the application log. The application log is can exported and used as a checklist to clean up bad data. You can design the project that only data is moved to IDocs when all records within a transaction passed the BRF+ validation. This way you can be sure that a high volume of IDocs will be loaded without defects. This will eliminate unnecessary stress during a project go-live.

Master data management with BRF+

The impact of bad master data is often underestimated and therefore not given the appropriate attention. There are very expansive solutions to improve the quality (e.g. SAP MDM/MDG), very competitively priced alternatives (e.g. Maextro), but you can also decide to use the free BRF+ tool instead.

It just depends on your specific system landscape which option is the most effective.

When you decide to use the Business Rule Framework and follow the advice given in this blog, then you could achieve quick results.

If you start from ground zero, then it makes sense to select one master data object and define a small set of rules. Collect these rules in rulesets and put them into the correct order within a single function that will return messages (e.g. in the BAPIRET2 structure). Make sure that the function receives as much data as possible, also if no rules are defined for a specific set of data, to avoid future changes to the signature. You can then use the code template for the BRF+ function in a simple ABAP program that will write the returned messages from the BRF+ function into the application log, before displaying the application log.

Imagine you use the material master data as the pilot. You then create an ABAP program that uses a range of material numbers, plants and sales areas as selection criteria. Add a loop within the ABAP program to analyse material-by-material. Then make sure that the BRF+ function contains a signature that can receive a structure with material general data and tables containing the associated plant and sales area data. You can decide to start with some simple rules checking the material general data, as the rules linked to plants and sales areas can be added into the BRF+ function at a later time. Ideally give every potential error a dedicated message number, allowing you to provide end-user documentation on how to resolve specific warnings or errors. Create several variants for this ABAP program and set-up job scheduling to execute the report with a variant. Then every morning someone from the master data team can look at the application log (transaction code SLG1) and review if any warnings or errors have been reported.

This example is very lo-fi and very easy to implement. You can extend the rules whenever they are identified by the stakeholders responsible for material master data quality. Deployment of new rules do not require the involvement of the development team unless you add new dimensions to the material master that impacts the BRF+ function signature (e.g. adding rules to check batch master data).

You can apply this strategy for every master data object (e.g. assets, business partners, company codes) and extend the set of rules throughout the next months and years.

Accept the limitations when choosing Business Rule Framework and do not try to replicate more advanced functionality. Soon you will realise that more comprehensive control of your master data (e.g. copying material plant data) will be more cost-effective when buying a software product from an SAP Partner, like Maextro.

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.