In my previous blog post I discussed details about the App Orchestration workflows and gents. In this blog I will be covering more details about the specific workflows that the App Orchestration Technology creates.
Changes in the desired state trigger the creation of workflows. A workflow consists of one or more steps. The same step type could be included in different workflows. For example, a step might deal with moving machines to an OU. This step could be part of the farm allocation workflow or it could be part of the machine decommissioning workflow. In both cases, machines need to be moved to some OU, but the step is really the same with different parameters (different machine names, different target OU).
Some workflows only contain one step. In this case referring to the workflow name or the step name indicates the same operation, but the implementation is still the same. In future versions, more steps might be added to an existing workflow.
The following is the complete list of workflows that can be triggered by the App Orchestration engine:
1. OU structure
2. Machine capability
3. Workload machine metadata
4. Workload machine validation
5. Get farm information
6. Farm allocation
7. Workload machine allocation
8. Update worker group
10. Workload machine de-allocation
11. Remove application
12. Update Web Interface sites
13. Remove a farm from a web interface site
14. Remove Web Interface sites
15. Remove infrastructure machine
16. Remove controller machine
17. Remove workload machine
18. Remove workload
The following is the list of step types that a workflow might contain:
You might notice that the step names follow a similar name convention as PowerShell cmdlets. The App Orchestration Agent maps each step to a cmdlet name that is loaded as part of its PowerShell module. Having the step name match closely to the cmdlet name makes it easier to modify any default implementation, as described in my previous blog. Note that the agent module adds a prefix to the verb part in order to follow the PowerShell guidelines when constructing cmdlet names. So for example, the Get-Capability step is implemented by the Get-CamCapability cmdlet.
The first workflow you will encounter is the “OU structure” workflow. It typically has the Update-OU step which is intended to verify that the specified OUs exist. In this case, the OUs that need to be created are the import OUs, which is where the machines need to be dropped in order to be imported to the system.
When the App Orchestration agent detects machines in any of those OUs, the “Machine capability” workflows are created for each machine. This workflow has the Get-Capability step which runs an image analyzer tool in order to identify the capabilities of the machine. These capabilities are built according to the software that is installed in the machine. For example, there are capabilities that identify XenApp and Web Interface machines. The actual content of the capabilities is only used internally for validation purposes.
After a machine is imported and its capabilities validated, depending on the type of the machine, a different workflow is created. In the case of workload machines, the “Workload machine metadata” workflow is created next. This workflow is only assigned to the first machine of its catalog. It contains the Get-Metadata step which works similar to the Get-Capability step. The image analyzer tool is run in order to extract even more details about the machine. In this case, an inventory of all the applications available in the start menu is built, including the icon and file type association data. When this workflow completes, the data returned is stored in the corresponding Workload catalog and it will be used to validate other machines that are added. This is done with the “Workload machine validation workflow”, which contains the Compare-Metadata step. This step contains part of the data returned by the Get-Metadata step that ran on the first machine of the catalog. The step validates that all the data in the new machine matches the expected values.
In the case of importing XenApp controller machines, the “Get farm information” workflow is created. This workflow contains the Get-FarmInformation step. This step retrieves the farm name, the controllers in the farm and the database information. Every controller will be assigned this step. When the App Orchestration engine receives the data for all controllers in a farm, then a farm object is created. At this point one of the controller agents is assigned as primary. Only this agent will be assigned workflows that are to configure the farm. The other controller agents will act as backups and will be used if the primary agent is down.
In the case of Web interface machines, no other workflows are created at this point. Assuming that all workflows completed successfully all the machines are now ready to be allocated to workloads.
Up to this point, all workflows were assigned to the App Orchestration agent that runs in the same box as the App Orchestration Engine. However, the Get-FarmInformation step is targeted to the agent running in the XenApp controller machine. In general, workflows that are specific to a product will be assigned to the specific agents.
In the next blog I will continue describing the workflows that handle the allocation of machines.
This blog is part of a series on app orchestration. For the rest of the articles in this series please refer to these articles:
• Provisioning machines. Part 1 and 2
• Managing Tenants (coming soon)
• Managing Advertisements
• Managing Subscriptions (coming soon)
• Patching Workload Machines (coming soon)
• Understanding Workflows. Part 1, 2 and 3
• Troubleshooting (coming soon)
• Integration with CloudPortal Services Manager (coming soon)