Architecture of BRFplus-based Applications

[ttrapp]

A very successful pattern for business applications is the separation of business processes and objects from business rules. The latter can be implemented in business rules framework like BRFplus which is the state-of-the-art technology of the ABAP application server. In the following I will discuss two different architectural patterns for applications using business rules and I will give you my opinion about the biggest strength of using BRFplus: it allows simulation of execution of business. Please remark that I don’t speak of the simulation of a single BRFplus rule using the BRFplus workbench – I speak of performing the calculation of changed business rule by calculation perhaps millions of calculations in batch processes to estimate the consequences of changes in your ERP system. And last but not least I will muse about the connection about business rules and business processes.

Before going into detail I will have to explain some basics of BRFplus. BRFplus functions, which are the interface of ABAP applications and business rules, can be action-based or function-based. But what does the mean? Let me cite SAP library when it explains so called BRF functions which are the interface of ABAP code and a business rule:

A function can be designed for one of the following modes of operation:

• Functional Mode
  In functional mode, function execution starts with the assigned top expression. From this top expression, the processing may run through any number of nested subexpressions until a result is returned.
• Event Mode
  In event mode, the function is associated with a list of rulesets that are executed according to their execution priority and their position in the list.

If you are interested in this topic I recommend a look at SAP Library. But please let me summarize:

• In functional mode you can work with expressions only (and of course nested subexpressions) which are computational units of calculations.
• In event mode you can use rules (which are IF THEN ELSE operations) and so the central entities of rule based systems. Moreover you can group rules to rule sets which makes complex rules easier to understand. Rules call above mentioned expressions and call actions.

In fact in this blog I will discuss actions and ways to use them properly but before going into detail I’ll discuss an important best practice for rule based systems.

A Best Practice for BRFplus: Use Event Mode Only!

In the following I would like to give you an advice: use event mode only. The reason is that in the event mode you can use rules and rule sets which is quite flexible since rules can have preconditions and can be grouped to rule sets where in functional mode you have only a single expression. This has quite a few benefits:

• Rule sets can be assigned to a function which is a very flexible mechanism: you can develop a BRF function as part of an application and in an implementation project you can assign different rule sets to this function perhaps in a custom BRFplus application.
• The rule sets assigned to a function will be processed according to their priority. Each rule set can be enabled and disabled. Moreover it can have preconditions which makes it possible to control execution of different rule sets according to certain criteria. You can use this method for proper modularization complex set of rules. Let me give an example: consider the case that you have different business rules for certain customer groups, countries or companies. Then you can define different rule sets and control the execution using preconditions.

  So the event mode will give you access to the central element of BRFplus where functional mode is only useful for single computations using expressions. Of course you can start a BRFplus project using functions in functional mode but if requirements get bigger (rules face reality and are getting more complex or software logistic must be more flexible) you will have to switch to functions in event mode.

Using BRFplus as Computation Engine

You can use BRFplus (either in functional mode or event mode) as computation engine. The rule machine computes calculations, automatic approval or rejections or performs fraud detections for example.

For me this is the best use case for BRFplus because the separation of application logic and Business Rules. If the execution of business rules is a functional (although in event mode) you can call them without any side effect. This makes it possible to copy the rules, change them and look at the results by processing already processed cases and look at the results. Please remark again that I don’t speak of the simulation of a single BRFplus rule using the BRFplus workbench – I speak of performing the calculation of changed business rule by calculation perhaps millions of calcutions in batch processes to estimate changes in your ERP system. This is really useful, just think at the following examples:

• Are certain fraud cases detected after changing the rules when changing BRFplus rules in fraud management processes for example? What about false positives?
• Will the change increase the workload of user since the results will lead to much workload of the users? A the changed rule might judge too much items as to be controlled manually by users.
• Or is the opposite the case? Are the results of checks too laxly after the change?

  In my opinion we have to design business applications in a way that we can perform simulations. This is extremely important for data driven systems (think of banking or insurance solutions where nearly all business objects are processed automatically. I expect that data driven systems will become more and more ubiquitous if processes from mobile systems reach the backend systems.  

The capability for simulation makes an ERP/CRM application more transparent because experts will be able to  answer questions what would probably happen after changing business rules. This transparency leads to agility because it can reduce risks when changing business rule and make it even possible to change business processes.

Using BRFplus Only as Process Engine

But back to BRFplus: functions in event mode can trigger actions which can be used to start processes in the ABAP application. These can be calls of function modules, the start of workflows, sending emails and creation of message logs which are accessible as protocols of the Business Application Log.

I use the mechanism of creating logs very often and read those logs from the memory and use them in the same way like computations of functions.

But actions are far more powerful and can be used to implement side-effects to rules think of sending eMails to certain users like power users. This can lead to an architecture where BRFplus works like a process engine: BRFplus performs a calculation and then takes over the control of the process flow by starting workflows. It can even throw asynchronous workflow events and change the status of business objects and even running workflows.

Personally I’m a little bit suspicious about these features: at first we separated business rules from business processes and now we are doing just the opposite. You may think of these concerns as a theoretical issue but it has immediate consequences:

• What kind of workflows BRFplus should trigger? It is difficult to design complex workflows and many of them are too rigid for practical use.  So you could try an alternative and trigger many “simple” workflows instead of a huge one but this leads to another problem: now the business user has many workitems in his or her inbox and can be confused because it may be not easy to understand what to do with a single business object.
• If BRFplus actions trigger workflow events the design gets more complex because now the business rule has knowledge about business objects and running workflows. If you design such an architecture you should be very careful because of this complexity: it can lead to complex error situations which can be nearly impossible to analyze if you don’t have sound SAP workflow skills.

  But the biggest problem is in my opinion that performing BRFplus functions with side effects can lead to an architecture where simulation is no longer possible. In my opinion you should try to separate BRFplus computations and actions so that still a meaningful simulation of a changed business rule is possible even if you omit the actions while performing a ROLLBACK WORK in a simulation process.

An Advice

When starting to create rule based applications you should consider the following:

• If you have only a few business rules then using BRFplus might not be the best choice and coding them in ABAP might be the better option.
• The more business rules you have aspects like governance and a central repository become more and more important and BRFplus might be the best choice.
• If you create data driven and rule-based applications in ABAP you should use BRFplus. But please be aware that for those applications aspects like change management of rules and the link between processes and rules.

This blog entry covered the last aspect: you can use BRFplus as computation engine and as process engine and within SAP standard software you will find implementations for both architectural patterns. Both patterns have their strengths and weaknesses and you be aware of them.