The overall architecture of the App Orchestration Technology was discussed in an earlier blog post in this series. In this blog I will be covering more details of the App Orchestration Technology Workflows and Agents.

A traditional management system is task based, where changes in the managed systems are attempted immediately and any issues must also be resolved at that time. However, App Orchestration implements a desired state system, where changes in the managed systems are performed offline, using workflows. This allows for operations to be retried or even executed again making sure that compliance is achieved.

A workflow in App Orchestration Technology is broken down in steps, where each step could be assigned to a different agent depending on the type and scope of the operation. Typically, there is one App Orchestration Agent in each box that requires configuration changes. For example, there will be an Active Directory agent, a XenApp agent and a Web Interface agent. These agents could be located in any box that has access to the management APIs for the corresponding products. In this release of App Orchestration, the Active Directory agent resides in the same box as the App Orchestration Engine. The XenApp agent resides in each of the XenApp controller boxes. The XenApp session hosts do not require an agent service. Finally, the Web Interface agent resides in the Web Interface box.
Each of the workflow steps generated by the Orchestration Engine component is assigned to specific agents depending on the task to be performed and the scope of the operation. All agents continuously check at configured intervals whether new workflow steps are assigned to their own specific agent instance. The progress in the execution of tasks is reported back to the Orchestration Engine upon start. Any agent could be assigned multiple workflow steps at the same time. The agent is able to execute all the tasks in parallel up to a maximum throttle limit, which is configurable. The default is 20 concurrent tasks.

A task can be long running, but there must be a report of in-process status. Otherwise, when the maximum time allowed expires, the workflow will be aborted. The timeout value is configured and defaults to 60 minutes. When the workflows are not completed, they will be retried again automatically or manually. This is possible because each workflow has been implemented to be idempotent. The configuration could be done partially or even completely. In each case, the workflow only executes what is needed to comply with the desired state.

Another case where workflows are terminated by the agent is when it is not possible to report progress status. When the maximum number of connection failures is exceeded, the agent will terminate all running workflows since it is not possible to report on the state of those tasks anymore. This maximum number of failures is configurable and it defaults to 5 attempts. All these agent runtime options are stored in the registry, but they can be changed using the cmdlet Set-CamAgentConfiguration exported by the CitrixCamAgent module, installed with the agent.

The App Orchestration administrator can monitor workflow execution using the Citrix App Studio console. Different operations are possible depending on the workflow state. Workflows can be cancelled even if the agent has already started processing then. When workflows fail, they can also be re-tried. Depending on the error, sometimes manual intervention might be required, such as granting permissions. In this case re-trying the workflow will let the agent pick-up the workflow again. When the workflows succeed, they are moved into history so that the current number of active workflows remains manageable.

When an agent loses connectivity with the Orchestration Engine, a new agent with the same role will be elected if possible. In this case the original agent will be marked as unavailable and no new workflows will be assigned. If it is possible to resolve the connection issues, the agent will resume polling for tasks, but it will be used as backup only at this point.

All the information that the agent needs to execute a specific configuration task is included with the workflow. Some workflows also require the agent to use specific credentials. However, this information is not included as part of the workflow. In this case, the agent will query the Orchestration Engine for credentials as needed. This request is made over a secure connection (HTTPS).

There is an agent role for the agent that is running in the same machine as the Orchestration Engine. This agent has a built-in workflow that monitors the configured import OUs for new machines to be imported.

Agents that are installed on other machines (such as a XenApp server), do not start polling automatically since all connection attempts will be rejected until App Orchestration adds this machine as a valid agent. This happens after the machine is successfully imported and its capabilities are validated.

The agent includes a PowerShell module that can be used to customize the settings, such as polling interval and task execution timeouts as described above. All the settings map to registry entries that can be configured using policies to propagate these changes to all agent machines. The name of the module is CitrixCamAgent and the cmdlet to configure it is Set-CamAgentConfiguration. Help is available for this cmdlet as well as other agent cmdlets.

It is possible to customize any workflow by overriding the default implementation, or even part of it. The agent module exports several cmdlets and any of those could be customized by loading an extension script file or set of files. The location of these files is also configurable with the Agent module or with a registry key. Please refer to the configuration cmdlet described above.

One example of customization of a workflow has to do with the strict validation of workload machines from a catalog. The default validation ensures that the machines in the catalog are identical in terms of applications installed and also operating system updates, as well as application configurations that could affect launching the application, such as file type associations. To modify this validation, the cmdlet Test-CamWorkloadMachineCapability could be changed to implement a different validation. This cmdlet takes two string parameters with the XML data that is expected and the actual data read from the machine image. The cmdlet then returns any differences between the two. By default they have to be identical, but this rule can be modified if necessary. In the simplest case, we could always ignore any differences by creating a function that doesn’t return anything, as follows:

Function Set-CamWorkloadMachineCapability { }

The new function definition can be saved in a script file (ps1) and saved in any folder. The agent can then be configured to load any script files in this folder by using the Set-CamAgentConfiguration cmdlet. The new implementation will be used instead of the original one. Note that the machine script execution policy might require changes in order to load unsigned scripts. This can be done with the Set-ExecutionPolicy cmdlet.

Note that the above case is just for illustration and is not recommended since it is very important that all machines in a catalog are identical in order to guarantee a consistent user experience regardless of the specific machine used to delivery an application or desktop. More details on other customizations will be explained in another post.

In future posts I will cover more detailed customizations and explain the implementation of specific workflows.

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 (this article) 2 and 3
• Troubleshooting (coming soon)
• Integration with CloudPortal Services Manager (coming soon)