Skip to Content

Architecture of BRFplus-based Applications

A very successful pattern for business applications is the separation of business processes and objects from business rules. The latter can be implemented in business rules framework like BRFplus which is the state-of-the-art technology of the ABAP application server. In the following I will discuss two different architectural patterns for applications using business rules and I will give you my opinion about the biggest strength of using BRFplus: it allows simulation of execution of business. Please remark that I don’t speak of the simulation of a single BRFplus rule using the BRFplus workbench – I speak of performing the calculation of changed business rule by calculation perhaps millions of calculations in batch processes to estimate the consequences of changes in your ERP system. And last but not least I will muse about the connection about business rules and business processes.

Before going into detail I will have to explain some basics of BRFplus. BRFplus functions, which are the interface of ABAP applications and business rules, can be action-based or function-based. But what does the mean? Let me cite SAP library when it explains so called BRF functions which are the interface of ABAP code and a business rule:

A function can be designed for one of the following modes of operation:

  • Functional Mode
    In functional mode, function execution starts with the assigned top expression. From this top expression, the processing may run through any number of nested subexpressions until a result is returned.
  • Event Mode
    In event mode, the function is associated with a list of rulesets that are executed according to their execution priority and their position in the list.

If you are interested in this topic I recommend a look at SAP Library. But please let me summarize:

  • In functional mode you can work with expressions only (and of course nested subexpressions) which are computational units of calculations.
  • In event mode you can use rules (which are IF THEN ELSE operations) and so the central entities of rule based systems. Moreover you can group rules to rule sets which makes complex rules easier to understand. Rules call above mentioned expressions and call actions.

In fact in this blog I will discuss actions and ways to use them properly but before going into detail I’ll discuss an important best practice for rule based systems.

A Best Practice for BRFplus: Use Event Mode Only!

In the following I would like to give you an advice: use event mode only. The reason is that in the event mode you can use rules and rule sets which is quite flexible since rules can have preconditions and can be grouped to rule sets where in functional mode you have only a single expression. This has quite a few benefits:

  • Rule sets can be assigned to a function which is a very flexible mechanism: you can develop a BRF function as part of an application and in an implementation project you can assign different rule sets to this function perhaps in a custom BRFplus application.
  • The rule sets assigned to a function will be processed according to their priority. Each rule set can be enabled and disabled. Moreover it can have preconditions which makes it possible to control execution of different rule sets according to certain criteria. You can use this method for proper modularization complex set of rules. Let me give an example: consider the case that you have different business rules for certain customer groups, countries or companies. Then you can define different rule sets and control the execution using preconditions.

  So the event mode will give you access to the central element of BRFplus where functional mode is only useful for single computations using expressions. Of course you can start a BRFplus project using functions in functional mode but if requirements get bigger (rules face reality and are getting more complex or software logistic must be more flexible) you will have to switch to functions in event mode.

Using BRFplus as Computation Engine

You can use BRFplus (either in functional mode or event mode) as computation engine. The rule machine computes calculations, automatic approval or rejections or performs fraud detections for example.

For me this is the best use case for BRFplus because the separation of application logic and Business Rules. If the execution of business rules is a functional (although in event mode) you can call them without any side effect. This makes it possible to copy the rules, change them and look at the results by processing already processed cases and look at the results. Please remark again that I don’t speak of the simulation of a single BRFplus rule using the BRFplus workbench – I speak of performing the calculation of changed business rule by calculation perhaps millions of calcutions in batch processes to estimate changes in your ERP system. This is really useful, just think at the following examples:

  • Are certain fraud cases detected after changing the rules when changing BRFplus rules in fraud management processes for example? What about false positives?
  • Will the change increase the workload of user since the results will lead to much workload of the users? A the changed rule might judge too much items as to be controlled manually by users.
  • Or is the opposite the case? Are the results of checks too laxly after the change?

  In my opinion we have to design business applications in a way that we can perform simulations. This is extremely important for data driven systems (think of banking or insurance solutions where nearly all business objects are processed automatically. I expect that data driven systems will become more and more ubiquitous if processes from mobile systems reach the backend systems.  

The capability for simulation makes an ERP/CRM application more transparent because experts will be able to  answer questions what would probably happen after changing business rules. This transparency leads to agility because it can reduce risks when changing business rule and make it even possible to change business processes.

Using BRFplus Only as Process Engine

But back to BRFplus: functions in event mode can trigger actions which can be used to start processes in the ABAP application. These can be calls of function modules, the start of workflows, sending emails and creation of message logs which are accessible as protocols of the Business Application Log.

I use the mechanism of creating logs very often and read those logs from the memory and use them in the same way like computations of functions.

But actions are far more powerful and can be used to implement side-effects to rules think of sending eMails to certain users like power users. This can lead to an architecture where BRFplus works like a process engine: BRFplus performs a calculation and then takes over the control of the process flow by starting workflows. It can even throw asynchronous workflow events and change the status of business objects and even running workflows.

Personally I’m a little bit suspicious about these features: at first we separated business rules from business processes and now we are doing just the opposite. You may think of these concerns as a theoretical issue but it has immediate consequences:

  • What kind of workflows BRFplus should trigger? It is difficult to design complex workflows and many of them are too rigid for practical use.  So you could try an alternative and trigger many “simple” workflows instead of a huge one but this leads to another problem: now the business user has many workitems in his or her inbox and can be confused because it may be not easy to understand what to do with a single business object.
  • If BRFplus actions trigger workflow events the design gets more complex because now the business rule has knowledge about business objects and running workflows. If you design such an architecture you should be very careful because of this complexity: it can lead to complex error situations which can be nearly impossible to analyze if you don’t have sound SAP workflow skills.

  But the biggest problem is in my opinion that performing BRFplus functions with side effects can lead to an architecture where simulation is no longer possible. In my opinion you should try to separate BRFplus computations and actions so that still a meaningful simulation of a changed business rule is possible even if you omit the actions while performing a ROLLBACK WORK in a simulation process.

An Advice

When starting to create rule based applications you should consider the following:

  • If you have only a few business rules then using BRFplus might not be the best choice and coding them in ABAP might be the better option.
  • The more business rules you have aspects like governance and a central repository become more and more important and BRFplus might be the best choice.
  • If you create data driven and rule-based applications in ABAP you should use BRFplus. But please be aware that for those applications aspects like change management of rules and the link between processes and rules.

This blog entry covered the last aspect: you can use BRFplus as computation engine and as process engine and within SAP standard software you will find implementations for both architectural patterns. Both patterns have their strengths and weaknesses and you be aware of them.

You must be Logged on to comment or reply to a post.
  • Hi Tobias,

    Nice blog, thanks for sharing.

    Not sure I agree with the best practice. I'll wait for my personal BRF+ guru, Glen Simpson, to comment on this topic (actually, Glen, I'm still waiting your best practices blog 😉 ).

    As for the first point in your advice, how do you know you will have only "a few" business rules? Even if you have only let's say half a dozen business rules, this might, and most certainly will, change in the future. So if you start coding you rules in ABAP now, you will not change to BRF+ when another business rule comes along, because it's just another one. Suddenly will be dozens or hundreds rules and the chaos is installed. So my advice is: go for it now, even if you have just "a few".



    • Hi Custodio

      I'm definitely not a guru... I've just had more opportunity to make more mistakes than you. 😉

      I agree with your idea to "go for it now" with the caveat that you need guidelines and governance in place as soon as practical. I know that's difficult to do when there are no published Best Practices and you have no prior experience in a concept or technology, but if that's the case then I'd recommend "informal governance" via knowledge-sharing sessions and trying to stay consistent with the best practices that you've worked out so far.

      I'm not sure that I'm qualified to write a blog about "The Best Practices" but I might be able to write one about "My Best Practices". I guess I might have already started that with my other comment on this blog. 😛 Will try to find some time...


    • Principally I'd also say: start with brfplus as soon as possible, but there is the issue of having to learn yet another tool. Not all organizations lend themselves to easily adopting new tools and frameworks and institutionalizing the required knowledge/experience. And if for instance only 1 developer has the good sense of starting to use brfplus and the others are not interested, you might end up in a worse situation than before. Sometimes lack of knowledge (sharing) might make it better to stick to ABAP as long as it's not getting out of hand.

      Just my 2ct, Fred

      • I agree because BRFplus is more than "just another tool": it can change the architecture of your custom application. Using BRFplus for isolated rules doesn't make sense because of the overhead. You need the commitment from the chef designer / application architect.

        Best Regards,


    • I think this is a good advice - BRFplus has many advantages. Nevertheless I would like to read your blog post about your experience with BRFplus. What was the most import important lesson you learned within your BRFplus project? Can you tell us about pitfalls when working with BRFplus?



  • Hi Tobias

    There are so many good points in this blog, it's hard to know where to start and stop commenting. 🙂

    "Use Event Mode only"

    This is excellent advice and it's something I also advocate. Not only does using Event Mode future-proof your rule as you suggested but it also allows you to separate the change control of the rule's "definition" from the change control of its "implementation". By "definition" I mean the Function (specifically, the signature), which is often fixed and tightly coupled with the ABAP code that calls it, and by "implementation" I mean the Expressions, which can and should be allowed to change more regularly. Creating a Function in Functional Mode means that the Function and the Expressions it uses MUST be both local or both transportable but using Event Mode allows you to create the Function as a transportable object (my recommendation) and gives you the choice to create the Rulesets and Expressions as local or transportable.

    Calculation Engine vs Process Engine

    I like the differentiation between Calculation (determine a result without side-effects) and Process (perform an action to change the state of the system). I, too, am wary of using BRF+ as a Process Engine for similar reasons to yourself. Firstly, I am a strong believer that rules should be idempotent and have the ability to be simulated multiple times to produce the same result. Rules that create side-effects are not idempotent and therefore cannot guarantee the same result. Take this rule for example:

              IF purchase requisition is not approved and value < 100 THEN auto-approve the purchase requisition

    Obviously, you can't guarantee the result will be the same if the rule is executed for a second time as the first execution may have changed the approval state of the Purchase Req. Alternatively, this rule is rerunnable:

              IF purchase requisition is not approved and value < 100 THEN the purchase requisition should be auto-approved

    After executing this rule, the caller has the option to re-execute the rule, carry out the approval or just ignore the result whereas this option is not available for the first rule. To encourage rules like the latter I often ask colleagues to rephrase their business rule as a question using business terms only. Phrasing the rule as a business question (eg. "Should Purchase Req be auto-approved?") usually ensures that the rule does not carry out unwanted actions but it also prevents the rule creator getting bogged down in technical detail of "how" the rule will be implemented before the rule is even defined properly.

    The second reason that I am wary of using BRF+ to carry out actions is one based more on bias than architecture... I am an ABAP developer and it generally makes more sense to me to do the action part in ABAP than to execute a second BRF+ function. I'm sure there are probably reasons or situations where calling a BRF+ function to carry out an action is preferable (workflow, maybe?) but I don't think I've encountered them. I'd be interested to hear other opinions on this.

    "If you have only a few business rules then using BRFplus might not be the best choice and coding them in ABAP might be the better option"

    I don't fully agree with this one but I think I would if it was amended slightly: "If you don't have guidelines and governance for BRF+ rule design in place then coding your rules in ABAP is a better option". There is no reason that BRF+ can't be used for small changes but unless those rules are designed properly and consistently then you may end up making a mess of your rules repository.

    "The more business rules you have aspects like governance and a central repository become more and more important and BRFplus might be the best choice"

    I think that governance over rule design is a VERY important piece of the BRF+ puzzle and its something you need to work out very early on. There's  quote in one of the BRF+ marketing slidepacks that says something like: "electronic concrete", once poured, is hard to get out. I think it's meant to convey that BRF+ rules are less like concrete than traditional (ABAP) code and so, easier to change. Whilst I agree with this to a point, I also think that once you create a handful of BRF+ objects in a certain way, in certain BRF+ Applications, and promote them to Production then it can be very hard to justify changing the structure of those objects later, just to tidy up your rule repository and make your rules consistent. This is why my first piece of advice to anyone thinking of starting to use BRF+ is "1. Governance, governance, governance" 🙂

    Thanks again for your blog and for highlighting some important points.



      • Thanks Sascha. 🙂

        Maybe my comment will morph into a real blog post at some point in time...

        Kudos still goes to Tobias for kicking it all off.

        • It seems to me that there are many topics I would like to read your opinion and best practices in a blog.

          The first topic was already mentioned: best practices for use of named objects resp. applications with reuse objects vs. use of anonymous objects. It is really funny: when creating my first BRFplus rules I tried to make reuse of much objects and got into trouble when I had to apply changes. Later I tried the opposite and used many unnamed objects which caused an inflation of objects and I couldn’t reuse some well designed expressions. Now I’m doing a mixture between both depending some heuristics.  I would like to hear your opinion.

          Another interesting aspect is testability which is a bit painful in BRFplus. In pure ABAP applications rules are hard coded or configured using customizing. The latter could be a test customizing in a development system (resp. client) or could be provided using mock objects and with ABAP Unit I can do regression tests. In BRFplus I’m writing test applications that allow to upload test cases (values of the context) as CSV files. But this could done better. Carsten Ziegler announced a test framework for BRFplus. Is it released? What are your opinions about it?

          Best Regards,

          • Hi Tobias

            Regarding named vs. unnamed objects:

            We probably need to separate the concepts of creating named/unnamed objects and the actual reuse of named objects. In my view, it's important to create (sensibly) named objects in nearly all situations as this allows the potential for reuse however the object should only be reused if it is semantically correct in a particular context. For example, you could create a Value Range Expression containing the list of "Domestic Sales Order Types for Process XYZ". It should be obvious from the name where this object can and can't be reused but if you gave this object a name like 'ORDER_TYPES1' (an over-exaggerated simplification 🙂 ) then it is difficult to know where it can be safely reused. If an object is sensibly named and reused only in the correct context then there should be no issues with subsequent maintenance of the object... eg. to add new domestic sales order types for process XYZ.

            One place where I deviate from this "it's better to create named objects" guideline is that I rarely create named Rules, mainly because there is no option to do so when creating a Rule from within a Ruleset. I haven't encountered too many situations where reusing a Rule gave me any major benefit so it hasn't caused me any issues so far.

            Regarding the test framework

            I'm afraid I'm not the best person to comment on this. As much as I'd like to be, I'm not very experienced with test frameworks and TDD. If you can suggest a good resource for best practices for TDD in SAP development (more than just a "how to") then I'd very much appreciate it.

            I recall seeing a discussion thread about unit testing with BRFPlus but I haven't heard any official announcements about a testing framework. I may have missed it though...



    • Hi Glen,

      thank you for your remarks – you mentioned really important points.

      What reasons can I imagine not to use BRFplus? Sometimes you already have a calculation engine in SAP standard (mostly driven by complex customizing) that you have to use for the reasons of consistency to SAP standard. In this case I check whether all computations could be done without any (or only very few) new customizing values using existing function modules could be done in ABAP easier. What do you think about it?

      What about the case if there is no existing calculation engine in SAP standard: are there reasons to prevent you from BRFplus? I’ll give you an example where the use of ABAP might be sometimes better. There are Business Rules which rely mostly on database lookups that have to performed using BAPIs since the data might have been changed in an earlier stage of the process. If I want to implement this rule using BRFplus I have two possibilities: I can SELECT everything before calling the function with consequence of a huge signature or I have to use many procedure calls which means to create a new BRFplus wrapper for existing ABAP code. Both is not satisfying because bridging the gap between ABAP and BRFplus could take too much effort especially when the rule could be developed in ABAP without any new customizing. But please be aware that this may change: In NW 7.31 I found a BOPF adapter for BRFplus which could bridge the gap and makes the use of BRFplus much easier.

      Best Regards,

      • Hi Tobias

        I should have clarified my comments by saying that I mostly use BRFPlus when implementing custom rules for custom applications or custom rules for enhancements (BADIs, user exits, etc) to standard applications. In these cases, I have control over both the caller of the rule and the custom rule itself. You are 100% right that if there is existing customizing that meets the requirement then it does not make sense to replace it with BRFPlus. I was only suggesting that if the options are BRFPlus or a new custom table/hardcoded rule then I would choose BRFPlus.

        Your second scenario is an interesting one and something I have pondered too. The only time I am happy to use a DB Lookup is when I'm reading a pre-existing customising table or a table that I can be almost certain will not be changed before the rule is called. If transactional data is required then I will nearly always pass that data into the function. I can't think of any situations where the signature has grown overly large but I can imagine that there probably are such scenarios.

        I think one good reason to use BRFPlus instead of ABAP, despite the potential for bloated function signatures or increased effort, is that your rule will be discoverable in a central rules repository rather than being hidden in code. There are probably other good reasons...



  • I would like to add one more, non-technical, aspect to consider: organizational readiness. Most likely it will be application experts who creates and maintains the rules. If not, then at least it is the application expert who will write the functional requirements. Application experts are very used to thinking and expressing requirements in terms of custom (z,y) tables which they are currently not with BRFPlus. The lack of experience could lead to more inaccurate requirements, longer development time, and more maintenance errors. That said, there are lots of cases where the benefits of BRFPlus outweigh the disadvantages.

    • That's a very good point too. Often, the introduction of BRF+ requires a lot of evangelism within the project team (let alone the end users) before it is accepted as "the norm". Sometimes this is the hardest part!

      • Excellent point. So what do you think is the right way to start with BRFplus? Which SAP trainings are useful / necessary?

        Best Regards,


    • I think working with data models is not that bad and when working with HANA they will become even more important. So what are the specific dangers when people think in terms of custom tables and how can you overcome these problems?

      Best Regards,


  • @Tobias: Once again this is an excellent blog and it is further very interesting for me to follow the discussion.

    @All: I think it may be a good idea to host an open discussion forum as a telco with webex session where people can openly give feedback and discuss questions. If this is interesting to you I can take care for finding a date, infrastructure, invitations and minutes. Maybe I will write some kind of invitation blog.

    Some more comments to the blog:

    - I recommend the creation of decision maps and establishment of the rules analyst role (support business teams in rule design, discuss integration points with IT, ...)

    - I miss the SAP NW DSM add-on in the discussion. It adds some very interesting capabilities that also have strong impact on application design. Then statements like the following have to be checked again "If you have only a few business rules then using BRFplus might not be the best choice and coding them in ABAP might be the better option."

    - My biggest lesson is that often rules are built by a developer for a developer. However, rules should be written for non-developers using for example nice description texts.

    • Hi Carsten,

      A public conf./webex call to further discuss this would be great. Especially to cover DSM and how that changes the application design dynamics, which I don't see yet (but always ready to be convinced otherwise 🙂 ).

      Another idea might be to host an expert networking session about this topic at sapteched Amsterdam.

      Cheers, Fred

  • hi Tobias and all

    I have worked with BRF+ in Public Sector module where it is integrated into the Tax Assessment framework. We started using it a couple of years ago when it was first released and found that it was substantially slower to implement business logic in BRF+ than it was in ABAP code, mainly because BRF+ had not long been released and there were many teething problems, and we were new to its use. This caused grief for project management and as a result there was a reluctance to continue using it on subsequent project releases which I think was a bit of a shame as it has its merits for managing complex business logic.

    One major advantage of BRF+ over ABAP is the 'lean trace' it provides out of the box, no longer do you have to replicate an issue to be able to find its cause, the trace gives you a step by step log of what happened, the results of expressions and the values in the context. Business rules may take a bit longer to develop in BRF+ but it does make your solution more supportable in the long term. I'm not convinced that BRF+ is a tool for anyone other than developers.

    thanks for the blog


    • John,

      I understand your comment concerning "teething". 😉

      What I do not share is your assessment at the end and concerning the speed of building rules. Maybe there is also a difference between the version you used and the latest one with drag and drop etc.

      I have traveled to many customers over the last years and in many cases I had no time to prepare upfront for the use case. So I often went into the first discussion without any preparation. In such as case BRFplus is a perfect tool as I can sit together with business and IT experts and model the rules together with them. They do not need to learn ABAP or so but can comment, discuss and provide feedback instantly. They identify gaps and contradictions in the rules - which are often not seen when written down in lengthy requirements or design documents. I know several projects where functional experts were leading the rule creation. Although of course I agree some parts of the rules (e.g. data binding, data retrieval) require developer support. But often it is the decision tables that change. In BRFplus you can control change and limit it to certain expressions.

      And even in cases where business people were not allowed to toucht the rules, the benefit of design and execution transparency can speed up the process of implementation significantly. On the other hand, having more people understand what is going on may also result in more (productive) discussion about the rules. Whereas the black box approach (ABAP) code excludes a lot of people and finally everybody checks his tests cases to ensure his case is covered.

      Very important is the design of the rules. Rules have to be built for non-technical people. There are many ways in BRFplus this can be achieved (see some of my blogs).


      P.S: With DSM support you can simulate your rules in the productive environment without transport or productive use. You can update your rules on mutliple systems at the same time within seconds. You can fall back to previous versions in the productive system within seconds and so on. I will write a blog about this soon. You do not have this in ABAP.

      • hi Carsten

        thanks for the reply

        I haven't worked with BRF+ in its current state as we couldn't patch it, we tried but found that PSCD was too tightly integrated with BRF+ and it broke, unfortunately SPs were out of the question (don't ask). So I'm probably not well qualified to make a judgement on development speed (hence "may take a bit longer"), what I was trying to say is that even if it does take longer its worth the time investment for the visibility of logic and trace functionality.

        Good news is that I am about to use use it in a 7.31 environment on a custom development so am looking forward to using a stable version 🙂 .

        thanks john

        • IMHO BRF+ in NW 7.02/7.31 is quite stable. The only problem have been changes in the UI which produced many errors at the frontend which can be seen in various OSS notes. In later SPs (I tried SP6 and SP8) this is quite stable.

          Best Regards,