Handling Selective Multiple Actions in SAP Business Rules Management System
By Arun Soni,
Incture Technologies Pvt. Ltd.
| Table of Contents |
|---|
| Introduction |
| Objective |
| Prerequisites |
| Components of NW CE BRM |
| Things to know before using BRMS (Invoking Rule Set) |
| What is a Rule Engine? |
| How a Helper Class accesses the Rule Engine? |
| How to access a specific Ruleset via a Rule Engine API? |
| How does a Rules Composer DC get executed? |
| How Rule Engine works on Data Transfer Objects (Java Objects)? |
| Why only Design Time dependency on EJB Component? |
| What is a Rule and how does it behave? |
| What is a Decision Table and how is it executed? |
| Why use identifier in the case of multiple match returns? |
| Why addToList() method is used in multiple match returns? |
| Creating a Rules Project |
| Procedure |
| Appendix 1.1 - Mass Level Multiple Returns |
| Appendix 1.2 - Required sets of Returns |
| References |
Introduction:
SAP NetWeaver BRM is part of the package solution in SAP AS Java combining the power of SAP NetWeaver BPM, SAP NetWeaver BRM.
This document aims to give an introduction to Business Rules Management System (BRMS) as a development tool, and in addition how to maintain such rules in different use cases using Java Session Bean(s) and Java Classes.
Objective:
To provide an implementation for handling selective multiple actions with a set of conditions from SAP BRMS Decision Table and also to brief the purposeof each component which actively takes part in its execution.
Prerequisites:
- SAP Composite Environment (CE) server
- NetWeaver Developer Studio (NWDS)
- Basic Java Programming skill
Components of NW CE BRM:
The components of NW CE BRM, which help to perform the lifecycle aspects of rules like modeling, testing and runtime changes, are described below:
- Rules Composer: This design time component is integrated into NW Developer Studio.
- Rules Engine: This runtime component is available as a service in NW CE.
- Rules Manager: This runtime authoring tool is built on WD Java technology and integrated into NW Web AS.
- Repository: This component is integrated into NW CE, and used to manage customer business rules and their change history.
- Rule Engine
- Helper Class to use RuleEngine API(RuleEngineInvoker.java)
- Rule set(Rule + Decision table)
Things to know before using BRMS (Invoking Rule set) –
- Rule Engine
- Helper Class to use RuleEngine API(RuleEngineInvoker.java)
- Rule set(Rule + Decision table)
The points mentioned are explained in detail below
What is a Rule Engine?
A Rule Engine is a component which is available as a service in NW CE Server. It takes multiple requests and invokes the relevant business rules from the rules repository.
A request to the rule engine can be sent using
1. BRMS APIs provided by SAP
2. From a BPM process DC.
In this document we will discuss in detail about point 1.
How a Helper Class accesses the Rule Engine?
An instance of RuleEngine.java class plays a key role in accessing the Rule Engine component. The instance is created via a Helper Class through a JNDI (Java Naming and Directory Interface) reference name. It is a Java API for a directory service that allows Java software clients to discover and look up data and objects via a name.
How to access a specific Ruleset via a Rule Engine API?
Whenever we try to implement the rules in our business scenario, we create a Rule Set in the Rules Composer DC.
Shared is the sample code to invoke a Rule set using RuleEngine.java class instance where projectName is the Rule Composer DC name.
Note: “Ruleset” is accessed by the EJB Class. Rule or Decision Table cannot be invoked directly.
How does a Rules Composer DC get executed?
The hierarchy of execution of Rules Composer DC is shown in the figure below –
In order to implement BRMS in our business object, we have utilities to access the Rules Composer Development Component, for an instance it can be a Session Bean which can access these Rules.
The figure clearly depicts the exact flow of executing the Rules. At first the Ruleset is invoked and then the Rule is triggered, and based on the condition provided in the Rule, the corresponding Decision Table is evaluated.
How Rule Engine works on Data Transfer Objects (Java Objects)?
A DTO is an object which carries data between processes. It has to do with the fact that communication between processes is usually done resorting to remote interfaces (e.g. web services), where each call is an expensive operation.
In this case, a Java class is created in a package in the EJB DC and exposed as a public part.
This Class contains getters and setters of the parameters which will be binded to the Decision Table in the Rule Composer DC.
Now this class can now be accessed by the Rules Composer DC, provided the Rules Composer DC has got a design time dependency on the EJB Component. We are now supposed to load this class in the Project Resources in the Rules composer DC in order to bind it to the Decision Table.
When we try to load a class via an EJB Component, the package structure comes up asking to choose the java class file.
Note:
1. The getter methods for parameters always form the Condition Part of the Decision Table where as the setter methods and addParameter methods form the Action Part of the Decision Table.
2. It is a best practice to assign Alias Names to the getters and setter methods locally in the Rule composer DC, so as to make it more identifiable.
3. There should be only design time dependency to the ejb DC where the DTO is created which is explained as below.
Why only Design Time dependency on EJB Component?
Before understanding why only design time dependency on EJB Component, we discuss the type of dependencies and their need for a DC –
-Deploy Time: This dependency is needed when some Enterprise Application or Web Application is archiving its related jar/war files and deploying a new build each time. Talking about the rules, it is an independent component present on the server, for which there is a Rule engine to invoke the Rule set. Hence Deploy Time dependency is not added on EJB.
-Runtime: It is needed, when some API’s are being used or processing has been manipulated in between where there is a hard reference created between the components during Runtime, but Rules Composer Component never uses or exposes any method or API which is accessed in EJB for Runtime Processing. Hence Runtime dependency is also violated.
Design Time dependency is thus added so as to use its class as an object and create a decision table on top of the same object.
What is a Rule and how does it behave?
A Rule is an entity in Business Rules Management Systems which describes the constraints, regulations and policies that are used to define the behavior and conduct of a business. They represent the core logic of each organization, guiding and controlling the basic processes that form the backbone of any business transaction.
A Rule in a Rules Composer DC looks like this –
A Rule has various internal functionalities to perform -
- Rule –It represents the name of the Rule which is assigned while creating a Rule inside the Rule set.
- Priority –It is an important functionality of a Rule to set the priority of its execution during runtime. By default the priority is set to 50000, the value has nothing to do with its invocation. It plays a vital role in a case where there are multiple rules to be executed. Its value has to be then set by us, stating the order of Priority of its execution. The Rule with the highest value of Priority is evaluated first followed by its subsequent lower value priorities. If all the rules have same priority, the rule engine executes all the rules in parallel.
- Effectivety –It is a Control flow deciding factor which decides whether the Rule has to be further considered or not. By default it is set to “Always” assuming that it always requires to be executed.
- Preconditions –Before considering the actual conditional parameters for a Rule, we can assign certain preconditions which are more specific in the conduct of a Business. As in a case where there are 10 Rules put in place for a business, we can thus assign a value for a particular parameter which will be present in the exposed Data transfer Object(DTO) which assures that the Rules which are been targeted are right and thus they can then proceeded with their further execution.
- If - This block consists of condition/s which is/are process specific, used to decide as to which Decision Table to be evaluated. If a process doesn’t have any such condition, then it is required that a generic condition has to be put in place to evaluate the Decision Table as in “Boolean. TRUE Equals Boolean. TRUE”.
- Then - It has statements to evaluate a single or a set of Decision Tables.
What is a Decision Table and how is it executed?
A Decision Table is a business matrix or an excel file which can easily be maintained by end users. Whenever there is a change to be made in the business rules, the user just needs to upload an excel file which is available locally in the system drive provided that they have the exact alias names for the headers and also they have the same type.
Features of a Decision Table –
- The Decision Table is always evaluated based on the properties prescribed in Documentation and Properties.
- The flow of execution of the matrix is always from left to right and top to bottom.
Here are some details about “Documentation and Properties” for a Decision Table which one needs to know, it has two properties of type Boolean, each having a specific function to perform -
-Return multiple matches - As the statement says, it is to return multiple matches from a decision table. It depicts that the control flow will keep oniterating through the Decision Table from Left to Right and Top to Bottom until it finds a valid set of actions/returns on a given condition.
It is made true if it has to return multiple matches otherwise it is false by default.
-Rows are mutually exclusive- In this case, the Decision Table is expected to return a single value, the control searches for only one record match and it terminates the further flow of execution.
It is made false if it has to function for returning multiple matches otherwise it is true by default.
Why use identifier in the case of multiple match returns(like above case in screenshot)?
Identifier is a parameter used in the Data Transfer Object whose getter method is taken as one of the conditional parameter in the Decision Table. It is an “Integer” type parameter whose input is always set to the maximum value available in the table.
Its primary purpose is to let the control undergo multiple iterations from left to right and top to bottom in the Decision Table. The Identifier serves the purpose only when the properties “Return Multiple Matches” is made true and “Rows are mutually exclusive” is made false in the Documentation and Properties section of the Decision Table.
Whenever an identifier is used, then it is expected to have a fixed value inside the Session Bean. In the case of Conditional Multiple returns, the user shall provide the value himself but not fix it.
Refer to the use case related to identifiers and conditional multiple returns in Appendix 1.1 and 1.2.
Why addToList() method is used in multiple match returns?
In order to return multiple values, we create a parameter of List type and when this class is exposed and if the setter method of the list is bound with the Action Part of the Decision Table in order to return multiple matches.
The List fails to return multiple matches, the reason being –
- It is an empty list.
-There are no elements added to it which intends it not to return multiple matches.
Hence, we now create a method called addToList() method in which we add elements one by one to the list used. The element addition happens when the control is iterating from top to bottom on a decision table until we get the desired list of returns.
Creating a Rules Project:
Procedure-
- Create an EJB Development Component.
- Select Development component and then click on Next and give some appropriate name.
- Create an Enterprise Application Development Component in order to deploy the EJB DC with the same prefix as given for EJB. (Here it is named multiplereturns/ear).
- Follow the same steps as above and select Enterprise Application to create the DC.
- We now create Rules Composer Development Component in order to maintain our Rules and Decision Tables.
- Click on next and assign an appropriate name to the Rules Composer DC.
(Here it is named multiplereturns/brm).
- We now add the following dependencies in order to access the SAP Rule Engine.
Dependencies of EJB: (Both Build Time Dependencies to be added)
- tc/brms/façade
Dependencies of Enterprise Application:
- tc/brms/façade (Deploy Time and Runtime)
- multiplereturns/ejb
Dependencies of Rules Composer DC:
- multiplereturns/ejb (Design Time)
Create a Package and create the following classes in it –
- A Data Transfer Object Class to bind it with the BRMS Decision Table.
- A Session Bean to invoke the BRMS Rules Engine.
- The Rules Engine Invoker Java Class
Here is the following structure of the package
- Create the Rule and a Decision Table to be evaluated in the same rule. Also the Documentation and properties of the Decision Table is to be changed.
a. Return multiple matches a true
b. Rows are mutually exclusive a false
Appendix 1.1 - Mass Level Multiple Returns:
- The Data Transfer Object (i.e. SuperMarketRequestMessage in this case) has to have an Identifier of type Integer to return all the maximum matches it gets.
- The Action Part of the Decision Table is bound with the addList() method of the Data Transfer Object used in the Decision Table as to add the Output one by one in the Array List. (Here it is addAvailableQnty () ). <Refer to the Document>
- Now we try to invoke the Rules from the session Bean and capture its response which has to be multiple.
Testing the Rules :
Appendix 1.2 - Required sets of Returns:
- Now we try to provide a limit factor to fetch a certain number of records.
- In this case, the admin wants to provide a parameter called “Price” as a limiting factor to fetch the list of quantities which fall under that price range.
- One more parameter is added in the method signature to provide the value for “Price”.
- We are now required to modify the Decision Table in order to make it work on Price attribute.
- We now provide the data for fetching the selective returns from the table.
- We get the expected response from the Decision Table (here we have 5 returns for the requested Data).
Testing the Rules :
References:
- SAP Managed Tags:
4 Comments
