Handling Blocking Tasks Messages
Blocking tasks messages have similar identifier with the object being the blocking task. The blocking task references:
Its parent task – The suspended task referencing the object and the task parameters attributes it was set with in the original request.
TaskOwner – The object on which the task operates.
The actions that can be taken on this blocking task (resume, abort fail, updateProgress).
Receiving and acting upon on the blockings task is accomplished with the vCloud director API callbacks. System admin privileges are required to perform these operations.
Aborting a task returns a success status. It should be done only:
If the requested vApp went through automatic approval logic and was disapproved.
To replace an operation to be carried out by another one. For example, start a pre-provisioned vApp instead of provisioning a vApp.
When it is required that parameters for a requested task be replaced. For example, when determining a specific virtual datacenter for a vApp based on placement logic
When calling the same operation as the one that triggered the notification routing and filtering must be properly configured to avoid creating a loop.
A task should be failed when the operation occurring before the task is determined to fail. An example is an operation required before running the task failed. For example, CMDB was not reachable.
The task must be resumed for operations that must complete before the next task starts. Examples include:
OVF user information must be added to a vApp before adding a vApp to catalog.
Requested vApp goes through automatic approval logic and was approved before being added to vCloud.
Change request must record the object state in CMDB system before making change.
Task progress should be updated to avoid having the task time out, or to log a status message to the user.