Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
carsten_ziegler
Active Contributor

This blog shows some best practices for the authoring of decision services in SAP NetWeaver Decision Service Management with BRFplus business rules. Where appropriate, I will contrast good with bad examples to illustrate my arguments. The idea of decision services based on business rules has the functional experts in its focus. These people need to be able to understand the business rules and take ownership of the logic that contributes to their success.

The screenshots were taken from a system with NetWeaver 7.3 Enhancement Package 1 (which is equal to NetWeaver 7.0 Enhancement Package 1) and SAP NetWeaver Decision Service Management 1.0.

Content

  • Descriptive object texts
  • Object documentation
  • Expression result values
  • Usage of technical expressions
  • Rule catalogs
  • Access control
  • Decision service design and documentation

Descriptive object texts

I cannot emphasize enough the importance of good descriptive texts for BRFplus objects such as formulas, decision tables, table operations, and especially for the more technical expressions, such as database lookups and procedure calls. When people with a technical background start modeling business rules, they tend to apply the same patterns they use for programming to the authoring of business rules in BRFplus. This is especially true when it comes to defining object names. And often, things get even worse when we look at the object texts. Moreover, many IT people configure the BRFplus workbench so that the technical object names are shown in the user interface instead of the texts.

The following example shows a pricing ruleset. Although simple in its logic, it looks complex. Names with technical prefixes have been used. The names do not explain what the objects are used for. Also, the names include German abbreviations, maybe because the data objects are bound to the Data Dictionary where German abbreviations are still common in some modules.

How can we improve this? It all starts with making the right personalization settings. To open the personalization dialog, use the highlighted icon in the BRFplus workbench.

On the General tab of the Personalization dialog, make sure the Show Technical Names checkbox is deselected. By the way, if you want to learn more about the various personalization settings, choose Show Quick Help from the background context menu. Most of the available options have an explanation attached that helps you understand the effect of each setting.

Once the Show Technical Names option is deselected, the example from above looks like this:

Now, it is very clear what this ruleset is used for. It is easy to understand the meaning of each data object and expression. Even people without technical expertise are able to read and understand the business rules.

For each object in BRFplus, two text fields are offered:

  • Short Text (up to 20 characters)
  • Text (up to 80 characters)

When both are maintained, BRFplus uses the short text by default. If the short text is missing, BRFplus uses the text, which provides a lot of space to describe the object well. So, instead of entering a cryptic short text, just leave it empty and use the Text field only.

Texts have even more advantages over names. While names adhere to restrictions known from development and database objects, texts do not have any such restrictions. They can be translated into several languages which make the rules including all used objects not only form English sentences but also form sentences in other supported languages such as Portuguese, Spanish, Chinese, German, and so on.  Also, special characters such as the German Umlauts are supported. If you like, you can go to extremes and insert a text like the following - no problem:

In case you have bound a data object to a Data Dictionary data element, you can still overwrite the texts to customize the appearance according to the needs of the target group. And remember – a major part of the target group are business experts, not just developers. Needless to say, changing a text is automatically reflected in all the places where an object is used. 

Technical expressions such as a database lookup expression (selects data from a database table) or a procedure call expression (calls an ABAP function module, an ABAP method, or an SAP HANA procedure) can be nicely described with texts, too. A text such as “Retrieve business partner properties” is much better than “SELECT NAME AGE … FROM BUT000”.

The same is true for complex conditions that may be formulated as questions with the help of the text property. In the following example, a table operation expression is used to get the total for a month out of a table.

All these features in BRFplus contribute to a so-called Domain Specific Language (DSL), that is, business-readable instructions for the execution of the decision service. Rüdiger Plantiko has recently published a blog with a nice explanation of this principle using a real-life example.

At best, you start with a business vocabulary defined by the functional experts. Then, this vocabulary is translated into BRFplus objects and used throughout the rules. I have seen complex business rules that were understood and owned by business teams within a few days. A positive side effect of this approach is that feedback for improvements can be discussed between IT and business without any translation step.

Object Documentation

Each object in BRFplus can be documented. You can find the documentation input field in the general data section. Documentation can also be language-dependent.

As soon as documentation is available for an object, you will find a new icon in the top row. Just click on it to let the system take you directly to the documentation tab.

In addition, if documentation has been maintained for an object, this is also reflected in other places in the workbench, such as the help menu or the object menu, which will show you the object documentation in a popup.

Additionally, rule documentation can also be inserted directly when creating rules. This is part of the so-called rule header that can be made visible with the glasses icon, or with rule-specific menu. Good rule documentation can help a lot to introduce the decision service logic to new experts, thus making your projects more efficient.

Since each rule in a ruleset has exactly one documentation string, we recommend not making the rules too big. The following figure shows a bad example (rule #3), followed by a better one (rules #4 and #5):

Expression result values

Each expression in BRFplus has exactly one result data object. This can be an element, a structure (with components of type element, structure, or table), or a table (with an element of a structure as its line type). In a rule, a decision is made about which part of the result should be taken over into the context, and how this should be accomplished (either updating a data object or inserting it into a data object of type table). It is, for example, possible to use a decision table with 3 result columns but take only 2 result values over into the rule context. The example below shows a decision table with two result columns, Base Price and Explanation. BRFplus has automatically generated a result structure (“Result Structure Of Table with Product Prices incl. Discounts”) with these two components.

In the rule, it is possible to update the context data object Base Price only and ignore Explanation.

It is further possible to map the result of the decision table to another context data object. Although the table returns Base Price, I can set Price as the context data object to be updated by using the little highlighted menu.

Sometimes you may not want to return a result. This may be the case when your expressions only perform actions. If this is the case, make this clear in the rule by using the respective option.

For loop expressions and call procedure expressions, it is possible that no specific result is to be returned and mapped to a context field. Instead, the context is updated within the loop. Nevertheless it is good practice to use a result, ideally, the updated data object. This makes clear to the reader of the rule what is changed during rule execution.

Often, rules authors are not clear about all the options BRFplus provides. Instead, workarounds are applied that make the rules look more complex than necessary.

Rule catalogs

Rule catalogs are a very efficient means to organize business rules and related artifacts. One object can be used within many different catalogs. Structuring folders can be created, and even referencing between catalogs is possible.

Catalogs optimized for specific user groups can be preset in the personalization settings. It is further possible to limit the navigation pane to catalogs only. If you do so, the appearance of the BRFplus workbench can be simplified significantly.

Access control

Catalogs can be used to simplify the navigation in the BRFplus workbench. Business experts are enabled to find their content quickly. Nevertheless, they may not be allowed to change all those objects. Especially objects like functions or technical expressions may be changed by technical experts only. To this end, authorization checks are available in BRFplus. Should you feel that this is still not sufficient or flexible enough for your use case, exits, such as the authorization exit, can be used. A separate document has been provided to explain how to use exits.

Decision service design and documentation

Finally, a very important topic is the documentation of decision services and business rules. I recommend using so called decision maps. A decision map is a high-level process description with a focus on the decision services involved. No separate tool is required for the creation of a decision map. Microsoft PowerPoint and comparable tools will do the job.

Decision maps show non-technical people where decision services are invoked. They are decision-centric, leaving out many technical implementation details. A decision map does not replace an architectural diagram or a business process model. These are, however, intended for technical experts.

For each decision service a separate document should be created that documents the decision service interface and implementation. I have created a template document that you may download and use.

Other interesting blogs I recently read about BRFplus


7 Comments