Long lasting actions and presistance within nodes

[zeroconf]

hi all,

I'm new to BPM and also to jBPM. I'd like to know if the following is realizable with jBPM.

Let's say I have the following process:

<process-definition name="myprocess">
 <start-state name="start">
 <transition name="to-longexec1" to="longexec1"/>
 </start-state>

 <node name="longexec1">
 <event type="node-enter">
 <action class="my.LongProcess1"/>
 </event>
 <transition name="to-longexec2" to="longexec2"/>
 </node>

 <node name="longexec2">
 <event type="node-enter">
 <action class="my.LongProcess2"/>
 </event>
 <transition name ="to-end" to="end"/>
 </node>

 <end-state name="end"/>
</process-definition>

So as you can see it is a linear process which invokes two classes (LongProcess1, LongProcess2) which do heavy calculations. So lets assume every calculation lasts for 1 hour while and doing scientific calculations.

The process should get started via a web interface where a user logs in with his/her account data.
The whole process last long but there is no wait-state (beside start, end).

Is there any way that the user logs out from the web interface and the process is still running. Later on is there any way to get the running process when the user logs in again?

If there were task-nodes with short actions you could probably use the getGraphSession().saveProcessInstance(processInstance) call like it is shown in
example 2 in the jBPM-3.0 documentation - but in my case there aren't any tasks but
long running java classes

Does anybody know how to deal with this problem?

Thanks in advance
zeroconf

[brittm]

This isn't really a problem for JBPM.

First, in my experience, once a process instance has been saved , subsequent node completion will be recorded to the database whether you continue to call saveProcessInstance() or not (you just might not get all the logging you want).

Second, as for keeping the action handlers running when the user logs out, that's completely up to how and where you place the java code that actually kicks off the process execution--that's a java question, not a JBPM one.

Try this:

* Create a new process instance in a java bean operating in a thread that will continue separately from your web page execution.
* In that bean, call saveProcessInstance() and signal() the process to continue from the start state.
* ...your user moves on (logs out), but your actions continue to run in the bean...
* User logs back in, and can see which states have been completed (they've been recorded to the database as the bean continues to run to completion). You might even have your action handler periodically update a process variable to indicate how far along it is in it's computation.

Does anyone know why this might not work?

-Britt

[zeroconf]

thanks brittm for your helpfull response.

I already start the ProcessInstance in a thread and it keeps running
after logging out. So that seems to work.

But can you give me a hint how to get back the pointer from the running thread or ProcessInstance? (I know that is not really a jBPM related issue)
I'm starting the process from within a Portlet which is closely related to a Servlet.
Is it nessesary to use a Java Bean?

thanks in advance
zeroconf

[brittm]

As long as your code keeps running after your user moves on, it doesn't matter what you use.

Your portlet/servlet/bean whatever should return the process instance id of the newly created process to the UI before continuing to process--either by returning the value directly for the user to record, or by persisting it in some other way in your application for future use by your UI.

You may want to maintain a listing in your application of all process instances that were started on a particular day or whatever, and let your users choose the one in which they are interested when they return. How you manage that will be totally up to you.

Remember that you can use process variables to store additional information about processes (like who they belong to, etc.) and use a JPBM or Hibernate query to return process instances based on that data.

-Britt