Business rules play an important role in your day-by-day business activities. They help to enforce company policies or business guidelines. Several typical business scenarios can be handled much faster due to the efficient handling of rules by automated rules engines. Think of all the business scenarios that can now be covered by using rule-based solutions:

• Decision rules with the goal to automate complex decisions such as distributing workload by using a rule-based task assignment logic considering aspects such as availability and expertise of employees. Another typical use case for decision rules is the optimization of transportation logistics supporting truck loading and inventory management.
• Validation rules for checking the contents and validity of data coming in via messages or forms. Another use case for validation rules is the verification of an applicant’s eligibility for certain product offerings, for a credit card, or loan.
• Recommendation rules allowing the guidance of the buying behavior by personalized Web sites and product recommendations
• Calculation rules for calculating sales commissions, prices, discounts, and rebates
• Alert rules identifying suspicious or critical business events such as fraud, or the drop or increase of stock prices by a certain percentage in a certain time

As this list indicates, rules are almost everywhere. Handling them efficiently means huge benefits for companies as rules typically change frequently.

However, the situation for managing rules has changed significantly. Before the advent of rules management systems, the rules were handled in an unprofessional manner. For example, often the knowledge about rules and how to apply them was in the minds of clerks who knew how to react in certain situations due to their experience. Or look at all the Microsoft Excel spreadsheets spread around in different departments of a company that have been created to encapsulate all the rules to find, for example, the right price for a certain customer. Finally important rule-related logic is buried somewhere deep inside hand-crafted code, making it hard to find, understand, maintain, or change.

All these approaches cost companies quite a lot of money because they hinder fast adoptions to changing market conditions. Modern companies simply cannot afford delays in updating their rules. The risk of losing their competitive advantage is simply too high. That’s why business rules management systems such as SAP NetWeaver Business Rules Management (SAP NetWeaver BRM) as part of the SAP NetWeaver Composition Environment (SAP NetWeaver CE) play an increasingly important role in today’s IT infrastructure.

SAP NetWeaver BRM allows the definition of two kinds of rule sets: Rete-based and flow rule sets. According to these two rule set types, SAP NetWeaver BRM handles each kind with its own engine — the Rete engine and the flow engine. The key difference between the two is the way in which rules are executed.

I focus on how the SAP NetWeaver BRM Rete engine works. I will describe in great detail how the engine handles Rete rule sets so that you can optimize your rules for your particular use cases. (For information on flow rule sets, see the sidebar at the end of the article.)

Understanding Rete-Based Rule Sets

Imagine you have hundreds of if-then rules. The key question is: How can the rules engine efficiently identify those rules whose IF condition is true (is fulfilled) and in which sequence are the found rules finally executed (or fired)?

The most obvious solution — namely iterating overall rules, checking the conditions against the known facts, and if the condition is satisfied, simply firing the rule – doesn’t work for a huge set of rules. It is simply too slow. Therefore, the Rete algorithm improves performance by building a separate representation of rules. It uses a network of nodes in the form of a tree. The path from the root node to the leaf node reflects the conditional part of a rule. As facts (represented by nodes) change, the nodes are updated accordingly. As soon as all rule conditions are satisfied, the associated rule can be fired.

With the new representation in the form of a tree, a price has to be paid for the performance improvements. Rete algorithms consume a significant amount of main memory. Implementations of Rete algorithms try to benefit from the speed improvements without sacrificing memory.

In essence, for the Rete algorithm to work you define the data on which the rules work (called the working memory) and the set of rules. Based on the working memory’s content (the facts), rules are fired as they become activated. The firing of rules changes the contents of the working memory, leading to another round of evaluating the rule’s conditions and a new round of firing the rules whose conditions are satisfied. This process is repeated until the rule can no longer be fired. The key point to understand is that you don’t provide a concrete execution sequence. That’s the task of the rules engine.

Rules Composer

I will walk you through how to develop a simple rule set for calculating the discount for a customer based on his credit status. Let’s get started with the rule’s design time. The design time of SAP NetWeaver BRM is called Rules Composer and it is part of the SAP NetWeaver Developer Studio. After starting SAP NetWeaver Developer Studio, you can directly open the rules composer perspective by following menu path Window > Open Perspective > Other… from the main menu and selecting Rules Composer in the newly opened Open Perspective dialog (Figure 1).

Figure 1

Open the Rules Composer perspective

Create a new rules project by following menu path File > New > Project… from the main menu. The New Project wizard opens. On the first screen, you have to select an appropriate project wizard. As I want to create a rules project, I select Rules Composer > Rules Composer Development Component node and click the Next button.

The Select Software Component step appears. Click the MyComponents node and proceed to the next step. Provide an appropriate name for your rules project, such as spj_rules. To actually create the project, click the Finish button. As a result, you can identify your newly created project in the Project Explorer view in the upper-left corner. Expand the nodes of your project. The result should look similar to Figure 2.

Figure 2

Rules project in Project Explorer view

Add Resources to Your Rules Project

Rules have to work on data. The question is: How do you define this data? SAP NetWeaver BRM offers you two options: either use standard Java objects or define your data within an XML Schema Definition (XSD) file. In either case, the chosen class or XSD file represents the outside view of your rule set. It is the interface, the contract between the calling applications and the rule set and comprises fields that can be exchanged between the caller of the rule set and the rule set itself. For simplicity reasons, I am using an XSD file that looks like the one in Figure 3. You can also download the file at the end of the article.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns=https://www.w3.org/2001/XMLSchema 
xmlns:discount=https://www.sap.com/discount 
xmlns:ctc=https://sap.com/ctc 
xmlns:xs=https://www.w3.org/2001/XMLSchema 
xmlns:xsd=https://www.w3.org/2001/XMLSchema 
targetNamespace="https://www.sap.com/discount">
    <element/>
    <complexType>
          <sequence>
                   <element/>
                   <element/>
                   <element/>
                   <element/>
          </sequence>
    </complexType>
</schema>

The interface between your rule set and the consumers of your rules consists of four fields:

• name: the buyer’s name
• credit: reflects the buyer’s credit score (GOOD or BAD)
• spendingHabit: summarizes the buyer’s spending habit such as LOW or HIGH
• discount: the return value for the caller representing the calculated discount for that particular buyer

To define the XSD file for your project, consider these questions:

• Which business functionality has to be covered by my rule set?
• Which data is needed to fulfill the business functionality?
• Which result the caller of my rule set expects and which data is necessary to fulfill these expectations?

Making the data available to your rules project is a two-step process. First, import the XSD file. Then you have to make the data available to your rules project. It is not enough to only import the XSD file. You have to explicitly add the data to your project’s resources. For this purpose, a special node named Project Resources is reserved in your rules project (Figure 2).

Step 1. Import the XSD File

In Figure 2, right-click the wsdl node beneath the src node. Select Import… from the context menu so that the Import wizard opens. You want to import an XSD file, so select the identically named node beneath the Web services node and click the Next button. Accept the default output folder in the next wizard step by clicking the Next button.

You are now on the Select or enter an XSD URL screen. Navigate to the XSD file in your file system by using the Browse… button. Once you’ve found and selected the file, click the Finish button to import the XSD file. It appears as an entry beneath the wsdl node.

Step 2. Make the Data Available to Your Rules Project

In this step you add the fields to the rules project resources. Either double-click the Project Resources node in the Project Explorer view or right-click the node and choose Open from the context menu. In either case, the Project Resources editor opens in the SAP NetWeaver Developer Studio main area. The Aliases tab allows you to add fields from the XSD file to your project. Click the Add button in the upper-right corner and select XSD Element from the pop-up menu (Figure 4).

Figure 3

Example XSD file

The Add XSD Element dialog opens showing the namespace of your imported XSD file. Expand the node and select the DiscountCalculation entry (Figure 5). Click the Finish button to add the file’s contents to your project resources. As result, the DiscountCalculation entry appears in the list of available alias names (Figure 6).

Figure 4

Add the XSD fields to the rules project’s resources

Figure 5

Select the XSD element for import

The Aliases tab is very important. It allows you to rename the technical terms from the XSD file and give them some more meaningful business descriptions. Typically, business people who probably don’t want to be bothered with technical details of XSD files are responsible for rules modeling. As such, it is a good idea to give those rather technical descriptions meaningful business-related aliases. You can easily rename the fields by clicking the name once (this activates the text) and replacing the original text. For example, you could rename the DiscountCalculation/credit field to Buyer’s Current Credit Score.

Each field has two entries. Behind the scenes, the system generates a Java class for your imported XSD file with the fields as the class’s member variables. In addition, the system enhances the class through getter and setter functions to access the fields.

For example, in Figure 6, two entries are generated in the Alias Name list. DiscountCalculation/credit refers to the getter function (read functionality) whereas DiscountCalculation/credit = {String} stands for the setter function (write functionality). You can identify the setters easily by the additional postfix = {String} because setters have an additional parameter, namely the new value that has to be set. Getters don’t have this parameter — they simply return the current value and therefore don’t need a parameter.

If you want to rename a setter, leave the postfix as it is. Just overwrite the name part (e.g., DiscountCalculation/credit). It should also be apparent to the rules modeler which function is the read operation and which one is the write operation. To stay with the Credit field example from above, a valid name replacement might look like this:

• For the getter: Buyer’s Current Credit Score
• For the setter: Set Buyer’s Current Credit Score = {String}

In front of each alias is a check box that allows you to either enable or disable the associated field. If the field is enabled, you can use it when defining your rules. Otherwise, the field does not appear in the rules modeling environment and therefore is not usable. This makes sense if you know beforehand which fields are read only and which ones are write only.

A typical example is the Discount field. It represents the return value containing the calculation result, so you only need the setter method, not the getter. Therefore, you can remove the check mark in front of the getter method DiscountCalculation/discount. However, for the sake of simplicity, I’ll leave all entries as they are and continue with the rules definition.

Create a Rule Set

Now that you have defined the external representation of your rule set, you can begin to define the rules. A rule set consists of several rules that belong together logically. You create a rule set first and then add the rules to it. Create a new rule set by right-clicking the Rules Modeling node in the Project Explorer view and choosing New Ruleset from the context menu (Figure 7).

Figure 7

Create a new rule set

A dialog appears that asks for the rule set’s name. For this example, enter the name Buyer Discount Ruleset 1 and click the OK button. The Ruleset Editor opens in the main area of SAP NetWeaver Developer Studio. As you can see in Figure 8, which depicts the Ruleset Editor’s Overview tab, you can create rules and decision tables.

Figure 8

The Ruleset Editor’s Overview tab

Decision tables are just an alternative way to express rules. Whereas rules are expressed as if-then statements using simple English phrases joined with “and” or “or” logical operators, decision tables reflect a tabular representation of rules. This is sometimes easier to read and maintain — especially for business people — because of its spreadsheet-like structure.

Figure 9 shows a simple example of a decision table. The decision table figures out whether an approval for an order request is necessary or not based on the region the request originated from and the total amount of the order.

Figure 9

Decision table for finding out whether an approval is necessary or not

As I want to concentrate on the inner working of the rules engine in this article, I will not dive deeper into the creation and use of decision tables.

Define Constants and Variables

For this example, I need to define local constants and variables that should only be valid in the scope of the current rule set. To achieve this, click the Definitions tab in the Ruleset Editor. You should see two areas: Fixed Definitions and Variable Definitions (Figure 10).

Figure 10

The Definitions tab in the Ruleset Editor

The Fixed Definitions area allows you to define constants, whereas the Variable Definitions area encapsulates local variables. I want to define some fixed values for predefined discounts.

Step 1. Click the plus-sign (+) beneath the Fixed Definitions headline. A context menu containing data types opens. Click the double data type once.

Step 2. The line double double1 = 0 appears. In this line, double represents the data type and double1 represents the constant’s name. Rename the constant by clicking double1 once and entering a new name (badBuyerDiscount) in the edit field that appears. Press the Enter key to activate the change. The line should now say double badBuyerDiscount = 0.

Step 3. Assign a new value to the constant by clicking 0 once and entering 5 as the new value. Press the Enter key to leave the editor. Figure 11 shows the final result of your changes.

Figure 11

Successful definition of a constant

This constant represents a discount percentage for a buyer with a bad credit score. I then repeat the previous exercise and add even more constants. One constant for a buyer with a good credit score named goodBuyerDiscount with its value set to 15 and one constant reflecting a special discount for the summertime is called summerDiscount. Its value is set to 10.

Step 4. Add a new variable named buyerDiscount in the Variable Definitions area following the same description above. This variable accumulates all the discounts a buyer might receive. Figure 12 shows the final result of all the changes. Save all your changes.

Figure 12

Fixed and variable definitions

The Common Definitions tab in the Project Resources editor (Figure 4) allows you to define global constants and variables. In this case, global means that you can reuse the data across several rule sets, whether they are Rete-based or flow rule sets. Editing them is identical to the procedure described above.

Now everything is in place to model the rules.

Modeling Rules

The starting point is the Overview tab of the Ruleset Editor (Figure 8). Either click the tab or select Overview from the Outline view in the lower-left corner of the SAP NetWeaver Developer Studio window (Figure 13).

Figure 13

Switch to the Overview tab using the Outline view

Click the Overview node and the associated tab appears in the Ruleset Editor. Next, click the New button to the right of the table to view the Rules in Buyer Discount Ruleset 1. The Create New Rule dialog opens, which allows you to enter a name for your rule. Give it the name ChkIfDiscountHigh and click the OK button to proceed. The Rule Editor opens (Figure 14).

Figure 14

Initial Rule Editor screen after creating the rule ChkIfDiscountHigh

Steps to Define the Rule

The intention of this rule is to check whether the maximum discount of 20% has been exceeded. Here are the steps to define this rule:

Step 1. Click the plus sign icon beneath the If keyword. A new line containing the condition Operation.isSuccessful() Equals true appears (Figure 15).

Figure 15

IF condition added

Step 2. You can now change each part of the condition individually by clicking the associated string. For example, by clicking the string Operation.isSuccessful() a context menu opens listing all fields you can use in this particular context (Figure 16).

Figure 16

Choose the field for the comparison

As you can see, the list differentiates between fields defined with the Definition Editor (beneath the Definitions node) and the fields you imported via the XSD files (beneath the namespace node DiscountCalculation). For my example, I want to check whether the accumulated discount aggregated in the buyerDiscount field has exceeded the limit of 20%. Therefore, select the buyerDiscount field by clicking it once.

Step 3. Set the logical operation. I only want to set a new value for the buyerDiscount field if it exceeds 20%. So, I have to compare its current value against 20. Click the Equals string once and select Greater Than from the context menu (Figure 17).

Figure 17

Select the logical operation Greater Than

Step 4. Set the comparison value to 20. Click 0 once and enter 20 in the field that appears (Figure 18). Close the context menu by pressing the Enter key. With that, the condition part of the rule is finished. Next, you assign an action to the “than” part.

Figure 18

Set the value for the comparison to 20

Step 5. Click the plus-sign icon beneath the Than keyword (Figure 19). Again the context menu allows you to set appropriate actions. In this example, I want to set a new value to the buyerDiscount field beneath the Assign node. Click it once and the line Assign :: buyerDiscount = 0 appears. As you can see in Figure 19, the different variables appear beneath different subnodes. Variables defined with the Definition Editor appear beneath the Assign node whereas the fields imported via the XSD file are listed under the Execute node.

Figure 19

Set the value for the comparison to 20

You may ask yourself why the imported fields are grouped behind the Execute action. The fields contained in an XSD file are translated behind the scenes into Java classes with getter and setter methods. Consequently, the Execute action does nothing other than call the getter and setter methods. The action executes the method calls. In Figure 19, I want to set a new value to a field, therefore only the setter methods for the respective fields are listed.

Step 6. Change the value 0 of the Assign action to 20 for maximum discount. Click the 0 once and enter 20 in the field provided. Close the in-place editor by pressing the Enter key (Figure 20).

Figure 20

Change the buyer’s discount to the maximum value 20

Congratulations! You have defined your first rule. The final result is depicted in Figure 21.

Figure 21

Final result for rule ChkIfDiscountHigh

Save all your changes and repeat the steps above to define four more rules. They are defined as follows (the first row always contains the rule’s name followed by its condition and action):

1. ChkIfDiscountLow
If
buyerDiscount Less Than 5
Then
Assign :: buyerDiscount = 7.5

This rule ensures that at least a discount of 7.5% is given to customers even if they have a bad credit score. This is a generous company.

2. GoodCreditBuyer
If
DiscountCalculation/credit Equals GOOD
and buyerDiscount Equals 0
Then
Assign :: buyerDiscount = summerDiscount+goodBuyerDiscount

This rule reacts on the buyer’s credit score. If it is good and you haven’t assigned a discount yet, you calculate the buyer’s discount by adding the two constants summerDiscount and goodBuyerDiscount.

In comparison to the other rules you have defined so far, there are some enhancements to explain. The condition this time not only relies on a definition field, but also on an imported field (DiscountCalculation/credit). Therefore, you have to select it from the list beneath the DiscountCalculation node (compare to Figure 16).

The DiscountCalculation/credit field is then compared against the string constant GOOD. Enter the string GOOD as shown in Figure 22 and press the Enter key.

Figure 22

Enter the constant string value GOOD

Next you have to add the AND operation after the first condition line. Click the plus-sign icon once beneath your newly created condition. The editor automatically adds the AND operation and a second condition. Adapt the second condition as needed.

Finally, you calculate a value. After you have chosen the summerDiscount field as the first parameter of the sum from the context menu, click summerDiscount again and choose <Add a new expression> from the context menu (Figure 23).

Figure 23

Add a new expression

As result, the add operation (+) and the value 0 is added after the summerDiscount field. You can now change the operation by clicking on the + operation. For this example, leave the plus sign and just replace the value 0 with the constant goodBuyerDiscount. Figure 24 shows the end result.

Figure 24

Define the calculation for a good buyer

3. BadCreditBuyer
If
DiscountCalculation/credit Equals BAD
and buyerDiscount Equals 0
Then
Assign :: buyerDiscount = summerDiscount-badBuyerDiscount

This rule reacts again to the buyer’s credit score. This time, if it is bad and you haven’t assigned a discount yet, you calculate the buyer’s discount by subtracting the constant badBuyerDiscount from summerDiscount.

4. SetBuyerDiscount
If
buyerDiscount Greater Than 0
Then
Execute :: DiscountCalculation/discount = buyerDiscount

This rule finally sets the calculated discount as return parameter by placing the buyerDiscount's value into the imported field DiscountCalculation/discount.

You have now set up all your rules. In part 2, I’ll show you how to test the rules and understand the rules’ execution.

Flow Rule Sets
In flow rule sets, you decide the rule’s execution sequence. You define graphically in which sequence the system calls scripts, decision tables, and rules. Figure A depicts an example of a flow rule set.

Figure A

An example flow rule set for an approval

Dr. Volker Stiehl

Prof. Dr. Volker Stiehl studied computer science at the Friedrich-Alexander-University of Erlangen-Nuremberg. After 12 years as a developer and senior system architect at Siemens, he joined SAP in 2004. As chief product expert, Volker was responsible for the success of the products SAP Process Orchestration, SAP Process Integration, and SAP HANA Cloud Integration (now SAP HANA Cloud Platform, integration service). He left SAP in 2016 and accepted a position as professor at the Ingolstadt Technical University of Applied Sciences where he is currently teaching business information systems. In September 2011, Volker received his Ph.D. degree from the University of Technology Darmstadt. His thesis was on the systematic design and implementation of applications using BPMN. Volker is also the author of Process-Driven Applications with BPMN as well as the co-author of SAP HANA Cloud Integration and a regular speaker at various national and international conferences.

 

You may contact the author at editor@SAPpro.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.