Timer boundary event not supported for Service Task?

[xjshangguan]

Hi,

I have learned in my own testings (jobExecutorActivate=true) and from the forums that timer boundary event is not supported for service task.  Can anyone confirm?   This will impact us significantly because most of our flow components are service tasks either calling external web services or java classes executing locally. We basically would like to time all activities in case of any unresponsiveness of elements, just like Autosys' Max Run Time.

Oracle has this implemented for sure.  Although we are always able to implement a time checking thread running in parallel with the java task, it is not so elegant even in workflow diagram perspective.  Does anyone have any kind of workaround? 

Happy Holidays

Sean

[jbarrez]

No, Activiti does not support timers on service tasks. The reason for this is transactions: when you have a long-running service task, it keeps the transaction open, which is never a good idea. On top of that, timers in Activiti are also persisted in the database, so when they run, they won't be able to read the 'open' transaction of the service task.

Now, the best practice is to have a short-lived service task, that simply triggers an external something. After the service task, there should be a receive task. the external entity can then trigger the process instance again. That way, the transactions are short, as they should be. If you need a timer, just put it on the receive task.

[xjshangguan]

We do have short lived service task calling external web services. if everything works, we will be fine. The reason why we are looking for timer is when external services are not responsive.
Thanks for the advice. Several of us do have your "Activiti in Action".

[derikalov]

Per BPMN, a ServiceTasks is atomic Activity but nowhere it says it is supposed to be short lived.
Secondly, what would be the semantics of cancelActivity="true" if ServiceTasks are always just asynchronous submit? There is SendTask concept in BPMN for async submits.
Not to mention that DataSet-associated wait may also induce blocking on any Activity, which may be desirable to handle via timeout.

But even in practical terms, what about service tasks that are implemented via Camel (i.e. delegateExpression="${camel}"). The Camel route can take some time and I would like to be able to detect timeouts.

I can rewrite CamelBehaviour myself and i.e. run Camel on a thread pool, then posting an event, and having Timer Boundary event on my ReceiveTask in my process. But it would be nice to (A) have support for it out of the box from Activiti, and (B) this kind of hacking complicates flows, instead of naturally using just one box (ServiceTask) I have to remember/document to use 2 boxes, ServiceTask + ReceiveTask.

[trademak]

Hi,

That's a valid point. Based on this discussion we are thinking to provide out-of-the-box support for this pattern.
We could introduce a new service task type that allows you to add a timer boundary event.
Under the hood the pattern will probably be implemented with Camel in the background and an additional receive task, but you don't need to configure this yourself.
Would that be helpful?

Best regards,

[derikalov]

Yes, this would definitely be helpful.
Just off the top of my head - one way of doing this would be to provide another variety of ActivityBehavior interface, for example:
public interface ActivitiInterruptableBehavior { // Or ActivitiStatefulBehavior
      void setExecution(ActivityExecution execution);
      void execute() throws Exception;
      void interruptExecution(); // best-effort, exceptions ignored, not to confuse with compensation (which is for previous steps)
}
so if my activity:class or activity:delegateExpression resolves to implementation of this interface, the Activiti can assume that (1) boundary timer events should be supported; and (2) optionally, developers can choose to handle cancellation (i.e. stopping long upload/download). This would also mean the instances of ActivitiInterruptableBehavior can be stateful (I think currently instances of ActivitiIBehavior are per-process def, not per execution).
I think BPMN spec does not tell what cancel=True really means for the activity implementation. I may be wrong but I think it may be useful and it does not break the BPMN semantics.

Or, this interrupt-ability and timeout-ability can be communicated to Activiti via Java annotations.

[mamtag]

Hi trademak,
Do we have any update on the service task which allows to add timer boundary event?

Thanx.

[trademak]

Hi,

No we didn't do development in this area yet. What would be your use case for needing this?

Best regards,

[boekhold]

Hmmm, I'm looking into this exact same topic: a process needs to make an external request via JMS request/reply, and the reply could take from seconds to minutes to come back. For the Business Analyst who designs the workflow model, we don't want to complicate his life by requiring him/her to fiddle with servicetask->receive message, plus possible gateways/timers to be able to model this. We want a single task that makes the request and receives the reply, allows us to configure a timeout on it, and doesn't unnecessarily keep any Activiti DB transactions open.

For a service task that does the request/reply, I just found the following post: http://forums.activiti.org/comment/9956#comment-9956. However this doesn't yet address any timeout handling via a timer boundary event.

Anything that can be done in this area to make modeling these scenarios simple and quick for Business Analysts?

Maarten

[jbarrez]

If you take that implementation from that post, you can put a regular timer event on it.
A more complex implementation could mimic this behaviour and hide the event in the diagram by creating a TimerEntity in the execute() method there.