jBPM in JBossESB

[estebanschifman]

There are plenty of ways to combine jBPM and JbossESB capabilities. A few have been explored, and a preliminary version some classes has been added to the trunk in order to facilitate interoperation between both products. Unit tests and a quickstart to show a two way end to end simple interaction are under construction and will soon be commited as well.

AbstractCommandVehicle: yet another 'standard' way of packaging a command, it's arguments and return values. It has a toCommandMessage() method that renders an ESB Message containing the command information, paired with a constructor that takes a Message. It could also used without packaging/extracting it from an esb message, just with setters and getters.

JbpmCommandVehicle: specializes it for interaction with Jbpm. It is intended to work in conjunction with the JbpmCommandInterpreter class, that can be used as an action in the ESB. A few jBPM commands have been implemented, and we would hope more will be included as the community feeds ideas to complete what is now a very small subset of
all possible interactions with jBPM.

If we do things properly it should be possible to standardize on this format for all interactions originated in ESB aware classes and jBPM, including responses to these requests. I am a beginner with only superficial knowledge of the jBPM internals and intricacies, consequently it is very important that contributors with deeper jBPM exposure provide their feedback to point out mistakes, suggest better ways of tackling this matter, and contribute some code . We will appreciate ideas on some base (may be abstract) classes that implement org.jbpm.graph.def.ActionHandler, and that can make it easier to interact with the ESB from the jBPM world.

[rex.sheridan]

Upon initial investigation I found a possible issue in JbpmCommandInterpreter. I found the following line used in most of the methods:

_jbpmCtx.getSession().beginTransaction();

I am not sure this code is necessary because getSession automatically begins a new transaction for you.

[marklittle]

Sounds like great progress Esteban.

[kukeltje]

I'll do a source checkout of the esb code tonight and have quick look. Currently a german company is contributing a lot of additional commands and a swing (swt?) based app to access the core. So stay tuned for lots of new things in this field.

[marklittle]

Thanks Ronald. If you want to become a JBossESB contributor, send me an email.

[rex.sheridan]

One idea that could be helpful for the jBPM user is to insert the ESB message (or just the body of the message) into the ContextInstance. That way the workflow could have easy access to the data.

[kukeltje]

Contributor... hmmmmm I have still some things on my list for jBPM and Seam... and... don't know how it is in other parts of the world, but a day currently has just 24 hours ;-)

Let me just have a look at things first... :-)

[marklittle]

You don't have to commit to a lot of time or effort. Small help still means you're a contributor.

[burrsutter]

"rex.sheridan" wrote:
One idea that could be helpful for the jBPM user is to insert the ESB message (or just the body of the message) into the ContextInstance. That way the workflow could have easy access to the data.

I think this is a very good point. The quickstart/examples should at least illustrate how an ESB message can be broken down into context instance variables so they are available to the EL in jBPM (decision nodes, task assignments, etc.) By default we can push the whole message in as a single instance variable for "free" meaning no work on by the user (you the ESB programmer).

The Message could be pushed through a transformation action and returned as POJOs (see the transform_XML2POJO) and you can then use a custom action to load those POJOs into instance variables for jBPM.

We also need a known message header property to store the token id for correlation purposes.

Thanks Rex!

[estebanschifman]

In order to do that, it would be real easy to add an Operation to the esb.util.jbpm.CommandVehicle class (plus the code to handle it in the listeners.actions.jbpm.CommandInterpreter), that will return the full JbpmContext in the user object (setUserObject(XXX) method).
Nevertheless, there is already an operation there that will return a list of variables (or all variables if no list of names is specified) either from the contextInstance, or from the Token.
Please see how listeners.actions.CommandInterpreter handles the getProcessInstanceVariables and getTokenVariables operations.
If we use these, would there still be the need to get the full context in the message ?

[rex.sheridan]

Esteban, I think we may have a slight miscommunication. My idea is to put the ESB message into the jBPM ContextInstance, not to get the jBPM context into the message (although that is useful too).

From what I can see in the code it is possible to get the message into the context. However, I think it currently requires some mechanism outside the CommandInterpreter (i.e. another action in the pipeline) to set it up. Here is what I think that action code may look like.

public Message process(Message message) {

 CommandVehicle command = new CommandVehicle(CommandVehicle.Operation.setProcessInstanceVariables);

 Map<String, Object> variables = new HashMap<String, Object>();
 variables.put("message", message);
 command.setVariableValues(variables);

 return command.toCommandMessage();

}

What I am really looking for is some way to configure the CommandInterpreter to do this for me.

[estebanschifman]

Good idea Rex. If we put your code inside the CommandInterpreter with another method name (e.g. copyVariables), and we use :

<action process="copyVariables,process" />

then the message will be copied to the context before invoking the process method, without the need of another action class

[estebanschifman]

A better name would probably be: messageToJbpmContext(Message)

[kukeltje]

One thing that would be nice is to also have a kind of mapping from elements in the message to individual processvariables. e.g. a (collection of) xpath statement(s) or maybe an xslt that take a message and produce an (set of) individual value(s). Don't know if that should be a transformer or functionality of the jbpm 'connector'. This is ofcourse only interesting if the process is modeled in jbpl (which does not support xml messages, at least not as real xml 'type') bpel does support it.

[estebanschifman]

1) For Rex: My previous suggestion might not hold water. I am now playing around with a property

<property name="includeMessageInContext" value="true" />

so the setVariableValues will include the originating message in the command Message if that value is true

2) For Ronald:
What about for example:

<action class=".....">
 <property name="mapping">
 <direction from="jbpm">
 <variable jbpmName="x1" messageProp="z3" />
 <variable jbpmName="x2" messageProp="z2" />
 <variable jbpmName="x3" messageProp="z1" />
 </property>
</action>