jBPM Migrations - hints and tips part 1

Introduction
Since we have started the jBPM Migration project I have been getting more and more inquiries as to how best prepare a jBPM3.2.x process for future migration to jBPM5. These questions have no easy answers, though I have tried to help you 'Get your BPM Ducks in a Row' at JUDCon last year in Berlin and again with more follow up at JUDCon in Boston.

With the last release of jBPM Migration Project (v0.8) we have reached a point of providing a fully runnable CLI Java jar component that eventually migrate your existing jBPM3 process definitions to jBPM5 in the BPMN2 format. This means it is now time to start thinking about what you can do to make the migration process as painless as possible.

In this first installment we will kickoff the discussion about migrations with a look at the process definition in jBPM3. We will discuss the background of jPDL and what this allows you to get away with in your process modeling. This article will conclude with a look at some issues you can encounter at the top level of your jBPM3 process definition.

jPDL gave us freedom
With jBPM3 you get a non-standard XML Java Process Definition Language (jPDL), which is not a bad thing as up to the acceptance of the BPMN2 standard everyone was left to sort out their design languages themselves. This jPDL is a simple and easily understood language that Java developers can very quickly understand and it comes with an XSD to allow for validation.

A down side to this jPDL is that you can do quite a bit of down and dirty work underneath the process definition layer (as I discussed previously, there are various layers in our jBPM projects) in your Java handler code. With the introduction of BPMN2 we now have a specification and standard that describes a more proper way of modeling and executing your BPM processes.

This new standard with it's requirements for modeling has shown us that when we as process developers are given the jPDL freedom to model as we see fit, we tend to come up with very innovative solutions to say the least! Trying to map these innovative solutions has shown that with a bit of thought and attention you can position you existing processes to easily migration to the future with BPMN2.

So let's get started with a look at the highest level of your process definitions. Here you should find something like listed here:

    < ## rest of the process definition. ## /> 
  

Up to now, I have been receiving process definitions from customers, partners and interested community members. I am amazed at the amount of process definitions that have either a missing xmlns attribute or it is not filled in with a version. As you can see above, to use our migration tooling we validate all incoming jPDL against its XSD. Make sure your process definition matches the toolings version!

If we take a look at how processes are started in jPDL, you might have decided it was a good idea to use the event element in a start-state like the following code shows:

   
    
      
        
      
 
      
    

    < ## rest of the process definition. ## />
  

Within BPMN2 it is not allowed to have an action take place in a start node. We are able to convert this by extending your process definition to include a Java Node (domain specific node extension to BPMN2) which we insert after the start-state. This allows us to execute the Java code you have in the MyHandler class before we move on to the firstNode. You can see the results in figure 1.

Figure 1: extra Java Node added.

This might not be an acceptable solution for your processes. In that case you will need to re-factor your process definitions to move the action to a separate node. This example clearly illustrates one of the many differences in how the jBPM3 modeling language allows you to accomplish an item of work in your process without clearly modeling it in your process definition. We will show more examples as we proceed through this series of articles.

This concludes our initial introduction to jBPM Migrations where we provided you with some hints and tips to help you start preparing your processes for migration to BPMN2 and jBPM5.

What's next?
Stay tuned for more, we plan to supply a series of articles that zoom into specific elements that you will find problematic in a process. We will look at start-states, end-states, nodes, states, transitions, decisions and much more.