First of all, the worst thing you can do is to program a ‘Wait up to x seconds’ within a BOR Method! Imagine that 30 workflow instances are started and start executing the “wait up to” at the same time (eg: after event queue processing), this will cause your eg 20 work processes to wait and therefore a system standstill for a few seconds.
In any case ‘wait up to x seconds’ is BAD PRACTICE!
In order to implement a “Wait” within a workflow, you might use different ways to implement!
How to solve this correctly?
1) The first goal should be to avoid the use of any ‘wait’-principle. Typically, one should be able to rely on the SAP standard principles on synchronous Tasks (where the workflow only continues after task is completed = DB update should be finished) or asynchronous Tasks (where the workflow continues after a Terminating event indicating the DB update was finished).
Unfortunately, in some (rare) cases the update to DB was not completely finished therefore they might require on of the below options:
This principle is always good practice since here your workflow becomes also reactive on Events from outside your workflow (eg: when a delete on an object is triggered, your workflow can close down and therefore becomes self regulatory)
The only thing you need here is an Attribute on a Business object that will be filled and which can be then evaluated against the condition value. The job (scheduled via SWU3) will evaluate this condition upon execution.
3) The last option (but not always bullet proof) is to create a ‘Requested Start’ Deadline on the Workitem.
Option 1 and 2 are the best options and most bullet proof, if you can solve it by implementing a ‘Wait for event’, please do so… If not, then you probably can solve it with the ‘Condition on Create Workitem’
I hope these tips will help us to create better designed and more performing workflows!