Hi members,
I need to call an API every hour for a status check (this loop will be over a period of 10 hours) Once I receive the positive status, I will continue with the rest of the process.
So, in order to schedule this API call hourly, I’m looking to introduce a delay of 1 hour in between the process flow.
I see that BPM doesn’t have any delay timers (please confirm). If so, can anyone please suggest a workaround
note: API request have unique id, which varies for each process instance
BPMN has delay elements but webMethods does not implement them. We use an and-join (which is never satisfied) with a timeout in such situations. Ugly, but it works ans does not lock any resoures during the wait time.
There are already several requests on Brainstorm:
03189 Support of intermediate catch timer events
03229 BPMN Intermediate Timer Event
05175 Receive Task must be able to use intermediate boundary timer event
Hi,
I’ve tested several approaches but the one I prefer is the receive document event with a join timeout, where the document is never emitted.
Don’t forget you can only set a join timeout once you have a transition.
Take care NOT to have anything other than THAT ONE out-transition.
If you want sub-minute delays, verify you have already the latest fixes installed and the PRTTIMERENTRY table has field EXPIRES with type TIMESTAMP (not DATE).
Best regards,
Hi,
do you really require a process model here?
An IS Scheduler might be sufficient in this case, which calls the API every hour.
Regards,
Holger
Thank you @Gerardo and @fml2 for your inputs.
I landed to a solution almost on the same lines, except that I used Task instead of Join for introducing the delay.
This task will be auto “Completed” after set timeout.
Rational behind using a task - I can control the timeout from task engine (exceptional cases).
If I need to call the API within the timeout period (I can force it from the task engine by changing the Task state to “Completed”)
In case of join timeout, I don’t have this control on the timeout.
@Holger, as I mentioned in my initial post, I have a unique id in each process instance and same is the input for API request. For this use case I feel scheduler won’t be the right candidate.
Hi Naidu,
as Schedulers allow assigning input variables since wM 9.5 it might be possible to pass the API request id there.
See IS Built-In-Services Reference for the pub.schedulers folder for further information on how to create and delete schedulers programmatically.
My idea was:
When it comes to the API call start a scheduler with run map every 1 hour, start time=now and end time=“now+10 hours”.
When API call was positive, publish a document back to the process with correlation signalling the success and delete the scheduler.
In the model, after the API-Step (non-blocking in this case as the scheduled service runs outside of the process engine) place an and-join waiting for the published document for the correlation.
So you might have several of theses schedulers running in parallel, but you do not require TaskEngine for this which might be a little bit oversized.
Regards,
Holger
@Holger Good to know about this. Thank you.
This is indeed an interesting solution, but it somehow contradicts to my understanding of scheduler. So far I thought that scheduled jobs are something that is rather static, i.e. set up e.g. when the server starts and then is not changed anymore. You suggest quite a different approach where scheduled jobs are used much more dynamically, on the process instance basis. Technically that is perfectly possible, but “ideologically”…
I might have to rethink my understanding. But tell me please: Would you use such approach if wM BPM would implement timer events? Or is just a workaround for a missing feature? In the latter case I’d prefer to work with join timeouts because the solution then would use less components (BPM only vs. BPM and IS) and hence would be less complex (and also would not require special document types, correlation etc).
I’d also be very interested to hear opinions from others.
