In reviewing the API documentation App Orchestration, I realize that there is a missing section: page explaining how extend the AO agents somehow was missed when compiling the documentation on the product.
So now I present "missing manual" for the 2.0 AO workflow extension mechanism officer. We will ensure that this is included in the in-product Help for the next version of AO
API Documentation - Supplemental :. Extension Agent Functionality
App Orchestration performs the configuration on the products and components it manages by running workflows on agents. Each task or change administrative configuration can cause one or more workflow running, potentially across multiple product areas and data centers. App Orchestration manages the programming of these workflows, and the dependencies between them.
The workflow logic is implemented as PowerShell functions on machines running agents App Orchestration. Each PowerShell functions can be extended or overridden.
Extension workflow function
Create and sign your own PowerShell script files with definitions of functions that provide your workflow customizations, as described below.
Then, place this script in a file on all machines of the agent in the workflow; for example, if the workflow is executed by XenDesktop delivery controllers, place the script on all delivery controllers in the site (s) of delivery where you want your change to take effect.
Configure agents on these machines to pick up the script override by setting the path to the folder where it is located:
Import-Module Set-CitrixCamAgent CamAgentConfiguration -ExtensionsFolderPath [Path] Restart-Service CitrixCamAgent
the agent will now perform your duties when running workflows.
Adding synchronous actions
This is the best way to extend the integrated workflows because it offers a high level of compatibility between versions. If the integrated workflow logic is changed in a future version of App Orchestration, your override will continue to operate without affecting the new logic
Examples :. Logging before or after a workflow executes, or call March 1 rd component party to make some additional actions that quickly supplement.
You can provide a function that executes before workflow logic, naming it with the verb Initialization and specifying the name of the workflow (without dashes ) the name.
For example, to run your own logic before the workflow "Update-OR", create a function named Initialization-UpdateOU .
You can also provide a function that executes after workflow logic, naming with
specifying the name of the workflow (without dashes) as the name. For example, to run your own logic after the workflow "Update-OR", create a function named Complete-UpdateOU .
These functions should take as input the workflow data and should return $ True to indicate that the integrated logic can continue to run, according to this model:
Function Initialization-UpdateOU {[CmdletBinding()] param ([Parameter(Mandatory = $true, Position = 0, ValueFromPipeline = $true)] [PSObject] $ WorkflowStep) process (# Your logic to be executed before the logic high-return $ True)} function full-UpdateOU {[CmdletBinding()] param ([Parameter(Mandatory = $true, Position = 0, ValueFromPipeline = $true)] [PSObject] $ WorkflowStep) process (# Your logic to run after the high logic return $ True)} If the integrated logic changes, override the script will work with the new changes automatically.
Adding long-term actions
This method override workflow is more complex, but still provides a high level of compatibility between versions. If the integrated workflow logic is changed in a future version of the App Orchestration, your override will continue to operate without affecting the new logic.
When this differs Adding synchronous actions is that the new logic you add can take an arbitrary amount of time to complete
Eg .. meanwhile human intervention before the stream continuously working, integration with e component 3 of the party that takes an indefinite amount of time to complete
to do this, your application must be able to know when it is ongoing, and when he finished. You can make long term operations before or after the integrated workflow logic using Initialization and full verbs based on substitutions, as described in Adding synchronized actions. However, you can return $ False to indicate that your action is long race and has not yet finished.
Function Initialization-UpdateOU {[CmdletBinding()] param ([Parameter(Mandatory = $true, Position = 0, ValueFromPipeline = $true)] [PSObject] $ WorkflowStep) process (if (! (IsStarted $ WorkflowStep)) {StartMyProcess} if (! (IsComplete $ WorkflowStep)) {return $ False} return $ True)} in this example, you would need to provide the implementation of the functions isStarted StartMyProcess and IsComplete .
Whenever your tax override function $ False , it may take 5 minutes or more before being interviewed again to determine the end.
Replacing a function of workflow
This is the most difficult method to extend the workflow functionality. It has two major challenges:
-
The integrated logic for workflow is often very complex. change can have unintended consequences on the ability of the App Orchestration to ensure the accuracy of the configuration.
-
The adoption of new versions of Citrix App Orchestration components will be difficult, as any new feature to be emulated or extended by your manually replace.
However, there may be cases where the extent of customization you want requires this approach. It gives you maximum flexibility in how the workflow runs.
The best approach to do this is to start by finding the integrated workflow logic. It is
located in
% Program Files% Citrix CloudAppManagement Agent CitrixCamAgent
Search the files in it directory to the point of the function of input workflow. Workflow functions Cam prefixed to the name of the function name; for example, the workflow "Update-OR" is located in a function called Update-CAMOU .
Then copy this logic in your own function with the same name, and where necessary to twist your customizations. Keeping your small changes is the best way to minimize the risk of unintended consequences elsewhere in the App Orchestration configuration system.
While your function has the same name and signature, and exists in the ExtensionsFolderPath configured as described in Extension function workflow, the agent will use your function instead the integrated logic.
0 Komentar