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?
Summary
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.
- SAP Managed Tags:
2 Comments
