Eric D. Schabell: Examining Red Hat JBoss BRMS design time architecture for rules and events (part III)

Friday, October 10, 2014

Examining Red Hat JBoss BRMS design time architecture for rules and events (part III)

(Article guest authored together with John Hurlocker, Senior Middleware Consultant at Red Hat in North America)

This is the third part in the series started around possible Red Hat JBoss Business Rules Management System (BRMS) deployment architectures.

Previously we covered in two parts the various deployment architectures you have to deploy a rules and/or events project in your enterprise.

In this article we move forward to the various aspects around rule authoring with a focus on how a rule administrator in charge of your business logic can effectively complete the tasks needed to ensure proper delivery.

Rule administration

A rule administrator will be involved with configuration of JBoss BRMS dashboard tooling before rules are authored.

Administration of building rules.
Some of the issues where she might be involved are related to initial product setup, but what is more in her area of expertise is where we will focus. She will be part of the process around selecting authoring tools and determining the rule formats to be used on projects.

After the projects have started and rule authors are working with the tooling selected and combining their efforts with the application development teams, the rule administrator will have the task of validating the business logic to be used.

Test scenarios.

Building

Once the business logic has been captured in a rules project, the rule administrator is responsible for building the rule package that will be distributed to applications.

This process starts with the rule administrator running all tests that are included in the business logic or rules project, both the tests included in the rule authoring suite and the eventual developer tests.

Assuming the enterprise in question has proper continuous integration tooling setup we will leave that testing story to others and focus on the ability to test the rule packages with the tooling provided to a rule administrator within JBoss BRMS dashboard.
Report shows failure.
  • Test scenarios
    • Rule authors can create test scenarios to validate rules and knowledge bases through JBoss BRMS in the workbench. These test scenarios are independent of your applications implementation.
  • JUnit testing
    • Just a short comment to note that to properly test any rules with application code it should be exercised with some form of unit testing tools. 
    • Rules deployed after passing testing.
    • Just because there are test scenarios setup in JBoss BRMS workbench that pass successfully does not mean that there might not be issues with their usage within an applications implementation.
  • Notify rule developer(s) if there are errors.
  • If there are no errors the rule administrator can build the appropriate rule package(s). In JBoss BRMS this will produce a Maven artifact, which is a normal JAR file.
Looking to Automate your business?

Next up

In the next article in this series we will discuss the tasks a rule administrator deals with to deploy the rule packages into her enterprise to support the applications making use of them.