Script to create a pause of 5 seconds in workflow

[GILBERTO_CORUJO]

Hello:

Do you have a script to create a pause of 5 seconds in a workflow?

I appreciate your help.

[Aki_Daiguji]

Hi Gilberto,

You can have a Workflow Unity script be executed as an Action at the point where you want this pause, and within the Unity script, use C#'s Thread.Sleep method to pause the current thread for 5000 milliseconds. You will probably get slightly more than 5 seconds since there are some work that takes place before the script is executed.

Here's an MSDN page on Thread.Sleep method:

msdn.microsoft.com/.../system.threading.thread.sleep(v=vs.110).aspx

[dave_sanderson · Accepted solution]

Hi Gilberto,

I am just curious why this must be a script? There may be some reasons NOT to do it this way, but you can use recursive native workflow to delay for five (or more) seconds. This is wont be exactly five seconds, but depending upon how important pausing for exactly five seconds is and you have a bit of wiggle room - as in 5.1-6 seconds wont mess up the processes - this seems to work for me in version 15. not sure when the expression function ceil became available though so your results may vary:

• using the action Set Property to Expression create propWaitUntil property and set it equal to ceil(now()*24*60*60)+5. This sets the current date time in seconds (24 hours a day, 60 minutes an hour, 60 seconds per minute) to five seconds in the future. 

• using the action Set Property to Expression create propNow property and set it equal to ceil(now()*24*60*60). This captures the current date time in seconds.

• using the rule Compare Property Value set PropWaitUntil is < propNow indicating that the time I had set to wait for in the future (that is + 5 seconds) is less than the time (in seconds) now, so the wait has been completed

 

• • Under True branch (wait is over)
    • I added a message box stating that five seconds are up

• • • BREAK - I added a break after the message box, but you would not want it because it prevents what ever comes after the Task List from being evaluated. I would avoid putting steps unrelated to waiting five seconds in this task list. That way you could just copy/paste this Task List next time you want a five second rest and not worry that you have other actions/rules that are NOT strictly involved with waiting five seconds
  • In the false branch
    • drag and drop or copy/paste the same action that created propNow
    • Copy and paste the Rule created above into the False branch

the whole thing looks like this - note that you can keep expanding false branch of the rule forever and will keep getting the repeat. versions ago if you shift + right arrow, the configuration client (where workflow used to be configured) would crash as the branches kept expanding. that does not happens in Studio (*phew*). I only expanded three false branches, but you get the idea

so I am very interested in hearing why i should not do this 😉 I get it may take up more processing power than a script, but how much more and how big of an issue is that?

thanks all - I am looking forward to the comments !

[#4]

Looks like you have the workflow designed to best test the impact. I'd say create a session property before you enter your loop that holds a count and then increment that count within the loop. Then throw that value out to diagnostics console after you've exited the loop and see to what level of recursion (processor/memory impact) the wait could result in vs. just sleeping the thread in a small script.

Like you said, it's mostly harmless and I understand that the push is to replicate as much scripting as possible in workflow & expressions. I also think different use cases (a pause of 10 or 30 seconds) would highlight the impact more. IMHO a simple reusable script ("Pause") and a single call to that script in a workflow with a duration property set right before it reads a lot easier to someone looking at the workflow than a recursive rule does AND it is lighter on the system resources.

[Alex_French]

Did I help create this monster?

Without trying it, I would think that the recursion would get extremely deep extremely fast, and either actually cause crashes or cause some sort of safeguard in the AppServer to kick in and stop if from doing what you expect. Or maybe safeguards just make it work okay.

I think that in theory recursion can always be represented as a loop, and loops can always be represented as recursion, so maybe the actual work by the AppServer isn't recursing deeply?

One trick you might be able to use to prevent super-deep recursion would be to do some work that takes a little while. E.g. if you trigger an autofill that does a database query that takes about 0.5 seconds reliably, you know you won't get deeper than 10 levels of recursion, but you're precision isn't getting much worse either. But that's still using up somebody's resources (on a database server), and I certainly wouldn't expect it to be reliable and consistent.

Or did you already slip in some kind of "do some work" that I didn't notice? I would think the expression comparison would take extremely small resources, but maybe it takes up enough time that it limits the recursion depth.

I'm really curious to hear more about whether this, as built, seems to create any problems, or if it just works okay, why is it working okay?