Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Red Hat JBoss BPM Suite - How to Change Runtime Session Strategy

DZone's Guide to

Red Hat JBoss BPM Suite - How to Change Runtime Session Strategy

Free Resource

Today’s data climate is fast-paced and it’s not slowing down. Here’s why your current integration solution is not enough. Brought to you in partnership with Liaison Technologies.

 

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.

Is iPaaS solving the right problems? Not knowing the fundamental difference between iPaaS and iPaaS+ could cost you down the road. Brought to you in partnership with Liaison Technologies.

Topics:

Published at DZone with permission of Eric D. Schabell, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}