Posted by: kukeltje | 3 July, 2009

jBPM 3 seam/jsf/richfaces based console

A few months ago, development on the new console for jBPM started.  Initially, it was the intention that this console could also serve as the next console for jBPM 3 with the jBPM 3.3 branche initially being the target. Not much later, it was decided to only develop this console for jBPM 4 and the jBPM 3.3 branch was discontinued and 3.2 was the main stable branche again.

Personally I thought it was a pity that jBPM 3.x did not get a new and shiny (web 2.0?, whatever that may be) console. Fortunately the new console is opensource and therefore I think that just ‘complaining’ is no valid reaction and that I could/should work a little sweat by doing it myself.

Well… no, I didn’t… mainly for one reason. Time… Since that is limited and the frameworks that I use in my day job, Seam, JSF/Facelets and Richfaces are not aligned with how the new console is being implemented (GWT, no seam), so I choose not to do. Until two weeks ago.

A customer told me they got some internal requests for a more advanced ui for an application. What they wanted was not something I did before, so I needed to experiment a little. My experiments turned out to be fruitful, so I decided to put some time in it and try to create a new console. Yes, besides the time I spend in the jBPM forum, on the tenniscourt, golfcourse, and on my Yamaha YZF600R, there is still some time left, being in between girlfriends helps)

Still, I choose not to do it in GWT, but neither did I try to use the existing console. Why a new console you might ask and not extend the one already there since it is JSF based? The main reason was that it is based on Gravel ( . Something that predates Seam and Richfaces/Ajax4JSF but in a way tries to accomplish the same. If you visit the project page and click some links, especially doc related links, you know why I did not want to put much effort in it. Not that it is badly designed or anything, I just don’t think it will stand the test of time. And besides, I did reuse some of the code behind the current console though, so not all was lost.

But before I’ll present you the first screencast of this jBPM 3.x console, let me summarize what it provides:

  • Many of the same things the current jBPM 3.x console (duh, you would say, but let me tell you that ‘porting’ his took just 3 days)
  • A look that is comparable with the jBPM 4 console
  • The ability to open multiple tabs (not browsertabs, but in the application) for almost anything, including the ability to work on multiple tasks at the same time
  • Context menu support for actions on almost anything
  • Doubleclick functionality to open items (e.g. tasks)
  • Based on JSF/Facelets/Richfaces/Seam
  • Advanced UI components from Richfaces, so no fully custom things anymore
  • Seam components for accessing tasklists, etc, comparable to the ones that by default in Seam, but more suitable for paging, filtering etc.

jBPM Console

(Thanks to Joram for putting this screencast on his site since wordpress does not allow embedding flash)

But before everybody starts cheering, let me also state what it is not:

  • It is not the official replacement of the jBPM 3 console. Not that I would mind if it became that, but since jBPM 3 is in ‘maintanance mode’ when 4 will officially be out, not much official effort will be put in jBPM 3.
  • It is not fully seam based in the way that it does not use the entitymanager (@JbpmContext is not used,
  • It is not a competitor for the jBPM 4 console, although it would be very simple to make it usable for 4.0
  • The source is not free/open yet mainly because I need a repository and for it and it needs some cleaning up since I focussed on functionality (stupid me ;-))


  1. Oh my god. You must be really bored in between girlfriends. Or that client paying a shit load of money. However, if you would have looked at the jbpm4 console, you would have realized that it simply requires an implementation of the integration layer to make it work on jbpm3. So, instead of ‘porting’ parts of the legacy console, you could have had he integration provided within 3 days. IMO, you suffer from the DIY syndrome.

    • Wow…. thanks for the compliments.

      As mentioned, the reason for doing this was given by a customer request for something that is almost not jBPM related. At least not directly. The tabs, context menu and extended datatable is what this customer wanted. And yes, that client paid fairly well for the basics (5 day of work), thank you. The remaining time for actually creating this console took 3 days of my personal time as mentioned. Time well invested since I learned some additional details which I can use for this customer AND for another personal project (more later)

      Besides this, I *have* looked at the jBPM4 console. I do like it functionality wise and architecturally there are also interesting (positive!) things. I agree that purely integrating jBPM3 in there would have been possible with not much effort I’ve seen and analysed that. Still it would have been time invested in something that *commercially* would have been more difficult for me to do something with. I do have to eat to you know, and cannot afford switching frameworks just because someone else choose to use GWT. I, myself, could never have created the tabbed functionality etc in GWT in the amount of time I had for this customer. And if this customer had not request this specific functionality I would not have started at all.

      Regarding the DIY syndrome, If I’d really suffered from it, I would have extended Gravel, created my own DI framework and maybe even a new persistency layer, but I did not. I reused a lot of existing frameworks and even (as also mentioned) code from the existing JSF based console.

      To give you a little more context, this ‘new’ console is part of a bigger project I’m working on that will in due time be open source. The ui for this project has been under development on and of for some time now, even before GWT was chosen to be the framework for the jBPM 4 console. I have already integrated XForms with this months ago. So forgive me investing time (and money) in things I already know, have, like and want to earn a living with.

  2. I like it! Any chance you will make it available soon? Maybe you can send it to me? 🙂

    • ‘soon’ is a relative thing. Compared to the end of the universe it will be soon. Compared to tomorrow, it might be several orders of magnitude later (one or two months). Sending the code as is, is not a good idea.It needs cleaning up etc.

  3. Excellent work! I would really like to try out your port to seam regardless of how messy your code is.

  4. Hi!

    I’m doing something simililar in my spare time and I wanted to ask you if I could take a sneak peak at your source code? I would be really grateful if you would consider sharing your work so far.

  5. looks great .Can you please share this code with me? If you can please send me in

  6. Thanks for all the requests. The code of this application can be split in two. The ‘advanced’ Richfaces usage of paging, tabs context menue etc with some seam (not as much as I want to, but that might change) and the jbpm part. The latter is not really rocket science, plain usage of the jbpm 3 ‘api(s)’ and one new annotation that wraps method calls in the (in)famous try-finally block so my (your) code is much cleaner 😉

    I’m currently in the process of splitting this up so I can write a nice blog about the first part. That blog will be rather lengthy and I might split it up in multiple posts. but before that, I’ll post the code (minus the jBPM stuff) somewhere on a share site. So please, a little more patience for the code, but if you guys/girls have any suggestions on the ui part, what you’d like to change, see added etc, don’t hesitate to discuss.

  7. Hi,

    you might want to have a look to seambpm on sourceforge ( We also needed a console for JBPM 3.3 compatible with seam.
    This console is more production admin oriented (find an instance by the value of a variable, signal simulteanously a list of instance, …)


    • I did a quick check and there is a lot of overlap, but also some differences.
      – I use the rich:mediaoutput for the image where you use a (seam) resource filter.
      – Paging etc is about the same, but you might run into the need for some custom comparators regarding the running/suspended/ended. I hate (well kind of) how that is in jBPM3. Would have been much easier if there was a convenience method on the suspendable nodes to get an an element back of e.g. an ennumeration.
      – You’ve focussed on I18N, I did not (yet), Fileupload (deploy process) I did not (yet), using s:decorate (was on my list as well)
      – I’ve worked on still being able to retrieve the forms from the database, using tabs (with conversations!!), context menu, rich datatable

      But for the rest, I see a lot of opportunities to combine work.

      Manaty… freelancers… cool… if you need a pair of additional hands 😉 I’m always interested in these kinds of projects. What about including XForms in it instead of JSF for the forms…. really cool

    • Oh and your JbpmConsoleService definitely looks interesting. That was one of the cleanups on my side that I have to do. Especially using the query api is interesting. Now I do think I’ll give it some more attention.

      Oh (2) and you reused the same interesting part of the current console like I did (the processimage overlay) 🙂

      I’m currently in the process of looking into preventing rerendering the content of all tabs when a new tab is added. Well maybe preventing rerendering is difficult, but using s:cache might be an option to at least prevent the all methods of previously rendered components go off again.

      I’m curious what your further intentions are, You might want to drop me a private email at ronald jbpm org (fill in the obvious blanks;-))

  8. Hi,

    Yes we look for new freelancers and you are very welcome.
    In fact Manaty is not one but several independant companies (france, morroco, china, lithuania) formed by J2EE freelancers, working mainly in telecom industry. The goal is to compete with large IT companies 🙂 so i’d be please to discuss with you if you are interested.

  9. I saw the snapshot and I have to admit I was instantly hooked. What desktop environment/theme are you using? Looks absolutely awesome 🙂

    Seriously tough, why not host this code under the jbpm3 codebase? While the 3.x series is in maintenance mode indeed, this could be incorporated alongside the aging jsf console as a “provided in the hope it will be useful” yet unsupported module, just like simulation. Unlike the gwt console it would be more of an incremental upgrade to existing jsf console apps and, as evidenced by the various replies to your post, still valuable to jbpm3 users.

    I cannot offer help with seam or jsf code as I have limited experience with web apps, but I can definitely assist with integrating with the overall maven build and adding an installer checkbox for it.

    What do you think?

  10. Hey Ronald.

    Wow, impressing!! Would be definitly cool to host is “as is” on jbpm 3.3.x since a lot of people ask for such kind of thing. Maybe that changes with jbpm 4 being out there, but do not yet now…

    In one word: Cool…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: