jBPM 5.0 released

The jBPM team is pleased to announce the release of jBPM5!

jBPM is a Business Process Management (BPM) system, allowing you to specify, execute and manage your business processes, for both developers and business users. The jBPM core is a solid, lightweight engine that can be embedded inside your application or deployed as a service.



The most important features of the jBPM 5.0 release are:

• a core engine supporting native execution of business processes following the latest BPMN 2.0 specification

• powerful Eclipse tooling for developers, allowing creation, advanced debugging and deployment of your processes

• a process repository (with web-based UI) for managing your process definitions

• web-based tooling for business users including web-based editing of your business processes, a process management console, human task lists, etc.

jBPM 5.0 is one of the most powerful engines out there (already supporting a large set of constructs as defined in the BPMN2 specification), not only does it allow dynamic adaptations and migration, but it also supports flexible and adaptive processes.

Last, but not least, jBPM5 is not an isolated process engine but it can also be used as one of the component inside a much larger solution. If your real-life business problem for example has to deal with flexibility, events or is data-driven, we allow powerful integration with business rules, event processing and other services in your environment. This allows you to select how to model (each part of) your business knowledge, effectively combining these different paradigms into one solution.

To get you started, are you looking for some screenshots or screencasts? Or want to start browsing the documentation? Or you really want the hands-on experience? Then try out the (full) installer and run the ant script to set up a demo environment, that will guide you through a few of the components using a simple example. The installation chapter in the documentation contains a few screencasts to help you out. After that, you can continue reading the documentation, play with the example by modifying it, or start your own project.

And here are the links:

• Download the artefacts
• Latest documentation
• jBPM homepage
  

Got any questions? Try

IRC: #jbpm at irc.codehaus.org
Email: jbpm-dev@lists.jboss.org
jBPM User Forum

Getting started with jBPM5

With the release of jBPM 5.0 around the corner, lots of people are very eager to start using it. And luckily for us, they are willing to share their experience, so that other might be able to benefit as well. So here are some blogs you might find interesting if you're getting started as well.

Vignesh has kindly created a "Getting started with jBPM 5" video. He's put it up on his blog here.

"I once wrote a blog on setting up jBPM 3 with jBoss ESB which proved useful to lot of folks. Now I am going to present a similar one for the all-new jBPM5. There is indeed a huge difference between the two and I must admit that the new product stack is looking very good, loaded with many must-have options any BPM product should ship with.
I will write about all the technical insights in a separate post. One good news you should know is that the installation has got a lot easier in this version. Let's just get started with jBPM 5, install it, and see it for ourselves."

The guys at Plugtree have also created a tutorial that helps you create a process that includes variables, constraints, etc.

"This posts aims to teach the basics of modelling your processes into JBPM5. You’ll learn how to use the builtin Eclipse editor to create simple processes, with branching, joining, external variables and code constraints."

Looking for even more? Here's a post that groups a number of posts, videos and tutorials about jBPM5.

Enjoy !

A process repository using Guvnor

One of the missing pieces in the jBPM 5.0 CR1 release was the inclusion of a process repository. Luckily, your waiting time is over!

A process repository is an important part of your BPM architecture if you start using more and more business processes in your applications and especially if you want to have the ability to dynamically update them. The process repository is the location where you store and manage your business processes. Because they are not deployed as part of your application, they have their own life cycle, meaning you can update your business processes dynamically, without having to change the application code.

Note that a process repository is a lot more than simply a database to store your process definitions. It almost acts as a combination of a source code management system, content management system, collaboration suite and development and testing environment. These are the kind of features you can expect from a process repository:

• Persistent storage of your processes so the latest version can always easily be accessed from anywhere, including versioning
• Build and deploy selected processes
  
• User-friendly (web-based) interface to manage, update and deploy your processes (targeted to business users, not just developers)
  
• Authentication / authorization to make sure only people that have the right role can see and/or edit your processes
• Categorization and searching
  
• Scenario testing to make sure you don't break anything when you change your process
  
• Collaboration and other social features like comments, notifications on change, etc.
  
• Synchronization with your development environment

Actually, it would be better to talk about a knowledge repository, as the repository will not only store your process definitions, but possibly also other related artefacts like task forms, your domain model, associated business rules, etc. Luckily, we don't have to reinvent the wheel for this, as the Guvnor project acts as a generic knowledge repository to store any type of artefacts and already supports most of these features.

The following screencast shows how you can upload your process definition to Guvnor, along with the process form (that is used when you try to start a new instance of that process to collect the necessary data), task forms (for the human tasks inside the process), and the process image (that can be annotated to show runtime progress). The jbpm-console is configured to get all this information from Guvnor whenever necessary and show them in the console.


If you use the latest snapshot version of the jbpm-installer, that should automatically download and install the latest snapshot of Guvnor as well. So simply deploy your assets (for example using the Guvnor Eclipse integration as shown in the screencast, also automatically installed) to Guvnor (taking some naming conventions into account, as explained below), build the package and start up the console.

The current integration with the jbpm-console uses the following naming conventions to find the artefacts it needs (though we hope to update this to something more flexible in the near future):

• All artefacts should be deployed to the "defaultPackage" on Guvnor (as that is where the jbpm-console will be looking)
• A process should define "defaultPackage" as the package name (otherwise you won't be able to build your package on Guvnor)
  
• Task forms that should be associated with a specific process definition should have the name "{processDefinitionId}.ftl"
• Task forms for a specific human task should have the name "{taskName}.ftl"
• The process diagram for a specific process should have the name "{processDefinitionId}-image.png"

If you follow these rules, your processes, forms and images should show up without any issues in the jbpm-console.

Migrating to jBPM5

With jBPM 5.0 almost out of the door, users are looking for ways to migrate their existing processes to jBPM5. To avoid any confusion about what is (and is not) planned, let's summarize what you can expect from us.


Migrating your process definitions

If you've been using jBPM in the past, you've probably been using the proprietary jPDL language to represent your processes. With the arrival of BPMN 2.0 however, there now is a new standard for representing business processes. jBPM5 supports native execution of BPMN2 processes. This means however that your existing jPDL processes need to be translated to BPMN2 before they can be executed on the jBPM5 engine.

Most of the old jBPM node types can be mapped directly to an equivalent in BPMN2. For some features (for example the java callbacks), we might require you to choose between a few possible transformation, or to fill in additional details. That's why we will be offering a tool for a one-shot semi-automatic transformation of jPDL processes to BPMN2.

The following screencast is a preview of what you can expect (in this case for a fully automatic transformation.) It shows how a simple jPDL process can be transformed into BPMN2 format, so that it can be executed on the jBPM5 engine.



Updating your integration code

You also need to update your integration code, i.e. how your application talks to the process engine. While the API to talk to the execution service itself hasn't changed significantly, e.g. startProcess(..) or signalEvent(..), how you set up your session and deploy processes has been generalized. As a result however, jBPM is no longer an isolated process engine but your processes can be combined with powerful business rules and complex event processing! We'll be documenting how you can migrate your existing integration code to the new API so you can start taking advantage of this.

At this point, we're not planning to support runtime data migration. If you're curently using jBPM3 in production, you shouldn't be afraid to keep using it, as it currently is supported by JBoss and will be for many years to come. You can start developing new processes on jBPM5, and migrate your existing processes whenever you're ready.

We have set up a migration project and Eric Schabell and Maurice de Chateau are already working hard to get the first transformations out there. You can find more information on their Wiki and Eric has also written a few blog entries about it. The migration project will initially focus on migration from jBPM3 to jBPM5. With a little community contribution however, it should also be possible to use the same approach to support jBPM4 to jBPM5 migration. So let us know if you want to help out! ;)