Introduction
In the previous article we discussed the migration strategy as a whole and zoomed in on an initial problem with an event in a start state. In this article we will continue onwards in our exploration of the various concepts that play a role in positioning your existing jBPM projects for migration to BPMN2.
 |
| Figure 1: two exit transitions. |
In this article we will take you through some of the issues we have encountered in real life jBPM3.2 processes. This will be focused on node implementations that are inventive to say the least, but do not map at all to a BPMN2 process definition.
Down and dirty
When given the freedom to be as creative as only a developer can be, we should not be surprised when a BPM implementation starts to make use of the available constructs that jBPM provides. When we examine the usage of a node, we see a construct such as in Figure 1 (
node2) which signifies a single process step. Here we would like to imagine there is a single unit of work being accomplished, like a call to a back-end system, a check of a process variable, etc.
 |
| Figure 2: add a decision. |
This is all possible within the confines of jBPM, but what we have often seen is the case of Figure 1 (
node) which has two exiting transitions. The problem is that the Java implementation handler for this
node has taken the liberty to make some decision based on facts present as to which transition will be taken upon exiting
node. It might take transition
yes or it might take transition
no, we can't determine which transition will be taken based on just the process definition.
 |
| Figure 3: BPMN2! |
When you run the jBPM Migration tool and feed it the process definition from Figure 1, it will not fail to transform this. How is that possible you ask? It was just stated that two exit transitions from the
node was not allowed by the BPMN2 specification? Well, we validate all incoming jPDL against the provided XSD and all out-going BPMN2 against the
FULL XSD of the BPMN2 specification. Funny enough, when you try to display this in your favorite BPMN2 editor, be that jBPM5 or Eclipse native editors, it will fail to display. This is because most of the editors around now are supporting a sub-class of executables from the BPMN2 specification and not the entire specification.
 |
| Figure 4: two incoming transitions |
Until these editors either tighten up their implementations or broaden horizons we will need to massage the processes we have created. As you can see in Figure 2, a little bit of analysis shows us that the
node needs to be expanded to include a
decision for determining if we go with transition
yes or transition
no.
The final step is what we get when we run this through the jBPM Migration tool and generate a valid BPMN2 process. This can be seen in Figure 3. The nodes have been converted into scriptTasks and the decision was converted into a gateway (diverging).
Incoming transitions
 |
| Figure 5: fixed two input transitions. |
Taking a look at the input side of our nodes, we can see that with a single incoming transition we have no problems with either validating, converting or displaying BPMN2. What would happen if we had a situation where there was a process defined such that
node2 has two incoming transitions? This is shown in Figure 4 and any attempts to convert will again be processed by the jBPM Migration tool without problems as it validates against the full BPMN2 specification.
It is not really a very well defined BPM process and we should clean this up so that there are three distinct paths. This is a good idea because you can then supply accurate management information on which path through the process was taken. Look at Figure 5, you will find there are now
end states for all three paths you take through the process. This allows us to report to our management how many
yes paths, how many
no paths and how many
maybe paths were taken through this process. The final full BPMN2 process after conversion by the jBPM Migration tool is shown in Figure 6.
 |
| Figure 6: final BPMN2 process. |
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 have covered start-state and nodes so far. We still have to look at end-states, states, transitions, decisions and much more.
