Eric D. Schabell: February 2014

Monday, February 24, 2014

JBoss BRMS Taste of Training Webinar - Decision Tables


Have you heard about Red Hat’s Taste of Training webinars?

On March 27, 2014 there will be a fantastic rules webinar showing you some of the basics around rules with a focus on the decision tables in the Red Hat JBoss BPM Suite. This will take place in two separate sessions:

Session 1:
Date: Thursday, March 27th, 2014
Time: 13:00 UTC | 9 a.m. (New York) | 3 p.m. (Paris) | 6:30 p.m. (Mumbai)
Duration: 60 minutes

Session 2:
Date: Thursday, March 27th, 2014
Time: 18:00 UTC | 2 p.m. (New York) | 8 p.m. (Paris) | 11:30 p.m (Mumbai)
Duration: 60 minutes

Whether you’re evaluating a specific training course or are eager to learn something new, the Taste of Training webinar series is your gateway to award-winning Red Hat® Training.

These hour-long webinar demonstrations are delivered by members of the Red Hat Curriculum team, providing practical knowledge and real-world examples. Can't attend a scheduled upcoming webinar?

Watch the recording on demand afterward.

Defining business rules as a decision table

Both business analysts and developers have roles in creating business rules that can be quickly updated. Business analysts devise the rules, and developers code them. One way to do this is to devise rules with decision tables that developers can code from.

Writing rules for a rules-based application
Join this webinar to learn how business analysts can use a spreadsheet to devise decision tables that developers can then use to code business rules.

Working with Red Hat® JBoss® BRMS, we’ll show you how to:

  • Lay out spreadsheet-based decision tables.
  • Create an actual decision table in a spreadsheet.
  • Include the decision tables in rules application code using a JUnit test.

Thursday, February 20, 2014

JBoss Webinar Slides Available - Business rules, events, and processes. Oh my!


As I previously mentioned, today I gave a live webinar that covered the various components that you can leverage in the JBoss BPM Suite to leverage your enterprise rules, events, and processes.

There were almost 500 registrations and I got a lot of questions online during the event that I was not all able to get to. Don't worry, I will be getting to them over the next week and get back to you personally if you asked a question that did not get answered live online.

Here are the slides and for those that missed the session you can watch the recording that is already online by registering for this webinar.



Watch for those replies and thanks for listening to my story!

Monday, February 17, 2014

JBoss BPM Suite Webinar - Business rules, events, and processes. Oh, my!


I will be hosting a webinar on the topic of rules and process integration based on Red Hat JBoss BPM Suite 6 on February 20th, 2014 at 17:00 UTC, 12:00 New York, 18:00 Paris, and 22:30 Mumbai.

The following abstract give you an idea of the content I will be covering.


Business rules, events, and processes. Oh, my!

Business rules and events exist to drive processes. So in today's dynamic business environment, creating and updating business rules quickly and efficiently is essential. Business process management (BPM) with rule-driven applications is key to making that happen. Red Hat® JBoss® BPM Suite can help.

Are you ready to dive into the world of business process management to create business rules that can be updated by business users without bothering programmers to make code changes? If so, this webinar is for you.

JBoss BRMS for business processes and rule-driven applications

After this webinar, you’ll be able to:

  • Recognize capabilities, components, and basic concepts of building business processes for rule-driven applications.
  • Recall 2 real life projects that bring those concepts to life, with step-by-step explanations of how to reproduce them yourself.
  • Capture your company’s business logic, start to model your company’s business processes, and dazzle your employer and colleagues with your new found skills.

Friday, February 14, 2014

Red Hat JBoss BPM Suite - how to change runtime session strategy


In another installment of the JBoss BPM Suite Tips & Tricks series we will be helping understand how you can modify the default session strategy for a deployment of your BPM project.

We will be using a simple demo project that can be found in our demo collections on github, which will allow you to view and experiment with the final working example in a JBoss BPM Suite installation.

The JBoss BPM Suite installation you will have to set up yourself, but you can leverage our JBoss BPM Suite installation project we have to save you some trouble.

The goal

The previous article in this series showed you how to access your process context variables from a rule, the problems associated with the default session strategy, and how to solve them to get the rule to fire every single time a process was run.

Now we will describe for you the process of changing your runtime session strategies so that without any special checks in your rules, you will get a rule to execute every time your process is run.

The setup

Start by unzipping the demo project repository and copy it into the JBoss BPM Suite installation projects directory.
# Start by cloning project at 
#   https://github.com/eschabell/demo-collections.
#
$ git clone git@github.com:eschabell/demo-collections.git

$ cd demo-collections

$ unzip niogit-rule-procvar-perinstance-strategy.zip

# Follow instructions and install JBoss BPM Suite 
# via https://github.com/eschabell/bpms-install-demo.
#
# Then copy the demo repository into the JBoss BPM Suite server.
#
$ cp -rv .niogit bpms-install-demo/target/jboss-eap-6.1/bin

# Start the JBoss BPM Suite server.
#
$ ./bpms-install-demo/target/jboss-eap-6.1/bin/standalone.sh

# Login with user 'erics' and password 'bpmsuite' to get started.

Now we can take a look at the process, how it is configured to be deployed by default, what the rule is, what we have to do to modify a process variable, and look at the output.

The strategies

Define deployment with per instance strategy.
Remember in the previous article we showed that multiple runs of the process would only have the rule executing on the first run due to the session strategy being SINGLETON. This meant that the facts in memory were being executed and removed on the first pass, but on subsequent passes through the process no facts were being added to the working memory so the rules never execute again.

We will now change that by changing the deployment runtime strategy to PER_PROCESS_INSTANCE, meaning that every single process that is started gets its very own session.

To do this we need to remove any existing deployments in the Deploy -> Deployemnts view from our JBoss BPM Suite dashboard and then create a new deployment as shown where we select PER_PROCESS_INSTANCE strategy.

New default strategy in our deployment.
Once this is done you will be able to run your process and watch the rule fire every time, but first we need to remove the changes we made previously to compensate for the single session strategy.

Rule updated to always execute.
We do this by updating our rule to remove the check for new objects in our working memory.

Next step is to remove the mappings of a new object into the working memory through the Assignments and DataInputSet mappings from our rule task node.

With these changes saved we can now go to our deployment and start a new instance of the process to prove that it will execute the rule every single time we run it.
Removed mappings.

One warning, should you hit the Build & Deploy button on the Project Editor or restart the server, you will lose the deployment you set up above.

Just recreate it and remember to choose the PER_PROCESS_INSTANCE strategy otherwise the rule will not execute after the initial first run of your process.

A successful log of three consecutive runs should look something like this:
11:35:47,038 INFO  [stdout] (http-localhost/127.0.0.1:8080-3) Execute Java Step
11:35:47,044 INFO  [stdout] (http-localhost/127.0.0.1:8080-3) Tested Rule
11:35:47,047 INFO  [stdout] (http-localhost/127.0.0.1:8080-3) Rule fired!
11:36:05,965 INFO  [stdout] (http-localhost/127.0.0.1:8080-3) Execute Java Step
11:36:05,968 INFO  [stdout] (http-localhost/127.0.0.1:8080-3) Tested Rule
11:36:05,970 INFO  [stdout] (http-localhost/127.0.0.1:8080-3) Rule fired!
11:36:10,479 INFO  [stdout] (http-localhost/127.0.0.1:8080-3) Execute Java Step
11:36:10,482 INFO  [stdout] (http-localhost/127.0.0.1:8080-3) Tested Rule
11:36:10,484 INFO  [stdout] (http-localhost/127.0.0.1:8080-3) Rule fired!

If you look at this from the Process Instance view pane, it would look like this:


We hope you now understand how a process is deployed using a rule, how to access and update a process variable from a rule in your project, what the effect is of the various runtime session strategies, and that you can put this knowledge to use in your own projects.

Thursday, February 13, 2014

Red Hat JBoss BPM Suite - accessing process context variables from a rule


In another installment of the JBoss BPM Suite Tips & Tricks series we will be helping understand how you can access or change a process context variable from inside a rule in your BPM project.

We will be using a simple demo project that can be found in our demo collections on github, which will allow you to view and experiment with the final working example in a JBoss BPM Suite installation.

The JBoss BPM Suite installation you will have to set up yourself, but you can leverage our JBoss BPM Suite installation project we have to save you some trouble.

The goal

The basic goal of this article and demo project is to show you exactly how to design a process that uses a rule that if it fires will then access and modify one of the process variables. This communication between a process and a rule is an often asked question.

The setup

Start by unzipping the demo project repository and copy it into the JBoss BPM Suite installation projects directory.

# Start by cloning project at 
#   https://github.com/eschabell/demo-collections.
#
$ git clone git@github.com:eschabell/demo-collections.git

$ cd demo-collections

$ unzip niogit-rule-procvar.zip

# Follow instructions and install JBoss BPM Suite 
# via https://github.com/eschabell/bpms-install-demo.
#
# Then copy the demo repository into the JBoss BPM Suite server.
#
$ cp -rv .niogit bpms-install-demo/target/jboss-eap-6.1/bin

# Start the JBoss BPM Suite server.
#
$ ./bpms-install-demo/target/jboss-eap-6.1/bin/standalone.sh

# Login with user 'erics' and password 'bpmsuite' to get started.

Now we can take a look at the process, how it is configured to be deployed by default, what the rule is, what we have to do to modify a process variable, and look at the output.

The initial output

Our process consists of a simple run through that prints a log statement at the first node, then runs a rule (which we want to modify a process variable), then a gateway where we decide if the rule fired or not, and then the path where the rule fired (we log that) or the path where the rule did not fire (we log that too).
Test process for rule modifying a process variable.
What we want to test is that a rule with a Left Hand Side or Condition that evaluates to TRUE, will trigger its corresponding Right Hand Side or Action to print a log statement that the rule fired.

On our initial attempt we had a process that only had the first two nodes, then ended. We expected to see something like this in the logs if we ran three instances of the process:
17:29:46,315 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Execute Java Step
17:29:46,330 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Tested Rule
17:29:46,315 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Execute Java Step
17:29:46,330 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Tested Rule
17:29:46,315 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Execute Java Step
17:29:46,330 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Tested Rule

What we ended up with was this:
17:29:46,315 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Execute Java Step
17:29:46,330 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Tested Rule
17:29:46,315 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Execute Java Step
17:29:46,315 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Execute Java Step

At this point we modified the process you see above, adding two debug nodes that report if the rule fired or not, making the outcome clearer. We expected to see something like this in the logs if we ran three instances of the process:
20:51:22,491 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Execute Java Step
20:51:22,494 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Tested Rule
20:51:22,497 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Rule fired!
20:51:35,615 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Execute Java Step
20:51:35,618 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Tested Rule
20:51:35,621 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Rule fired!
20:51:43,312 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Execute Java Step
20:51:43,316 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Tested Rule
20:51:43,320 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Rule fired!

What we ended up with was this:
20:51:22,491 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Execute Java Step
20:51:22,494 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Tested Rule
20:51:22,497 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Rule fired!
20:51:35,615 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Execute Java Step
20:51:35,618 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Rule did not fire...
20:51:43,312 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Execute Java Step
20:51:43,316 INFO  [stdout] (http-localhost/127.0.0.1:8080-2) Rule did not fire...

What happened to the rule firing the second and third time? Not only that, the rule never even triggers in the second and third time through, why?

To find out we need to look at the session strategy that is applied by default.

The deployment

Taking a closer look at how this process is deployed, we see that it makes use of the default session strategy SINGLETON which means it will run all process instances in a single ksession.

Deployment by default is using SINGLETON runtime strategy
This means that the process would put any facts into working memory and then run through our process and at the rule task it would evaluate the rule. This was the first time through an instance.

The second (and all consecutive) time through the working memory was not being modified so the rule is never evaluated, it just passes over it.

To fix this we need to make the process clearer, so we added a process variable to be updated when the rule fired, a gateway to check the process variable, and if set to log that the rules had fired. Remember, the rule firing sets the process variable.

Let's see how that looks.

The rule

We took our initial stab at the rule by setting it up to always match the condition so that the action would fire:
rule "update-procvar"
ruleflow-group "fire-always"

when 
  eval(true)
then
  System.out.println("Tested Rule");
end
Remember with the single ksession the first time through it fired, but after that it never gets evaluated again. To fix this we will need to make sure that some form of object or fact is added into the working memory each time this process instance is run.

Luckily this is provided for in a rule task, where you can create Data Assignments and map your DataInputSets. This is done by selecting the rule task and expanding the Properties sidebar to show you that we have created a fired variable and assigned it the value null, then we are inserting it into the working memory as our DataInputSet.

Mapping the fired variable into the working memory every time.

import org.kie.api.runtime.process.WorkflowProcessInstance;

rule "update-procvar"
ruleflow-group "fire-always"

when 
  $pi: WorkflowProcessInstance()
  String()
then
  $pi.setVariable("fired", "true");
end
What we have done here in the rule is add an import to give us access to the process instance we are running in, then assign it to the local variable $pi so we can work with it to access our process variable, then we have a check that will always succeed if there is a new String object in working memory. Remember we insert a fired object every time we enter this rule task node?

This should cause the rule to evaluate and then using the process instance we can set the process variable fired to true, which is exactly the check that is done at the following gateway node.

Let's run it a few times and see what happens?

The Output

Now that we have sorted out the issues and understand what it means to have a single ksession in which our rules will only fire on a new instance if there has been some fact change in the working memory, we are ready to test our solution.

This is what you will see when you run three instances of the demo process:
21:06:32,767 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Execute Java Step
21:06:32,774 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Tested Rule
21:06:32,777 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Rule fired!
21:06:41,646 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Execute Java Step
21:06:41,654 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Tested Rule
21:06:41,656 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Rule fired!
21:06:47,559 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Execute Java Step
21:06:47,565 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Tested Rule
21:06:47,567 INFO  [stdout] (http-localhost/127.0.0.1:8080-5) Rule fired!

We hope you now understand how a process is deployed using a rule, how to access and update a process variable from a rule in your project, and can put this knowledge to use in your own projects.

Tuesday, February 11, 2014

Red Hat JBoss BPM Suite - access GIT project using SSH


This is one of the most asked questions that I have been getting since the release last week of Red Hat JBoss BRMS & Red Hat JBoss BPM Suite v6 products.

For this article, I will be referencing JBoss BPM Suite product as this is a super set of the JBoss BRMS product. This means that all I describe below in this solution below applies to both products.

It all has to do with the new development and deployment models that are introduced when the repository being used is GIT based.

If we take a closer look at the JBoss BPM Suite architecture we see that the repository linking business users and the development teams is a GIT repository.

JBoss BPM Suite architecture
The usual work flow would have the business analysts working in the JBoss BPM Suite web based GUI tooling using model designers, process designers, and various rule designers to put together their projects. Once this has been completed, or parallel to this work, developers in the organization can work on their applications and contribute to support the business analysts with updates.

When we were working and testing the initial beta releases of the product this was all done through the unsecured git-based protocol, which allowed you to clone and push without any form of authentication. This would look like the following example, using the Generic Loan Demo, of cloning a read-only copy of the project:

$ git clone git://localhost/bpms-generic-loan

Cloning into 'bpms-generic-loan'...
remote: Counting objects: 266, done
remote: Finding sources: 100% (266/266)
remote: Getting sizes: 100% (213/213)
remote: Compressing objects:  51% (110/212)
remote: Total 266 (delta 22), reused 133 (delta 19)
Receiving objects: 100% (266/266), 47.97 KiB, done.
Resolving deltas: 100% (54/54), done.

As of the final product release, it is no longer possible to push your changes without authentication.

If you should try to push any changes you will see the following errors:

$ git push

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

To achieve this you would make use of the SSH protocol when you clone and push your projects. This would look like the following, again using the Generic Loan Demo project:

Secure clone project

$ git clone ssh://erics@localhost:8001/bpms-generic-loan

Cloning into 'bpms-generic-loan'...

The authenticity of host '[localhost]:8001 ([127.0.0.1]:8001)' can't be established.
DSA key fingerprint is 62:c2:c5:4c:22:3a:dd:8e:24:34:bf:3f:16:e7:3c:73.
Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '[localhost]:8001' (DSA) to the list of known hosts.
Authenticated with partial success.
Password authentication

Password: bpmsuite   <<<<< enter-password-here

remote: Counting objects: 266, done
remote: Finding sources: 100% (266/266)
remote: Getting sizes: 100% (213/213)
remote: Compressing objects:  51% (110/212)
remote: Total 266 (delta 22), reused 133 (delta 19)
Receiving objects: 100% (266/266), 47.97 KiB, done.
Resolving deltas: 100% (54/54), done.

Secure push changes

$ git push

Authenticated with partial success.
Password authentication

Password: bpmsuite   <<<<< enter-password-here

Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 282 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2)
remote: Updating references: 100% (1/1)
To ssh://erics@localhost:8001/bpms-generic-loan
   f789a22..659ef75  master -> master

I hope this helps you along as you explore and expand you knowledge while developing your BPM projects with the JBoss BPM Suite.

Friday, February 7, 2014

Chicago JBUG Report - JBoss Evangelists on Tour



This week, as previously reported, we had a pretty special JBUG event in Chicago with all of the JBoss Technology Evangelists in one room for the day.

They forgot to mention that it would be -19C with wind chill bringing it down to -26C.

This made travel into the office for the day long event a challenge but we kicked it off and presented on diverse topics around JEE, JBoss EAP, JBoss BRMS, JBoss BPM Suite, JBoss DV, and JBoss FSW.

The group was allowed to pick the topics they wanted to dig into and were given sets of workshop files to take home for personal use and exploration.

I covered the JBoss BRMS & BPM Suite Primer in a session and then provided them with a small workshop example around golfing.

The slides can be found here: