- VMware vRealize Orchestrator Cookbook Second Edition
- VMware vRealize Orchestrator Cookbook Second Edition
- Credits
- About the Author
- About the Reviewers
- www.PacktPub.com
- Preface
- 1. Installing and Configuring Orchestrator
- 2. Optimizing Orchestrator Configuration
- Introduction
- Tuning the appliance
- Tuning Java
- Configuring the Kerberos authentication
- Configuring access to the local filesystem
- Configuring the Orchestrator service SSL certificate
- Orchestrator log files
- Redirecting Orchestrator logs to an external server
- Backup and recovery
- Control Center titbits
- 3. Distributed Design
- Introduction
- Building an Orchestrator cluster
- Load-balancing Orchestrator
- Upgrading a cluster
- Managing remote Orchestrators
- Synchronizing Orchestrator elements between Orchestrator servers
- 4. Programming Skills
- Introduction
- Version control
- Changing elements in a workflow
- Importing and exporting Orchestrator elements
- Working with packages
- Workflow auto documentation
- Resuming failed workflows
- Using the workflow debugging function
- Undelete workflows and actions
- Scheduling workflows
- Sync presentation settings
- Locking elements
- 5. Visual Programming
- 6. Advanced Programming
- Introduction
- JavaScript complex variables
- Working with JSON
- JavaScript special statements
- Turning strings into objects
- Working with the API
- Creating actions
- Waiting tasks
- Sending and waiting for custom events
- Using asynchronous workflows
- Scripting with workflow tokens
- Working with user interactions
- 7. Interacting with Orchestrator
- Introduction
- User management
- User preferences
- Using Orchestrator though the vSphere Web Client
- Accessing Orchestrator REST API
- Accessing the Control Center via the REST plugin
- Running Orchestrator workflows using PowerShell
- Using PHP to access the REST API
- 8. Better Workflows and Optimized Working
- 9. Essential Plugins
- 10. Built-in Plugins
- Introduction
- Working with XML
- Working with SQL (JDBC)
- Working with SQL (SQL plugin)
- Working with PowerShell
- Working with SOAP
- Working with Active Directory
- Working with SNMP
- Working with AMQP
- 11. Additional Plugins
- 12. Working with vSphere
- 13. Working with vRealize Automation
- Introduction
- Working with the vRA-integrated Orchestrator
- Automating a vRA instance in Orchestrator
- Configuring an external Orchestrator in vRA
- Adding Orchestrator as an infrastructure endpoint
- Adding an Orchestrator endpoint
- Integrating Orchestrator workflows as XaaS Blueprints
- Managing AD users with vRA
- Using the Event Manager to start workflows
This is a recipe that will make you wait for it...
There are two different kinds of wait tasks, tasks that wait for a duration and tasks that wait for a specific date and time until they proceed.
We need to create an action to help us track time. It will just log the current date and time. The action already exists in the action folder com.packtpub.Orchestrator-Cookbook2ndEdition.helpers:
- Create a new action and call it
getNow. There is no need to define any in- or out-parameters. - In the script section, place the following script:
var current = new Date(); System.log(current);
- Create a new workflow.
- Drag a Sleep task onto the schema and create the
sleepTimein-parameter as input for the workflow. - Add the
getNowaction we have just created before and after the Sleep task. - When running the workflow, check the log. You will notice how the workflow will wait for the allocated seconds.
- Create a new workflow.
- Drag a Wait until date task onto the schema and create the
waitDatein-parameter as input for the workflow. - Add the
getNowaction we have just created before and after the Wait until date task. - When running the workflow, check out the log. You will notice how the workflow will wait until the allocated date and time:
A wait task will pause the workflow execution for a certain amount of time. The main difference between a Sleep task and a Wait until task is the amount of system resources that are used for waiting.
The Sleep task will just wait; however, it will still require memory and one thread per sleep task. The Wait until task is more specific in how it saves system resources. When the Wait until task starts, the workflow is saved to the Orchestrator database and is woken up again on the specified date and time. Orchestrator uses a single thread to deal with the all the workflows that are set to wait until a certain date/time. This preserves quite a bit of resources.
This leads us directly to the most important usage for wait tasks, long-running workflows. If a workflow is running for a long time, such as polling for new e-mails or waiting for a user interaction, a wait task can reduce the amount of system resources consumed during the wait period.
There are actually two waits for date tasks, one in Generic called Waiting timer and the other in Basic called Wait until date. Both are essentially the same.
The JavaScript commands for waiting are System.sleep([milliseconds]) and System.waitUntil([Date],[Number of milliseconds]).
Please note that the sleep command works with milliseconds, whereas the Sleep schema element works with seconds.
The waituntil command has two inputs: the date and the number of milliseconds. The milliseconds define the delay time between two checks to see whether a certain date has been reached. Also, the command returns a Boolean value that is true when the wait has finished.
-
No Comment