Introduction
Sometimes we need to stop processing our workflows and wait for example to check a process in a guest every few seconds. But vRealize Orchestrator gives us two options. We can use Sleep task or use Waiting timer/Wait until the date that will suspend workflow and schedule resume when you want. But what are the differences? When should we use the sleep tasks, and when suspend the workflow? In this article, I am going to answer those questions. We will also run a simple test workflow to show how it works in practice.
Sleep vs Waiting timer
vRO gives us two ways to pause a workflow if you want to wait for a certain amount of time. First is a JavaScript function called System.sleep(). It is probably the most common use for short pauses. The second option is to use the Waiting timer block in vRO (or Wait until the date block, but generally similar). But what is the difference? The main difference is in the amount of resource that is used for waiting.
System.sleep() function will wait, and it means that it will use memory and CPU cycles for that. One thread per sleep task. What if you run ~100 workflows, and they will have a sleep function for 10 seconds? 100 threads will use CPU for 10 seconds just for waiting. Remember that there is a limit to the number of active workflows. That’s why we don’t want to use our resources while waiting. And we come to option number two.
The waiting timer is more specific. It saves our resources because our workflow is suspended and saved to the vRO database. Then, when the time has come, it will be woken up again. vRealize Orchestrator uses one thread for all workflows that are in waiting for state. So if we need to wait for something for a long time, for example, user interaction, mail, or a process in guest, we can save many resources using that approach.
If we look at the VMware Orchestrator Coding Design Guide (you will find the link in Resources at the end of the article). We can find such explanation:
- For short sleeps, you only need to do a System.sleep to avoid serializing and deserializing the workflow inputs, attributes, and so on.*
- Sleeping for an extended period of time should be done with a workflow sleep, by using a Waiting Timer versus a sleep within a scriptable task.
*Serialization is a mechanism of converting the state of an workflow memory into a file. Deserialization is the reverse process where the objects are recreated in memory.
Let’s do a short test
I have prepared a short workflow that will use a System.sleep() function or Waiting timer depends on what we want. The workflow does nothing. Just increase the counter from 1 to 20 and wait for 10 seconds. I am not going to explain every block here because we will build your extended sleep workflow later. Fortunately, vRO gives us performance statistics for workflows run, and we will use it here.
Workflow performance that uses System.sleep():
Workflow performance that uses Waiting timer:
How to build your own Extended sleep workflow for future use
So now, we can see that it does matter. So definitely, we should use a Waiting timer for longer breaks. Unfortunately, we cannot do that as an action because we have to drag the Waiting timer block into the canvas. So, we need to create a workflow to use it later. We can find such workflow somewhere on VMware sites or blogs. Below I will explain step by step how you can build extended sleep workflow yourself. It is straightforward.
We need some inputs to workflow:
– delay(number) – How many seconds we want to wait.
Also we need to define some variables:
– schedulerDate (Date) – When we want to wake up our workflow if sleep if long enough.
– errorCode (string) – String used to throw an error.
First element is a simple Decision element that check if delay is greater than 5 seconds (you can modify time if you need).
If a delay is lower or equal than 5 seconds we are going to scriptable task called “Simple sleep”.
Inputs:
– delay(number)
//Use system sleep;
System.log("Sleeping for: " + delay + " seconds.");
System.sleep(delay*1000);If a delay is greater than 5 seconds workflow will go to “Set scheduler date” scriptable taks.
Inputs:
– delay(number)
Output:
– schedulerDate (Date)
System.log("Delay is greater than 5 seconds. Scheduler will be used.");
var schedulerDate = new Date((new Date()).getTime() + delay * 1000);We add a Waiting timer element.
Input:
– schedulerDate (Date)
And we need to bind Exception handling to our variable errorCode.
Why do we need to do that, and what are we going to do next? Imagine that you have paused your workflow for 2 minutes, and in the meantime, the vRO server has been restarted. Let say tath vRO server starts after the date that workflow should run. What will happen? Waiting timer block will throw an error (“Timeout on signal“) if the time is in the past. It means that we have to handle that and resume our workflow. And that we will do in the next part of our Extended sleep.
So if the waiting timer will throw an error, it goes to a simple Decision element called “Check error code.” Here we check if the error code is “Timeout on signal.” If not, we are going to finish the workflow with an error. If yes, we move forward and check the date in the next Decision element called “Expired or not”:
Input:
– schedulerDate (Date)
if (schedulerDate > new Date())
{
System.log("Workflow resumed and still waiting for execution.");
return true;
}
else
{
System.log("Workflow scheduler date expired.")
return false;
}Resources
VMware Orchestrator Coding Design Guide.
Extended sleep workflow.
Summary
That’s it!. As you can see, in that way, we can nicely optimize our workflows and reduce the usage of vRO resources.
BlanketVM 