Posts in Category: JBoss

Book review: jBPM Developer Guide by Mauricio Salatino

I’ve managed to give the jBPM Developer Guide by Mauricio Salatino, which was sent to me less than a mont ago by the people of Packt, a thorough read. Reviewing a book is not a simple task, certainly not when the topic is quite familiar. So I started every chapter by writing down some notes of what I would expect to find, and checked while reading if the content could cover my expectations.

Since many people will simply skip to the conclusion part (at least, that’s what I do when I read a book review), I’ll start off with The Short Review.

The Short Review

Basically a book review needs to answer the following question:

Would you recommend the book?

Yes. I would certainly recommend the book to any novice jBPM user. The book covers practically all jBPM3 concepts and gently builds up the complexity of the content. Having this book a few years ago when I started out with jBPM, would have saved me tremendous time. Granted, the book has some minor flaws (see The Long Review), but it currently is the best guide and reference when you want to start using jBPM. period.

The Long Review

In the following sections, I will summarize for each chapters the notes I’ve taken while reading the book.

The book is published by “Packt Publishing”. The nice thing about Packt is that they are generally fast to publish books about new and exciting, mostly open source technologies. On top of that, they also invest a part of the profit back into the project, which is a noble deed if you ask me.

In general

  • This book is about jBPM3, not jBPM4. One might think this is a bad thing, but do remember that jBPM3 is extremely stable and is part of the JBoss SOA-Platform for many years to come (today jBPM3 is the only official supported version by Red Hat – these things take quite a time). People that are familiar with jBPM3, will have no problems to make the jump to jBPM4.
  • A general nuisance is the language usage throughout the book: although the sentences are syntactical correct, they often not feel ‘right’. Others have already commented on this fact, so I’m not going into it here. I don’t blame the author: he shows a great amount of enthusiasm and jBPM knowledge, but with a little more editorial reviewing, this book could have gotten that little extra edge.
  • The book is great for jBPM starters, no single doubt about that. However, I would have liked to see more ‘best practices’ and advanced configurations (JMS/SOA/etc.). Let’s hope for a next jBPM book that covers those topics 😉

Preface and Chapter 1: Why developers need BPM

This chapter is a bit overwhelming for beginners. The author tries very hard to convince people of the rightness of open source software (which is perfectly valid ), but it’s too heavy as a starter chapter. This chapter would have been a good appendix, I guess.

Oh yeah, I don’t necessarily agree with Mauricio’s definition of a ‘BPM suite’. You’ll understand it when you read it 😉

Chapter 2: jBPM for Developers

Good introduction to some important concepts like wait states, nodes, process definition vs instance, etc. The downside of this chapter is that it tries to explain these concepts by building a simple state machine in Java code. In my opinion, 99% of the jBPM starters will find this too overwhelming. I found it fun to read, but then again my day job is to build such “state machines” 😉

Luckily, it goes uphill from here. My advice would be to read the chapters 1/2 after starting from chapter 3, and only giving them a quick read either way.

Chapter 3: Setting up Our Tools

Mandatory chapter for every beginner. I really liked the fact that nothing is “taken for granted’, as tools like SVN and Maven are also covered with some text. Many technical books assume that this is common knowledge, but experience has taught me this certainly is not the case. I also really liked the ‘community’ take on things in this chapter. The author explains and demonstrates that by knowing maven, svn, etc. every one can contribute to open source ecosystem. As a core jBPM dev, I was happy to find these encouragements.

This chapter demonstrates in depth how tools (Maven, Eclipse, etc.) need to be configured to get the maximum out of your jBPM experience. Also the jBPM project structure is touched, which is in reality a true knowledge advantage I’ve not yet seen in many jBPM users.

A small side remark (has no influence on jBPM novices, ofc.): the history of jBPM is a bit skewed, which is a bit of a pity if you’re closely involved with the project (eg. jBPM was orginally not created by JBoss)

Chapter 4: jPDL language

When I was reading this chapter, I noted down “To the point! This is the content you need”! I can’t express it better than that. A must-read chapter for every jBPM adept.

I was delighted too see that the author often explains functionality by referring to snippets in the source code. In my opinion, this is the way open source tech books should be. When I was still a jBPM consultant, I often looked at the source code to learn how corner cases where handled, or what exactly a certain operation does, etc. As Ronald often states on the jBPM User Forum: the best documentation is the source.

Chapter 5: Getting Hands Dirty with jPDL

In this chapter, the topics explained in the previous sections are used in a real project. The use case is interesting and has great didactical value. I had some reservations when I read the use case, and noted down some questions on how the author would tackle them (if they were tackled at all). I was happy to find them all answered by the end of the chapter. Perhaps a small remark could be here that the jBPM configuration isn’t showed in this chapter. This could be a bit confusing for some starters, since it involves some “magic” that is easy to explain.

Chapter 6: Peristence

Really thorough and detailed explanation of jBPM persistence. Excellent transaction explanation and great diagrams that explains what happens in which situation (automatic nodes, wait states, when updates happen, etc.). Really every aspect is covered (for example even Hibernate caching is touched), nice!

Imo, perphaps the best chapter of the book.

Chapter 7: Human Tasks

Perfect follow-up for the previous chapter. Good, detailed content about probably the most important construct of any BPM engine. I also really like the webapp approach at the end of the chapter: this is the stuff why people buy the book.

Chapter 8: Persistence and Human Tasks in the Real World

This chapter perfectly aligns with the previous Human Task sections: good and very detailed content.

Chapter 9: Handling information

Great explanation about variable usage in jBPM. The content is good for starters and should get you going quite far. But in my opinion, some things should have gotten more attention, since variables are an area in which many mistakes are made in real life projects. Some topics that could have gotten more love: hibernate objects as variable (+ why !), serializable (what about synchronisation problems?), business keys for process instances (why do you need them).

Chapter 10: Advanced features

This chapter definitely covers some advanced features. It even managed to surprise me: I had totally forgotten about the superstate indirections using “../” in the node names (altough I’ve used it a lot on a certain project) and the book mentioned this little detail! Also start tasks were covered – nice!

Some topics which I have needed a lot in my past projects weren’t covered (but this is really advanced stuff, and definitely not for startes): subprocess binding, more database schema focus, e-mail node and custom HQL queries using the jBPM objects. So altough I really liked the chapter, it could have gotten extra points when dealing with those topics.

Chapter 11: Advanced topics in practice

Not to miss chapter since here asynchronous execution is explained. The books goes really deep in the nitty gritty details of async executions – which I like. However in my opinion, the book doesn’t stress enough the crucial importance of the async functionality enough. But after reading this chapter, you’ll definitely be able to understand and try it for yourself.

Chapter 12: Going Enterprise

Explanation of what the jbpm-enterprise jar offers. Some good practices are states here, like the EJB intermediate layer with ids (jBPM4, anyone?). Also remote client usage is covered, together with Timers and job (VERY good explanation btw).

As my conclusion already can be found in the beginning of this post, I’ll repeat here the one-sentence summary. If you are starting out with jBPM, there is no better book or guide to get you guys. Highly recommended!

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).

jBPM goes BPMN!

For those who follow the jBPM internal discussions a bit, the marriage of jBPM and BPMN will come as no surprise. Since this summer we’re coding away at a native BPMN2 implementation on top of our Process Virtual Machine (PVM), and you might have seen tweets or forum posts passing by where the term ‘BPMN’ pops up. However, the only proof were some classes in our SVN trunk …. until now!

In this post I’ll give you a sneak peek of our current BPMN2 execution effort which will be documented, QA’d and incorporated in the jBPM 4.3 release (scheduled January 1st). Many thanks go out to our community members Ronald Van Kuijk and Bernd Rücker, who have contributed a significant amount of  ideas and code (and in fact, still are contributing to the BPMN2 implementation now as we speak). This is open-source power at its fullest…

Happy times indeed!

What is BPMN2?

Basically, the Business Process Modeling Notation (BPMN) started out a pure graphical notation standard for business processes, maintained by the Object Management Group (OMG). Version 2.0, which currently is in beta, adds execution semantics to the specification and this is of course where it gets interesting for jBPM.

The primary benefit of BPMN2 is that it is a standard accepted by the IT industry, which means that process models become portable (graphical and execution-wise) across process engines such as jBPM. Since process executions are the raison-d-être of jBPM, it is only natural we are now investing in BPMN2. People who are familiar with JPDL (the current native language of jBPM) will have generally no difficulties in learning the BPMN2 language, as many constructs and concepts are shared. In fact, from a high-level point of view, BPMN2 and JPDL are in concept solving the same problem (which is a biiiiig difference with BPEL – but that’s a story I’ll let other tell).

Of course, this is just the nutshell explanation. You can find a lot more information in our wiki.

Enough talking … show me how it works!

The business process we’re going to implement looks as follows (click to enlarge – created using the wonderful editor from our friends at Signavio).

You might recognize this example, since we’ve also implemented it in JPDL as an example in our distribution.

The business process is simple: an employee can start a new process and make a request for a certain amount of vacation days. After the request task has been completed, the manager will find a verification task in its tasklist. The Manager can now decide to accept or reject this request. Depending on the outcome (that’s the little rhombus on the outgoing transitions, or better said ‘sequence flow’ as it is called in BPMN. It means that there is  a condition that must be true to follow it), a rejection message is send or the process ends.

As is the case with JPDL, BPMN2 uses an XML language to define the process definition. Our business process looks like this in BPMN2 XML:

<?xml version="1.0" encoding="UTF-8"?>
<definitions id="vacationRequest"
 xsi:schemaLocation=" BPMN20.xsd"

 <process id="vacationRequestProcess" name="BPMN2 Example process">

   <startEvent id="start" />

   <sequenceFlow id="flow1" name="fromStartToRequestVacation"
     sourceRef="start" targetRef="requestVacation" />

   <userTask id="requestVacation" name="Request Vacation"
     <potentialOwner resourceRef="user" />
     <rendering id="requestForm">

   <sequenceFlow id="flow2"
     name="fromRequestVacationToVerifyRequest" sourceRef="requestVacation"
     targetRef="verifyRequest" />

   <userTask id="verifyRequest" name="Verify Request"
     <potentialOwner resourceRef="manager" />
     <rendering id="verifyForm">

   <sequenceFlow id="flow3" name="fromVerifyRequestToEnd"
       sourceRef="verifyRequest" targetRef="theEnd">
     <conditionExpression xsi:type="tFormalExpression">
        ${verificationResult == 'OK'}

   <sequenceFlow id="flow4"
       name="fromVerifyRequestToSendRejectionMessage" sourceRef="verifyRequest"
     <conditionExpression xsi:type="tFormalExpression">
        ${verificationResult == 'Not OK'}

   <scriptTask id="sendRejectionMessage" name="Send rejection Message"
       <![CDATA[System.out.println("Vacation request refused!");]]>

   <sequenceFlow id="flow5"
     name="fromSendRejectionMessageToEnd" sourceRef="sendRejectionMessage"
     targetRef="theEnd" />

   <endEvent id="theEnd" name="End" />


Most of the constructs are straightforward, certainly if you’re coming from a JPDL background. Do note that the Resource construct isn’t correctly implemented (yet), but that should be solved for the 4.3 release. Also note that you already can add taskforms to your user tasks (see line 33-35 for example).

Also interesting to note is the way how the outcome of the user task is used is for guiding the flow through the process (line 41 and 49). We could have used an exclusive gateway to do the same (which is also already implemented), but we’re using formal expressions on the outgoing sequence flows coming from the user task, just to show you we can.

That’s cool … but I’m a Java developer!

Rest assured: everything that makes jBPM a blessing to use is here to stay. Tom has put a tremendous effort in the jBPM PVM and we now are reaping the fruits of his work. BPMN2 is implemented on top of the PVM, which means that many things come for free: database persistency, database transactions, the service and query API’s, etc. it all just works.

So, when we want to test a business process, we use the same Java approach which we always had with jBPM:

public class VacationProcessTest extends JbpmTestCase {

  protected void setUp() throws Exception {

    NewDeployment deployment = repositoryService.createDeployment();

    String deployId = deployment.deploy();


  public void testRequestRejected() {

    ProcessInstance pi = executionService.startProcessInstanceByKey("vacationRequest");

    // After process start, peter (employee)
    // should be a candidate for the task
    Task requestTasktask = taskService.createTaskQuery()

    // After this task is completed,
    // a manager (eg alex) is be able to see a 'verify' task
    TaskQuery verifyTaskQuery = taskService.createTaskQuery()

    Task verifyTask = verifyTaskQuery.uniqueResult();

    // When completing the verification task,
    // we also need to store the result of the decision
    // (will be done through the taskform normally)
    Map<String, Object> vars = new HashMap<String, Object>();
    vars.put("verificationResult", "not OK");
    taskService.completeTask(verifyTask.getId(), vars);

    // With a rejection, we should see
    // the 'sendRejectionMessage' task in the history log
    HistoryActivityInstance hai = historyService.createHistoryActivityInstanceQuery()



So what you’re seeing here is

  • Testing BPMN2 business processes in pure Java code that everybody understands
  • in a way which is exactly the same as for JPDL
  • and using the very same API which we are all familiar with
  • and using the very same database schema as before!

What’s there not to like? In my opinion, the argument of the same API is really really really powerful. The PVM is showing its power at its fullest! To configure your jBPM installation for BPMN2, you just have to add this line to your jbpm.cfg.xml file:

<import resource="jbpm.bpmn.cfg.xml" />

Conclusion: using BPMN2 processes in your application with jBPM is extremely easy. Everything you know about embedding and configuring jBPM is just as before … except that you’re now using a portable and standard process language.

What else?

A lot. Just check our wiki to see what’s planned for the 4.3 release. When talking in pure BPMN2 constructs, these are all planned for next month: Exclusive Gateway (XOR), Parallel gateway (AND), Service Task (Java based), Manual Task, Receive Task (Java only), Script Task, User Task, None start event, None end event, Terminate end event, Sequence Flow, Conditional Sequence flow, Formal expression, Interface (Java), Resource + ResourceParameter. More is possible, if we go to bed a bit later than usual 😉

To finish this sneak peek, here is a screencast of our jBPM console executing the BPMN2 example process which is described above. In this screencast, you’ll see Peter (the employee) requesting 5 days of vacation using our business process. After he finishes the request task, he logs out. Mike, a manager, now logs in and finds the vacation request in his task list. He rejects the request since there is too much work. Peter will now be notified with a rejection message (for this demo, just a printout to the console). The forms you see are using the same taskform mechanism which I described earlier.

The last part of the screencast shows that the reporting functionality, which was already available for JPDL, also works for the BPMN2 processes. Even better, since the PVM defines a shared database schema, reports can aggregate data based on JPDL and BPMN2 processes without any problem!

Until next post!


New feature in jBPM 4.2: Auto-upgrade your jBPM installation


With the 4.2 release coming close (somewhere beginning next week), I feel is time to write about one the new nice features of this particular release.

As a software engineer, I’m always eager to try out a new release when of one of the products/frameworks/… I use on a daily basis hits the shelves. I’ve also learned that I’m not alone on this matter and that it is a common thing among developers to have this burning itch to try out new stuff. But with every new release it’s also always keeping fingers crossed and hoping that everything stays working as it was without actually having the system blow up in your face.

With a new jBPM release, there are three ‘change-areas’ which could disrupt your current system:

* API changes. As I wrote a few months ago, starting from jBPM 4.0, there is a new API. Our policy is is to keep changes to the API (extremely) limited and deprecate any to-be-changed operations for two or three releases before actually replacing them completely. This means you have plenty of time do execute the change. So no blow-up on this front.

* JPDL schema changes. A New jBPM release often means additional features, which could lead to jPDL schema changes that make existing process definitions incompatible with the latest release. This issue has been addressed in the upcoming 4.2 release: old process definitions will remain backwards compatible with newer releases of the engine. Not a single change to your precious process definitions will be needed when upgrading your jBPM4 installation. So for example process definitions coded in 4.1 style will be deployable to a 4.7 engine. For more info, see the Jira issue. So again, no fear for blow-ups here.

* Database changes. Since jBPM uses a relational database as a persistence mechanism for processes, tasks, audit history, etc… new features in the engine can lead to changes in the database. We try to keep these changes as limited as possible, but sometimes they are simply needed to evolve. Of course, with every release we indicate which changes need to be done to the database, but if you skip a few releases before you upgrade this tends to become cumbersome.

It’s this last point which I want to demonstrate in this post. The 4.2 and every subsequent release have a new mechanism on board to determine the current version of the database schema and update it to the fresh release automatically.

Setting up the ‘old’ data

We’ll start by downloading and unzipping an older release of jBPM, jBPM4.1:

[jbarrez@jenova 4.2_upgrade]$ unzip

We’ll now create the jBPM schema using one of the install task shipped in the distribution. Since I’m using a MySQL database, I first need to update the jdbc properties that the install script will be using:

[jbarrez@jenova 4.2_upgrade]$ your-favourite-editor jbpm-4.1/install/jdbc/

and change it to my local database:

We can now create the schema in my local database (notice how we just need to add the ‘database‘ parameter, the script will then take the connection properties from the file we’ve just edited):

[jbarrez@jenova 4.2_upgrade]$ cd jbpm-4.1/install/
[jbarrez@jenova install]$ ant create.jbpm.schema -Ddatabase=mysql
Buildfile: build.xml
 [echo] database......... mysql
 [echo] tx............... standalone
 [echo] localhost
 [echo] current dir = /home/jbarrez/dev/blog/4.2_upgrade/jbpm-4.1

 [echo] creating jbpm schema in db jdbc:mysql://localhost:3306/jbpm

Executing resource: /home/jbarrez/dev/blog/4.2_upgrade/jbpm-4.1/install/src/db/jbpm.mysql.create.sql
79 of 79 SQL statements executed successfully
BUILD SUCCESSFUL Total time: 3 seconds

Which gives us a fresh jBPM 4.1 schema in our database:

We now use a basic ‘Hello World’ process definition:

<process name="helloWorld" xmlns="">
    <transition to="display hello world" />
  <custom name="display hello world" class="be.jorambarrez...DisplayHelloWorld">
    <transition to="theEnd" />
  <end name="theEnd" />

… to start a process instance through the jBPM API:

public static void main(String[] args) {

ProcessEngine processEngine = new Configuration().buildProcessEngine();
RepositoryService repoService = processEngine.getRepositoryService();
ExecutionService executionService = processEngine.getExecutionService();

NewDeployment deployment = repo.createDeployment()

The debug log shows us the actual execution trace, where our ‘Hello World’ message is displayed between the engine logs.

17:53:15,219 FIN | [ProcessDefinitionImpl] creating new execution for process 'helloWorld'
17:53:15,224 FIN | [DefaultIdGenerator] generated execution id helloWorld.1
17:53:15,229 FIN | [ExecuteActivity] executing activity(25788693)
17:53:15,229 FIN | [ExecuteActivity] executing activity(display hello world)

Hello World!

17:53:15,230 FIN | [ExecuteActivity] executing activity(theEnd)
17:53:15,230 FIN | [ExecutionImpl] execution[helloWorld.1] ends with state ended

Upgrading in one minute

Suppose now that we take this process to production. Life is happy and peace. But then comes a new jBPM release. The developer hands start to itch again … So we take the jBPM 4.2 distribution and unzip it:

[jbarrez@jenova 4.2_upgrade]$ unzip

And we change the dependencies of our little Hello World project, by either replacing the 4.1 jar with the 4.2 jar in the build path. Or if you are using Maven:



Of course, since we are adventurous developers, we don’t care about upgrading and just run our Hello World process with the new jBPM version. However, the new upgrade check will now kick in:

Exception in thread "main" org.jbpm.api.JbpmException: jBPM DB schema not in sync
 with library version: no JBPM4_PROPERTIES table.   Run the upgrade target
 first in the install tool.
 at org.jbpm.pvm.internal.cmd.CheckDbCmd.execute(
 at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(
 at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(
 at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(
 at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(
 at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(
 at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(
 at org.jbpm.pvm.internal.cfg.ProcessEngineImpl.checkDb(
 at org.jbpm.pvm.internal.cfg.ProcessEngineImpl.buildProcessEngine(
 at org.jbpm.api.Configuration.buildProcessEngine(
 at be.jorambarrez.jbpm4.upgrade.Main.main(

As you can see in the stacktrace, during the creating of the jBPM ProcessEngine a check on the database schema will take place (tech detail: it uses the JBPM4_PROPERTIES table and some other checks to do this). And since the exception is thrown during ProcessEngine creation, this also stops us from executing processes in a old schema – which is a good thing.

So we follow the instructions of the exception above and run the upgrade script. Don’t forget to change the database properties (as we did above).

[jbarrez@jenova install]$ ant upgrade.jbpm.schema -Ddatabase=mysql
Buildfile: build.xml
 [echo] database......... mysql
 [echo] tx............... standalone
 [echo] localhost

 [echo] upgrading jbpm schema...

 ... // *snip* Hibernate setup etc

 12:30:02,501 INF | [DbHelper] --- Executing DB Commands -------------------------
 12:30:02,501 INF | [DbHelper] create table JBPM4_PROPERTY (
 KEY_ varchar(255) not null,
 VERSION_ integer not null,
 VALUE_ varchar(255),
 primary key (KEY_)
 ) type=InnoDB
 12:30:02,544 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,544 INF | [DbHelper] alter table JBPM4_HIST_DETAIL drop index IDX_HDETAIL_HACTI
 12:30:02,564 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,564 INF | [DbHelper] alter table JBPM4_HIST_DETAIL drop index IDX_HDETAIL_HPROCI
 12:30:02,578 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,578 INF | [DbHelper] alter table JBPM4_HIST_DETAIL drop index IDX_HDETAIL_HVAR
 12:30:02,595 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,596 INF | [DbHelper] alter table JBPM4_HIST_DETAIL drop index IDX_HDETAIL_HTASK
 12:30:02,610 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,611 INF | [DbHelper] create index IDX_HSUPERT_SUB on JBPM4_HIST_TASK (SUPERTASK_)
 12:30:02,625 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,736 INF | [PropertyImpl] nextDbid is initialized to 4
 12:30:02,740 INF | [Upgrade] jBPM DB upgrade completed successfully. 
 12:30:02,740 INF | [SessionFactoryImpl] closing
 12:30:02,741 INF | [DriverManagerConnectionProvider] cleaning up connection pool: jdbc:mysql://localhost:3306/jbpm
BUILD SUCCESSFUL Total time: 4 seconds

The output of the script show us that some upgrades were done: a new table was created, some indexes were altered and some colum values were updated.

When we now retry running the Hello World process, everything works fine:

12:41:19,275 FIN | [DatabaseIdComposer] generated execution id helloWorld.10010
12:41:19,279 FIN | [ExecuteActivity] executing activity(28678425)
12:41:19,279 FIN | [ExecuteActivity] executing activity(display hello world)
12:41:19,280 FIN | [ExecuteActivity] executing activity(theEnd)
12:41:19,280 FIN | [ExecutionImpl] execution[helloWorld.10010] ends with state ended
Hello World!

And if you pay close attention to the logs, you’ll see that the schema check is OK now:

12:41:18,687 INF | [CheckDbCmd] jBPM version info: library[4.2], schema[4.2]

NOTE: if you got a grumpy DBA: the jBPM distro also ships with plain .sql files to use for upgrading the schema, which you can hand over to him/her.


And that’s it, folks. We’ve got API stability, backwards schema compatibility and as I just showed you, upgrading the database takes only a minute of your time… leaving more time for you to actually code business processes!


To finish the post, I just want to show you a screenshot from our Hudson continuous integration job. Since the upgrade feature is extremely important for us, we test it against all our supported databases and JDK versions. The test job that is executed is actually very close related to the explanation of the previous section. With every new release, this configuration matrix will continue to grow. Which means that in every future release are certain of backwards compatibility and upgradeability.

Happy jBPM coding!

Upgrading in one minute

jBPM4 real-life example: The Train Ticket Demo (part 5: BI and BAM)

Business processes are never finished

As a business changes or grows, business processes will need to incorporate these changes or they will become a drawback for the business. There are the natural changes that come as the business or the market change, but some changes are related to the actual feedback that is received from measuring metrics about the business process executions.

If you take a look at the BPM lifecycle, gathering this feedback means that the process executions must be monitored. Using the metrics gathered there, it will be possible to discover bottlenecks in the process (eg some task is taking long due to a human resource problem) and to act upon them. The next step will then be optimizing the business process, with the new knowledge as background. Now, the lifecyle is completed and we’re back to modeling the actual changes in the process in our BPMN Signavio editor. So, as a developer, it might be interesting investing in jBPM, since your work will never be done (this applies certainly for contractors ;-))

Traditionally, there are two concepts that are often used when one discusses ‘monitoring’ business processes. I’m talking here about Business Intelligence (BI) and Business Activity Monitoring (BAM). Typically, BI is used when the data that is used is historical (eg. monthly reports), whereas BAM is used when the data is real-time. Often, BAM is coupled with Complex Event Processing (CEP) to allow for automatic actions that are triggerd once a certain event or pattern is discovered. Yes, I know these are lot of fancy words, but they all come down to one thing: displaying data of business processes in some way or another.

In this article, I’ll demonstrate how BI and BAM can be done with jBPM. Today, I also have 2 screencast for you, so be sure to read the article to the end (which should be the case anyway 😉 )

Business intelligence with jBPM

I’ve already discussed this topic in a previous article, so I’ll be short here. Using the jBPM console, it is very easy to write your own BI reports and display it in the console. Since we are using the Eclipse BIRT engine, this means that the reports are also usable without the console or embedded within your own application. Take a look at the following screencast, where two things are shown:

  • The cellhone emulator (aka the jBPM-phone) is used to send text messages to the Ticket Handling Platform and the jBPM console is used to inspect the actual process instances.
  • The default BI report is rendered and displayed through the jBPM console.

Business activity monitoring with jBPM explained

For implementing BAM, we’ve used a setup as displayed in the following picture (click for bigger version):

Conceptually, the story goes as follows: inside the process, events (= pojos) are fired to a JSM queue. On this JMS queue, a message driven bean is parsing the events and handing them over to a CEP engine. In the demo, we are using the Esper engine, wrapped in an EJB3 such that the CEP handling scales with our existing architecture. Depending on the type of event, Esper will execute an action by invoking a so-called Subscriber. In our demo, this is mostly writing aggreagations to the database.

Note that this way of working is based upon the ideas from the book ‘Open Source SOA’, by Jeff Davis. Which also includes two big chapters about jBPM, by the way.

We’ll now look more closely into how this is actually done in Java code:

On certain activitites, we define an event listener. In the following example, we listen to the ‘end’ event of the ‘chargecustomer’ activity and send an event using the SendEventToQueue handler class. Also note that the event is send asynchronously, which means that the actual sending of the message is not done in the original thread. This way, the response towards the customer can be send more quickly.

<custom name="charge customer ...">
  <on event="end" continue="async">
      <field name="eventClass">
        <string value="org.jbpm.trainticketdemo.event.TicketSoldEvent"/>
      ... (more fields, see source for details)
  <transition to="end"/>

The TicketSoldEvent that is fired here, is just a regular pojo:

public class TicketSoldEvent implements Serializable {

  private String from;

  private String to;

  private Double amount;

  // getters and setters


These events are received by a message driven bean and handed over to the Esper runtime engine (see line 17):

@MessageDriven(activationConfig =
 @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
 @ActivationConfigProperty(propertyName="destination", propertyValue=JmsConstants.EVENT_QUEUE)
public class EventQueueProcessor implements MessageListener {

 // field declarations omitted

  public void onMessage(Message message) {

    try {
      if (message instanceof ObjectMessage) {

        ObjectMessage objMsg = (ObjectMessage) message;
        Object obj = objMsg.getObject();

    } catch (JMSException e) {

Without going into much details about Esper (read their excellent documentation if you are interested). We use Esper in the demo to cope with ‘pojo streams’. These pojo streams can be aggregated and queried upon using regular SQL, which I think is really cool:

EPStatement moneyTracking = admin.createEPL(
 "select count(*) as nrOfTickets, sum(amount) as total, " +
 "avg(amount) as average, stddev(amount) as stddev " +
 "from sec)");

 moneyTracking.setSubscriber(new MoneyTrackerSubscriber());

Note that we are selecting here the count, sum, average and standard deviation aggreagtion of the ticket sale data, based upon the TicketSoldEvent pojos that were received during the last 15 seconds. The results of that query are handed over to another pojo, the MoneyTrackerSubscriber, which will just store this results in the database for displaying them in the GUI.

Note that we are barely scratching the power of Esper here. It is for example also possible to join pojo streams, based on pojo field values. Take for example a look at the following snippet, where we join the TicketRequestReceived event with the QuoteSentEvent which have the same processInstance id, to calculate the time between receiving a cellphone text message and actually replying on it (which might be an SLA).

// SLA for the time between the ticket request receival and the quote sending
 EPStatement responseTimings = admin.createEPL(
 "select TicketRequestReceivedEvent.timestamp as ticketRcvTime, QuoteSentEvent.timestamp as quoteSentTime, " +
 "TicketRequestReceivedEvent.processInstanceId as processInstanceId " +
 "from hours) inner join hours) " +
 "on TicketRequestReceivedEvent.processInstanceId = QuoteSentEvent.processInstanceId");

But you can go much further with Esper. I particulary like the pattern detection mechanism for streams. I’ve used it in the past a lot, for example to build a fraud-detection system: when a certain pattern in the events is found (I believe it had to do with money that was first refused and than we checked on events that were related to the same customer trying to get smaller amount of money approved), an email would be send out to all the account managers involved. But such features are probably for a next iteration of the demo. By that time, we might be able to leverage the SAM solution which Heiko described in a blogpost.

Bam: The end result

The following screencast shows the end result of the explanation of the previous section. The data that is gathered by the subscribers of our events, are displayed using a Seam application, with Richfaces for the general GUI and Primefaces for the flash chart rendering. Using some ajax magic, the charts are rerendered in real-time.

The demo BAM application shows following information:

  • The average and standard deviation time between receiving the text messga eand sending a response (SLA)
  • The time it took the customer to respons with an ‘accept message’, shown as a pie chart with catagories (eg < 30 seconds)
  • The number of customers who had enough money on their balance vs those who didn’t
  • The total money earned (with average and stddev)  in the last 10 windows of 15 seconds

It is easy to see how the information from the BI reports and the BAM application can be used to enhance the business process. Eg when a lot of customers aren’t able to pay because they forgot to add money to their account, it could be wise to add a step to the process that ask ‘do you want to add more money?’, using the credit card registered with the customer. So, your imagination is the only limiting factor here 😉

Like before, the source code can be found in our svn repo:

jBPM4 real-life example: The Train Ticket Demo (part 4: the end application)

The path from a business process model towards an automated business process implementation is often a long one. After the initial process modeling in the Signavio editor, the initial development and prototyping, it is now time to start the actual development of our Train Ticket handling platform.

In reality, development will be mixed with additional discussions between IT and business, enhancements and changes in the BPMN process model and definitely some addtional prototyping will be needed. Here it may look like an easy transition between our prototype and our eventual and application, but do keep in mind that this phase is the one were most often future failures are born. It is of extreme importance to keep in mind that a business process is The Holiest of Holy of a given company. Therefore, business process implementations must be as close as possible to what the business expects, and this often takes time to synchronise all stakeholders involved.

In this article, I’ll present the implementation of the business process as described in the previous articles. The end result will be a high-performant, scalable (by means of clustering) train ticket handling platform, using standard Java EE components. This article will also show how easy it is to integrate jBPM with any given Java tech. As described in my previous article, let jBPM enrich your architecture!

Of course, as a open source project we have a reputation to keep up. All of what we discussed in the previous articles and this article is contained in the download at the bottom of this article. Many people have asked me for the executable demo and so here it finally is! Like I said before, don’t hesitate to show this demo to all the people you know!

Architecture Overview

The following picture shows a high-level overview of the architecture.

Most of it is probably clear by just looking at it, but I’ll summarize what’s going on here:

  • The entrypoint to the application is a regular HTTP servlet. SMS gateways communicate between telecom operators using plain HTTP messages, so the choice for this technology is obvious.
  • We have a cellphone emulator (swing rich client), aka the jBPM-Phone, at the left side. This cellphone runs on my local machine and it sends text messages to our Ticket Handling Platform using the same HTTP messages used by the SMS gateway. This way, we can test our logic, without actually paying for the text message transfer.
  • The Servlet parses the incoming text messages and offers this to the TicketService, depending on the type of the message (a message that starts a new process, or one that triggers the task in a waiting process instance). See line 9 and 16.
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
  if (isTicketRequestMessage(msgContent)) {

    TicketRequest ticketRequest = parse(msgContent, sendDate, senderNr);

    if (ticketRequest != null) {


    } else if (isTicketAcceptanceMessage(msgContent)) {

      String acceptanceId = parseTicketAcceptanceMessage(msgContent);
        if (acceptanceId != null) {

          ticketService.handleTicketAcceptance(acceptanceId, senderNr);

        } else {
          LOG.warn("SMS message content invalid. Throwing it away.");

  • The TicketService is a stateless EJB3 service. The incoming message will be used to start a new process instance of our well-known ticket handling process (see previous articles if you haven’t the slighest clue). This means that the TicketService will actually call one of the jBPM API services, nothing more. Note how easy we have integrated jBPM with the EJB3. No magic involved: this is plain Java code, people. See line 16, 27 and 34 in particular.
public class TicketServiceImpl implements TicketService {

  ... // field declarations

  public void handleTicketRequest(TicketRequest ticketRequest) {

    Map<String, Object> vars = new HashMap<String, Object>();

    vars.put(ProcessVariable.FROM, ticketRequest.getFrom());
    vars.put(ProcessVariable.TO, ticketRequest.getTo());
    vars.put(ProcessVariable.CELL_NR, ticketRequest.getCellPhoneNr());

    ProcessInstance processInstance = executionService.startProcessInstanceByKey(TICKET_PROCESS, vars);

    if (LOG.isInfoEnabled()) {"Ticket Process with process instance id " + processInstance.getId() + " started");

  public void handleTicketAcceptance(String acceptId, String cellPhoneNr) {

    // Look up the task through the jBPM API

    Task task = taskService.createTaskQuery()
             .processInstanceId("ticketProcess." + acceptId)

    if (task!= null) {


      if (LOG.isInfoEnabled()) {"Task " + task.getId() + " completed by " + cellPhoneNr);


There are two important notes here:

  • The TicketService is a regular service, nothing special there. Here I’ve chosen for an EJB3 approach, but you can well imagine this to be a Spring service, where the jBPM services are injected into the service. The important part here is that the ticketService is a plain service, just like any other (CRUD) service in the application. See my article on “where does jBPM fit into my architecture”.
  • I’m using standard JEE components (servlet and EJB3), in a complete stateless way. This means that this architecture can scale up linearly with any given load (eg with a simple load balancer). Also note that the use of jBPM does not imply any limitation on scaling this architecture. jBPM is designed from scratch with concurrent executions in mind, and synchronisation is actually done at the database level. Every API call is self-contained, on which node in the cluster it is executed.

Notice that there is an additional component on the picture: the user registration app. This is a simple Seam application, that just allows for users to register their cellphone and add money to their account. For the moment, adding money is just filling in the form, but I’m sure you can imagine this to be done by MasterCard, or any other payment method.

Use The Source, Luke

If you want to just download the demo, then just scroll down to the next section. If you want to check out the source however, then these instructions are for you.

Check out the source for the Rich client emulator from our public svn repo:

svn co jbpm-phone

Building the emulator is really easy, just do a standard maven build:

mvn clean install

The executable jar can be found in the target subfolder and is called jBPM-Phone-1.0.jar

Check out the source for the jbpm-on-rails platform from our svn repo:

svn co jbpm-on-rails

The project is structured as a Maven-multiple-module with the following modules:

  • domain: contains the simple domain model of the ticket handling application: a TicketRequest, a User and a Quote
  • jboss-integration: contains some classes that are used to integrate easily with the JBoss AS, like binding the ProcessEngine to JNDI.
  • process-logic: this module has the most interesting classes. Here you’ll find the custom activities, Decision handler, event listeners, etc.
  • ejb: EJB module which contains the TicketService implementation as described above. Also contains the QuoteService EJB3, which emulates the external service shown in the architectural overview.
  • war: contains the described servlet that handles incoming text messages from customers
  • ear: wraps the ejb jar and the war in an ear that is deployable on the JBoss AS.

Building the project is done by just doing a standard maven build

mvn clean install

The resulting ear can be found under /ear/target. This ear is tested on a JBoss AS 4.2.3. I’m using some JBoss-specific extensions, so don’t expect it to run on other containers.

Download the demo

The complete application: a JBoss server (4.2.3) with the user registration app and the ticket handling application, together with the Rich client emulator can be downloaded here (+- 237 MB).

Follow these steps:

  • (this is the most intensive step) Go to $UNZIPPED_FOLDER/jboss-4.2.3.GA/server/default/deploy open up the jbpmeditor.war file with any zip utility and open the web.xml file. Look for the fileSystemRootDirectory and change the value to an existing foler on your own hard disk. Currently, the value is set to /home/jbarrez/Desktop/signavio-repository. Take care that the web.xml file is actually rewritten in the zip file (not all tools can do this).
  • go to $UNZIPPED_FOLDER/jboss-4.2.3.GA/bin and start up the JBoss server (./ on linux)
  • go to $UNZIPPED_FOLDER/ and execute the jar: java -jar jBPM-Phone-1.0.jar
  • open your browser and go to http://localhost:8080/user_registration. You can log in with the emulator userid using 123456789/password and add some money to the emulator’s account.
  • Play around with the emulator. A ticket request is sent by typing ‘TICKET CITYA CITYB’.


You can see how all this looks in reality by viewing the following screencast. In the movie, you’ll see how to use the emulator (aka the jBPM-phone), how to add some money to the emulator’s balance and how the ticket handling server communicates nicely with the jBPM-phone. All of what you see in this movie, can be done by yourself by downloading the demo!


jBPM4 real-life example: The Train Ticket Demo (part 3: prototyping with the jBPM console)

Business processes are hard to get right from the first try. This is logical, since business processes are hard coded in the mind of the business people and pouring all this knowledge into a model is hard. So typically, it takes some iterations through the BPM lifecyle until a process model is derived that somewhat matches with what the business actually is doing.

So where are we now in the Train Ticket story? We’ve modeled our process and we added business-specific logic to the business process. We’re still in the development phase, according to the BPM lifecycle.  But in these days, nobody will ever rush into development straight away at this point. Agility is all the buzz nowadays, and there is no reason why it shouldn’t be.

In this article I’ll show how you can leverage the jBPM console to  build a prototype of the final application. Of course, the jBPM console can do  a whole lot more than prototyping (like basic process governance, reporting, etc), we’ll come back to these topics later. For this article, we’ll only highlight the prototyping capabilitites of the jBPM console.

Using the taskform functionality of the jBPM console, it is very easy to emulate user input and output without investing a lot of valuable development time. The use of these taskforms will allow you to show the interaction with the business process from the viewpoint of the end-user. It enables discussions between business and development, without actually building a complete application from scratch.

Agility in its purest form, who doesn’t love that?

Enriching the business process with taskforms

In a previous article, I already explained how to add a taskform to a business process. A task form is a HTML form which we can specify in the JPDL process definition, that captures the I/O towards and from the end-user. We’ll do the same here for the train ticket process, which is shown here again as reference:

There are 2 points of input/output in the process:

  • The process is started when a cellphone text message is arrived. This text message contains the start and destination train stations.
  • Once a price quote for the itinerary is calculated and the credit balance of the customer is verified, a text message is sent back with the price quote. An acceptance task is created for the customer. When the customer sends an acceptance message back, the process is continued by completing the task.

Whenever a process instance is started through the jBPM console, the ‘start’ activity is checked to have a start form. This form will be displayed before starting a process instance and the input variables of the form will be stored in the process instance so they can be used later on.

To attach a start form to a process definition, the start activity must be enhanced with a form attribute:

<start form="org/jbpm/trainticketdemo/trainticket_startform.ftl" g="11,105,48,48" name="start">
  <transition to="Calculate quote"/>

As shown in this snippet, the form is stored as a .ftl file somewhere in the project package tree. This file contains a basic HTML form and input text fields. Remember, the values of these input fields are later used as process variables.

    <form action="${form.action}" method="POST" enctype="multipart/form-data">
      <h3>Send SMS:</h3>
          <td><input type="text" name="from" /></td>
          <td><input type="text" name="to" /></td>
          <td>Source cellphone nr:</td>
          <td><input type="text" name="cellPhoneNr" value="" /></td>
      <input type="submit" name="Send"/>

Filling in this form will store the from, to and cellPhoneNr variable in the process instance as a process variable.

Adding a taskform to the ‘accept quote’ task is done in exactly the same way:

<task assignee="#{cellPhoneNr}" form="org/jbpm/trainticketdemo/accept_quote.ftl" ... 

In our final application, a text message will be sent to the customer before arriving in the acceptance task. In the jBPM console, we can emulate this behavior by using the taskform to display process information. Note the usage of expressions ${} to output process variables in the html taskform.

    <form action="${form.action}" method="POST" enctype="multipart/form-data">
      <h3>Accept Quote:</h3>
      <input type="submit" name="Accept"/>

Taskforms in action

That’s all there is to it. Just enrich your JPDL process definitions with some taskforms and deploy them to the jBPM database. Don’t forget to add them to the deployment next to the process definition xml by calling the deployment.addResourceFromClasspath(“org/jbpm/…”) operation.

The following screencast shows the end result of this iteration: a protoype of the application using the jBPM console and the taskform functionality.

What’s next?

In the next article, we’ll finally be able to build the real application.

Stay tuned!

(j)BPM: where does it fit architecturally?

How does jBPM fit into my architecture?

This question pops up regularly in my mailbox or on the jBPM user forum. Even when I was still a jBPM consultant, this question was the first line new customers asked me.

But there is no ‘all-in-one’ answer to this question. Like many answers in IT, the real answer is ‘it depends’. It depends on which frameworks you selected already. It depends on the expected load of the business processes. It depends on the existing systems which need to be accessed in the process. It depends if you want to centralize BPM knowledge in one application or not. And so on and so on …

jBPM is extremely flexible since our key feature is being embeddable in any Java technology out there. Pick your favorite framework, and I’m sure there is a way to fit in jBPM. But it’s the very same embeddability that often causes people architectural headaches. Mis- or underinformed people often want to take the easy path, and big BPM vendors know this.

A well-dressed sales guy will give a smooth presentation with colorful charts and he will promise you heaven and more. Of course, before acquiring the BPM system, you must first put (a lot of) cash on the table. That’s the way the world turns, right? And what are you getting: a big black-box server. You can send requests to it and it magically gives you the answer (hopefully it is the right one), hence the developer in the picture below that is painting on his screen. Paintings tend to look good from a distance, but you know that once you get close it tends to get blurry.

Big black-box servers don’t give you architectural headaches. No, on the contrary: they define how your architecture should look…

It could be me, but I like to keep things under control. I like to see what’s happening in my architecture, how it all fits together and which systems are communicating with each othe.. You know, that warm, fuzzy feeling you get once your own designed architecture keeps up with every load you throw at it. jBPM just gives you that openness en flexibility you need to build an architecture suited for your business, without having to suit your business to an architecture implied by a big black-box system.

Since jBPM is at its core just a simple Java library, there is no limitation on how you want to include it into your architecture. I’ll list a few of them here, but remember that jBPM will never be the limiting factor when designing your architecture. However, I do have my own ideas and experience. So, there is a definition I tend to use when people ask me about jBPM and architectures:

A business process *is* a part of the domain model, so ideally BPM should be non-intrusive and integratable with *every* architecture and technology. So let me reverse the question now: how does your domain model fit into your architecture?

Many people don’t see a business process as part of the domain model (remember my black-box story …), but it makes a lot of sense if you think about it. What is a domain model? Well, it is a representation of your business domain, of the raison d’être of your business of company. What is a business process? Well … it is a representation of how your business does something to create value. It is a representation of domain objects communication in some fixed way (a ‘flow’) to create some business-specific value.

So what does this mean in practice? It means that concepts like a Task (eg ‘send inquiry’), a Process Instance (a ticket sale) or an actor are at the same conceptual level as the domain model. Do note it doesn’t mean to scatter around your logic (like custom activitities, service invocations, etc.). Best practices in architecture design do still apply, and even more with jBPM (since they are applicable without restriction).

So by now I hope you can understand why we at jBPM don’t like the black-box-magical-server approach. A domain model is often scattered around many architectural layers or applications. Nobody asks questions when a domain object tends to be used accross different layers, and it is the same for the business process. If it makes sense in your architecture to not centralize a business process, then do it. It will make your architecture more understandable and easier.

Like I said, this means you can use jBPM in a lot of architectural styles:

  • In some designs, a BPM layer is placed either above a service layer – I like to call this a scenario layer
  • jBPM code is often wrapped the same way as a DAO (where I most of the times use the term PAO (Process Access Object). Services make calls to the PAO’s, just like they are accessing domain objects through the DAO’s. In a Spring environment, this is a true and tested approach.
  • Or you could build a big centralized server that does only BPM operations. This looks very much like the black-box servers I mentioned before. In some architectures this makes sense (eg tax processing split over several clusters), but you now don’t get a black-box server, but an open system that shows you all its internals. No magic involved. If you want to wrap it in WS-*, REST or whatever gets you going, fine. You don’t get that kind of choice with typical BPM products.

I’m sure that if you searched our user forum, you could triple this list in a few minutes.


This article is a bit of a side track in my current ‘jBPM4 real-life example: The Train Ticket Demo’ saga, but you’ll see that my ideas of this article are applied in the eventual Train Ticket Application (ie ‘jBPM on Rails’). Architecture designs tend to get a lot simpler if you look at BPM as part of the business domain. And jBPM just gives you that kind of control: flexibility and embeddability in any Java technlogy.

So, let BPM enrich your architecture, not cripple it.Use jBPM and free your architecture today!