What is the “Plus” in BRFplus?

[ttrapp]

Carsten Ziegler did a great job promoting BRFplus an SCN in blogs, with his book and SAP TechEd lessons. He also published a very interesting paper on the differences between BRF and BRFplus: http://scn.sap.com/docs/DOC-4559. It seems to me that BRF was quite unknown because it was mainly used in the SAP for Insurance Solution and in contrast BRFplus is the successor of BRF and all other rule technologies with the ABAP world. For those who don’t know the differerences between BRF and BRFplus I will summarize some important points and their consequences:

• BRF has poor editors compared to BRFplus. It’s more difficult to create and to analyze artefacts.
• BRF rules are more complex since you need additional expressions to access the context. Another reason for complexity is that you don’t have expressions like decision tables, so you had to do it all on your own.
• As a consequence BRF developers sometimes defined own expression type and used sophisticated expressions for their purposes. And of course they wanted to reuse them which also increases the complexity of the BRF rule sets because you have to take care of side effects.
• BRF artifacts are identified using application, type and name. If you can use only one BRF application (because the SAP supports only access to one application) you have to be very careful and use difficult naming conventions to keep order over your rules. When moving from BRF to BRFplus the naming conventions will often stay because otherwise parallel maintenance and compararison will become difficult in the implementation phase.
• Last but not least: as a consequence of above mentioned drawbacks most BRF rule sets became too complex that only experts know how to change them.

·      Another drawback of BRF was the speed of execution because of interpretation. When I first came in contact with BRF in release 6.20 the problem was visible in the debugger: when working with simple expressions there was a deep inheritance hierarchy and since ABAP has in release 6.20 (perhaps this changed) no mechanism of VTABLEs the speed was very poor. As the consequence BRF experts sometimes tried t change the rules to optimize their execution speed which often make them too complex. In BRFplus this is not necessary but BRF experts sometimes tend to optimize rule sets too early.

In my last blog about BRFplus I discussed architecture principles of BRFplus applications that in fact apply to every rule based systems architecture: http://scn.sap.com/community/brm/blog/2013/08/11/architecture-of-brfplus-based-applications. Now I want to discuss what those differences mean for implementation projects.In my opinion using BRFplus can make the implemented rules more tranparent, it allows you to be more agile and focus on business processes because you don't need to care about pesky technical weaknesses of BRF. But this also means that BRF experts who start working with BRFplus hat to question their BRF practices and change their mind. In this blog I'll discuss only some aspects and I would like open the discussion and I hope as a result I'll be summarize the discussion to give BRF experts a concrete advice when starting with BRFplus.

Difference between BRF and BRFplus from the viewpoint of an Implementation

What does this mean for BRF experts who enter the world of BRFplus and know only a little about the features of BRFplus?

• At first they ask for naming conventions because in the past they are the only way to control complexity. My answer to this question is very simple: If they want to use their old naming conventions they can do it but this shouldn’t slow down the implementation of a BRFplus implementation. Since all objects are identified using GUIDs you can rename objects very quickly. So my first advice is: start working with BRFplus and rename the objects afterwards since this is very simple in BRFplus.
• A crucial aspect is reuse. Since BRF has much overhead compared to BRFplus reuse makes sense although it is difficult because of side effects. For BRFplus my answer is that you should try to reduce the complexity and do reuse only if it is absolutely necessary.
• As I already mentioned in BRF artifacts are identified using names and not GUIDs. This makes it possible to define expressions that use standardized elements that are centrally governed and can be easily “injected” in BRF applications for creating a common reuse layer which is useful if the BRF “frame” (elements, functions and some expressions) are developed in a central manner (think of a concern in business) and rules, rule sets and additional expressions are developed by local companies belonging to the same business group. In this case reuse of elements between BRFplus applications can help you but also increase the complexity  may come to point that the use of SAP NW Decision Management may be absolutely necessary. I think in this case it would be interesting to discuss BRFplus design patterns.

In the following I would like to discuss a very simple BRFplus design pattern for reuse:  

• When creating a new BRFplus application usually all my elements and expressions are reusable and potential candidates for reuse. Procedure call expressions arte good candidates for reuse since it indicates that there is a functionality that can’t be done in BRF (think of calling BAPIs) or is too difficult to be implemented in terms of BRFplus.
• But even if I identify candidates for reuse I’ll question whether reuse is necessary especially if I move these expressions in a lower “basis” application because reuse makes only sense if all “client” applications can be changed at the same time if the expression changes otherwise there is the danger of unwanted side effects. This is not surprising because we expect the BRFplus runtime (another “basis” application) to be stable, too, so that changes don’t affect other BRFplus implementations.

  So my current best practice is currently the following:  

• I reuse the context elements and use variables only if necessary.
• Expressions are reusable but I try to reuse them only when necessary. I think in BRF my reuse factor was a little higher compared to BRFplus.
• Rules are sometimes reusable but in many cases they are unnamed and “tied” to a ruleset. I make a rule reusable when it makes sense to me from a business perspective and the BRFplus represents a real business entity with semantic that makes reuse likely.
• In BRF I defined huge projects and tried to reuse many expressions because of technical reasons and in BRFplus my advice is to introduce more redundancy and focus on the business perspective when doing reuse.

But I want to say that these are only a rule of thumb when comparing  BRF and BRFplus implementation - and depending on the project I’m working in I it may be possible that I will favor a different solution.  

Summary

Besides new editors, code generation and so on, BRFplus has really unique features compared to BRF:

• It allows rapid prototyping: Just start developing a set of expressions and rules and discuss them with a domain expert.
• We can use BRFplus in small projects for new applications because we don’t need sophisticated naming conventions like in BRF in many cases. In fact I recommend to focus on readable names that lead to business rules that business users can read. If naming conventions should be necessary then renaming objects is a very easy task in BRFplus.
• We can focus on business logic and don’t need to focus on performance issues like we had to do in legacy BRF. We can even try to create readable rules by using tests and short texts.
• Even analyzing rules is much easier: Sometime colleagues just mail BRFplus applications to me so that I can install, analyze and comment them. This is not thinkable in BRF where you need special test systems. And transparency and agility will even more when working with SAP NetWeaver Decision Management.

Opening the Discussion

I would like to open the discussion:   

• What are you experiences when moving from BRF to BRFplus?
• What do you as BRFplus expert to a BRF expert when starting with BRFplus? What is the first advice you give to him or her?
• And even if you don’t know legacy BRF, how would you, as BRFplus expert, reuse objects?
• What effect has the use access of BRFplus artifacts in your projects? Is reuse simpler compared to BRF?
• What are your best practices for documentation? How do bridge the gap between internal documentation and description of rules in Word documents of domain experts who define the rules?