Implementing advanced rule Management in IBM operational Decision Management

Introduction

This article describes the IBM ODM governance framework for advanced governance solutions. This article provides a flexible alternative to common rule governance implementations based on configurable Java business logic, as shown in the Rule Governance product sample. We will demonstrate that using rules (rather than Java) to govern the change process improves the energy efficiency and flexibility of advanced governance in the ODM.

For the governance of change activities, we recommend that you review the new governance features in the ODM V8.5.

Rule Governance Example

The schema for the governance extensions provided in the product samples is shown in Figure 1. The core of this example is the session controller, which provides access based on state. The Decision Center provides a custom session controller, called Workflowsessioncontroller, that extends the ilrdefaultsessioncontroller. Workflowsessioncontroller replaces methods such as Checkupdate, Checkcreate, and checkdelete to perform governance operations.

The limitations of the schema are as follows:

The State Library permissions are controlled by the text profile embedded in the Decision Center EAR. If you do not redeploy the EAR, the configuration changes cannot be applied.

Implement custom business logic with Java. Because implementing and testing Java changes is expensive, it may be necessary to merge with each new version of the ODM API. In addition, the decision Center EAR needs to be redeployed for each change to the node.

Project access is controlled by combining two different role concepts: functional roles and project roles. This can lead to a surge in roles. For more information about this content, see Assigning Roles section.

Figure 1. Rules govern the architecture of ODM product samples

Rule-based rule governance

Consider the following scenario: If you delegate the governance logic in the EAR file to a decision service (as shown in Figure 2), what happens.

Figure 2. Rule Governance Decision Services

The schema in Figure 2 assumes that the Decision Center is on the same application server as the decision server in order to allow local POJO (Plain old Java Object) calls. Another approach is to embed the J2SE rule engine into the Decision Center EAR. This method is used if the decision Center does not have access to the decision server.

The parameter interface between the governance decision service and the governance session controller is implemented through the regular rule set signature pattern. This pattern can change the rule model (. brmx) without redeploying the Decision Center EAR. Build the object model using the Excel dynamic domain that is mapped to the rule model.

Governance Rule Flow

The rule flow in the governance decision service is shown in Figure 3. It is divided into six streams, which are to a large extent corresponding to the Controller method of the session.

Figure 3. Governance Rule Flow