Posts Tagged: jBPM

jBPM talk @ JDD09 online on Youtube

I just found out that the friendly people of Proidea (organisation behind the Java Developers Day or ‘JDD’ in short) have put the jBPM talk online which we did back in October.

The talk is divided into four parts, all nicely organized in a playlist on the Proidea Youtube channel.

Pictures of the talk (and the rest of the event) can be found here.


Native BPMN 2.0 execution with the freshly released jBPM 4.3

Happy 2010 to all the folks who read this blog! I’m extremely pleased to start this  year with a bang by announcing that jBPM 4.3 has been released!

As we announced last month, the major achievement of this release is the native BPMN 2.0 execution on top of the PVM. See the announcement itself for more information, examples and a shiny movie.

The main goal of the first release of our BPMN 2.0 implementation was to implement the ‘basic’ part of the specification. Using the basic constructs, one should already get quite an impression how BPMN 2.0 can be used in practice with jBPM. We’re extremely proud that we’ve managed to include the BPMN 2.0 implementation as an integral part of the jBPM framework. This means that no database or API changes are required when you want to start using BPMN 2.0 with jBPM. Heck, enabling BPMN 2.0 in jBPM requires one single line of configuration. Just check the example of the previous BPMN 2.0 blogpost to see all this sweetness.

The complete distribution zip file can be found on

This distribution includes quite a few examples to get you started. The developers guide that is shipped with the distribution also contains a whole new chapter about how to implement BPMN 2.0 processes using jBPM 4.3. The content of the documentation is detailed and people with no prior BPMN 2.0 knowledge should be able to understand it without much problems. See the subdirectory /doc/devguide to find this guide. Or you can take a look online(link to my own version, online doc on isn’t yet updated due to past holiday season – but this can change any moment now).

To finish up, let me quote one of our prominent Community Users, Bernd Rücker:

“2010: the year of BPMN 2.0”

Of course, BPMN 2.0 isn’t the only thing we’ve been doing the last two months. Check our JIRA for a complete changelog. Most noteworthy new features are the ejb and jms invocation for JPDL – features that are easy to leverage for a future jBPM BPMN 2.0 release …

As always, thanks for reading!

Upcoming review ‘jBPM Developer Guide’ by Mauricio Salatino

Building an open source framework sure is a rewarding experience. You see community people logging issues, contributing patches, answering forum posts, joining the community days, etc.

And sometimes there is a crazy enthusiast user who sacrifices *a lot* of his free time to write a jBPM book. Heck, writing a jBPM book has been a long-lived dream for me … but some things always seem to come between that dream and reality (you know, like building a BPMN 2.0 implementation on top of jBPM). But that’s probably just an excuse, I know.

Writing a book takes a lot of time and effort and it’s an adventure that’s not to be taken light-heartedly. So many, many, many kudos to Mauricio Salatino for writing the just released “jBPM Developers Guide”! Just click on the book cover on the left to get more information or to order your own copy.

The people of Packt publishing were so kind to send me a review copy of this book, which I received this morning (see picture below). So expect a review coming up soon (I’m going to give it a thorough reading).

jBPM4: What’s new (part 3)?

The new (rock-solid) service API

When making the transition from jBPM3 to jBPM4, the most remarkable change is probably the new service API.

In jBPM3, it was not always clear  where to look for a certain operation. Some operations were found on the JbpmContext, or on the GraphSession, or on the TaskManagement interface, or yet some other class. So there definitely was an API, but the growth of jBPM both in Slocs and adoption in the past years have transformed it into a maze for many people who wanted to learn jBPM.

In jBPM4, the jBPM team has drastically moved away from these shackles of legacy and has chosen a simpler approach with a less steep learning curve: the service API. Every jBPM story (webapp, standalone, shared BPM server, etc.) starts with a ProcessEngine. As the name implies, the ProcessEngine is the key for doing the actual BPM stuff. But like the engine of your car, you need components to control and guide your engine (gears, brakes, etc) or the engine will do nothing. So basically what you’ll do is create a process engine from a given jBPM config (jbpm.cfg.xml) and acquire from it the services.

  • RepositoryService: allows managing static process data: deploying process definitions, enable/disabling them, query them, etc.
  • ExecutionService: exposes operations concerning the runtime executions (ie process instances and sub-executions): starting process instances, variable management, retrieving and deleting executions, etc.
  • TaskService: this service will probably be used the most, since it gives access to the most crucial part of BPM, Human Interactions. Everything you ever wanted to do with human tasks is done through this service: creating tasks (ad-hoc is supported!), querying, assigning them, task completion, etc. You’ll notice that, in comparison with jBPM3, task management has been given a complete redesign which makes tasks easier to access, query and filter.
  • HistoryService: in jBPM4, a clean separation has been made between the runtime and historical data. The previous services all had more or less something to do with active executions of a process, whereas the historyService is only concerned with things of the past. Through this service, historical data (such as completed process instances or executed activities) can be easily queried. This service also gives access to some statistical calculations which are done by the engine. There is no real prior component for this in jBPM3, so be sure to check it out!
  • ManagementService: the last service is the one that’ll be used only by ‘management apps’ (eg the jBPM console). This services allows for example to query jobs and execute them (without the needing a job executor), but typically you’ll not use it in end-user software.

Note: the Query API which I discussed in part 2, is also accessible through these services.

The services are designed such that every practical jBPM use case is covered by it. All the API services are tested by us at our QA lab against several databases (HsqlDB, MySQL, PostgreSQL and Oracle for the moment, but we’ll expand this very soon), different Java versions (jdk 5 & 6) and JBoss AS versions. So when you use this new API, you can be sure it is stable as a mountain goat (is this a valid expression?).

But jBPM-power users shouln’t be afraid that this ‘easier’ jBPM API leads to less power. The service API is in fact an abstraction on top of the CommandService facade approach, which was already in the more recent versions of jBPM3. In fact, every service operations translates into a Command, which is executed in the well-known try-catch-finally block of jBPM. Take a look at the source of DefaultCommandService if you want to know more. You can easily retrieve the CommandService to get access to the full power of the jBPM engine:


Power users will know what to do with it 😉

Stay tuned for the next post, where I’ll show you how easy it is to create a Hello World process with jBPM4 and the service API.

jBPM4: What’s new (part 2)?

The new and shiny query API

Many people will agree with me that starting with jBPM3 was hard at some points. The operations offered by the engine could cover every use case, but it tended to grow cumbersome. Power-users quickly switched to writing complex Hibernate queries to get the job done quickly. However this led to several problems:

  • One had to know the complete jBPM data model to write these queries. Learning curve++.
  • It was hard for the jBPM team to introduce new features that broke compatibility, since many (important) customers relied on their custom queries.
  • jBPM was regarded by some as too low-level and thus rejected.

But, grief no more.

The new API has been enhanced with a query system that will cover most of the queries you can think of. Developers who have to write company-specific query can still rely on Hibernate. But for most people out there, the query API will be more then suffice.

Queries can be written in a unified way on all major jBPM concepts: Process Instances, Tasks, Deployments, Historical processes, … For example:

List<ProcessInstance> results = executionService.createProcessInstanceQuery()
.page(0, 50)

Gives all the process instances of the given process definition which are not suspended. Oh yeah, the result is also paged. Pretty neat, isn’t it? Querying tasks is done in completely the same way:

List<Task> myTasks = taskService.createTaskQuery()
.page(100, 120)

This query will give me all the tasks for a given process instance assigned to me, paged of course, in a descending order based on the duedate.

Conclusion: Those unreadable and unmaintainable Hibernate queries can be forever banished to the nighmare realm. The query API is powerful and easy to understand. The steep learning curve of jBPM3 has been lowered significantly by this new API component. And we can now change the datamodel internally, without breaking the queries. What’s there not to like?

jBPM4: What’s new?

History lesson

Back in the days before I joined JBoss (translate: up until last moth ;-), many people asked me why they should be switching to jBPM4 once it was released. At that point in time, I could list all the announced features, but I really hadn’t used them in practice. The last couple of weeks however, I’ve been pretty deep (and pretty late) in the core code, and to those people I can now honestly state it was well worth the wait.

I still remember, when I was learning this ‘jBPM’ thing, there were already rumors about ‘version 4’ and ‘the PVM’, but nobody really could tell what it was and when it was coming out. There was a great demand for jBPM3 consultants on the market, so I really didn’t mind…

Fast-forward almost one and a half year… things look quite different now. I left the jBPM consultancy and joined the team of my consultancy raison d’ être. I wasn’t there when it begun and I wasn’t there on the big day and every release up till then. But I’m sure proud to be there when The Next (R)Evolution of jBPM hits the shelves next month (although my contribution is limited).

I’m guessing that most of you readers are familiar with jBPM (or at least have heard of it), so I’m not going to do a marketing blabla here. In this post, and the posts in the coming weeks, I’m going to illustrate what’s new in jBPM4, what’s improved and why I believe that the latest incarnation of jBPM (still) is the most kick-ass framework for BPM developers.

jBPM4 in a nutshell

jBPM4 can be best described as the result of smashing jBPM3 in a million pieces, carefully selecting the superb bits, putting them together with completely new or rewritten components by using the newest and fanciest glue available. Don’t worry, the core concepts of jBPM still are alive and kicking in jBPM4 (my old consultant soul smiles). But everything around has been given a rewrite, using the more than 5 years of experience in a wide-spread adoption that the jBPM team has been exposed to. But like I said, in the next posts I’ll take you for a detailed look into this stuff, for the moment I’ giving a quick (and incomplete) overview:

  • Calling the jBPM4 engine is done through a stable API (aka services). So this means no more try-catch-finally-close-the-context blocks anymore or writing a jBPM operation (on which you are really proud) to find out the next day it was already in there, hidden in an obscure package. Every of the services is tested against a range of databases (Oracle, PostgreSQL, MySQL and HSQLDB), Java versions and JBoss AS versions on every commit in the JBoss QA lab (Hudson based).
  • The database schema has been completely redesigned. The new schema facilitates migrations (version wise and process wise) and has been built with performance in mind.
  • No more method chaining. People who have been there, know what I’m talking about (I lost quite some time on this one at my first customer). The core engine uses the concept of atomic operations.
  • The Job executor and activities have been completely rewritten with performance and removing concurrency conflicts in mind (remember the StaleStateExceptions…).
  • A fancy web2.0 console, which allows for demo’s with the extra touch 😉
  • Improved documentation, split in a user- and developer’s guide. We all *love* documentation 🙂
  • And much much more … but track my blog if you want to know them 😉

The story continues…

jBPM Community Day 2009 retrospective

Last Friday, the second edition of the jBPM Community Day was held in Antwerp, Belgium. In my opinion, the event was a great succes and I sincerely hope that the tradition will be continued next years.

If you weren’t able to attend the event (for which you should have a really, really good reason ;-),  you can read some impresions from other people who beat me to write about it:

I also gave a tech demo/presentation about jBPM4 and how the new API can be used to do BPM stuff really easily. The demo is about the business process behind a parking meter. Using my cellphone through bluetooth I showed how I could send a message to my parking meter on my laptop, which triggerd the start or continuation of the business process. Oh yeah, bluetooth is a hell to work with … I think the people in the audience got this message 😉

For more information, take a look at the slides:

Presentation jBPM Community Day 2009 – First steps with jBPM4

View more presentations from jorambarrez.

Some screenshots of the application (which isn’t nearly as cool as doing the demo with my cellphone in live 😉 and the (simple) BI console can be found at:

To prove that I’m really triggering my processes through bluetooth, I took this video (with my old cellphone). The quality isn’t that good, but you’ll get a taste of what the real life demo was all about:

The source code of the demo, the HSQLDB database and the cellphone app can be downloaded here. Please keep in mind that the code is for a demo, it shouldn’t be used in production systems. Perhaps if I get enough requests, I’ll tidy the code up. Also, probably it’ll only will work on Windows (due to bluetooth DLL’s) … you can still use the failsafe console though.

Integrating jBPM3 with Spring (Part 1)

A common requirement I hear a lot is on how to integrate jBPM and Spring. This marriage of jBPM and Spring seems only natural, since both are Pojo-loving frameworks and both are often used in combination with Hibernate.

So, it’s very sad to see that currently there is no library available that allows to easiliy integrate jBPM and Spring. I do know that there exists something such as Springmodules, but using it (unknowingly) in the past has taught me the hard way that it is not usable anymore (it’s based on jBPM 3.1.x, which introduces very difficult and subtle bugs when used with a more recent version).

In this article I’m going to show you how easy it is to integrate jBPM with Spring. I’m going to focus only on jBPM version 3 here (version 3.2.x and 3.3.0 atm), since many people will still (have to) use it for a while until and after jBPM version 4 is released. Luckily, for jBPM 4, Spring integration will be provided out-of-the-box, leveraging the work the work that is done by my good friend Andries Inzé.

The goal of this Spring integration can be split into 3 sections:

  • Interacting with the jBPM engine through the Command service facade
  • Let Spring manage the transactions
  • Using Spring beans in jBPM process definitions (ie injected with other dependencies defined in the Spring container
  • Managing the asynchrounous component of jBPM (ie the JobExecutor) from within the Spring container

Using the CommandService

Traditionally, a call to the jBPM engine follows a fixed pattern:

Jbpmcontext ctx = JbpmConfiguration.openContext();

try {

…. // jBPM code

} catch (JbpmExecption e) {

… //exception handling

} finally {



Since this is cumbersome, the jBPM developers have introduced the CommandService which simply takes a Command (interface) which looks like this:

public interface CommandService {

public Object execute(Command command);


The reason why we specifically want to use this service in Spring is that tor Spring-users, this pattern (template – callback) is nothing new if you think about the TransationTemplate, JdbcTemplate, HibernateTemplate, etc.

Let Spring handle the transactions

By default, every call to the jBPM engine (or every Command given to the CommandService in our case) is done in a seperate transaction. This is not how typically Spring transactions work (ie where services are transactional). Since we propably want to pack a couple of jBPM calls into one transaction, we need to do two things.

First, we need to disable the jBPM transactions and use the Hibernate session which is currently bound to the thread. In the jBPM config file (jbpm.cfg.xml) we do following adjustments:

<service name="persistence">
        <bean class="org.jbpm.persistence.db.DbPersistenceServiceFactory">
            <field name="isTransactionEnabled"><false /></field>
            <field name="isCurrentSessionEnabled"><true /></field>

Secondly, we need to inject the Sessionfactory, which is defined in the Spring container, into the jBPM engine:

JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();

Putting it all together

We can now create the necessary classes to implement the steps as required above:

<bean id="jbpmConfiguration" class="be.jorambarrez.jbpm3_spring_integration.JbpmConfigurationFactoryBean">
    <property name="sessionFactory" ref="sessionFactory" />
    <property name="startJobExecutor" value="false" />
    <property name="springJbpmObjectFactory" ref="springJbpmObjectFactory" />

<bean id="springJbpmObjectFactory" class="">
    <constructor-arg value="jbpm.cfg.xml" />

<bean id="jbpmCommandService" class="org.jbpm.command.impl.CommandServiceImpl">
    <constructor-arg ref="jbpmConfiguration" />

Note that we only need 3 classes. The SpringObjectFactory is an implementation of the jBPM ObjectFactory interface. Through this interface, jBPM will retrieve beans that it needs to function. Our implementation implements the ApplicationContextAwara interface to have access to the Spring container. When the jBPM engine needs a specific bean, the Spring container is first consulted, before delegating to the default jBPM object factory. This means that we can define beans used by jBPM in Spring now. The default jBPM object factory uses the jBPM config file to built itself.

The  JbpmConfigurationFactoryBean is a factory bean that produces a singleton JbpmConfiguration (shareable and threadsafe). If you would inspect the source code, you can see that the injected sessionFactory is used to inject the Spring SessionFactory into the jBPM engine. The same is done with the SpringObjectFactory, to replace the default one.
Note that this bean also allows to start up the Job Executor. We will explain in detail the Job executor in the next part of this article, since there are a few complications regarding transactions.

Using Spring beans in a process definition

Since all beans containing business logic are defined in the Spring container, it is only natural to be able to call Spring beans from a JPDL process definition. We have implemented the SpringDelegation class to do this:

<node name="myNode">
    <action class="be.jorambarrez.jbpm3_spring_integration_.SpringDelegation" config-type="bean">

In short, you simply need to define the name of the Spring bean you want to use. The SpringDelegation class can be used for any typical jBPM delegation: ActionHandler, DecisionHandler, AssignmentHandler, etc. The SpringDelegations acts as a proxy object by implementing all these jBPM interfaces and delegates to the Spring object when an operation is invoked on the proxy.

Implementation note: I’m not 100% happy with the implementation of the SpringDelegation proxy. It caches the ApplcationContext statically after injection by being ApplicationContextAware. If anyone should know a cleaner solution, please let me know. The downside of this solution is that you must define a bean in Spring, which isn’t injected nowhere (ie the applicationContext must be injected in the static field):

<bean id="springDelegation" class="be.jorambarrez.jbpm3_spring_integration_.SpringDelegation" />

Downloading the sweetness

You can download a jar with the classes described above here.

You can download the source code here. This is a regular Maven project, so contributors don’t hold back.

And please don’t peak too much inside the source code… there is already stuff in there for the next part of this article ;-).
In the second part I will discuss how the jobs and timers integrate into Spring. We’ll see that some special attention is required reagarding the transactions.
In the final part of this article, I will demonstrate how these few classes can be used together with Spring and jBPM3 to build a real-life application. So stay tuned (and subscribe to my rss 😉

UPDATE (25/08): Be sure to also read the excellent posts by MrMagoo on the jBPM forum:

jBPM job executor for Spring

Today, a collegue of me asked how the jBPM job executor is started using Spring. Before going into details: the job executor in jBPM is used to execute jobs (truly an original name). A jBPM job is a unit of work which has a certain duedate. The most common usage of a jBPM job is a timer: when an amount of time has expired, an action must happen. A more complex usage is asynchronous messaging, where the messages are wrapped into jobs.

Now, the default jBPM distribution contains a so-called ‘job executor’. In a nutshell: this component checks if there are new jobs available (now > duedate) and executes the attached action. There are three ways of starting the job executor:

  • Using the org.jbpm.job.executor.JobExecutorThread class. This is a normal Java thread, so all the common thready things can be done with it. If you want to use these threads, also make sure to check the  org.jbpm.job.executor.JobExecutor class.
  • The enterprise version of jBPM has a JobExecutorServlet. Given a jBPM configuration, it starts up the job executor. The nice thing about this servlet is that it hides all the ugly implementation details of the threads and only needs some configuration
  • The enterprise version also has an EJB implementation which uses JMS. Altough this is quite cool, it is quite overkill for the most applications.

The thing is, these three options aren’t really fit for a Spring based application. Off course, you can call servlets or EJBs in one way or the other using Spring, but it still remains quite clumsy.

The nice thing about open source frameworks is the fact that they are … well … open. So, given the source code of the JobExecutorServlet, it is easy to see that the clever framework creators have narrowed the necessary steps down to these 2 lines (which can be written in 1 line actually):

jbpmConfiguration = JbpmConfiguration.getInstance(configurationName);

By using the Spring org.springframework.context.ApplicationListener interface, one can listen to application context calls. So, if we execute the previous lines while loading the Spring application context, the jBPM job executor threads will also be started. The resulting bean can be found here. Simply declare it in the Spring config and inject a jBPM configuration.

So, that’s it. There’s nothing special or difficult about it, but I hope it’ll save some time for at least one fellow jBPM developer.



Update: Andries Inzé showed me that there is another way of achieving the same by using Spring bean “init or factory methods”:

<bean id=”jbpmConfiguration” factory-method=”getInstance” init-method=”startJobExecutor” class=”org.jbpm.JbpmConfiguration” >


I really like it: there is no extra bean needed using this approach.

jBPM gets sexy: first sightings of new web console

I’m sure many will agree with me: the current jBPM console was in desperate need of some sweet web 2.0 love. I’m also sure that many brave new jBPM adventourists have not dared to go deeper into jBPM after seeing the console (which is, after all, the first thing one will see when trying jBPM).

But … weep no longer! Heiko Braun has posted on his blog a first glimpse of the new and shiny jBPM console. It looks very slick and I’m sure it’ll have all those web 2.0 thingies since it uses GWT. I’m also very pleased to see an early integration of BI/BAM/SAM features in the console. This is exactly what customers expect from a workflow tool.

I’m also hoping they’re gonna include security (BI only for analysts, deployment only for developers, … perhaps they can ‘borrow’ something from the Guvnor …). And if they really want to rock the party I’m hoping for a ‘plugin system’ so new things can be added to the console very easily (eg a simple intranet application integrated with the console … or some business tailored enhancement to the process viewer)

The PVM, JPDL 4 and the new console … one thing is certain: the future of jBPM is bright!