3. Triggering Workflows with vCloud Notifications : 3.6 Triggered Workflow Examples : 3.6.1 Example of a Workflow Approval: Approve vApp (Simple)
   
3.6.1 Example of a Workflow Approval: Approve vApp (Simple)
The Approve vApp (Simple) workflow is a good example of the different mechanisms involved to gather information from blocking tasks, make decisions, and then take action.
Figure 16. Workflow Schema: Approve vApp (Simple)
 
The Workflow Runner workflow automatically populates the input parameters listed in the following table.
Table 10. Workflow Inputs: Approve vApp (Simple)
Parameter
Detail
vApp
The vApp to be approved.
user
The user who provisioned the vApp.
blockingTask
The blocking task for the vApp instantiation.
 
3.6.1.1. Workflow Steps
1. Change the blocking task timeout to the one set in the configuration (to avoid timeout of the blocking task before it can be handled).
2. Get as much information as possible on the vApp and its child virtual machines. Because the vApp does not exist yet its object may not contain all of the expected information. This information is compiled in a content attribute.
3. Set an email subject to vApp Request [vAppName] has been requested by user [username]”.
4. Determine whether this organization was set for auto approval. If so, resume the blocking task.
5. If the organization is not set for auto approval, set the approvers (either a single email or set to use the organization administrators, and get their email addresses).
6. Send a notification email for the approval. The approval can be done from the vCenter Orchestrator client or from the vSphere Web Client.
7. Generate a user interaction waiting for approval.
8. Send a last notice email if the user interaction times out. Fail the blocking task if the last notice email was previously sent.
9. If the user interaction is approved then resume the blocking task. Otherwise fail the blocking task.
The other approval workflows are built on the same base.
3.6.1.2. Error Handling
Avoid a looping situation where the triggered workflow generates a message that triggers the workflow again. There are different techniques for avoiding this problem:
*The workflow might have started the vCloud operation using a different user, so the triggered workflow should resume the blocking task when the user configured for vCenter Orchestrator in vCloud Director is used.
*Use metadata to set a defined key value pair on the task that should be resumed if blocked, and check incoming tasks for it.
The package also contains a helper category that contains the following useful workflows:
*Abort, fail, or resume all blocking tasks – Allows unblocking all tasks for a given vCloud Director host at the same time.
*Remove all AMQP brokersRemove all brokers that have been added in the vCenter Orchestrator inventory.
*Remove a vCloud Director notification subscriptionDelete a subscription and all of its queues.