Red Hat JBoss BPM Suite - How to Change Runtime Session Strategy
Join the DZone community and get the full member experience.
Join For Free
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.
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.
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.
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.
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.
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:
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.
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. |
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. |
![]() |
Rule updated to always execute. |
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.
Business process management
Session (web analytics)
JBoss
Published at DZone with permission of Eric D. Schabell, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
How To Manage Vulnerabilities in Modern Cloud-Native Applications
-
Using OpenAI Embeddings Search With SingleStoreDB
-
Database Integration Tests With Spring Boot and Testcontainers
-
Health Check Response Format for HTTP APIs
Comments