Thursday, June 30, 2011

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.

There are some changes in the structure of the JBossTools project moving towards JBDS 5 release. From this point onwards they are looking to separate the SOA tooling and posted the following in their release blog which I am bookmarking for future reference as I use these tools extensively.

Where are my SOA Tools ?We are working on splitting out the SOA functionality (Teiid, Modeshape, Drools and jbpm) from the core distribution since the SOA tooling historically are not following the same release cycle of the core and thus at times it is beneficial that they can release their final version a bit delayed from the core. That means that for this milestone the main updatesite does not contain SOA tools but will for now be on a separate update site.

Sunday, June 19, 2011

IntroductionSince 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.

Friday, June 17, 2011

I know you can find all of these out there on the Internet, but I don't want to have to search for all of them again so my collection of power user tips are collected here. Note that these are not 'extensions' but just basic tooling or configuration adjustments that are pretty well hidden from you by default:

# I want to see the date on my desktop clock.
#
$ gsettings set org.gnome.shell.clock show-date true
# If you want to modify your menu and create launchers
# just install Alacare. For example, you can use this
# to create Power Off and Reboot buttons in your menu.
#
$ sudo yum install alacarte
# I want the right-hand top of app buttons back. Install
# the 'gnome-tweak-tool' and you'll find the app under
# 'Accessories > Tweak Advanced Settings.'
#
$ sudo yum install gnome-tweak-tool
# Click on Shell, then select "Arrangement of buttons on
# title bar" - All. Log out and on login your buttons are
# back.
#
# Use the gnome-tweak-tool to get your Desktop icons back.
# Click on 'File Manager' and turn on "have file manager
# handle the desktop". Now the usual icons are back, plus
# anything you want to add to Desktop.
#
# Alternative to the Power off button.
#
$ sudo yum install gnome-shell-extensions-alternative-status-menu
# An alternative window manager Avant. Once installed try
# opening a terminal and launch it: "avant-window-navigator"
# Get it into the start-up: Click on the avant-window-navigator
# icon and play with the many options. Down at the bottom,
# under General, there's "start Awn automatically". Reboot
# and test.
#
$ yum install avant-window-navigator awn-extras-applets
# Add theme functionality to your Gnome Shell.
#
$ sudo yum install gnome-shell-extensions-user-theme

Tuesday, June 14, 2011

Got the call at the last minute to help a colleague who went down sick by giving two sessions, one on jBPM5 and the other on JBoss tooling for SOA.

Below you will find my short impression of a few days there (I did not join most of the evening events due to having what turned out to be a sinus infection), I really enjoyed seeing lots of new faces and some old friends of mine from all our partners!

Wednesday, June 8, 2011

Today in Dublin I gave the session on Jboss SOA designing based on our products and tools which was to focus on bringing as much information over to the partner ecosystem (developers and architects mostly) as was possible in 40 minutes. I spent a large amount of time on the demoing our SOA-P ESB + service orchestration with jBPM, then demoed the BPEL tooling that is provided as a tech preview. Finally I showed off the latest jBPM5 released tooling that will be coming out real in Red Hat products. We ended up with around 30 people in the room.

Tuesday, June 7, 2011

Today in Dublin I gave the session on jBPM which was to focus on bringing as much information over to the partner ecosystem (developers and architects mostly) as was possible in 40 minutes. I had a real hard time brining the content down to allow time for demo, so choose not to demo in the session but to invite anyone interested to meet me afterwards. I was able to sneak a bit of the jBPM Migration story at the end of the session which raised some interest.

We ended up with around 40 people in the room, very interested and I ended up talking for an hour after the session with two different interested parties (questions and more). All in all a success I think.