BPM and Business Rules: K2 and InRule

RT

ROAD Team

05/06/2015

Business Process Management (BPM) software tools have helped modern businesses efficiently automate manual processes and achieve predictable results across various line of business applications.

Most BPM tools allow for simple decision processing within workflows. These workflow decisions are often used for routing purposes, where a workflow instance is directed down a particular branch of process steps or assigns tasks to users based on a single rule. These routing rules are often simple in nature, with consideration of only a few data points at one time.

However, many real-world rule business problems require that complex business logic is applied to hundreds or even thousands of related data points to make a decision or calculation. In these cases, calling out from the BPM to a rule engine can add business value to the solution.

The example below shows a sample scenario of integrating a BPM solution with a business rule engine. In this case we will explore integration between K2 Blackpearl SmartObjects and SmartForms with the InRule rule engine.

K2 offers robust workflow and forms engines that are built on an integration framework called SmartObjects. SmartObjects allow for a consistent approach to integrate forms and workflows with disparate systems and data stores. However, when a K2 workflow or form needs to execute complex business logic, those SmartObject components can also call out to InRule to make complex decisions.

The key enabler for this business logic integration is that both InRule and K2 are built on SDK accessible frameworks of metadata that describe the data structures that they consume. K2 calls this metadata SmartObjects, where InRule refers to the metadata as Entities. A broker component for K2 can then discover InRule entity structures, and then map InRule entities to K2 SmartObjects in a generic manner. The same broker component can be reused for many different business problems, and it can integrate the two systems without writing any code.

InRule has been working with K2 on a sample broker component that can achieve this “low code” integration between BPM and rules. The remainder of this post will walk through how this sample component can be configured to discover InRule rule applications and execute those rule applications from K2 components. The broker component is installed by copying DLL files to a K2 Blackpearl server.

The diagram below denotes the interaction between the components discussed in greater detail further below. This architecture could apply to on-premise or cloud installations.

Step 1: Create a Rule Application in InRule and Publish the Rules to irCatalog

For an example, consider the Mortgage Calculator sample from the InRule training exercises. This rule application takes some input fields for a loan and then calculates payment information for the loan. A list of a few of the InRule entity types in this rule application are noted below. There are 1:1 relationships between the Mortgage and the LoanInfo and PaymentSummary entities.

Once the Entities are defined, business rules are added to operate on the InRule entities. The entity structures will eventually be populated by data passed from K2. Once the rule application is ready to use, it is checked into irCatalog.

Step 2: Discover the InRule Rule Application from K2 and Import the Schema

The InRule broker component for K2 should be installed on the Blackpearl server. After that component is available, it can be registered with the K2 server so Service Instances can be registered within the K2 SmartObjects Tester.

When the Service Instance is registered, it is pointed to the InRule irCatalog service to discover entities and rules at design time. The Service Instance is also pointed to an instance of the InRule Rule Execution Service so rules can be executed at runtime.

Once the Mortgage Calculator rule application has been discovered by K2, there is metadata available in K2 to generate SmartObjects. In this sample, the SmartObjects for the Mortgage Calculator are generated in a bulk operation using the SmartObject Tester.


Now that the SmartObjects have been generated, there are data structures to pass data between K2 and InRule. However, there are also SmartObject methods generated on each SmartObject that can invoke InRule auto rulesets or specific explicit rulesets.


Step 3: Test the Connectivity between K2 and InRule

Now that SmartObjects have been configured, they can be tested from the K2 SmartObject tester. Sample JSON input parameters can be passed through K2 to the InRule Rule Execution Service. After InRule completes rule execution, K2 can process the JSON response from the InRule Rule Execution Service and display the results in the tester form.


Step 4: Write a SmartForm or Workflow that Executes Rules

Now that the SmartObjects with rule execution methods are available in K2, rules can be integrated with K2 SmartForms and Workflows just like any other K2 SmartObject. Below is an example of a SmartForm that executes the Mortgage Calculator rule application when the user clicks a button. The input fields in the Loan Information view are passed to InRule, and the response from the rule engine is written back into the text boxes in the Payment Summary view.

Conclusion:

Although BPM tools offer powerful and robust engines for long-running workflows, inevitably some processes will need to execute complex business logic. This is where integration with a rule engine adds business value to a solution.

Since K2 and InRule have both focused on building “low-code” platforms with tooling that favors configuration over coding, they are a great fit to be used together for line of business systems that handle both long-running business processes and complex business logic.