recovery of an automated process?

[rmunjuluri]

Hi,

My understanding has been that JBpm engine currently does not support automatic recovery of an automated business process in case of situations like system crashes etc. I am trying to validate my understanding...

Say, if there is a business process that has states/nodes that transition to the next states/nodes by each node invoking the executionContext.leaveNode(). now if the system crashes while the process instance is in the middle of execution, there seems to be no recovery process to continue the process execution from where the engine left before the system crash.

Is my finding correct? if so, the JBpm Service might need to be extended at start up look for incomplete processes, processes that are not waiting on an actor to trigger continuation.

thank you very much
-ram

[kukeltje]

jBPM, uses a database for persisting process state and variables. Each committed transaction is persisted and will still be available after a systemcrash.

May I ask where you got the impression that jBPM could not have 'automated recovery'? Only if an in-memory database is used this is the case. In all other situations recovery is available.

[rmunjuluri]

Ronald,

thank you very much for your response... here is my understanding of the Jbpm engine. Please let me know if I am missing something.

I understand that the states and the process/context instance variables are saved to the database during the execution of a process instance. This works great in situations where the execution is sort of waiting for an actor, for example a user thru from web-console, to start the paused process.
Say for example in a typical document approval process where a doc is first approved by a peon, then the process waits the the supervisor to approve. If during this wait, the system is unplugged, the state is persisted in the db and so when the system comes up, the supervisor can still pull up list of docs, as tasks for approval, that he/she will need to approve that doc.

Now if we have an auto-transitioning process (without an actor intervention), that moves from one state to the next, if the system is unplugged and brought up, is there a scheduler or a JBpm startup service that goes thru the list of process instances that are not waiting on an actor and signal them continue? my initial understanding of the Jbpm MBean service is that it builds a jbpmsessionfactory and registers it within the JNDI tree. Clients can start accessing this factory to create jbpmsessions and continue. I dont see anything in the log that looks for process intances that are not complete and try to invoke them...

Is my understanding correct.

thanx
-ram

[kukeltje]

"rmunjuluri" wrote:
Ronald,

thank you very much for your response... here is my understanding of the Jbpm engine. Please let me know if I am missing something.

I understand that the states and the process/context instance variables are saved to the database during the execution of a process instance. This works great in situations where the execution is sort of waiting for an actor, for example a user thru from web-console, to start the paused process.
Say for example in a typical document approval process where a doc is first approved by a peon, then the process waits the the supervisor to approve. If during this wait, the system is unplugged, the state is persisted in the db and so when the system comes up, the supervisor can still pull up list of docs, as tasks for approval, that he/she will need to approve that doc.

Right, withy the exception that the state is not persisted when the system is unplugged, but when the system goes to the next node, whatever that node is. And I think I see your next point..

"rmunjuluri" wrote:


Now if we have an auto-transitioning process (without an actor intervention), that moves from one state to the next, if the system is unplugged and brought up, is there a scheduler or a JBpm startup service that goes thru the list of process instances that are not waiting on an actor and signal them continue? my initial understanding of the Jbpm MBean service is that it builds a jbpmsessionfactory and registers it within the JNDI tree. Clients can start accessing this factory to create jbpmsessions and continue. I dont see anything in the log that looks for process intances that are not complete and try to invoke them...

Hmm.... yes and no (but this is an area Tom should kick in)

Realy automatich 'actions' should be carried out on the transition. If the transition is not taken, the state (taskstate) is not completed and will show up next time in the tasklist or can be triggered again e.g. by a message that should stay in the jms queue if you triggered it async.

For this specific reason, Tom was not keen on implementing automated node types and it, until now, is not a default node-type in jBPM.

Many people wanted automated actions/states/whatever to show up in the businessprocess view, kind of like they were using it like a pure uml editor.

"rmunjuluri" wrote:

Is my understanding correct.

imo partly. One can debate whether it should be a jBPM responsibility. Remember it is a state machine, not an interpreter. Besides that, async nodes (put a message in a jms queue on the 'node-enter' event, have that message trigger some code and on returning from that code signal the node that originally triggered this code (simplified but I think you are smart enough to see what I meen)

"rmunjuluri" wrote:

thanx
-ram

Any time... nice discussion

[tom.baeyens]

i'll kick in...

basically you want transaction demarcation. if you have 5 automatic operations in sequence, by default jbpm will execute those in the thread of the client. so the client cannot commit his transaction until all the automatic operations are done.

if you want your client transaction to commit sooner, you can use asynchronous messaging and introduce a wait state. so you should write an action that sends an async message upon entrance of the wait state. then the client transaction will commit and the process will be waiting. when the asynchronous operation is complete, a notification is sent to e.g. an MDB (that you have to implement) that mdb can resume process execution with a signal.

all that has to be done "by hand" in jbpm 3.0 and earlier. now, i'm working on integrating automated support for this pattern. the solution i'm working out will be something like:


<action... />


i am making the async messaging configurable to work in a plain webapp env (without JMS) or with JMS/MDB when you're running jbpm in an appserver. to make it run in a webapp, i've built a simple message broker that operates on the jbpm db connection. i had to do some refactoring cause the configuration is now a bit more complex. for that i introduced a spring-like beans object factory notation... anyway hope that i made you enthousiast to look at the first 3.1 alphas that will be coming up in a few weeks. (if you can't wait that long you can always dive in the cvs) any feedback is highly appreciated.

regards, tom.

[kukeltje]

starts to sound like

http://www.jboss.org/index.html?module=bb&op=viewforum&f=220

[tom.baeyens]

there is a relation, but it's not the similar.

if you look into cvs, check out the org.jbpm.svc package. that JbpmService (currently in experimental stage) could be exposed as a webservice and plugged into JBI as a service engine. that is how i see the relation between jbpm and jbi. the bpel extension is another candidate to be wrapped as a JBI service engine.

regards, tom.