Skip to Content
Author's profile photo Carsten Ziegler

About performance in BRFplus/NW DSM

Some years ago we published a document with some recommendations and performance figures. The content of the document is basically still valid although it needs updates with respect to some details.

Continuous improvements

Over the last few years, we have significantly improved the runtime performance. Mostly, customers have been the drivers for the improvements. Looking at real world scenarios has allowed us to better optimize the generated code, since there was a specific challenge and a clear goal. The enormous customer base of BRFplus/NW DSM helps to improve and mature the product.

The results are several notes, some of which can be found in my previous blogs:

However, this is not the end. I am currently working on deployments of decision service and rules into the HANA database. It is too early to communicate any more about it. I will blog about it when the time has come to reveal the details.

How to identify a performance problem?

When asked for a performance analysis, I see some recurring patterns that often can be easily solved:

  1. Use of “bad” expression types
  2. Use of outdated invocation methods
  3. Old versions of BRFplus, missing fixes

Very often a simple test can be applied to check whether performance can be improved significantly. Whenever BRFplus loads objects from the database during rule execution, this is a strong indication of a problem. The general principle is that BRFplus should find all relevant information in the generated code. Therefore you can set an external breakpoint in method CONSTRUCTOR of class CL_FDT_MAINTENANCE. Should you stop there, take a look at the stack trace to understand the reason, which often is one of the three issues in the list.


Usage of “bad” expression types

All BRFplus standard expression types support code generation, with one exception: Dynamic Expressions. Therefore, we recommend avoiding this expression type by any means possible. It is often used because it is convenient and other patterns that allow compiling all the rules into ABAP code are possible. In some cases, additions to BRFplus have been created by SAP application developers or even by customers and partners. Only recently, the BOPF expression type was improved to support code generation. Whenever code cannot be generated, objects have to be loaded from the database which is a very time and memory consuming step. BRFplus has a mechanism to partially generate and jump into interpretation as soon as it is needed. As a rule of thumb, expect a performance penalty of factor 500 and more as soon as an expression needs to be loaded. Loading an object will hit the breakpoint in the constructor method of CL_FDT_MAINTENANCE.

Use of outdated process method

When BRFplus was released for the first time with NW 7.0 Enhancement Package 1, only one API was available for execution of a business rules. A typical call is shown in the following code snippet.


The actual call is made with method IF_FDT_FUNCTION->PROCESS (fourth line). It requires a function instance. This instance has to be created before rules execution can take place. Its creation requires doing selects in several database tables. Data object instances are also required. Again, you fill hit the breakpoint in the constructor method of CL_FDT_MAINTENANCE in this case. Instead of using this code, always use the code template generator. In NW 7.0 Enhancement Package 2, you can use report FDT_TEMPLATE_FUNCTION_PROCESS to generate a code template. In newer releases, you can find the feature in the BRFplus workbench on the function screen (requires technical features switched on in the personalization). The code can be copied into your ABAP source. You only have to set variable values. Although the code is not as easy to read, it is tremendously fast in execution. The code template generator will also compose the code dependent on capabilities of your managed systems.


Old versions of BRFplus, missing fixes

On first use BRFplus generates ABAP code on the fly. If there are problems, the process does not stop and return with error messages but instead uses the interpretation mode as a fallback. Often, such situations occur because of old release versions and missing fixes. You can also reliably detect this problem with the breakpoint as mentioned above. On first generation it is fine to hit the breakpoint. However, BRFplus may want generate code again and again when generation does not complete successfully. In this case you best check the notes or you open a support ticket to have someone help you identify the notes for your system.

NetWeaver Decision Service Management

In NW DSM, the previous three sources of errors do not occur because of conceptual differences. In NW DSM, you generated at a specific point in time and you will receive feedback if generation was successful and with reasons when it is not (for example, use of “bad” expression types, missing fixes). The old invocation API is not supported but DSM comes with a new, highly optimized and simplified API. The code generation function will automatically output the best code, also in scenarios in which NW DSM is used.

Problematic data access

Finally, there is a recurring pattern of performance problems that is not so easy to eliminate. In many scenarios data has to be retrieved for evaluating business rules. This may happen prior to the invocation of rules or within the business rules with help of procedure call expressions or database lookup expressions. In any case, expect one select single in a buffered database table to consume more time than processing a bunch of rules, formulas, and decision tables (if not huge). Therefore, it is essential to intelligently select multiple records from the database when possible. In NW 7.3 Enhancement Package 1, we have improved the DB Lookup expression to support aggregation and grouping. You may also use ABAP code that calls the rules to do the select and then pass the records as context data to the rules. Alternatively, instead of DB Lookup expressions, a class for data access that internally buffers and optimizes may be created. With call procedure expressions, the data can be retrieved from within BRFplus. In some cases it may also help to run a DB trace to identify selects that do not hit an index. Note that running BRFplus/NW DSM on a HANA DB often does not require optimizations with indexes, reducing the rule modeling effort.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jocelyn Dart
      Jocelyn Dart

      This is really pragmatic and very helpful Carsten.  I love the code generation template - it's a real boon for testing calls to the rules are correct independent of the calling program as well. I'm keen to see more on the DSM API. 

      Author's profile photo Former Member
      Former Member

      The code sample in the screen shot uses class CL_FDT_BRS_PROCESSOR to invoke the function (context passed via table type T_NAME_VALUE, invocation via instance method PROCESS).

      On our system (Basis 7.4SP5, DSM 1.0SP3), this class exists, but the CodeGen creates code using CL_FDT_FUNCTION_PROCESS=>PROCESS, passing parameters via table type ABAP_PARAMBIND_TAB.

      Which style is faster? Which is the newer API?

      Author's profile photo Christian Lechner
      Christian Lechner

      Hi Jürgen,

      according to the BRF+ book of Carsten the static method call CL_FDT_FUNCTION_PROCESS=>PROCESS is the faster one

      Both APIs exist since the begining (at least since NW 7.02)