Joe Developer

jBPM upgrade - 3.0 to 3.1 a BIG step

I recently upgrade an app that relies heavily on jBPM from 3.0 to 3.1, and it is a big step (3.1.2 specifically). I'm compiling a list of things I liked, things I didn't and things I learned.

Improvements in 3.1

1. TaskInstance is easier to extend in a cleaner fashion In 3.0 you could extend TaskInstance (something you almost have to do to support a number of use cases) via a config change in the jbpm.properties file. As far as we could tell though, the only way to finish the job was with a table-per-subclass mapping. In 3.1 TaskInstance is mapped with a discriminator column such that you can easily extend it with table per hierarchy without hacking the distributed mapping file.
2. Transparent persistence of "hibernatable" domain objects as process instance variables This is just plain nice, and keeps me from a)writing a bunch of coverters or b)using all sorts of work arounds. In a nutshell, if your class is persistable by hibernate AND your app and jBPM are sharing a hibernate configuration, you can save your domain objects as process variables transparently with no extra effort. This level of integration is very nice.
   There is a problem with it in the 3.1.2 release (I posted on this the other day), but Tom Baeyens says it is fixed in CVS so it will work as expected in the future without modification.
3. They refactored JbpmConfiguration and the whole configuration section The previous JbpmConfiguration class was a pain to work with... lots of static references to it, hard to plug into. The deprication of that class and the config system that replaced it is easier to use and plug into.
4. Cleaner integration with Spring and a single hibernate session factory via the latest SpringModules release (0.5) See the previous point. The 3.1 integration between Spring and jBPM is much easier to achieve. Made seamless with the use of the SpringModules project. There isn't much documentation on getting this done (I'm going to post an example with more info here in a bit), but it is possible to integrate the 2 and have a nice single TX manager and hibernate config that is all configured the way you're used to seeing it done. The down side is that you have to use callbacks with a template... long story short, I don't particularly care for that, but at least now there's a clean way to get the job done. Great work from the SpringModules gents.       
5. The consistent use of the jbpmContext object to get jBPM related tasks done In 3.1 you'll most frequently be using the jbpmContext to get the most common things done related to tasks, processes, process definitions, etc. It is still delegating to the other modules in the system, but having those delegations on a single class makes it easier for devs new to the product to get things done. You can still get at the modules (TaskMgt etc) to do more advanced work, but the convenience on jbpmContext is nice.
6. Automatically using the latest version of a subprocess rather than the version that was active at deployment time Finally. Another hack I can stop with... in 3.0 when your process instantiated a child process it was the version of the child process that was deployed when you deployed the parent. Read that again. This doesn't seem too bad, actually makes sense right? Doesn't make sense for one huge reason - it keeps large, long running processes from being flexible.
   I don't know about you, but I know a few business users that have told me that business processes change. Now for a variety of reasons you really need a process instance to execute based on the same process definition for the life of its execution. Trust them - this is the right thing. With that constraint though, you can have issues if your process is long on the calendar as changing a subprocess would have no effect on long running processes that called it. At that point it only served as a way to make a long process definition shorter. The new implementation supports the old way through the use of an added attribute when you call a subprocess, but by default (if I'm reading the docs right) will use the most recent version of the subprocess.
   This is a powerful feature. Given the constraint that you can't change the definition of a process for a particular instance, you can instead compose multiple processes into one larger one, buying yourself the flexibility to change a portion of the larger, long-running process by deploying a new portion of a sub process. Now you don't get any flexibility out of this if you don't design your process carefully, but with the capability at least supported you can truly have the flexibility required in business to with your solid workflow engine :) Thanks jBPM team.

Points of frustration

1. I didn't like the limitations of the old BeanShell scripts in decisions - the way the scripting context was initialized and run was a bit limiting and forced some work arounds I didn't like. Fortunately or unfortunately (depending on how many processed you had written), the decision condition style has changed.
   The new decision expression language is very much like jsf (to appease the Seam users that are using JPDL to define page flows). This is nice and clean but still limiting in power.
   By limiring I mean you really get one expression - in the old style and the new. Sure you can do a lot in one expression, but no complex scripting was supported. The transparent domain object access makes this less of a limiting factor overall, but there are times when I'd like to be able to execute just a wee bit more logic than a single expression gives me...
   There are answers to this for sure... The prettiest answer is to use Drools (now of JBoss)... Really though, I'd like to just be able to execute a little bit of code in a script (with a context I can control/manipulate prior to execution) rather than learn yet another framework. Drools is great, and is certainly the most robust answer, but seems like overkill when 3 statements and a return value would suffice in a lot of cases.  
2. The business calendar is STILL in a properties file. The business calendar and the supporting expressions based on timers are great, and overall it is a powerful feature in a workflow engine. If you're developing an app for in-house use you MAY be able to get away with the business calendar being defined in a properties file, but when you're designing an app to release, and run-time configurability is a must, having the business calendar in a properties file is rather limiting. I plan to hack this at some point to make it available in the DB as an option - it's the only way to go.
3. The actual XML that is the process definition still isn't stored in the DB that I've seen... One of the first things we did in our app was create a domain object with a big ole clob that would be used to store the process definitions. Now I'm all for pretty pictures in the GPD (and I'll get to that), but processes change - it would be nice to have them persisted by default rather than having to build that capability every time it's needed.
4. jbpmContext likes to commit transactions and close the hibernate session. Grrr. We had a bit of work to do to set up SpringModules to keep this from happening, as it wreaks havoc if you're using the OpenSessionInView pattern/Spring filter to manage sessions. (Yes, I know about the hibernate 3.1 getCurrentSession() technique. Not using it in this app.) I WANT the jbpm activities in the same session, with the same tx manager... It makes the most sense if you're going to embed jBPM, don't want to get involved with it's hibernate session etc, want simple process management or really just want an easy to configure state machine, but if you're doing a full integration it is a bit of a pain until you get things working.
   Once it's working though... works like a champ. Exactly like you'd want it to.
5. Swimlanes still only fire once per process instance. This is a big flexiblity loss as far as I'm concerned. I've submitted a Jira issue, and will have a patch available for this shortly. It seems that the preferred method is to use the identity module with some custom implementation and assignment expressions to get the job done.
   Custom swimlanes are much more flexible though, and allow a great deal of re-use if you code them carefully. We have only a handful of swimlane implementations that handle all of the use cases we're tackling right now, and I have only one more implementation to round out the set. If you haven't looked at creative uses for swimlanes, I urge you to. With non-singular execution they offer all the task assignment power you could want without the constraints of the identity module. The proposed swimlane extension gives lots of power when coupled with creative swimlane implementations.
6. The docs, and the javadoc, are a bit out of date and sparse. I can't complain too much though as the code itself is great documentation, is easy to follow, and generally tells me everything I want to know. They're kind enough to distribute a .classpath and .project file for us eclipse users, so integrating the source into an eclipse env for debugging is a 1 minute process.
   And before you say it - yes, I'm looking at adding to the docs where I can and giving back - its the least I can do I suppose for such a wonderful tool.
   For the dev new to jBPM though the lack of documentation and examples can be truly frustrating, particularly where the guide says "(document this)". Still better documented than most OSS projects though.
7. the GPD (Graphical Process Designer) is still a drag. Sorry guys. Quite frankly I don't use it, preferring like most devs I think to just write the xml... but it IS a great marketing tool. The PHBs of the world love a pretty picture...
   That said, it isn't really usable for anything serious if the intention is to generate all but the most linear, simple process definition. If you think you'll DL some WYSIWYG tool and be cranking out that complex process, you're sadly mistaken. Constructs that are a requirement in a moderately complex process aren't covered in the tool, and it is clunky and non-intuitive.
   I know, I know, its OSS - just fix it... If I relied on it for daily use I certainly would. Since I only use it to show the pretty picture of what I'm going to hand author anyway I'm not that concerned. I'm not bashing it - most workflow tools have some nice GUI so they (JBoss) sort of have to supply one - but at this point it's a checkbox to mark off on an RFP more than a fully functional tool.
   That said, it's a lot better now than it was, and kudos to the gents writing it, but there's clearly more effort being placed in the engine (which is a great decision IMHO).
   So use the tool to show a pretty picture for selling jBPM to your boss, but take the time to learn JPDL until the tool catches up.

Things I'm learning/looking at

There are a number of exciting new features in 3.1 and beyond that I'm looking forward to using... haven't used them yet, but I'll post when I do.

• Async nodes - we've no use case for them right now, but terribly useful when you look at web service orchestration without the annoyance that is BPEL.
• Drools integration - though I'm not all for having all the devs know it, it is a powerful integration that needs to be considered
• The whole messaging sub-system... looks neat and I'm going to play with it a bit in the near future.
• There appears to a whole form generating thing coming in 3.2. I'm interested to see how this plays out since we've already implemented this internally. Without care and attention it's probably going to be too constraining for the really hard stuff, but we'll see - I've been surprised before.
  however it shakes out, at least there will be more example code out there related to tieing a web UI to the core engine... we spent a fair bit of time figuring that out, and it's a REALLY common question on the forum - looking forward to it.

Random Thoughts

jBPM is still my favorite workflow engine, suited to a variety of tasks and solving a host of problems.
Though we're not using it for page flow (still a great thought), we're using it for all sorts of other things, and with a few extensions it is hands down the most powerful and flexible process tool I've used.

Hats off to the jBPM team for continuing to bring a great tool to the community.

If you're looking for a powerful, easy to use, extendable, and embeddable workflow engine you can't do much better than jBPM. And no, I don't work for them - just love the product after working with others in the field and spending the last 18 months with jBPM.

Posted at 01:00PM Sep 09, 2006 by saibrian in jBPM  |