Next State

[jasonw1]

From reading the documentation I understand that I as the developer I must call sginal to move the process into the transtition. I was wondering how this is "typically" accomplished using J2EE; JMS and Session Beans? Is there an example?

The only design that comes to mind is:
(1) persisting process variables
(2) and calling nextState("") which is defined in a base Action class that each custom Action can derive from. This method would call signal("") to move the process into the next state and then publish a JMS message with the necssary information to retrieve the process state.

Am I on the right track or is this already provided if jBPM is embedded in a applicaiton server? Is the a better much easier way to do this?

If JMS is the way to go does this mean I need to turn off auto-acknowledge ? I say this because if the system crashes while processing, the message will need to be resent. If auto-acknowledge is turned on the message would be lost ... right/wrong?

Thanks for any information. Examples would be great if their are any.

[enazareno]

If you download the jbpm code, there are several examples they have provided. However their running demo is a web-based app but you can definitley go from there. Actually the engine is independent of J2EE, so this means JMS, and all other J2EE components are not required. But if you are already using J2EE, you might as well take advantage of those, like you said, JMS is useful for long running processes so that if everything crashes, your data will not be lost and it will resume where it left off.

Regards,

Elmo

[ralfoeldi]

If JMS is the way to go does this mean I need to turn off auto-acknowledge ? I say this because if the system crashes while processing, the message will need to be resent. If auto-acknowledge is turned on the message would be lost ... right/wrong?

Wrong. At least if your using MDBs inside a transaction. Then the delivery of the Message is part of the transaction and if your machine crashes the message will get redelivered.

Concerning your first question I don't really understand what your going for. jBPM Tokens will move from one node to the next as long as the node itself moves them on to the next node, i.e. call signal with a transition. If the node does not signal and returns, the Token is in a wait state, waiting for some kind of external input. This can be from a UI, from a Timer, from a JMS Message, what ever makes sense to you. Once signaled the Token will again move on till the next wait state is arrived at.

What is the JMS Message sent during/after signal() supposed to do? By the way: the message would only get sent after signal() returns - at that point the workflow may have already proceeded till completion.

JMS Messages can be very usefull if you want to achieve asych execution, split execution into more than one transaction, as load balancer with MDBs, but they are not needed for direct execution of a workflow.

Happy New Year!

Rainer

[jasonw1]

Hi Rainer and thanks for the reply. So if I where to implement my own ActionNode then I would need to signal the next state? This is what I thought, but I am confused on where JMS and even J2EE fit into the execution of the workflow. An example workflow:

Start->A->B->C->End

The workflow is started by sending a JMS message "start.flow.acme". The "start.flow.acme" message listener signals("transition-to-b"). Once the signal method has returned do I need to publish another message so that another listener will retrieve the state of the process and execute the node? I do not want to process the entire workflow on one JMS server, but spread out over numerous JMS servers. Maybe I am still missing the point and I don't not meed JMS or EJBs to loadbalance the workflow.

I look through the source distribution and did not see any examples on loadbalancing the wrokflow.

Also, when a JMS message is delivered if auto-acknowledge is turned on then the trasnaction is successful. If the system crashes after delivery but before the node (say node b) finishes executing then the workflow is orphaned. Is that right?

Sorry for so many questions, but I would like to know the best way to process a workflow over several servers (whether it is using JMS,J2EE or by some other means).

[ralfoeldi]

Hi 'digitalclock'?

Once the signal method has returned...

the workflow is in a wait state, meaning there is nothing jBPM can further do without external action / input.

You basically have two options:
- 'process the entire workflow on one JMS server' that wouldn't be the JMS server but where ever the message consumer is located. There is nothing wrong with that. I assume you will have >>> 1 message so load balancing will happen.
- break up your workflow into smaller pieces of work. This will require you to suspend the workflow (by returning from the signal() method without triggering the next node, i.e. by returning from ActionHandler.execute() without taking a transition). But before you return from signal() you will have to send a new Message that will continue the workflow. All this is non trivial but has some benefits:
a) you can priorize parts of your workflow by using JMS priority mechs
b) you can break the execution of your workflow into different transactions.

Also, when a JMS message is delivered if auto-acknowledge is turned on then the trasnaction is successful.

This seems to me a quite revolutionary concept. But I will be glad to try it. What you are saying is that if I use auto acknowledge my transaction is sure to commit. That's cool. :-)

Should the new approach not work as expected: the old fashion concept is that you execute acceptance of a message AND execution of the workflow in a single transaction. That way if the workflow fails the message gets redelivered.

The luxury edition is to split the execution of the workflow and the persistence of the workflow state into different transactions... but that doesn't seem to be of great interest here.

What's wrong with an app server? A MDB would solve all your load balancing and delivery problems at once. No great effort in setting one up. JBoss even offers one for free.

What is very helpfull is to trace the execution of signal(). then you will probably understand all the details. It's really not that hard, just 5-6 classes deep.

Hope this helps even if it isn't a cookbook.

Greetings

Rainer