Posts Tagged: jBPM4

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()
.processDefinitionId(“my_process_definition”)
.notSuspended()
.page(0, 50)
.list();

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()
.processInstanceId(piId)
.assignee(“Joram”)
.page(100, 120)
.orderDesc(TaskQuery.PROPERTY_DUEDATE)
.list();

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: http://parkingdemo.jorambarrez.be/

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.