jBPM Developer Guide review - chapters 1 to 6 (part II of III)

Click on book to buy!

Back to jBPM Developer Guide review part I

This book makes the promise with the title that it will be giving us developers an in depth look at jBPM. This is the measure I am using when reviewing each chapter, asking myself if it fills a need I have as a developer. This is not a beginners book is the impression I had when looking at the cover. Also of note, this is not a cheap book, running over 48 Euro + shipping costs, so I would expect value for that kind of money.

I will jump right into the review, providing my impressions of each of the first six chapters:

Chapter 1
This is an introduction chapter that tosses out lots of technological terms for the new jBPM developer.

This chapter you can skip.

Chapter 2
This chapter attempts to take you through some basic BPM functionality for implementing a process engine (just a very basic one). It is kind of fun to see happen, but not needed for jBPM usage.

This is also a chapter you can skip without missing anything important for your jBPM development experience.

Chapter 3
This chapter is going to get into the nitty gritty with a jBPM deep dive. This is the feeling I am getting. A small comment, the jBPM background/history is a bit on the thin side and not founded in facts. Also first we are forced to take a walk through the jboss.org community stack, nothing to do with jBPM yet.

On page 75, the real business starts, we dive into jBPM and build it via Maven and SVN. I really like this, as most books on community projects fail to give even a simple Maven explanation. You will have no excuses to not have a running jBPM check out from the community projects repository after this chapter. We are off and running!

From page 75 onwards, this is a must read chapter.

Chapter 4
In depth dive into jPDL, nothing but good things to say about this.

A must read chapter.

Chapter 5
A real example project is setup, starting from the business side which is nice for the beginners but a bit of a waste for the developers. We never are involved with this part of the project and have to make do with the results.

The only let down on this chapter is the finishing section, which requires you to download the provided projects code to see how you can create an initial unit test to march through the process as designed in this chapter. This is such a fundamental step in every project you will do in jBPM that I am a bit disappointed that the author did not walk us through the code snippets in the chapter itself.

This is a must read chapter.

Chapter 6
Persistence and all things devoted to how jBPM uses this and how you set it up. Very good detail and clarity.

A must read chapter.

I will post a final part soon with chapters 7 - 12 and my final conclusions. I also want to keep a running list of questions and impressions that arise during my reading/reviewing. I will list older items in italics, new items in normal text and remove items as they are resolved.

Impressions and questions:

• no resources or references section in the book
• lots of Wikipedia references in-line, never a good thing to use as a primary reference
• in handling of a Nodes and Transitions I am wondering if dynamic transitions will be handled?
• are there any best practices to be given when implementing jBPM projects?
  
• I don't understand why all these technologies have been used in a jBPM Developer Guide (Drools, ESB, Maven, MySQL, Eclipse and SVN)
• the author gives us "homework" in the first three chapters, but then it just stops until the ninth chapter, rather a shame
  
• miss exception handling as an advanced feature?

Stay tuned for the final part III of this review series, coming soon!

Onwards to jBPM Developer Guide review part III

jBPM Developer Guide review - introduction (part I of III)

Click on book to buy!

The book arrived and I will be starting my review. I plan to split the review into three parts to cover this introduction, the first six chapters and finishing up with the last six chapters.

The jBPM Developer Guide is a PACKT publishing offering, which is publishing books on technical subjects for sme time now. They offer good quality books, with nice artwork and feel to them. This one is 350 pages and feels like you should be able to carry it with you as a reference guide to jBPM. PACKT is based in Birmingham, UK but the Credits page lists a team that contains the author (South American), a proof reader, two reviewers (South American) and a list of editors (India mostly).

After reading the Preface I was wondering what these people all did, for they surely can not be proud of the English used. Please don't get me wrong, it is English that is correct, but it is definitely English from a non-native speaker. This is a shame as it degrades the reading experience and is sometimes even down right annoying. I would expect proof readers, reviewers and editing teams to take more care with the final results.

That being said, the contents looks promising with chapters covering:

• soft introduction to BPM
• some graph programming and a first process
• setup of the development enviornment (jBPM, JBoss Drools, JBoss ESB, Maven, MySQL, Eclipse and SVN)
• jPDL
• implementing an example process
• persistence in jBPM
• Human Tasks with an example
• process variables
• looking closer into some advanced features

My initial impressions and questions are:

• I don't understand why all these technologies have been used in a jBPM Developer Guide (Drools, ESB, Maven, MySQL, Eclipse and SVN)
• the author gives us "homework" in the first three chapters, but then it just stops until the ninth chapter, rather a shame
  
• miss exception handling as an advanced feature?
• not sure the author has experienced "life in the trenches" with jBPM?
• why is the focus only on jBPM 3.x and nothing is said about jBPM 4.x, the only actively developed version of jBPM at the time of this books writing?
  

Well, it is always good to review something with some initial questions, so stay tuned as I explore the book further in the coming weeks.

Onwards to jBPM Developer Guide review part II
Onwards to jBPM Developer Guide review part III

2009 in review

It is that time of year, when Christmas has passed (did you get the things you wished for?) and the New Year is upon us. A time for reflection and appreciating the things we have achieved.

As I look back I tried to come up with a picture to put in this post that would reflect the leading theme in my year. It should come as no surprise, if you have been following my blog at all, that JBoss jBPM logo is the image that has guided my year!

I started 2009 still working at the SNS Bank, leading and implementing jBPM projects to put financial products on-line for her customers. I published many of these experiences and tried to lift the lid as much as one can from inside of a financial institution, even managing to post some code to this blog. Here is a bit of a review:

• work on a state-proxy completed, a par repository, a custom jBPM exception framework and JBoss serialization
• published several articles on Computable.nl: Out of work IT'ers, Open Source cost money, Dare to save with SmartIT, Companies have Open Source in their own hands and IBM integration of SUN
  
• previewed some of the jBPM 4.x releases: 4.0 beta 1, 4.0 beta 2 and 4.1 
  
• have been asked to review the newly released jBPM Developer Guide 
• published in 2009 BPM & Workflow Handbook and received a Silver award for BPM excellence 
  
• attended conferences: JFall, Open Source Conference Amsterdam, Devoxx, Soa Symposium, CAiSE/PRET, Dutch JBoss Event, jBPM Community Day and attempted (who was I kidding?) to speak at Java One
• taught two courses in Rome: BRMS and jBPM 
• attended a JBoss BRMS workshop in Atlanta, GA

All of this got the attention of Red Hat and I decided to join the team in May as a JBoss Solution Architect Benelux. It has been amazing to work inside the JBoss house, seeing the latest and greatest software rolling off the development blocks.

I was able to make some rather small contributions to some open source projects, with some translations for meebo.com, a small fix in jBPM 4.2 (can you find it?) which made the jBPM 4.3 release just before the end of 2009 and another patch is still waiting for evaluation in the jBPM 4.4 release.

On the cycling front, I picked up a new road bike, at the end of the year a winter mountain bike and made some great rides this year in several countries:

• new bike
• Veluwe ride
• Limburg rides; climbing and in the hills
  
• Uden ride
• Oude Holleweg and Van Randwijckweg in Beek
• Belgium Ardennes
  

 The only sad item I have to mention was the trading in of my beloved 1987 Austin Mini, the end of an era for me with regards to Mini's.

Being healthy and happy, I wish you and yours all the best in 2010!

jBPM 4.3 released

The latest release posted on sourceforge includes my patch for a very small fix (but it is my first in the jBPM project!) listed here as shown in the release notes readme.html file included in the download:

Patch

• [JBPM-2520] - The install build.xml is not reporting the new Signavio installtion target (patch attached)

 A nice way to end 2009! ;-)

Book review: jBPM Developer Guide

I have been approached about doing a review of this book, which will be appearing soon. As soon as I receive an e-copy or preview copy in the mail I will be posting my impressions in detail.

The book is available here from PACKT publishing.

JBoss Enterprise Application Platform (EAP) deployment plans

To be honest with you, I have never heard of deployment plans before. I was aware of deployment descriptors, but not deployment plans.

A bit of searching turned up this bit of information:

Every J2EE application module must include an XML based deployment descriptor that provide configuration information for the asset as well as defining relationships to other components.

There are two types of deployments descriptors:

• vendor neutral deployment descriptors (a.k.a deployment descriptors)
• vendor specific deployment descriptor (a.k.a deployment plans)

Deployment descriptors are necessary but are not always sufficient to deploy an asset on your server. Deployment plans provides additional information to map declared resources names, ejb names, security roles, JMS roles (if any) to actual resources in the server. The deployment plans also contain specific server settings and configurations.

So we are looking at a vendor specific deployment descriptor file for the various application modules use. Now I was curious to those for JBoss, so dug around a bit and have come up with this overview.

Vendor neutral:
J2EE module file type Standard deployment descriptors
-------------------------------------------------------------------------------
Enterprise Application Archive (EAR) META-INF/application.xml
Web Application Archive (WAR) WEB-INF/web.xml
Jar containing Enterprise Java Beans (JAR) META-INF/ejb-jar.xml
J2EE Connector Resources Adapter Archive (RAR) META-INF/ra.xml
Enterprise Application Client Archive (JAR) META-INF/application-client.xml

JBoss specific (EAP):
J2EE module file type JBoss deployment plan
-------------------------------------------------------------------------------
Enterprise Application Archive (EAR) jboss-app.xml
Web Application Archive (WAR) jboss-web.xml
Jar containing Enterprise Java Beans (JAR) jboss.xml
J2EE Connector Resources Adapater Archive (RAR) ---
Enterprise Application Client Archive (JAR) jboss-client.xml

There you go, happy deployment planning!

A custom jBPM exception framework for jBPM 3.x

I have spent some time over the last few months (slowly, only one day a week) working on a jBPM exception handling framework. I wanted to present the use case and leave the exact details over to you as an exercise in Java coding.

The idea is that jBPM (here using 3.x supported versions from the Red Hat JBoss Customer Support Portal (CSP) provides the standard jBPM exception and that I want to also have the choice to apply a dynamically generated transition from the point of an exception that takes me to a custom exception flow. This custom exception flow is nothing more than a single decision that, based on the type of exception I have passed, will choose a path to one of the following:

• task node (human task to evaluate the exception)
• state node (retry using a timer to wait a bit before trying again)
• any eventual node desired to process the exception

There are some fairly obvious benefits:

• no longer just one handling for all your jBPM process exceptions
• very extensible, just add new nodes into the exception handling process flow to provide new functionality
• placing exception handling into an apart flow means you can deploy this once and use it with all of your deployed processes
• provides for decisions, states and node exception handling. Transitions should not be doing anything exciting within my processes, if yours needs to you can extend this concept to these too.
  

The process flow diagram provided in this post shows the simple testing framework I used to enable this. All code snippets shown are simplified for this post. There is a global attribute that is checked for using our custom exception framework called 'useCustomExceptions'.

Decisions

For a decision node we need to implement the DecisionHandler from jBPM, so I do that in an AbstractDecisionHanlder that implements the decide() method and puts in an extra handleException() method as follows:

public String decide(ExecutionContext ctx) throws Exception {

  try {
         // pick transition from the decision handler.
         transitionName = chooseTransition(ctx); 
         getLogger().debug("Choosing transition " + transitionName);
  } catch (Exception ex) {
         if (useCustomExceptions) {
             getLogger().error("Handler threw exception.", ex);
             ctx.getNode().raiseException(ex, ctx);
         } else {
             getLogger().error("Handler threw exception.", ex);
             ctx.setException(ex);
             // use custom method to create dynamic transition.
             dynamicTransition = handleException(ctx);
         }
  }

  return transitionName;
}


// This method is provided in comment steps only, the rest
// is an exercise for you (I can not publish this code).
private String handleException(ExecutionContext ctx) {

  // Save the current node in the context to make a retry possible.
                
  // Make sure the transition to the Exception handling Node can be made.
                
  // Using handling node name for the transition name.
                
  return name_of_transition_leading_to_exception_handling;
}

Node

For a node we need to implement the ActionHandler from jBPM, so I do that in an AbstractActionHanlder that implements the execute() method. Furthermore I need to come up with a solution for the following issue that is unique to the jBPM 3.x node. When you enter a node, you have an on-node-enter event and when finished it will trigger the on-node-leave event which takes the transition that is assigned during the event on-node-enter event. This means using the Node.leave(some-transition) method will not work.

I got the reaction when I used this Node.leave(take-dynamic-transition-to-exception-handling) it worked fine until it entered the human-task wait state. At this point the originating node then continued onwards, taking the default transition (that was in the TransitionsList for the node) and merrily finishing the process flow. Even stranger, this was done on the same process id that was also assigned to some human task!

My solution is to provide a mechanism to do the following:

• create the dynamic transition to custom exception handling for the node
• add the dynamic transition to the TransistionsList for this node
• put a copy of the TransistionList (without the new dynamic transition) into the jBPM Context
• remove all transition entries from the TransistionsList except for the new dynamic one
• use Node.leave() to follow the new dynamic transition
• deal with exception handling
• upon returning to the node after exception handling, pick up the transitions from the jBPM Context
• fill the TransitionsList with those found in the jBPM Context
• use Node.leave() to use the default
  

Some code to give you an idea with migrateTransitionsInNodeToContext which shows the transitions being migrated into the jBPM Context. I have left out the recovery of the transitions from the context, as it is trivial to reverse the process. To give you a bit of a hint, when you are in the exception handling process and decide it is time to go back to your originating node, you create a dynamic transition and fill the originating nodes TransitionsList from the jBPM Context. 

Here are some code snippets:

public final void execute(ExecutionContext ctx) throws Exception {

  try {
        if (ctx.getNode() instanceof State) {
           // process a state.
        } else {
   
           try {
  
              // do something in node.
           } catch (Exception ex) {
    
              if (useCustomExceptions) {
                   getLogger().error("Handler threw exception.", ex);
                   ctx.getNode().raiseException(ex, ctx);
              } else {
                   getLogger().error("Handler threw exception.", ex);
                   transitionName = handleException(ctx);

                   migrateTransitionsInNodeToContext(ctx);

                   // Move the process along.
                   if (!StringUtils.isBlank(transitionName) &&
ctx.getNode().hasLeavingTransition(transitionName)) {
                      ctx.getNode().leave(ctx, transitionName);
                   } else {
                       // Use the default transition.
                       ctx.getNode().leave(ctx);
                   }
              }
           }
        }
  } catch (Exception ex) {
      // do something
  }
}

/**
 * Use given context to migrate all transitions in the nodes list that
 * do not match the dynamic transition created for an exception.
 */
private void migrateTransitionsInNodeToContext(ExecutionContext ctx) {
  List existingTransitionsList = ctx.getNode().getLeavingTransitionsList();
  List removedExceptionTransitionList = new ArrayList();

  int i = 0;
  for (Transition transition : existingTransitionsList) {
    i++;
    if (transition.equals(transitionName)) {
      getLogger().debug("List item #" + i 
          + " is our dynamic tranition: " 
          + transition.toString());
    } else {
       getLogger().debug("List item #" + i + " tranition: " 
               + transition.toString() + ", migrating to context.");
       removedExceptionTransitionList.add(transition);
       getLogger().debug("List item #" + i + " tranition: " 
           + transition.toString() + ", removing from node transition list.");
       ctx.getNode().removeLeavingTransition(transition);
    }
  }

  if (!existingTransitionsList.isEmpty()) {
      // place existing transitions into context variable.
      String ctxStoredTranstionsName = 
           ctx.getNode().getName() + "_stored_transitions_list";
      ctx.setVariable(ctxStoredTranstionsName, removedExceptionTransitionList);
  }
}

State

For a state we work analogue to the decision node but within the extended abstract class that implements the jBPM ActionHandler. This is left as an exercise to the reader.

2009 Silver winner for Europe - Financial Crisis Front Lines: SNS Bank

I posted earlier that my chapter was nominated for the Global Awards for Excellence in BPM & Workflow. I received notificaiton as follows:

2009 Silver for Europe— Global Awards for Excellence in BPM & Workflow

This is to congratulate you on the judges voting for SNS Bank IT as the Silver winner for Europe. This is a significant achievement in the face of heavy competition. The Winners and Finalists of this year's awards will be published in the BPM Excellence in Practice 2010. The Excellence in Practice annual book series profiles the winning case studies each year of the new winners of the BPM and Workflow Awards with the emphasis this year on Impact, Innovation and Implementation in BPM Excellence in Practice 2010. The Digital Edition has just been released.

The award was announce live online via a web conference and an engraved trophy will be delivered to the SNS Bank. My thanks to all who made this work possible.