Joe Developer

jBPM/JPDL GUI - a middle of the road approach

I've been using jBPM for a while, and really like it as a BPM tool. I've actually found a few uses outside the original purpose, but that's another post.

Like most tools though, I'm forced to code in XML. I'm not saying I don't want to code in XML, but it can get a bit tedious. Mix that with the love that the analysts and process owners have for pictures, and you'll be wanting a GUI for jBPM.

There is a GUI for jBPM. I've played with it in various incarnations and releases for a while, but always found it lacking. I don't particularly want a flowchart of my process, rather I wanted a structure that showed the semantics of my process that did some other work for me.

With a large process to author and a deadline for completion approaching, I did what any joe developer would do - I wrote a tool that would allow me to author the process in a tool and then export the XML.

This is a small screenshot of the editor:



Why write a different tool? A couple of reasons.

• Dave Thomas says the issue with a GUI is WYSIAYG - What You See Is All You Get. If there is a feature in the system that you know how to use but the tool doesn't expose it, you can't use it unless...
• I needed a tool wouldn't lose data in my process definition - even if it didn't support editing it in the GUI, it should keep the XML that I started with.
• The last time I used the JPDL editor from JBoss, it was rather tied to their way of doing things. I'm not doing things that way, and a tool should be as unobtrusive as possible.
• I hadn't written a fat client in a while, and it looked like a fun problem :-)

So how did I fair with my deadline? I used 2/3 of the time writing the first incarnation of the tool. I used 1/6 of the time authoring the process - and still came in with time to spare. The tool has since saved a lot of time in authoring other processes, so a win overall as far as I'm concerned.

Is is a flow chart? No. can I use it to create one? Certainly. The tool doesn't hide the process language from the developer - and it shouldn't. The holy grail of management drawing pictures that turn into software is a myth, and I'm not aiming to chase it.

Posted at 07:38AM Jul 13, 2006 by saibrian in Tools and automation (Sloth)  |  Comments[1]