Problem: a process instance needs to wait an determined amount of time (passed as input) on a process step before continuing. Something like 15 minutes for example.
Constraints: A big number of process instances can be running at the same time thus invalidating the usage of techniques that keep threads waiting/locked (wait, sleep…)
The interval maybe customized and can fixed (e.g. based on a specific time for instance at 16:15) or relative (15 minutes starting from the last step executed or a timestamp).
Volume: Today the worst case scenario would be 300 instances running at the same time. But it will grow in the future so it would be something like 3000 instances.
We thought that this seems a common issue and we have searched for a capability in the platform out-of-the-box to do this and were surprised not to find it. Are we missing something here?
Meanwhile we thought of the following approaches:
Use a scheduler task that publishes a doc every second containing a timestamp. Putting a receive step in the process to subscribe to that doc using the timestamp as a correlation ID. (We have concerns about hour changes/daylight savings and also correlation with multiple instances).
Use a task in MWS and queue that task for a period of time (This will introduce a lot of open task in the system and may not scale)
Using a join with a dummy receive step that will never happen and set a join timeout for that step. (Not pretty as you are representing some fake business to overcome a technical issue)
as far as I know there is no wait step in webMethods like you might know it from BPMN or BPEL. I do not really understand why that is the case because I consider it a common requirement to wait for a specified time/until a date in a process.
I think your third solution idea is the best - it avoids the overhead of creating a task and the dummy receive step also provides a way to interrupt the waiting step e.g. by an administrator publishing a document.
The most ugly thing about it is that you have to use the error transition type out of the receive step to catch your timeout. Maybe it would make sense to hide this part from your main process by extracting the wait step implementation into a subprocess which you could reuse wherever you need the wait step.
You might also want to look here for a discussion of the topic:
[url]wmusers.com
Hello, just to leave some feedback. We have successfully implemented alternative 3.
Timeout can be configurable as its a process parameter fed trough reference data.
What does not look good is that both timeout and iterations exceed (number of times to execute a step) are marked as error. When you look at the process it’s all marked with errors making it seem that it didn’t worked when in fact it did everything OK. :evil:
If I’m not mistaken the BPMN semantic allows such things to run as a normal process execution instead of exceptions.
In the future we will consider hiding this if no support for that semantic appears.
Just an addition: we implemented a common sub process that is responsible for the wait logic. It is able to wait until a specified date or for a specified amount of time.
We use a empty step with a join timeout. (see attached image) Additionally we use a receive step that can be used to interrupt the wait which is often required for administration or test purposes. So if the receive is not used the join timeout occurs when the wait is over. The good thing about a join timeout is that the step that times out is marked as expired at runtime. This looks a bit better than your solution with a receive step.
The nice thing about this sub process is that we can use is to place wait steps in other processes with a single activity.
