Service flows (and general system services) have no timer step by design - they are meant to run and return - so a "wait" inside a service is either a blocking sleep (acceptable for seconds) or a redesign (for anything longer):
// blocking wait of a few seconds inside a service flow script (holds the thread and the transaction - keep it short, e.g. polling an async job)
java.lang.Thread.sleep(3000); // 3 s
// polling pattern with a bounded loop
var ready = false, tries = 0;
while (!ready && tries++ < 10) { ready = checkJobStatus(tw.local.jobId); if (!ready) java.lang.Thread.sleep(5000); }
if (!ready) throw new Error("Job " + tw.local.jobId + " not finished after 50 s");Why not for longer waits: the service occupies a WebContainer / event manager thread and keeps its transaction (and database connection) open; the transaction timeout (default 300 s on WebSphere) will roll it back, and the load balancer / browser will time out the request that called it.
Redesign options when the wait is minutes or more:
- Put the wait in a BPD: call the service from a system task, then a timer intermediate event (minutes / hours / a date) or a message event that the external job triggers when done (delayed response pattern, question 1025). A small "system BPD" wrapping the service is the standard answer to "wait without a BPD".
- Undercover agent on a schedule: a scheduled UCA runs a service every N minutes to check for finished jobs and continues the waiting instances by message.
- Asynchronous service invocation from a BPD: start the long-running work as a separate BPD (tw.system.startProcessByName) and let the caller continue.
- Client side: when the wait is for the user's benefit (progress of an upload / job), poll from the coach with the UI Toolkit Timer + Service Call (question 2437) - no server thread blocked.
Rule: a service flow may sleep for seconds while it polls a fast job; every longer or unbounded wait belongs into the BPD's events, where the engine persists the instance and uses no thread while waiting.
References