Implementing advanced rule governance in IBM Operational Decision Management

This article introduces a rule-based Rule Governance design pattern. The design pattern can be applied to all versions of IBM® Operational Decision Management to improve the agility and strength of Decision Center governance. You can build your own implementation based on this pattern, or can contact the author for details on the IBM Rule Governance Asset. This content is part of the IBM Business Process Management Journal.

Share:

Nigel T. Crowther (nigelcro@uk.ibm.com), Senior IT Consultant, IBM

Nigel Crowther photoNigel T. Crowther is a Senior IT Consultant in the IBM Software Services for WebSphere BPM Practice specializing in business rules. He has over 10 years experience in designing and developing business rules and business process management systems and 25 years experience in IT. Nigel has experience across all business sectors with his greatest focus on financial systems. Nigel joined IBM as part of the ILOG acquisition in 2009.



22 May 2013

Also available in Chinese

Introduction

This article introduces an IBM ODM governance framework for advanced governance solutions. It proposes a flexible alternative to the usual rule governance implementation based on configurable Java business logic, as illustrated by the rule governance product sample. We show that using rules rather than Java to govern the change process improves the power and agility of advanced governance within ODM.

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


The Rule Governance sample

The architecture of the governance extension provided in the product samples is shown in Figure 1. At the heart of the sample is the session controller, which enforces access permissions based on state. The Decision Center calls out to a custom session controller called WorkflowSessionController, which extends the IlrDefaultSessionController. The WorkflowSessionController overrides methods such as checkUpdate, checkCreate and checkDelete to perform governance operations.

The limitations of this architecture are:

  • State base permissions are controlled by a text configuration file embedded within the Decision Center EAR. Configuration changes cannot be applied without redeploying the EAR.
  • Custom business logic is implemented in Java. Java changes are expensive to implement and test and may need to be merged with each new version of ODM API. Also the Decision Center EAR needs to be redeployed with each change to the code.
  • Project access is controlled by combining two different concepts of roles: functional and project roles. This can lead to a proliferation of roles. For more details on this, see the Assign roles section.
Figure 1. Architecture of the Rule Governance ODM product sample
Architecture of the Rule Governance ODM product sample

Rule-based rule governance

Consider what happens if you delegate the governance logic from the EAR file to a decision service, as shown in Figure 2.

Figure 2. Rule governance decision service
Rule governance decision service

The architecture in Figure 2 assumes Decision Center resides on the same application server as Decision Server to allow local POJO (Plain Old Java Object) invocation. An alternative approach would be for the J2SE Rule Engine to be embedded in the Decision Center EAR. This approach would be used if Decision Center does not have access to a Decision Server.

The parameter interface between the Governance Decision Service and the Governance Session Controller is implemented with the Generic Ruleset Signature Pattern. This pattern enables the rule model (.brmx) to be changed without having to redeploy the Decision Center EAR. The object model is built using Excel dynamic domains which map to the rule model. For details on the Generic Ruleset Signature Pattern, see Introducing the Generic Ruleset Signature pattern for WebSphere Operational Decision Management V7.5, Part 1.

Governance rule flow

The rule flow inside the Governance decision service is shown in Figure 3. It is divided into six sub-flows that largely correspond to the session controller methods.

Figure 3. Governance rule flow
Governance rule flow

The purpose of the six subflows are as follows:

  • Roles - return the functional roles
  • Status - return the status transitions given an artifact's current status
  • Permissions - determine the create/update/delete permissions for a rule artifact
  • Committed - sends notification messages given pre- and post commit status
  • Validation - validates rules and rule metadata and returns errors.
  • StyleCheck - Style-checks rules and returns warnings.

In the following sections, we'll take a look at each of these operations.


Roles

Role permissions in Decision Center are applicable across all projects. The way to define project access permissions is to create combined roles for each project and function. For example, a function of Tester and a project of LoanValidation would produce the TesterLoanValidation role. Two projects called LoanValidation and Annuity and two functions called Tester and Author would produce the following combined roles:

  • AuthorLoanValidation
  • TesterLoanValidation
  • AuthorAnnuity
  • TesterAnnuity

A tester accessing the LoanValidation project would be assigned the TesterLoanValidation role. Similarly, a tester accessing the Annuity project would be assigned the TesterAnnuity role. A tester allowed access to both projects would be assigned both the TesterLoanValidation and TesterAnnuity roles.

Adopting this approach for many projects can lead to a proliferation of roles. For example, six functional roles and ten projects would require sixty roles.

A simpler approach is to split project roles and functional roles, then restrict the Decision Center security model to operate only on project roles and restrict the Governance decision service to operate only on functional roles. Figure 4 illustrates the separation of functional and project roles.

Figure 4. Separation of roles
Separation of roles

The implementation of project and functional roles is simple. Just assign project roles in Decision Center as shown in Figure 5 and Figure 6.

Figure 5. Assign project role to LoanValidation project
Assign project role to LoanValidation project
Figure 6. Assign project role to Annuity project
Assign project role to Annuity project

Assign functional roles in Rule Governance as shown in Figure 7. Now project access is determined by Decision Center and functional access is determined by the Rule Governance permission rules described in the next section.

Figure 7. Assign functional roles in Rule Governance
Assign functional roles in Rule Governance

Permissions

As described in the previous section, we use the Decision Center security model to determine project access and delegate fine-grained access permissions to Rule Governance. In doing so, not only does this allow us to separate functional roles from project roles, but it allows fine-grained access permissions. For example you could restrict access by rule state, folder, rule name and expiration date.

In Figure 8, the author is allowed to change decision table attributes in new, defined and cancelled state, but can only change the rule body (definition) in new state.

Figure 8. Permissions decision table
Permissions decision table

Status

The diagram in Figure 9 shows state transitions for a rule author. The transitions are enforced in the decision table shown in Figure 10.

Figure 9. State transition diagram
State transition diagram
Figure 10. State transitions defined in a decision table
State transitions defined in a decision table

You can see that in row 1 in Figure 10, a newly created rule is set to new state. In row 2 the author is restricted to moving from new to defined or cancelled state.


Validation rules

Governance validation rules enforce who can do what and prevent the rule from being committed if there is an error. Figure 11 shows a governance validation rule preventing an author from testing his own rule. This can happen when a user is assigned both Tester and Author roles. An author testing his or her own rule is not desirable behavior because it breaks the "four eyes" principle.

Figure 11. Rule preventing author from testing his or her own rule
Rule preventing author from testing his or her own rule

The governance validation rule in Figure 12 prevents a user from submitting a rule without documentation.

Figure 12. Rule preventing author from saving without documentation
Rule preventing author from saving without documentation

Style check rules

Style check rules check for potential problems rather than errors. Unlike the validation rules, Style rules do not prevent the user from saving the rule, but simply create a warning message. It is up to the author and (ultimately the reviewer) to decide whether the warning advice should be taken. Figure 13 shows a style rule enforcing naming standards. The standard requires rule names to start with an upper case character and to be followed by one or more lowercase characters or numbers.

Figure 13. Style rule enforcing naming standards
Style rule enforcing naming standards

If a name breaks this convention, a warning message appears in the Warnings property field. In Figure 14, the user has entered an invalid rule name containing a dollar symbol. This is detected by the name validation rule in Figure 13, which writes to the Warnings property field.

Figure 14. Warning message
Warning message

To highlight the issue further, a warning symbol appears in the Rule Explorer view and the warning message is in the tool tip, as shown in Figure 15.

Figure 15. Warning indicator in Rule Explorer
Warning indicator in Rule Explorer

Other examples of style rules are:

  • Naming standards for column names
  • Decision table maximum row limits
  • Decision table cell value maximum length limits
  • Thresholds for numeric values in a decision table

Examples of these rules are shown in Figures 16, 17, 18 and 19, respectively.

Figure 16. Style rule to check whether a decision table has invalid column names
Style rule to check whether a decision table has invalid column names
Figure 17. Style rule to check whether a decision table has too many rows
Style rule to check whether a decision table has too many rows
Figure 18. Style rule to check whether a decision table cell value exceeds 16 characters
Style rule to check whether a decision table cell value exceeds 16 characters
Figure 19. Style rule to check whether change is beyond a threshold limit
Style rule to check whether change is beyond a threshold limit

Committed Rules

Committed rules are called on the onCommit event and determine whether a notification should be sent. A notification could be email, SMS or written to a database. Figure 20 shows a state transition from New to Defined triggering an email. The triggering rule is shown in 21.

Figure 20. Email notifications
Email notifications
Figure 21. Email notification rule
Email notification rule

The IBM ODM Rule Governance asset

All of the features described in this article and more are implemented in the IBM Rule Governance asset. This asset provides a customizable governance solution for advanced governance implementations. For more information and to obtain the asset, contact the author.


Conclusion

This article presented a rule-based Rule Governance design pattern that uses business rules rather than Java to improve the agility and power of governance implementations for Decision Center.


Acknowledgements

The author would like to thank Pierre Berlandier and Jonathon Carr for reviewing this article.

Resources

  • For more information about the IBM Rule Governance asset, contact Nigel Crowther
  • developerWorks BPM zone: Get the latest technical resources on IBM BPM solutions, including downloads, demos, articles, tutorials, events, webcasts, and more.
  • IBM BPM Journal: Get the latest articles and columns on BPM solutions in this quarterly journal, also available in both Kindle and PDF versions.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=930238
ArticleTitle=Implementing advanced rule governance in IBM Operational Decision Management
publish-date=05222013