Usage of Timer as Subprocess Boundary Event

[marcj]

Hey guys,

I modelled this sample case (not important if it males logic sense):

As part of a greater business process, an embedded subprocess has been defined. This subprocess encompasses 4 validation activities, implemented by 2 service calls and 2 script tasks. A timer has been attached to the boundary of the subprocess, which should be triggered anytime the subporcess has not been finished within 5 seconds. Therefore, the timer duration has been set to the value "PT5S", which I assume should be correct, right? In order to simulate that, a pause has been implemented with Thread.sleep(10 * 1000); in the Validate Payer BIC activity.

Yet, the timer does not get triggered at all...

Any ideas?

[swiderski.maciej]

the problem is that you put thread sleep in the script activity which locks current execution and thus preventing the timer to fire - only single operation can happen on given process instance. Make one of these tasks async and then timer will be executed. That is actually recommendation - use async processing in case processing can take longer time or you want to have possibility to interfere with the running instance.

HTH

[marcj]

Hi Maciej,

thx for your reply. What exactly do you mean by "making one of these tasks async" - is there a property to do so?

I tried to circumvent the thread.sleep(); by using that:

Date start = new Date(); Date end = new Date(); while(end.getTime() - start.getTime() < 10 * 1000){ end = new Date();  }

No impact on the timer though.

Curious for your reply.

[swiderski.maciej]

checkout this article about async execution.

HTH

[marcj]

Thx for the article. To summarize the information provided:

- Timer boundary events can only be attached to asynchronous activities respectively subprocess cointaining asynchronous activites.

- A set of synchronous acitivities therefore can´t be addressed by a timer event.

Is that correct?

[swiderski.maciej]

yes, that's pretty much correct. Boundary events makes sense only when there is state in given node - like human tasks so there is a chance that such not will receive the signal. As when it's being processed it won't be able to receive any signals and once done with processing it will deactivate boundary event before the signal arrives.

HTH

[marcj]

OK, just one last thing:

Therefore, the following process should be correct, right?

And that is because of the incorporated human task, correct?

[swiderski.maciej]

that's correct. As soon as the processing arrives into user task timer will be able to trigger.

HTH