Authors: Alexander Groenewold, Jan Schwarz, Dr. Martin Bartonitz
Almost every company has its own set of business rules and processes. This could make even the simple and common task of determining the next receiver of a workflow a complex and in-transparent decision. A frequent occurrence of this problem is for example during invoice processing, where several exceptions and rules usually constrain the procedure and prevent it from leading to the happy path.
In the past, when facing such complex systems of rules, our professional services teams often invented individual scripting solutions. This, however, is very time consuming, error-prone and needs more maintenance, and allows almost no flexibility or simple adaption of company’s business rule and processe changes. An elegant solution is in the use of a Business Rule Engine.
A Rule Engine allows the separation of programming code and business logic, and therefore enables the adjustment of business rules and processes regardless of the workflow or the underlying implementation. As a result the change cycle of process definitions is elongated, since the needed changes of business rules are now done within the rule engine environment.
There is currently a great hype among the business community concerning the use of Rule Engines and SAPERION is answering this growing demand by evaluating a possible integration of such into its Workflow Engine.
As a first step towards this, we have already begun to develop a prototype application supporting a Rule Engine-based decision making process. In order to (hopefully) ensure vendor independence a general interface towards the SAPERION workflow module has been specified. Using this interface we plan to connect different Rule Engines to evaluate their specific strengths, weaknesses and opportunities when working together with SAPERION.
The engines we picked for our research are open source JBoss Drools (http://www.jboss.org/drools ) and commercial IBM WebSphere ILOG JRules (http://www.ilog.com/products/jrules ), as those are among the most known, discussed and used.
For our initial example application we picked our upcoming internal “application for leave”-scenario, which provides a fairly straightforward set of rules and therefore allows for a quick early evaluation.
These basic rules are as follows:
- Every applicant needs the approval of her/his organization unit’s (OU) team leader.
- Should there be no team leader, or he/she is the leader him/herself, the approval of the leader of the OU above is required.
- CEO and CFO do not need approval
In order to enable the Rule Engine functionalities within existing feature of SAPERION we made use of our java-based Step-Performer and the Classic Connector API including the Workflow API, as described below:
- The corresponding activity for approval is routed to a system user named “LeaveRuleExaminer”
- The adapted Step-Performer processes any activity addresses to him:
- Evaluating the necessary business case parameters using the APIs of the Classic Connector
- Calling the Rule Engine with these parameters.
- Delegating the activity to the determined approver by calling the corresponding Workflow API of the Classic Connector
The first Rule Engine we used to implement this scenario is Drools. Here we wrote a little java program providing the specified interface towards SAPERION mentioned above and calling the Rule Engine by using its JSR 94 based API.
To enable the decision making process we provided the Rule Engine with a Drools Rule Language file (.drl) containing all rules and a Rule Flow file (.rf) stating the order these rules are to be executed in.
As a next step we plan to implement the same scenario using the ILOG JRules engine.