Skip to Content

Old BRF(Business Rules Framework) Implementation Strategy Guidelines

BRF Implementation Strategy Guidelines

Executive Summary:

Reason for such a blog expands with the need of maintainability of previous functionality whilst building a comprehensive solution with a higher degree of flexibility in terms of amendments for future releases.

Such a document should be followed in order to implement new business requirements that are to be in-line with a customer’s blueprint and standard sap guidelines.

Please note: this blog refers to the old Business Rule Framework tool.


     – Faster knowledge transfer

     – Organised and easy to access rules portfolio

     – Lower implementation costs

     – Helps to define a migration strategy for business rules

     – Lower maintenance costs


Active Global Support:
Florin Niculescu ( – Insurance Safeguarding Portfolio

Thus, the procedure for tackling:

     1. Need for maintainability

    1. Brf rules belonging to a similar functionality should be bundled under a certain rule set. There shall not be objects that are used across multiple lines of business – hence it is better to recreate / copy, based on the lob guidelines for creating new objects
    2. Each object created under brf should have comprehensive description and in case of expressions, actions, these should be referenced to the right place in the blueprint.
    3. Custom tasks(activity management) are not to be created by hardcoding, this will render us without any trace of brf customizing – worst case scenario is that these tasks are belonging to a certain line of business process – meaning they will be grouped under a rule set with possible custom events and corresponding customizing in place for expressions and actions.
    4. Shall avoid creation of objects of complex logic within a brf expression
    5. Shall not raise tasks from expressions, using anomalies, but from actions
    6. If old functionality needs to be amended – copy the necessary objects amend them and create new customizing in the rule set – do not remove the old objects logic from the rule set customizing – but deactivate them – reference each brf object with the new blueprint reference, usually based on it`s blueprint id
    7. Technical documentation for BRF rules is to be maintained separately under a global technical document template designed for brf rules. Reference to it is to be specified in the technical specification of built functionality (rfc) and functional specification with corresponding references (like it is now)
    8. When describing a brf functionality within a functional analysis try to use a formula like :

Ex.:  Segmentation Rules Template











set complexity to 8






set complexity to 7





Create log entry “L_CNooo”







Trigger task “T_CN ooo”






set complexity to 9






set complexity to 8

You can replace “Rule 1” with blueprint reference and “condition 1” with something like “risk file checked?” or “complexity < 7?” – Based on this approach we can easily devise dependencies, redundancies and take a fast decision on which objects are better to use for implementing the requirements

     2. Need for Migration to BRF plus

    1. Use function modules when creating brf expressions, as much as you can. If this activity consumes a lot of time from an effort perspective and the logic of it is simple then you can make use of customising abilities of the tool.
You must be Logged on to comment or reply to a post.
  • Hi Florin,

    I hope that BRF is a global "typo" and you mean BRFplus. If yes I would recommend correcting this. If this is not a typo and you really meant the old BRF I would state that the information provided here is outdated: the strategic tool for business rules in the ABAP stack is BRFplus (including S/4HANA according to the principle of one) and not BRF which is some kind of deprecated. If you start implementing rules (which means you spend money) then go for BRFplus

    Therefore, my next feedback is based on the assumption that you meant BRFplus:

    • In general, I do not really get what this blog is pointing to ... use BRFplus/ a rules engine to avoid custom code, migrate to BRFplus ...
    • A) Why should you want to copy objects if they are used across multiple lines of business? These base or cross-lob objects should be treated as such. You can introduce a globally visible application with those objects and reuse them from there. You wouldn't do that for ABAP code, so why should you introduce clones in BRFplus
    • B) The important point is: use the long text for that requirement, not the short text. Leave the last one empty and the stuff is readable. You should also mention that there is no benefit on that as long as you do not make the right settings in the BRFplus workbench
    • C) No idea what is meant by that description
    • D) Why? If the decision logic is complex, so will be the rules. You have to find the right ways to modularize the rules, but you will not be able to take away the inherent complexity in rules
    • E) Expressions are anyway not allowed to have side-effects. Actions are also not really recommended and in my personal opinion should be avoided (a rules decides what to do, the process triggers the consequent steps according to the decision)
    • F) Strange procedure. In BRFplus there is a dedicated lifecycle for the objects that could be used here
    • G) What is a technical documentation for BRFplus objects? Rules intend to be at least readable by business experts, so what technical info are needed. Why should you  want to distribute documentation if you could have it in one place

    Encapsulation decision logic ok, but why to put in a function module and not via a class-based approach?

    A lot of questions and comments, but from my point of view a quite debatable post

    For the sake of completeness: The expert space for BRFplus in SCN is here: SAP Business Rules Management. Should be mentioned in the blog in my point of view



    P.S. As this is not your first post - take a look at The SCN Rules of Engagement (especially item 6). This one also goes for SAP Active Global Support imho i. e. the contact info provided here

    • Hi Christian,

      I agree with you in all points. When I read the blog I could not really understand the point and how these strategies would apply. Specifically, I find the recommendation of using a function module and the technical documentation irritating and potentially even misleading.

      However, Florin might have created this blog based on his projects' implementation experience.



    • Hi Christian,

      this refers to the old BRF in regards to technicalities, but when it comes to concepts I believe some of these might be applied to BRF Plus, too since you mention it. The main purpose it to keep things simple.

      I will be franc your approach is a bit too technical for me, so I'm not sure to which extend the ideas you mentioned are best practices is a real implementation scenario.

      As far as my knowledge goes in regards to your comments:

      A) This is what I'm saying instead of making it cross line of business, do it lob specific, would be much more easy to find something in there. But then again it depends on the volume you have to deal with.

      B) Is referring to maintaining an alignment of what is in the system with what is in the blue print. I believe this is a decent approach.

      C) Refers to activity management as a best practice to use - I saw a lot of these directly hardcoded in expressions for example.

      D) Simple. the less complex this is, the less code is generated to process it. BRF as well as BRF Plus generates code - this makes processing of rules, in health insurance for instance pretty much performance consuming.

      E) in BRF there was a functionality where you were able to add anomalies directly to expressions - this is obsolete and pretty hard to trace/find if you don't know about it up front

      F) it is about BRF

      G) A good place for documents is Solution Manager and not BRF Plus; how many business users you know of saw BRF Plus and said it is self explanatory?

      The use of function module assures that migration of logic to BRF Plus is easier, and in addition the amount of code that is generated in the background is less.

      This also contradicts your comments on point G): if you agree to put the logic in a function module or class of your choice I don't think this will appeal to many business users as readable.

      I agree that the topic of BRF is outdated, because it is an old tool and all new rules should be created under BRF Plus, yet perhaps this is useful afterwards.

      Thank you for your comments !

      P.S.: I take it you saw a lot of BRF / BRF Plus implementations? So your experience might be different from mine. It is just in my view that what you are saying even if it's about BRF Plus seems idealistic. In my experience the reality differs.

      • Hi Florin,

        I agree on the fact that concepts concerning business rules are to some point agnostic to the rules engine that is used. But you are indeed not talking about concepts, but about how to build something in a rules engine. Anyway, as this is on BRF no further comments from my side on the content (especially as according to your answers you mixed up BRFRplus with BRF and some rules concepts).

        Concerning the P.S.: I did not make a statement what is running good or bad with BRFplus (there are definitely a lot of traps) - my point is that publishing a blog on BRF and how to do rules in BRF in the year 2016 does not add any value for the community here and even worse might lead some readers onto the wrong path in new developments as there is no clear summary.



        • Hi Christian,

          I understand your point of view (it only seems right to make an amendment in the summary in order to clearly specify that this is the old BRF) and indeed it might seem outdated and misleading to someone like you, who has lots of knowledge of BRF Plus.

          My observation was that the insurance industry is one of the few industries which is very much conservative and to some extend reluctant to change.

          Please take a look in the change of insurance products during the last 10 - 20 years, there are a lot of articles and reports on the internet from verified sources such as IBM.

          Having this in mind we might still have customers that are running both BRF and BRF Plus (customising allows behaviour for both rule engines, BRF as well as BRF Plus, to run in parallel. E.g. is the insurance solution for Claims Management). So the question here is, what can we do to support them, if it comes to it ?

          Please let me know where you think I've mixed up BRF with BRF Plus, so I can correct it?