Using BRFplus

• Introduction
• Problem statement
• Location of Rules
• Terminology
• Rule authoring environment
• Business rules
• Rule repository
• Business rule engine (BRE)

• Prerequisites
• Authorization
• Naming Conventions

• Object Management
• Applications
• Catalogs

• Objects
• Functions
• Data Objects
• Rulesets
• Rules in the Ruleset
• Rules
• Expressions
• Actions

• Methodology
• Business Rule Service Definition
• Deployment
• Advanced
• Cookbook
• When to use?
• Pay attention on 
• Generate code for the BRF plus function
• Integration
• BOPF
• Workflow 

Introduction

With a Business Rule Management System (BRMS) the rules can be implemented, accessed, and managed in one central place. The rule logic is decoupled from the general application logic and can independently be adapted any time to changed requirements.

Problem statement 

Companies have always had policies and rules in place to define what should or should not be done. Such rules can be found coded in software systems or in handbooks. Often, they even exist only as the expertise of a small group of employees in a department. A “business rule expresses specific constraints on the creation, updating, and removal of persistent data in an information system.

Terminology

Rule authoring environment 

The rule authoring environment is a set of user interface tools that target technical as well as non-technical users. IT professionals should not make business decisions in the form of business rules but instead help the business experts responsible for running a business area. The business experts have all the required business expertise to make the best decisions. The BRMS aims at empowerment of business users to enable them to change and to organize the business rules directly. 

Business rules 

Business rules are a formal expression of knowledge or preference, a guidance system for steering behavior (a transaction) in a desired direction. On the grand scale, business rules, then, are the guidance system that influences the collective behavior of an organization’s people and information systems.

Using a BRMS, business rules are updated with a much higher frequency, thus making business processes flexible.

Rule repository

The rule repository captures the business rules and the business vocabulary created in the rules authoring environment. It may also contain additional data that steers how the business processes make use of the business rules approach. The repository is kept separate from the rule engine in order to facilitate implementation and maintenance of the business rules. 

Business rule engine (BRE)

The business rule engine (BRE) is often seen as the heart of a BRMS. The purpose of the rule engine is to execute the rule based logic built with the rule authoring environment. 

Prerequisites

Authorization

Appropriate authorizations are the main prerequisite to allow users to work with the BRFplus Workbench. SAP_BC_FDT_ADMINISTRATOR is the role for BRFplus administrators. It needs to be included in the user profile with transaction SU01

Naming Conventions

For interfaces and classes, BRFplus uses the following conventions:

• Interfaces start with prefix IF_FDT_...
• Classes start with prefix CL_FDT_...
• Exception classes start with prefix CX_FDT_...

Within these objects the following naming conventions apply for attributes:

• Constant definitions start with prefix GC_...
• Static attribute definitions start with prefix GV_...
• Member attribute definitions start with prefix MV_...

Parameter names within class and interface methods (or also function modules)

have a prefix that consists of two to three characters. The first character defines

the parameter’s usage type:

• I for importing parameters
• E for exporting parameters
• C for changing parameters
• R for returning parameters

The second character of the prefix describes the parameter’s data type:

• V for simple variable types
• S for structure types
• T for table types
• R for reference types
• O for object types
• A for generic/unspecific data types like ANY or DATA

For table types an additional third character may further refine the type of the

parameter:

• H for hashed table types
• S for sorted table types

Object Management

Applications

An application is considered to define a logical unit for the creation of BRFplus artifacts. It can be compared to a development project in common programming environments: all objects required for a set of related rules are intended to be “collected” into one application.

It acts as a container in which objects of other types are created.

Customers should also use a namespace prefix, either an explicit one or one of the standard customer namespaces Y* and Z*.

The slash / is intended for the inclusion of a SAP-namespace and can only be used with the pattern //*. Also, customers and partners can reserve such namespaces.

For all BRFplus objects, versioning can individually be switched on or off. Versioning allows you to track changes and to run older versions of an object at a given time point. It makes the processing of an object implicitly time dependent.

The following storage types are supported by BRFplus: 

• System objects are stored client-independent and can be transported with Workbench requests. They can reference only other system objects, but can be referenced themselves by objects of all storage types. System objects are typically of constant nature and might be defined for reuse purposes. They can best be compared to program code. Customers are not allowed to change delivered system objects. As an example, BRFplus provides the standard system application FDT_SYSTEM. It contains some default data objects and expressions that can be reused by all other applications. 
• Customizing objects are stored client-dependent and can be transported with Customizing requests. They can reference system or other customizing objects, but can be referenced by customizing objects and by master data objects. Customizing objects are typically intended to define some default behavior that can be adapted by customers later on. 
• Master Data objects are stored client-dependent as well and not intended to be distributed. They are also local objects that cannot be transported to other systems. Master data objects can reference objects of all storage types, but can be referenced only by other master data objects.

Eventually, there is the possibility of defining an Application Exit Class. This offers an easy way to programmatically enhance specific capabilities of BRFplus on the level of an application. It is, for example, possible to restrict access to BRFplus objects with a custom authorization check mechanism of finer granularity. The validity of data entered in an expression might be cross-checked against some external data sources. Or, upon saving an object, a notification may be needed to trigger some additional processing. Technically an ABAP class needs to be created that implements the interface IF_FDT_APPLICATION_SETTINGS.

The Application Log is relevant only for specific object types that actually do log information, such as Message Log actions. A log instance is always assigned to a Log Object and Log Sub Object. They impose a hierarchical categorization and can be maintained in the system with Transaction SLG0.

Catalogs

A catalog defines an explicit, structured view for a collection of BRFplus objects. Its main purpose is to organize specific objects for and by business users, independent from the storage in the repository. In contrast to the object types described so far, a catalog object is not processing relevant.

Objects

Functions

To ensure fast rule processing, BRFplus generates and executes program code in the form of an ABAP class, the first time a function is executed.

Function objects incorporate a so-called context, a set of data objects to pass data. It can roughly be compared to the list of importing or changing parameters of a function module. Data objects are the equivalent of a variable in programming.

 If you want to define new rules for your application, you typically start with the definition of a function object.

Mode of Operation

• Functional Mode 
• A single, top-level expression can be processed and its result will be returned in the result data object. Even though the nesting of expressions into each other allows for some quite sophisticated logic, this mode is especially suitable for rather simple use cases. If you intend to use condition-based and sequential processing of multiple expressions, you should use the event mode. 
• Event Mode 
• The actual rule logic is not directly determined by the function. Rather, the logic is contained in one or several rulesets that can subscribe to the function. 
• When the function is processed, all subscribed rulesets are executed. Thus the function becomes extensible. The order of the ruleset execution can depend on a priority setting in the ruleset. 
• Each ruleset can incorporate rules that may change the state of the context or trigger the execution of external activities. By default, the result data object becomes a table that collects the IDs of all executed actions. But any other data object can also be set as a result. Within rule definitions, the result can be used just like any other data object of the function context. Rulesets can also have an additional, temporary context that allows more flexibility in the rule design. In short, the event mode is the preferred way to unleash the full potential of BRFplus rules design. 
• Functional and Event Mode 
• The third mode is actually a mixture of the other two modes. First, a top-level expression is evaluated to prefill the result data object. Then a list of subscribed rulesets is optionally processed. The mode exists largely for historic reasons. With the current release, the same logic can be designed with rules in the event mode meanwhile. 

Signature 

The signature of a BRFplus function consists of the context and a result data object.

 In the BRFplus Workbench, you can assign existing data objects to the context on the Signature tab with the button Add Existing Data Objects.

Data Objects

Data objects are the carriers of values in BRFplus. They combine the aspects of a variable and a data type definition. Data objects incorporate a type with individual characteristics.

Three different sorts of data objects exist in BRFplus: elements, structures, and tables.

Rulesets

In BRFplus a ruleset object has three main tasks: 

• It encapsulates a set of rules, but also defines under which conditions the rules shall be processed. 
• It connects the contained rules to a specific function object, which becomes the main trigger for the rules processing. 
• It enhances the function context with variables. Variables are additional, temporary data objects that can be accessed as context parameters within the nested rules and expressions.

One or multiple rulesets can subscribe to a single function, but functions do not directly reference any ruleset. Functions need to be set up in event mode to allow rulesets to subscribe to them.

At runtime, a function in event mode will trigger the processing of all subscribed rulesets. If multiple rulesets are involved, the order of processing can be influenced by a priority setting of the rulesets. 

With the default priority setting (zero), the subscribed rulesets may, however, be processed in arbitrary order. The event concept allows an easy and flexible way to enhance pre-delivered BRFplus functions. Even system functions can be extended with additional rules of storage type customizing or application data.

If the ruleset is not enabled, it will be completely skipped by the triggering function at runtime.  But even if the ruleset is enabled, it can define an additional precondition besides the triggering function. If the precondition is not fulfilled, all contained rules will be skipped as well.

Variables are of a temporary nature at runtime, so values can neither be read nor set from outside. Before any rule is executed, the ruleset can set an initial value for each variable by using an adequate expression.

Rules in the Ruleset

Exit conditions can be regarded as special rules that allow to skip any subsequent rules and thereby end the ruleset processing.

Exit conditions are typically intended to stop the ruleset processing when a valid result could be determined and no further rules are required for processing. However, there may also be use cases where the evaluation of subsequent rules is not possible due to some temporary constraints, e.g., missing data. When the constraints do not exist any longer, the rules processing could continue.

If deferred ruleset processing is enabled, an exit condition of a ruleset can not only quit the processing, but it can also be set up to remember the current processing state, including the values of all context data objects. This information can even be stored to the database and be used later on to restart the ruleset again. Two distinct points of entry for a restarted ruleset are possible:

• The ruleset is restarted before the exit condition. The exit condition is evaluated again and the processing of the ruleset may possibly be deferred yet another time at the same position. 
• The ruleset is restarted after the exit condition. Processing of the ruleset simply continues with the next following rule or exit condition in this case.

Rules

A rule basically implements an IF THEN ELSE logic. So a rule definition consists of three parts: the condition and possibly two lists of operations.

In detail the following operations are possible: 

• Reset a context data object to its type-specific, initial value.
• Set a value for a context data object. 
• Exchange values among context data objects. 
• Process an expression to determine a new value for a context data object. 
• Process a nested rule. 
• Execute an action to perform some other (external) changes.

Expressions

• Boolean
• Implements Boolean arithmetic for any number of operands. All combinations with logical AND, OR and NOT are possible. 
• BRMS Connector
• Connects to an external Business Rule Management System (BRMS) like the SAP NetWeaver BRM. 
• Case 
• Maps input values to a defined set of output values or actions 
• Constant 
• Simply returns a static, constant value. 
• DB Lookup 
• Analyzes or selects data from the database. 
• Data Retrieval: By default the expression is used to retrieve actual data from a database table. Either a single line or multiple lines of data can be read. A
• Aggregation: Multiple values of one table column can be aggregated into a single value with the following functions: Minimum, Maximum, Average, Sum, Count.
• Existence Check
• Decision Table 
• Sequentially processes a table of conditions and results. It returns either the first row or all rows where the conditions match. 
• Single Match Mode: In the single match mode, the processing stops at the first matching row and only a single result line can be returned.
• Due to the processing order from top to bottom, the conditions in the upper rows of the table should be more specific than conditions in the lower rows.
• Multiple Match Mode: In the multiple match mode, all table rows are always processed. The results of matching rows are collected into a table type overall result.
• Condition Columns: ?
• Result Columns
• Decision Tree 
• Traverses a binary tree, which consists of inner nodes carrying conditions and leaf nodes carrying the results. Dynamic Processes any other expression that can dynamically be determined by its ID. 
• Formula 
• Allows the calculation of formulas using a wide range of mathematical and logical functions and operators.
• Function 
• Call Calls another BRFplus function and returns its result. 
• To pass data to the target function, its context can be mapped to data objects in the context of the Function Call expression.
• Loop 
• Repeats a sequence of rules. 
• For each entry in 
• Repeat times
• Do until
• While do 

------------------------------------------------------------------------------------

For each entry

A rule can be added to fill output table inside the loop

------------------------------------------------------------------------------------

• Procedure Call 
• Calls either the static method of an ABAP class or a function module to determine a result value. It also allows you to update multiple context parameters at once. 
• Random 
• Either returns a random value or indicates whether a specified probability was met. 
• Search Tree 
• Traverses a non-binary tree in various modes. The tree consists of nodes that may carry conditions and results as well. 
• First-Match-Mode
• Multiple-Match-Mode: The whole tree is traversed. 
• Qualified-Match-Mode
• Table Operation 
• Supports a wide range of operations on table type data. 
• Information retrieval
• Data retrieval and aggregation
• Modifications
• XSL Transformation 
• Performs an XSL transformation to determine a result.
• Expressions of this type require at least one appropriate XSLT document in the system for that purpose. Such documents can be created with Transaction SE80 or XSLT_TOOL.
• Dynamic Expressions
• Expressions are usually nested into other expressions in a static way: expression A checks, for example, whether expression B returns some specific result value so that expression C will be evaluated. Therefore, expressions B and C are statically linked to expression A. At runtime, all expressions share the same context.

Actions

They are a special type of expressions that do not determine a result value but rather carry out changes, notifications, or other activities outside of BRFplus.

At runtime, BRFplus collects the IDs of all executed actions into the standard table data object ACTIONS of application FDT_SYSTEM. If the object is part of a function result, it can be used for further analysis afterwards.

Log Message Action

• Log Message actions can be used to add one or multiple messages to an application log. Application logs can be maintained in the system with Transaction SLG0. 

Procedure Call Actions 

• The action-type is, therefore, destined to perform some activities outside of BRFplus. However, context parameters can still be changed by a procedure call action if exporting or changing parameters are used.

Send Email Action

Start Workflow Actions

Methodology

A good approach to overcoming the problems inherent in the waterfall model is to classify the building blocks of the system to be implemented with respect to their change frequency.

 

Any business logic implemented not with business rules but with program code excludes the functional departments because it is not possible for them to determine where the logic is implemented. This lack of transparency creates a need to discuss and write down assumptions about system behavior and desired changes as specifications. In contrast, visibility of business logic leads to better insight on the part of the business experts who are responsible for the process.

Business Rule Service Definition 

• Name 
• Description
• Documentation 
• Input parameters (context) 
• Data objects (elements, structures, tables) Bindings to data dictionary
• Output parameters (result) 
• Data objects (elements, structures, tables) Bindings to data dictionary

Sketch

Deployment

In the creation process of a BRFplus application, a storage type has to be selected. BRFplus provides three different storage types that define how the application and its contained objects behave with respect to the CTS.

• System Data (S) System data is cross-client. The database tables used to save the data do not have a client key field. Changes affect all clients of an SAP system. Consequently, the transport of changes into another system does affect all clients of this system as well. The package is a mandatory attribute of system applications. The changeability of BRFplus objects in system applications is derived from the changeability of the package that is assigned to the application. If a local package is assigned, transport is not supported. 
• Customizing Data (C) Customizing data is client-dependent. The database tables that store the data have a client key field. Changes to customizing data in one client have no effect on other clients. The changeability of BRFplus objects in customizing data applications depends on client-specific system settings, which are maintained with Transaction SCC4. The import of changes into transport target systems happens in client 000. From there, they may be distributed into other clients with Transaction SCC1.
• Application Data (A) In contrast to customizing and system data, application data is not part of the configuration of the software. Application data is split up into master data (such as customers, products, materials) and movement data (such as line items, documents). Application data is always client-specific. The CTS does not manage changes to application data and the CTS cannot be used to transport changes into other clients or systems. There is no technical restriction on changeability. Application data may be copied between clients and systems with help of the XML exchange features of BRFplus.

Remote scenarios are characterized by the fact that rules modeling and execution take place in remote systems. The invocation can be performed with remote function calls (RFC) or Web service calls.

Advanced

Performance

The activation of tracing always leads to a decrease in performance because the trace data needs to be extracted, collected, and saved to the database on top of the regular processing.

The use of DB Lookup expressions typically slows down the rules processing, because the database access is a costly operation with respect to runtime. A database access performed by BRFplus does, however, not differ from an access that is manually programmed in ABAP.

Actions are often not designed for mass data scenarios. They typically call the API of an additional service, which might not be optimized for high performance scenarios. 

 When the currencies of two compared amounts differ at runtime, one amount needs to be converted into the currency of the other amount. In the above comparison the Income element might, for example, have the value 1250.00 USD. The used conversion services have to look up exchange rates that are located on buffered customizing tables. Also, additional conversion logic needs to be executed.

The more rules and expressions need to be evaluated for a function, the more the processing runtime increases. The complexity of the involved expressions will also individually influence their respective processing time.

Parallel processing is not a feature of BRFplus itself, but rather a general programming option. BRFplus is, however, prepared to be used in parallel. The approach may be considered for processing large data volumes that can be split into separate chunks.  

BRFplus has the capability to trace the processing of a function. Tracing allows you to investigate how the outcome of a function is determined with respect to the passed context parameter values. For each single processing step, information is recorded into a trace log.

RFplus inherently incorporates many possibilities for adapting business rules to custom needs. However, there is always a limit to the functional scope that standard implementations can cover. To overcome such unavoidable boundaries, BRFplus supports the integration of custom behavior at specific places of various depth and complexity: E The Procedure Call expression and action types can be used to program almost any logic with ABAP.

Application exits allow many ways to influence the maintenance and behavior of objects. Section 7.3.1 gives a deeper insight into this concept. E Related to application exits is the creation of additional functions for Formula expressions. Section 7.3.2 will give an in-depth example of such an enhancement. 

Cookbook

When to use?

• The function ( algo ) is clear.
• The rules set ( business rules ) consists of 3+ steps.
• The rules set might probably be changed or it is the request to expand it in future.

Pay attention on 

• When using the expression, check the context data carefully.
• In the IF condition, the expression must return boolean variables.

Generate code for the BRF plus functon

Activate the expert mode 

2768333 - How to generate code for BRFplus functions

Generate it by using report FDT_GENERATION_TOOL.

• Select 'Generate functions(forced)' and enter the affected function ID.
• Execute firstly without 'Generate for Lean Trace' enabled.
• Execute secondly with 'Generate for Lean Trace' enabled.

 FDT_TEMPLATE_FUNCTION_PROCESS

Integration

BOPF

The new BRFplus Expression Type /BOFU/RETRIEVE_BO_DATA in BRF plus is meant for Service Adapted mass enabled Retrieval of BOPF BO data is functional now. 

This expression makes data of Application BOs available in BRF plusenvironment Expression Type /BOFU/RETRIEVE_BO_DATA: A new expression type is available in BRF plus with which one can create BO Retrieve expressions in BRFplus. This makes Business Object data available in BRFplusenvironment supporting any kind of rule processing. 

Example usage: Example usage of this expression type can be found in BRFplusapplication /BOFU/FDT_TEST, /BOFU/FDT_TEST2. Usage of Test Business Object /BOFU/TEST_CUSTOMER, /BOBF/DEMO_SALES_ORDER etc. along with service adaptation can be tested in the example BRFplusfunctions. Other Reusablesaround BRFplus: Data elements /BOPU/FDT_CATALOG_UUID, /BOPU/FDT_APPLICATION_UUID, /BOPU/FDT_FUNCTION_UUID provide conversion exits so that internally they represent UUIDs, externally they represent human readable names of BRFplusobjects. These can be used in configuration tables to link to BRFplusobjects. They also provide association with appropriate search helps.