VCAC Workflows – The State Transition Blocking Pattern.
The above image shows the Master Machine State workflow (every machine within the vCAC Inventory has one) go through its natural lifecycle states, from being requested by the user, through approval, provisioning the machine, management and finally disposing.
Between each state transition the policy engine within VCAC decides which set of prioritised workflow(s) to execute in that given state, ie: a declarative rule can be added to say “for all Production Windows VMware Servers” update a CMDB and then initiate a Zerto backup procedure for example.
- VMware Cloud Automation Center allows for repository workflows to be executed at any given machine state & on receipt of custom events. Both of which are used as part of the Blocking pattern described below.
- Repository workflows can be created simply using the Workflow Generation wizard in the Cloud Development Kit
Normal Workflow Execution Flow
Basic Process flow overview:
- The Master Machine Workflow decides a child workflow is required to run at the given state
- A Child State Workflow is instantiated and checks out (version controlled) the given workflow to actually execute from the repository
- The Repository Workflow is instituted by the Distributed Orchestration agent for further policy based processing (ie: which location to run the workflow or which security domain etc)
- The Distributed Execution agent runs the repository workflow and processes the required logic
- Response (Success/Failure) is returned back from the repository workflow to the Child State Workflow
- The Child State Workflow responds to the Master State Workflow which may execute another child or move on to the next State.
The Blocking Pattern
To block the return call from the repository workflow to the child state workflow use the VCAC Cloud Development Kit & the Design Center Tool or Visual Studio.
How to perform this
1) In Design Center open the workflow and remove the SetWorkflowResult Activity
2) The ExternalWorkflowId is the Child State Workflow Id (a System.Guid type), this now needs to be persisted with the VirtualMachine. This can be done by adding a VirtualMachineProperty object, use the SetMachineProperty Activity.
3) The Repository Workflow has then completed & now left the Child State Workflow blocked. This means even if the DEM agents stop running mid processing whilst a 3rd party system does its task there is no loss of data/state. Now we need to unblock the workflow.
4) Using the technique posted in this blog an event driven workflow can be started. The difference though is the the event xml will look like this:
<entityEvent create=”1″ update=”0″ delete=”0″ entity=”VirtualMachineProperty“ model=”ManagementModelEntities” workflow=”UnblockVirtualMachineWorkflow“>
This is saying that if a new VirtualMachineProperty is added into the Database with the PropertyName having a value of UnblockVirtualMachine then execute the UnblockVirtualMachineWorkflow
An external system (Java, Microsoft C#, Powershell etc) can then insert a new VirtualMachine property (if they have appropriate security rights) which in turn will cause a new workflow called “UnblockVirtualMachineWorkflow” to run.
5) A new workflow UnblockVirtualMachineWorkflow will need to be created using the CDK and will require an input Workflow Argument of VirtualMachineProperty as that is the object that invoked the workflow.
From this property you can expand and find the VirtualMachine, look for the other custom property UnblockingWorkflowId which is storing the value of the Child State Workflow. The activity SetWorkflowResult can then be added with the value “new Guid(UnblockingWorkflowId)”. This will unblock the Child State Workflow and normal processing can continue as highlighted in Basic Process flow overview point 5.