A workflow executes its elements along its path one after another. Using asynchronous workflow execution, we can change this behavior and actually execute workflows in parallel.
We will need to build a new workflow.
For the first example, we will reuse the sleep workflow as well as the getNow action we created in the recipe Waiting tasks in this chapter. (06.04.01 Sleep and the com.packtpub.Orchestrator-Cookbook2ndEdition.helpers module in the example pack).
We will see two examples to demonstrate the asynchronous feature.
Here are some basics:
- Create a new workflow and create the following variables:
Name
Type
Section
Use
sleepTimeNumber
IN
It defines the time the workflow should sleep
wfTokenWorkflowToken
Attribute
The workflow token of the asynchronous workflow
- Drag an Asynchronous workflow task into the schema.
- When prompted, enter the name of the sleep workflow we have created in the recipe Waiting tasks in this chapter (
06.04.01 Sleepin the example package). - Now, edit the Asynchronous workflow tasks. The in-parameter is the one from the sleep workflow. Bind it to the
sleepTimein-parameter. - The out-parameter is a
workflowToken. Bind it to thewfTokenattribute. - Drag one
getNowaction on each side of the Asynchronous workflow tasks. - Save the workflow and run it:
Have a look at the execution. The workflow that started the sleep workflow asynchronously has finished (A in the previous screenshot) but the sleep workflow is still running (B). Also, please note that the sleep workflow doesn't write its logs into the main workflow.
This example shows how to combine asynchronous workflows with custom events:
- Duplicate the sleep workflow we created in the recipe Waiting tasks in this chapter (
06.04.01in the example package). - Edit the workflow and add the following variable:
Name
Type
Section
Use
eventNameString
IN
This transports the custom event name
- Add Send custom event after the Sleep task and bind the
eventNamein-parameter to it.
- Save and exit the workflow. Don't run it now.
- Create a new workflow with the following variables:
Name
Type
Section
Use
sleepTimeNumber
IN
Time the asynchronous workflow for when it should sleep.
eventNameString
IN
This is a string that contains an event name.
endDateDate
IN
This is the date/time until the workflow should wait.
SuccessBoolean
Attribute
This is the return value from the wait for a custom event.
wfTokenWorkflowToken
Attribute
This is the return value from an asynchronous task.
isExternalEventBoolean
Attribute
Set to
false. - Drag an Asynchronous workflow task onto the schema.
- When prompted, enter the name of the workflow you have just created (
3.15.2in the example package). - Add a wait for custom event element to the schema as well as some
getNowactions (see the following figure). - Bind the variables to the Asynchronous task and the Wait for custom event element.
- Save and run the workflow. Watch the execution.
You will see that the main workflow will wait until it has received the custom events, which indicates that the asynchronous workflow has finished.
Normally, a workflow executes one element after the other in a serial approach. From time to time, this can mean that your main program has to wait for some other tasks to finish before continuing. Using asynchronous execution, we can make workflows execute in parallel. A typical example is that you clone a VM (which can take a few minutes), and while it clones, you can create a new PortGroup that you can later attach to the cloned VM. To do this, create a new workflow that runs the create VM workflow asynchronously and sends a custom event when it is finished. In the meantime, the main workflow creates the PortGroup and then waits for the custom event to signal that the VM is ready. After the custom event has arrived, you can then map the PortGroup to the VM.
One thing you have to watch out for is a so-called race condition. If you start a workflow asynchronously and in sequence and then wait for the other, you might run into this. If the asynchronous workflow finishes before the sequential does, the event is already sent but nobody is waiting for it, resulting in the fact that the event wait will time out. In this case, you should either use the workflow token (see the recipe Scripting with workflow tokens in this chapter) or add a sleep to the asynchronous task to make sure it finishes after the sequential one. As an example for this, check out the example workflow, 06.06.04 wait for asynchronous (Race condition).