Skip to Content
Author's profile photo Tobias Trapp

What are your BRFplus Best Practices as ISV or Architect of a large Custom Development Projects?

Most people in custom development who work with BRFplus use it for two purposes:

  • SAP exposes a decision service and developers implement rule sets in own BRFplus applications and assign it to a function. This can be quite challenging since it would be desirable that decision management fulfills same business strategy in all lines of business of an enterprise and so within different applications within the value chain.
  • BRFplus is used to create own decision services in custom applications.

  ISVs but also large custom development projects know both use cases but are facing additional ones:

  • ISVs (like SAP) create BRFplus applications that are fundaments of rule sets that are implemented by their customers.
  • ISVs implement rule sets of SAP standard applications instead of their customers.
  • ISVs extend rule sets of SAP standard applications that are implemented by their customers.
  • ISVs create business rule sets for their customers.

  I won’t discuss the last use case which is in fact a perfect use case for SAP NetWeaver Decision Management Service but the first ones are really interesting since they raise questions about best practices.

In the following I will discuss the most common case: an ISV (an SAP Partner) develops application containing a BRFplus function and customers assign their rule sets to that function. So a rule set consists of two parts: a basis shipped by the ISV containing a BRFplus function and a BRFplus application created by a customer. The challenge is that there is no single development landscape and the whole solution is developed on different landscapes but has to fit together. And this can get complicated because of transport of the rule sets, versioning issues of two different rule sets in different landscape and (multi-layered) extensibility.

What kind of artifacts should ISVs ship and which Storage Type is most useful?

Obviously an ISV has to transport ABAP code that calls the BRFplus function, the BRFplus function, data elements that build the signature of the function. Sometimes it is necessary to ship some expressions (think of formulas, own expression types as well as procedure calls). Those artifacts as part of a partner solution can make the development of custom BRFplus application on top of that partner solution easier.


In my opinion it makes sense to choose system storage type for the partner application. The storage type customizing is not that useful: a rule set basis is governed and can be changed only by the ISV. But there is another reason why I prefer system applications: they can be shipped as part of software components built using the AddOn Assembly Kit in contrast to customizing applications  which are neither ready for shipment as BC Sets, moreover transport management of customizing applications is more cumbersome.

Transport from Development into Maintenance Landscapes

In larger custom development project the system landscape is more complex and besides development system there are maintenance systems that are used for shipment of hotfixes and in-advance shipments. Sometime it is necessary to port software from development into those systems. If BRFplus artifacts are part of that application you have no other choice than to transport a BRFplus application or parts of it. The reason is simple since all BRFplus artifacts are identified using GUIDs and a new created data element has two different IDs on two different systems even if the data elements have the same technical name. So if a customer uses the data element (shipped by the ISV from a maintenance system) in own expressions the ISV has to ensure that data element is shipped in a later release from regular development landscape with the same GUID otherwise the rules and expressions defined by the customer using the element with the old GUID will break.


So here is my first question: How do you transport BRFplus applications from maintenance to regular development or vice versa? Do you use the transport system or XML upload and which import parameters do you use? Do you transfer always the whole application of parts of it?

Best Practices for Extensibility

Most SAP Partner applications have to be extensible like applications of SAP Business Suite. Here we can distinguish different case:

  • An SAP partner (think of a solution provider) uses an extension technology and switches it on and ships the switched extensions to the customers. The extension can be switched functions/data appends, partner AddOns as well as switchable extensions created by the partner.
  • an SAP partner uses an extension technology and switches it on but doesn’t ship the switch settings so the customer has to switch those functions/data model extensions on in his landscape.

  In fact the second case is much more challenges since the changes in the data model require actualizations of BRFplus elements which can’t be done due to storage type. Of course BRFplus is well prepared for this: there are many user exits that allow changes of the system behavior here. But more interesting is the question about best practices:

  • How do you create extensible rule sets?
  • Are there besides generative techniques of BRFplus other approaches for extensibility? How far can you go with procedure and database calls for example to integrate extensions of the underlying data model?
  • What are best practices for rule sets where data models contain multi layered extensions – think of SAP Business Suite – industry solution – partner AddOn – AddOns for special customers – additional extensions by the customer?

  In fact I already had to solve one of these problems and found a simple solution: if there are extensions that are done by customers outside my development landscape I’m using a mix of generative approach and generic techniques to pass the data to a generated function. This is useful when the generated function is completely different from the one I’m using in my development system. But here I have many questions:

  • Wouldn’t it be great to have a mechanism for derivation of data types and function signatures in BRFplus?
  • Of course derivation introduces additional complexity for the BRFplus framework, the ISV and the customer so are there ways to avoid it? Are there other extension types like database or procedure calls and when should we use them?


I mentioned only two challenges in larger ABAP development projects resp. development of partner solutions but there are more. BRFplus and its successor DSM are great tools because of their openess and provide many possibilities to deal with those challenges out of the box.

But it would be interesting to learn how other partners solved above mentioned challenges and what kind of best practices they have. And SAP could help two, since development of SAP Business Suite faces some of above mentioned challenges and SAP could tell how they’re working if they are developing rule based solutions that slightly(?) differ in various system landscapes.

Assigned Tags

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

      When I lived in Germany, for a while every lunchtime i read the BRF+ book from SAP Press by Cartsen Ziegler.

      As I was in Heidelberg, despite being in a Beer Garden type pub, no-one found it odd I was reading an SAP book, as Walldorf was the town next door.

      I was very impressed (about BRF+ not the beer, though that was good as well) and as soon as I was back in Australia I started shouting about this (BRF+ not the beer) as loud as I could. No-one at my company had even heard of BRF+, despite being on ECC 6.0 for a year.

      I wish I hadn't bothered. There is one developer who is utterly convinced, everyone else thinks I am a fool. The CIO however was VERY interested.

      It almost came to blows last week, out of nowhere one of my collegaues talked about my latest project and out of nowhere he said - "this project has really complicated business rules - don't you dare use that BRF+ nonsense, otherwise the CEO will sack you".

      I instantly denied that was my plan, though I had been considering doing exactly that, my only concern had been performance, but I emailed Crasten Zeigler - and he emailed me back - setting all my concerns to rest. BRF+ uses generated ABAP code so at runtime there is no database access i.e. no performance hit, so no problem at all.

      I'm still not going to use it, because my organisation is not yet ready. If I make a mistake in my normal ABAP code, BRF+ will get the blame, and that will slam the door in it's face for a long time.

      What i want to see is BRF+ being used in standard SAP. Until that point I think I am right out of luck....

      Cheersy Cheers


      Author's profile photo Tobias Trapp
      Tobias Trapp
      Blog Post Author

      Hi Paul,

      I can’t understand the reactions of your colleagues. It sounds to me like the first reaction of old-school ABAPers when they heard about ABAP-OO for the first time. I knew managers of ABAP custom development projects who tried to forbid CALL Method command because ABAP-OO was considered complex, complicated and harmful. But that changed: without knowing the basics of ABAP-OO you won’t be able to develop ABAP UIs even in ABAP Dynpro. This has changed and the attitude towards BRFplus will change too. BRFplus can make ERP systems more transparent, faster and easier to change. I suggest you to read my blog entry:

      In this SCN space there are so many tutorials that starting with BRFplus is so easy.

      In above blog entry I’m dealing with really advanced aspects for BRFplus and most of BRFplus developers won’t get  into touch with the questions I discussed above, soon.

      But in my opinion ABAP developers should learn BRFplus and it is a superior technology. I proved this many times. Some weeks ago a developer came to me and asked me how to create a simple rule set. We discussed the requirement and it became clear that it can be developed using a decision table. I created it and copied the 200 entries of the specification into excel, changed it a bit, loaded it up and after two minutes I implemented a decision service in BRFplus without addition DDIC elements and customizing, table views and so on. From that moment the developer was convinced – so my suggestion is: your collegues shouldn't  theorize about BRFplus unless they have real skills – they should just start with it and create better business applications faster than before 🙂

      Later your colleagues will come to interesting and challenging aspects like homogenous decision management in theenterprise, consistency between business rules in all parts of the value chain, rule analytics and multi-layered extensibility of decision services and this is what I'm talking about in this blog entry. These aspects are really challenging but they don't prevent you from using BRFplus. BRFplus on its own can improve your applications by itself in many ways and there is no need to be afraid of this framework.