Autodeployment Service
Orchestra Runtime can deploy scenarios, update scenario credentials, and update landscapes without Monitor interaction.
To enable the Autodeployment service, specify a directory on the local file system for Orchestra to look up the files to deploy
(scenario, credential, and landscape files). Change the value of the environment
setting Runtime.autodeployment.dir to point to an empty directory, e.g. D:\Orchestra\Autodeployment.
By default, Orchestra will start polling this directory after restart and will deploy files whenever they occur.
To adjust the polling period, change the value of Runtime.autodeployment.polling.
Deployment File Types
Orchestra recognizes the following file types for autodeployment:
| File Type | Filename Pattern | Description |
|---|---|---|
| Orchestra Scenarios | *.psc for plain scenario files, *.psx for encrypted scenario files (see Licensing) | Scenarios will be deployed automatically when they are initially present. If an older version of a scenario is already deployed on the Orchestra Runtime, it will be used for redeployment. Note that your Orchestra node requires the correct product licenses to deploy encrypted scenarios. To view and redeploy older versions of a scenario, refer to Scenario Details. |
| Credential Configuration | *.cred.xml | User credentials for individual scenarios will be overwritten. This action is currently not possible for internal Orchestra users. Refer also to User Management. |
| Landscape Configuration | *.landscape.xml | The landscape will be applied to already deployed scenarios. You can view these changes and the former state in Landscape History. |
Completion Mode
To prevent deploying the same file multiple times, the Autodeployment service supports two modes for persisting its file state.
Adjust Runtime.autodeployment.mode to change the behavior.
| Completion Mode | Use Case | Description |
|---|---|---|
| External | A single Orchestra instance will be configured by an autodeployment directory. | Processed files will be renamed based on the success of their deployment. After renaming, they will no longer match the filename patterns described above. On success, the suffix .ok will be appended; on error, the suffix .err will be added. |
| Internal | Multiple Orchestra instances will be configured by an autodeployment directory. | The autodeployment service stores its state in the Orchestra runtime database, retaining the names of successfully read-in files along with their hash sums. When reading the same file a second time, the service will recognize that it has already deployed it and will skip it. Old hash sums of the same files are overwritten, allowing you to return to an older state of a scenario. |
Using the internal mode will disable polling on the filesystem.
Recursive Directory Scanning and Automatic Activation of Scenarios
By default, Orchestra ignores subdirectories of your autodeployment directory. Enable Runtime.autodeployment.recursive to scan subdirectories as well. If enabled, there are two specific names for subdirectories that will have a meaningful impact on the deployment of scenario files.
| Directory Name | Description |
|---|---|
| Activate | Scenarios read from this directory will be deployed and activated subsequently. |
| Deploy | Scenarios read from this directory will be deployed only without activating them. |
You can choose any other directory names to organize your deployment files. To determine whether scenarios in those directories should be activated, refer to the environment setting Runtime.autodeployment.activate.