[rules-users] Blocking Call to startProcess()

[Kris Verlaenen]

Yes, there are a few examples on how to implements a work item handler
here:
http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-process/drools-workitems/src/main/java/org/drools/process/workitem/

For example, this code allows you to invoke a service on the JBoss ESB:

public void executeWorkItem(WorkItem workItem, WorkItemManager manager) {
  Message message = MessageFactory.getInstance().getMessage();
  Body body = message.getBody();
  Map<String, Object> parameters = (Map<String, Object>)
workItem.getParameter("Parameters");
  if (parameters != null) {
    for (Map.Entry<String, Object> entry: parameters.entrySet()) {
      body.add(entry.getKey(), entry.getValue());
    }
  }
  String category = (String) workItem.getParameter("Category");
  String service = (String) workItem.getParameter("Service");

  ServiceInvoker invoker;
  try {
    invoker = new ServiceInvoker(category, service);
    invoker.deliverAsync(message);
    manager.completeWorkItem(workItem.getId(), null);
  } catch (MessageDeliverException e) {
    e.printStackTrace();
    manager.abortWorkItem(workItem.getId());
  }
}

It might be useful to have startProcess to block (as you might want to
wait until you know that your command actually worked and no exception
was thrown or similar).  If you want to have asynchronous execution (but
not have the hassle of invoking in a separate thread) and are not
interested in the result of the invocation, I guess you could use the
CommandBasedStatefulKnowledgeService in combination with the
AsynchronousInterceptor.

Kris

Quoting mardo <mardo at abicola.de>:

> Kris,
> 
> thanks for the quick reply. It makes perfect sense what you're saying
> about
> the implementation issues on the task level. Did I get it right that
> e.g. a
> specific task for (asynchronous) web service invocation would be
> implemented
> very similar to the WorkItemHandler
> http://www.mail-archive.com/rules-users@lists.jboss.org/msg09450.html?
> 
> 
> I didn't however understand yet why startProcess() has to block at
> all.
> Naively, this would rather be the semantics of a method like
> "executeProcess()". From my current understanding, even when
> launching
> concurrent instances from different threads using startProcess(),
> the
> required return value (ProcessInstance) I was aiming at is obtained
> earliest
> at the first wait state or termination of the process, right?
> 
> Thanks so far!
> 
> Best
> 
> Markus
> 
> -----Ursprüngliche Nachricht-----
> Von: Kris Verlaenen [mailto:kris.verlaenen at cs.kuleuven.be] 
> Gesendet: Dienstag, 3. November 2009 16:11
> An: Rules Users List; mardo
> Betreff: Re: [rules-users] Blocking Call to startProcess()
> 
> Markus,
> 
> You should not block the execution thread using long-running tasks
> (like
> sleep()) in actions, as this will actively lock the resources of the
> engine.  You should use wait states, event nodes and/or work item
> nodes
> if you want to perform long-running tasks.  Even when implementing a
> work item handler, the work performed there should either be quick
> and
> synchronous or performed asynchronously (acting as a wait state).
> 
> As a result, startProcess() will block only until the process has
> reached a wait state, but this should almost be instantaneously (and
> if
> you don't have any asynchronous behaviour, this could already be the
> completion of your process).  This allows concurrent execution of
> process instances if they contain asynchronous tasks (which is
> usually
> sufficient).
> 
> You could also invoke the engine non-blocking (in a separate thread)
> if
> you want true concurrency.
> 
> Kris
> 
> Quoting mardo <mardo at abicola.de>:
> 
> > 
> > > Hi there,
> > > 
> > > I just began exploring the capabilities of drools and also
> > considered its
> > > applicability for typical EAI scenarios.
> > > 
> > > It really may be a beginner's question. But I took the simple
> > example
> > > workflow and inserted a Thread.sleep() for its task action.
> > > 
> > > I experienced the blocking startProcess() as discussed here: 
> > > 
> > >
> >
> http://stackoverflow.com/questions/1326718/how-to-start-multiple-processes
> > > -in-drools-flow
> > > 
> > > So did I miss something or how would it be possible to get the
> > internal ID
> > > of the WF instance right after starting it before its completion
> to
> > be
> > > able to query the engine proactively during runtime?
> > > 
> > > I also see that this relates to
> > >
> >
> http://www.mail-archive.com/rules-users@lists.jboss.org/msg05828.html,
> > but
> > > I also don't see a solution here.
> > > 
> > > 
> > > 
> > > Thanks and Best
> > > 
> > > 
> > > Markus
> > 
> 
> 
> 
> 
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> 




Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm