In this blog entry I will discuss some advanced aspects of business rule management using BRFplus. It is not likely that those aspects are relevant for most BRFplus projects, but they will occur in complex development scenarios where the software has to pass from one system landscape to another which is the case for larger custom development or the development of partner solutions. If you are using BRFplus in those scenarios this blog entry might be interesting for you. If you are not then this blog might be interesting because you can learn that BRFplus/DSM projects can have a different focus and challenges depending on the kind of use:
- BRFplus implementation can be part the implementation of an SAP solution
- BRFplus implementation can be part of a change of an SAP solution – think of migration from a legacy business rule framework like BRF to BRFplus
- BRFplus can be used in custom development
- ISVs who extend SAP solutions usually have to extend the BRFplus interface of the underlying SAP solution
For all above scenarios all of BRFplus best practices are still valid but new best practices can be needed and I want to discuss some aspects of this. So this blog is definitely not blog for BRFplus beginners but can show you some characteristics of using BRFplus in large scale projects.
Most customers use BRFplus in two development scenarios:
- SAP ships a BRFplus function in SAP Business Suite and rule sets are implemented to control an SAP process. This scenario is very common in implementation of MDG, SAP Banking Solution, GRC and other solutions.
- A customer uses BRFplus in his own custom development, creates an own BRFplus function and own rule sets.
In both cases the customer has complete control about his BRFplus artifacts. He can also use DSM to optimize development and deployment of business rules:
- development in a central system
- deployment of rules in the SAP landscape without transports
- deployment into SAP systems even into lower releases and even hot deployment into production.
In this blog entry I will discuss BRFplus use cases from the point of view of independent software vendors. In fact we do exactly the same as above described: we develop BRFplus applications on top of SAP standard software and our own solutions and implement them. But we also use BRFplus in different scenarios:
- An ISV develops a function and the customers assign rule sets to this function. Here the ISV is in the same position as SAP as in the scenarios described above since his customers will heir business rules on top of the BRFplus function.
- The SAP Partner extends the data model and functions of SAP standard and the users of the partner solution create their own rule sets on top of SAP Standard and the partner AddOn.
In the following I will discuss some pesky little pitfalls in those scenarios.
Take Care of your Transports when doing modular BRFplus Development!
At first you have to understand that the ISV is in the same position like SAP. So far SAP doesn’t use DSM deployment to ship BRFplus artifacts to SAP customers and so won’t the ISV – unless there is an agreement about a defined governance process, but this is beyond the scope of this blog entry. But nevertheless DSM is part of many solutions like IS-U.
The challenge is that ISVs usually have a complex development landscaped with development as well as maintenance systems for shipping hotfixes. As a consequence an ISV has to ensure the consistency of the artifacts in both landscapes. Please note that the same challenge also occurs in larger custom development projects when there is modular development of BRFplus artifacts: business rules can’t be shipped as a single BRFplus application and consist of at least two parts: an adapter consisting of a BRFplus function, data elements and perhaps additional expressions, and rule sets in a separate application containing the logic of the decision service. Modular BRFplus development is often necessary since the BRFplus function called from the ABAP application is fix but the rule sets can be completely different on different SAP clients of even systems (think of global solutions with different productive systems). For an ISV this is the “normal” situation since the ISV is not the owner of the rule set. Maybe the following picture explains the situation:
Please be aware that this is ne only possible solution pattern. There are also applications in SAP standard where functions and data objects are generated, but shipping the signature of a BRFplus function is much easier to handle.
I recommend to transport the BRFplus adapter as system application because you can ship it in software components built using the AddOn Assembly Kit (AAK). The transport of customizing applications as BC Sets is not possible (at least at the moment) for various reasons.
Let’s look now at the simplified systems landscape with the systems of an ISV on the left and the systems of the customer on the right:
This situation can be managed quite easily if you understand the data model of BRFplus. A BRFplus artifact is identified by an internal GUID and not its technical name. Parallel development in development and maintenance is system therefore can be futile. Think of the case that a new data element with technical name “foo” is created in the maintenance system, shipped to production and used in a rule set in a system on the right and later created in the development system on the left and shipped in a regular release. In this case both elements have the same technical name but different GUIDs and so every BRFplus artifact that uses the “foo” will not work properly after “foo” is shipped for the second time. So you have to synchronize the development of BRFplus artifacts using transports or XML exchange. Please note that is nothing unusual and holds for many SAP development objects like workflow patters or derivation hierarchies of persistent objects and any many more. The only problem is that SAP invents new development artifacts very rapidly but the communication about maintenance is usually not described in SAP Help Portal and you find the information only in OSS after many customers got into trouble. It would be great if SAP would publish following information for every new development object / resp. strategic framework (like BOPF): naming convention, transport behavior and support by correction workbench. Here BRFplus performs well since naming conventions have been published right from the start and the BRFplus team of SAP has put so many documents on SCN that the behavior of BRFplus can be easily understood. But for other parts of ABAP development I hope that senior documentation architects like horst.keller read this blog and try to integrate this aspect to the documentation standard. This is very urgent since for custom development SAP landscapes get more complex to support rapid implementation and changes.
Extensibility of System of Rules
ISVs often extend solutions of SAP Business Suite: data models and business objects. Please also note that this is quite common and reflects the principle of the software pyramid that is the common architectural pattern of SAP solutions and their implementations:
As far as I know BRFplus functions are not extensible. If we need additional values in a rule set we use to create them as rule set variables and define their values as expressions. Of course BRFplus is open and you could use extension mechanisms of the workbench to bypass checks and to perform enhancements but I don’t recommend it since it will lead to many problems like every modification does.
When ISVs extend SAP solutions or want to create extensible but also robust solutions by themselves there are three patterns:
- Additional BRFplus expressions can be used to get extensions of the data model into the BRFplus application. The SAP Insurance solution uses quite sophisticated techniques you can use for inspiration, see here and here. Those extensions can be implemented using own expressions types or static method calls which is usually much easier.
- The second option uses BAdIs to take over the control of execution and calling an own BRFplus function instead of the one shipped by SAP. Often those functions are copied from SAP’s functions and extended afterwards. The drawback of this approach is that you have to take care when the SAP data model gets extended and then adjust the extensions and perhaps actualize DDIC binding and of course avoid name clashes.
- Another approach to support extensibility is to use the BRFplus API for generative techniques. This is perhaps the most advanced approach but I found it useful in some cases since it is very flexible.
Summary
With BRFplus SAP created a tool to separate business logic from business applications. This makes SAP Business Suite more transparent and easier to change. With DSM you have a tool for central development of rules which can be “injected” into systems but this doesn’t make transport of BRFplus artifacts obsolete, nor does it solve the challenge that comes with extensibility of SAP Business Suite automatically. The reason is that so far SAP positioned SAP NetWeaver Decision Service Management as product for scenarios in custom development with focus on deployment of rules into productive environment. As explained above this is very useful but doesn’t solve the challenges ISVs face when dealing with extensibility or when the landscape of the ISV is separated from the customer which is usually the case.
For most BRFplus projects above mentioned aspects are not significant but especially ISVs have to develop best practices to use BRFplus/DSM in an optimal way in more advanced scenarios. I mentioned some pitfalls and gave an example how extensibility can be implemented.
I expect that there are more solutions for above mentioned challenges and I would be pleased to discuss this aspect with other practitioners working in larger development projects. The reason is that BRFplus doesn’t have the limitations like other business rule frameworks in the SAP Business Suite and there are many possibilities to create flexible as well as extensible applications.
- SAP Managed Tags:
3 Comments
