Configuration By Exception: Why BRFplus is Superior to Customizing

If you are reading my blog you will have recognized that the business rule framework BRFplus resp. DSM is my favorite topic at the moment. The reason is simple: I consider it as strategic technology, I’m using it successfully and many colleagues of mine ask me about my experience. Luckily I have very smart colleagues and they are asking me good questions. Today a senior developer heard my explanation about BRFplus and had the following remark:

Ok, you may be right that BRFplus is more powerful and flexible than customizing but customizing has one big advantage: I can use it for configuration by exception. Often my processes are standardized and I can ship the configuration (= business rules) as customizing content. Often this is exactly what the customers want but if they would to change it I create a second customizing table which is empty and filled by customers in a customizing process in a kind of “configuration by exception” approach”: the framework reads the customizing entries from both tables and if there’s an entry found in the second table it overrides the first one. So using customizing you can implement a transparent and lean approach to system configuration by implementing only exceptions. So have to the advantages of both approaches: My applications are running out of the box with reasonable “master customizing” that can be overruled in a “configuration ba exception” approach.

This approach is really clever since it gives a solution to a common challenge: developers want to make implementation and maintenance of a customizing-driven application easier by shipping a “master customizing” which is owned by them and also introduce a two-stage approach that allows to overrule the customizing by customers. This approach has some advantages but also some problems, which I will discuss, too. But at first this was my response:

With BRFplus decision tables you can do exactly the same:

Just create a names decision table that has the same functionality as the customizing table. Use is in a rule set that can be assigned to a function.

If a customer wants to have a configuration by exception mechanism he can copy the decision table and create another one for his entries as well as a simple rule that performs the two-stage approach described above.

Of course speed it up be providing a BRFplus customizing project with exactly this functionality but can be used by the customers (or generate it in the fly using the BRFplus API).

I consider this approach as superior to the customizing solution:

At first it will be faster since you need no database access – BRFplus compiles everything to code.

Decision tables are more powerful than customizing tables since they support expressions and ranges. Moreover there are automatic checks for them as well as excel integration.

They have a version mechanism that is superior to customizing.

And last but not least there is a solution to a maintenance problem: If your “master customizing” changes this often requires an information process to people who overruled the “master entries”. With traditional transport mechanism (transport / BC Set) this is complicated, but you could use the BRFplus API to inform about changes or generate documentation about changes.

The following discussion shows a very simple fact: SAP solutions are extensible and configurable. The reduce the implementation effort and speed up the implementation process developers created quite sophisticated solutions in the ABAP world that are comparable to paradigms like configuration by exception which are quite common in the (more agile) Java world. But with BRFplus you can implement exactly the same solutions and even improve them.

yes, we can start to use BRFplus for configuration purposes. At the moment I’m still thinking how to use the configuration by exception paradigm in BRFplus for business rules and this blog entry describesmy first idea. As software architect I want to create applications that can be installed as easily as SaaS solutions. The variant I discussed above decribes”preconfigured” a BRFplus application that can easily adapted or even replaced by the customer.

There is only one advantage of keeping configuration data as customizing: viewclusters are a great tool for maintenance of customizing in a single dialog and there is a good integration into IMG which is standard for configuration of SAP applications.

And this is a challenge of BRFplus since it lives in a WDA environment and I don’t like browser windows popping up. What can we do?

We start a transaction that opens BRFplus workbench with the application we want to change (what about configuration in the side panel)?

We invest and create WDA based installation cockpits with self check functions like SAP Workflow configuration. This would be really could and would installation and implementation costs of an application dramatically.

We develop an own UI on top of BRFplus for an easier configuration – there are SAP applications who chose the same approach,

To be honest this is not a problem of BRFplus: we have to find out how ABAP Dynpro and WDA can live side by side. The BRFplus development team at SAP did a great job by providing an API an reusable WDA components but when BRFplus gets ubiquitous we have to find dialogue standards for IMG integration.

I think this is what I should do: I should find out like SAP did solve this by looking at examples at MDG, Transportation Management and so on. Do you have good starting points? SAP Library may be not that helpful since they don’t use pictures.

Yep, I understand the concern with mixing SAPGUI and WDA as the user experiences can be quite different. I’ve struggled with this myself.

The differences can be reduced if the SAPGUI theme matches the WDA them (eg. both use “Signature” theme) and you run the SAPGUI and WDA apps in a portal or NWBC but this isn’t a perfect solution. It’s also one that you (as an ISV?) probably won’t have much control over.

Another option, if portal/NWBC is not feasible, is to create a parameter transaction based on transaction WDYID and set the STARTMODE parameter to “GUI”. This will open the WDA app (eg. the BRF+ Catalog Browser) inside a SAPGUI window. This might be less “visually jarring” to the user than a browser window popping up over the top of the SAPGUI but, again, it’s not perfect.

I’m afraid I don’t have an ideal solution but I hope this helps a bit.

I think it makes sense to create small WDA cockpits called from SPRO that help to configure your application and most important the connection between the ABAP application and BRFplus. Carsten Ziegler described the techniques for BRFplus UI integration in his book but also wrote that there are much more features but this is beyond the scope of his book. Maybe he can give some hints and point me to good examples in SAP Business Suite.

At the moment I’m asking whether the WDA application FDT_WD_DEMO_EMBED_UI describes all features.