Signal process instance asynchronous

[hhhuber]

Hello,

i want to start a new process instance in an asynchronous way.
what i think of is a solution where i create a process instance and then call a

processInstance.signalAsync();

The call to signalAsync() does return immetiately and the process instance is scheduled like a timer and signaled from the jobexecutorthread.

any ideas how to achieve this in jbpm 3.2.5?

do i have to implement my own SignalProcessAsyncJob class to be able to schedule the signaling?

kind regards,

oliver

[jbarrez]

In jBPM3, you can make a node 'async', which does exactly that

[hhhuber]

i know about the 'async' attribute. but it does not what i want.

what i need is a possibility to start the process asynchronously.

using 'async' in a node whould mean to start the process synchronously and then continue asynchronously when the first node is executed.

any other suggestions?

kind regards,

oliver

[kukeltje]

making the the first node async has the same result as being able to start a process async afaik.

If you do not want it this way, then create your own JMS publisher and an mdb for really starting the process. This is the default way for JEE apps to do things async.

[hhhuber]

there are reasons why i don't want to make the first node 'async'. so i kept looking for a way to signal a process asynchronously. this is what i implemented:

a AsyncProcessSignalJob that can be saved as a jbpm-job. then the job executor finds and executes the job as any other job.

public class AsyncProcessSignalJob extends Job {

 /** The Constant serialVersionUID. */
 private static final long serialVersionUID = -8358943330005955423L;

 public AsyncProcessSignalJob() {
 }

 public AsyncProcessSignalJob(ProcessInstance processInstance) {
 this.setDueDate(new Date());
 this.setProcessInstance(processInstance);
 this.setToken(processInstance.getRootToken());
 }

 @Override
 public boolean execute(JbpmContext jbpmContext) throws Exception {

 ProcessInstance processInstance = this.getProcessInstance();
 processInstance.signal();
 jbpmContext.save(processInstance);
 return true;
 }

then i created a hibernate mapping file

<hibernate-mapping auto-import="false" default-access="field">

 <subclass name="foo.bar.AsyncProcessSignalJob"
 discriminator-value="P"
 extends="org.jbpm.job.Job">

 </subclass>

</hibernate-mapping>

which must be included in jbpm.hibernate.cfg.xml.

once i have created (but not signaled) a process instance i can schedule it like this:

 public void signalAsync(ProcessInstance processInstance, JbpmContext jbpmContext) {
 AsyncProcessSignalJob job = new AsyncProcessSignalJob(processInstance);
 jbpmContext.getJobSession().saveJob(job);
 }

does this look reasonable? have i overlooked something? i'm still in early testing phase so i cannot guarantee that this code really runs stable.

any comments would be appreciated.

kind regards,

oliver

[kukeltje]

Sure it might work, but I would not have chosen to go this route. For several reasons. Would take me to much time to comment in detail, but if I see your solution, I would have chosen an even different one.Just a plain node as the first node with a timer in it to continue the process. No hasseling with jBPM internals etc...

[hhhuber]

yeah, if i had started from scratch i would have taken the path with the 'async' node.
but that was not an option (already deployed processes with long running process instance; want to keep new versions to an absolute minimum) in my case.

also, i remember another posting in this forum where it was said that one of the big advantages of jbpm over other workflow engines is that you can extend it with your own code :-)

[kukeltje]

If you want to keep changes to a minimum, you *can* change the attribute of 'async' on a node in a currently deployed definition in the database to true. So...

Regarding extending it with your own code, yes, but that would be mostly actionhandlers etc. Only a few have created really custom nodes (with their own tag). Extending the job is the first time I've heard of this.