Friday, October 24, 2014

3 Simple Guidelines to Rule Development, Design and Traceability

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

In this tips and tricks article we present some background and guidelines for the design cycle encountered when one is working with rules projects.

This article is not the only standard or all encompassing source of how each and every rules and events project will evolve over time.

What it is going to do is provide you with the basics as we have encountered them in many projects in real life organizations. They are meant to give you some confidence as you embark on your very own rules and events adventure within the world of JBoss BRMS.

We will discuss some of the requirements phase around rules development, touch on a few of the design choices that will be encountered and elaborate on the options available for including requirements traceability within the projects.

1. Requirements

A rule author will analyze project requirements to determine the number of rules that will need to be created and also works with the requirements team so they can provide answers to any questions that might arise.

Analyzing rules requirements is the phase where a look at the following questions takes place:
  • Are there any WHEN or THEN conditions that are unclear when reviewing the requirements?
  • Are some of these rules data validations?
  • Can multiple requirements be combined into one rule?
By spending some pre-development time examining and validating the project requirements you will be able to narrow the scope of the work to be done in your development cycles.

These questions have been dealt with in previous articles in the tips and tricks.

2. Design

In the design phases an enterprise rule administrator will need to work with the organization and ask some of the following questions:
  •  Will the organization need to host a central rules repository or would that not be beneficial?
  •  Who owns these rules and is responsible for updating and releasing new versions?
  • Are there common rules that can be reused between groups?  
Centralized JBoss BRMS repository.

A central repository is one JBoss BRMS server available for the entire organization to author, store, and build rules.

It promotes rule reuse, is easier to manage and maintain instead of deploying multiple repositories in an organization.

If a set of rules is going to be shared with other groups then one of the groups will need to take ownership and will be responsible for updating and releasing new versions.

The rule author will need to work with the application team(s) to determine what rule format or formats will be used and which tool will be used to author rules. Some of the questions to be dealt with are:
  •  Should rules be developed in the BRMS Dashboard or through JBoss Developer Studio (JBDS)?
  • What are your rule authors more comfortable with?
  • Who will maintain the rules in the future?
    • Java developers, business analysts
  • Do the requirements work better in one format vs. another?
    •  e.g.  web based data table, business guided rule, DSL
  • What type of testing is required?
  •  JUnit and BRMS test scenarios?
These topics have been laid out in previous articles, please refer to them for a deeper discussion.

Options in meta data for requirements traceability.

3. Traceability

Once the rules and events are being implemented it is vital to have some sort of requirements traceability attached to the rules that links them to the originating requirements.

With JBoss BRMS rule authors can set meta data on the rules for traceability to requirement(s), for instance:
  • Associated requirements can be set on rules in the description section.
  • Associated requirements can also be set as an external link on the rule meta data.
  •  Reports can be generated by pulling meta data information from the repository.
In a future article we will dig deeper into how you can use meta data fields within your rules implementation to trace your requirements and extract this information to generate documentation around these requirements.

Tuesday, October 21, 2014

Rocket into the Clouds with OpenShift bpmPaaS Quickstarts

Are you ready for BPM in the Cloud?

This is not the first time we have put the various demo projects project into the Cloud, previously we did it on an older version 6.0.1.

This time around we have updated this to setup the project for you on OpenShift using JBoss BPM Suite 6.0.2, the current version of bpmPaaS.

Let's get started and help you setup this automated cartridge installation that kick start you with pre-loaded demo projects.

First you need to have an account on OpenShift Origin, which you then can upgrade for free to the Bronze level.

Generic loan process
This gives you access to the creation of MEDIUM sized gears which you will need for the bpmPaaS instances you create.

After that you can then create a new application via the online web administration console, where at the bottom of the page you will find a text box labeled Code Anything.

Paste cartridge URI, easy peasy!
This is a field where you can paste in one of the cartridge definitions we provide in the projects listed below.

Just follow each projects readme file instructions and you will be up and running a full bpmPaaS based on JBoss BPM Suite in a matter of minutes.

The projects now available for you in bpmPaaS with more to follow in the same project repository:
There are demo videos when available linked directly from the projects listed above. No excuse now for you not to give the JBoss BPM Suite a try in the Cloud.


Friday, October 17, 2014

Examining 2 Ways to Deploy Rules and Event with Red Hat JBoss BRMS (part IV)

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

In this week’s tips & tricks we will be revisiting the series started around possible Red Hat JBoss Business Rules Management System (BRMS) deployment architectures.

In the last article we talked about 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.

In this article we will describe some of the options available to a rule administrator when she wants to deploy rule projects into her enterprise in support of applications making use of them.

Rule artifact deployment

There are various deployment architectures available when using JBoss BRMS. The selection of one will often determine the course needed to be taken when deploying the final rules projects into your enterprise.

To recap the following list is has been covered in detail in the previous three articles (see bottom for links):
  • Rules deployed in application
  • Rules scanned from application
  • Rules execution server
  • Hybrid of rules execution server

Based on how an application’s architecture is setup, there are several options available for deploying rule projects or artifacts to your applications. You can use the KieScanner in your application or you can include the rule artifact in your applications deployable artifact.

1. Deploy with application

Rules Packaged with you applications deployable artifact is the most static way to manage your deployments. 

Figure 1: Application deployment with rules artifact.
Each application adds a specific rules artifact version as a dependency that is included in the build of the deployable application artifact. This has been outlined in figure 1, where you see the Build Script block as a placeholder for your organizations continuous integration framework. This chain of tooling ensures the desired rules artifact builds and passes all testing. It will then obtain a copy of the applications code that builds and passes all testing. These two are combined to generate a deployable artifact which is then deployed onto the hosting application server.

For an example of this we can look at the Customer Evaluation demo project where we have an application that contains a unit test. This application depends on a specific version of the customer evaluation rules project, which is included in the project POM file.

<!-- KJar file from project. -->

This ensures that our application will generate the deployable artifact that is based on version 1.0 of this rules project and no other.

Once deployed the rules can only be updated by building a new version of the rules project, updating the dependency and building the application again as described above.

What about dynamic rules updates?

2. KieScanner

If you are interested in dynamically updating rules without having to redeploy your applications and having the application then pick up the new rules, you need to setup the KieScanner.

Figure 2: KieScanner to monitor external rule artifacts.
In figure 2 the application is build with a KieScanner component configured which is started when the application artifact is deployed. It is configured to scan a repository for certain artifacts, like a specific version, only release versions or for the latest versions.

The specific version is as described above, use of LATEST refers to the latest released or snapshot version of a rule artifact, the most recently deployed rule artifact in your repository. Using RELEASE will get you the last non-snapshot release of the rules artifact in the repository.

For an example of this we refer you to the Cool Store demo project where the KieScanner is setup in our BRMSUtil class to scan for the LATEST version of the coolstore rule artifact.

public BRMSUtil() {    
    KieServices kServices = KieServices.Factory.get();
    ReleaseId releaseId = kServices.newReleaseId( "com.redhat", "coolstore", "LATEST" );
    kContainer = kServices.newKieContainer( releaseId );
    KieScanner kScanner = kServices.newKieScanner( kContainer );

    // Start the KieScanner polling the maven repository every 10 seconds
    kScanner.start( 10000L );


Now when we update our rule project, build a new version, the deployed application artifact does not need to be changed and will pick up the changes in 10 seconds. Every user of the application will then be using the newer rules.

This completes our series on examining the JBoss BRMS deployment architectures available to you for your enterprise and application development.

Go back to part I...

Go back to part II...

Go back to part III...

Monday, October 13, 2014

How To Duplicate Artifacts In JBoss BPM Suite in 3 Easy Steps

Earlier we have shown you how to access your business users project within the JBoss BPM Suite, by cloning over an SSH connection.

The following example is using the JBoss BPM HR Employee Rewards process project as the starting off point, giving us a completed process project.

Now we assume that we want to extend our existing process with a new BPMN2 concept, but we don't want to create a new process parallel from scratch. We have the desire to copy the existing artifact and start modifying from there.

Looking into the JBoss BPM Suite we can't find a way to do this in the dashboard, not even when we are managing the artifacts as an admin user.

Project Authoring duplicate of process artifact.
This is fine, as the developer setting up a project has more control options as the underlying repository is GIT which they can approach with all the normal tooling they use to develop their applications.

In the following 3 easy steps we use the command line in a console to show the GIT interaction to copy and insert a new process that gets you started working on the new modifications you want to make.

1. Clone process project

As stated, this has been covered in a previous article. Here is the short version to clone the rewards process project over SSH.

$ git clone ssh://erics@localhost:8001/rewards-demo

Cloning into 'rewards-demo'...
The authenticity of host '[localhost]:8001 ([]:8001)' can't be established.
DSA key fingerprint is ef:48:43:b3:ef:c4:ac:c7:d3:2a:3f:52:63:52:8c:e8.
Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '[localhost]:8001' (DSA) to the list of known hosts.
Password authentication
Password: bpmsuite1!

remote: Counting objects: 1277, done
remote: Finding sources: 100% (1277/1277)
remote: Getting sizes: 100% (1142/1142)
remote: Compressing objects: 100% (1076486/1076486)
Receiving objects: 100% (1277/1277), 135.97 KiB | 0 bytes/s, done.
remote: Total 1277 (delta 41), reused 0 (delta 0)
Resolving deltas: 100% (706/706), done.
Checking connectivity... done.

This gives you a local copy of the rewards process project and all artifacts.

2. Copy existing artifact

Now we want to create a copy of the existing rewards process to start extending with new functionality.

$ cd rewards-demo

$ cp rewards/src/main/resources/com/redhat/jboss/hr/rewards/rewards-approval.bpmn2 \

$ git add rewards/src/main/resources/com/redhat/jboss/hr/rewards/rewards-multi-approval.bpmn2

$ git co -m "Added new process to extend with multi-instance approval."

Administration perspective with duplicate added.
Now we have duplicated the artifact we want to extend, but it only exists locally in our project, we need to push it back to the business users.

3. Push back into project

We push the changes back into our central repository over SSH.

$ git push

Password authentication
Password: bpmsuite1!

Counting objects: 21, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (11/11), 787 bytes | 0 bytes/s, done.
Total 11 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4)
remote: Updating references: 100% (1/1)
To ssh://erics@localhost:8001/rewards-demo
   87e23d9..c772080  master -> master

Now we can see that it appears in business-central both in the Administration Perspective and the Project Authoring perspectives. This can be done in the same exact fashion using JBoss BRMS.
Pushed back into the central repository.

We hope this helps speed up your development by easily duplicating existing artifacts in your JBoss BRMS & BPM Suite projects.

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.


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.

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.

Go back to part I...

Go back to part II...

Wednesday, October 8, 2014

4 Foolproof Tips Get You Started With JBoss BRMS 6.0.3

Last week Red Hat released the next version of JBoss BRMS, labeled 6.0.3 and it is available in their Customer Portal for those with a subscription.

If you are curious as to what is new in this release, see the release notes and the rest of the documentation online in the Customer Portal.

What we are looking for are some easy ways to get started with this new release and this article has just the things you are looking for.

We will give you a foolproof installation to get you started, then show you a complete online web shop project you can experiment with, provide a completed Cool Store project for your evaluation needs and finally provide you with an advanced integration example that ties together JBoss BRMS with  JBoss Data Virtualization.
Installation to get started.

Tip #1

This is the first step in your journey, getting up and running without a lot of hassle or wasted time.

This starts with the JBoss BRMS Install Demo which gets you started with a clean installation, a user to get started, and the product open in your browser for you to get started designing your rules, events and rule flows.

Tip #2

Now you have an installation, you are looking at the product, but what should you do next?

No worries, we have a very nice hands on tutorial for you that shows you how to take your installation from zero to a full blown online web shopping cart application. You will build the rules, event and rule flow that is needed to realize this application.

Check this online workshop here:

Tip #3

Maybe you are just looking to evaluate or just play with the product we also have a fully finished Cool Store retail example for you to enjoy.

Online web shopping cart.
This is the fully completed online web shopping cart application with rules, decision table, event and rule flow that you can also put together yourself (see Tip #2).

This project also has links to more information and details around what it is made of and also provides a video walk through.

Give it a go and install the Cool Store Demo project to evaluate JBoss BRMS today.

Tip #4

The final step is to examine more advanced use cases like integration cases using JBoss Data Virtualization.

Integration solution.
It just so happens we have an interesting project, JBoss BRMS & JBoss DV Integration Demo, that is just as easy to install as the previous ones and it demonstrates the value of decision logic being used with diverse data sources in an enterprise.

Also be sure to enjoy the extensive video collection that is presented in the projects documentation, they walk you through all the details.

We hope these foolproof tips are all you need to get started with JBoss BRMS and the new 6.0.3 release.