Agent Upgrade and Plug-in Deployment Provisioning
You can use API commands for various upgrade activities on Agents, including Agent upgrades and plug-in deployments.
The following table lists the various activities that the provision upgrade group of API commands supports.
|
|
Control-M/Agent |
Control-M Managed File Transfer (MFT) |
Control-M Application Pack |
|---|---|---|---|
|
Upgrade to a new version |
Yes |
Yes |
Yes |
|
Roll back to a previous version |
Yes |
Yes |
Yes |
|
Install new plug-in on an existing Agent |
NA |
Yes |
Yes |
|
Remove plug-in from an Agent |
NA |
Yes |
No |
You must obtain the Agent installation packages for the upgrades and place them in the <EM_HOME>/AUTO_DEPLOY directory before the provision process. You must also ensure that the <EM_HOME>/CM_DEPLOY directory contains packages that are available for deployment from your Control-M MFT and Control-M Application Pack installations. For more information about preparing the packages, see Preparing Installation Packages for Agent Upgrades.
The Provision service offers the following commands for upgrade processes:
-
provision upgrades:versions::get: Obtains a list of available upgrades based on the installation packages in your directories.
-
provision upgrades:agents::get: Obtains a list of Agents in your environment that are eligible for an upgrade.
-
provision upgrade::install: Transfers a deployment package and installs it.
-
provision upgrade::uninstall: Rolls back an upgrade deployment package at the target Agent.
-
provision upgrade::get: Obtains status details for a specific upgrade activity.
-
provision upgrades::get: Obtains status details for all upgrade activities or for multiple upgrade activities based on specified filters.
-
provision upgrade:output::get: Retrieves output log messages from the Agent regarding a specific upgrade activity.
-
provision upgrade::retry: Retries to run an upgrade activity that failed previously.
-
provision upgrade::delete: Deletes the record of an upgrade activity that finished running.
-
provision upgrade::cancel: Aborts an upgrade activity that is currently running.
provision upgrades:versions::get
The provision upgrades:versions::get command enables you to obtain a list of available upgrades based on the installation packages currently stored in the following directories:
-
Control-M/Agent Packages: <EM_HOME>/AUTO_DEPLOY
-
Control-M MFT and Control-M Application Pack Packages: <EM_HOME>/CM_DEPLOY
-
CLI
-
REST
ctm provision upgrades:versions::get
The following example shows the REST API syntax for the provision upgrades:versions::get command in cURL.
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token" #for a session token
curl -H "$AuthHeader" $endpoint/provision/upgrades/versions
To select the AuthHeader value ("Authorization: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.
Response
The following example shows a response that lists all available upgrades according to type (Agent, MFT, or AppPack) and target version:
[
{
"type": "Agent",
"version": "9.0.18.200"
},{
"type": "AppPack",
"version": "9.0.18.100"
},{
"type": "MFT",
"version": "9.0.18.100"
}
]
provision upgrades:agents::get
The provision upgrades:agents::get command enables you to obtain a list of agents in your environment that are eligible for upgrade with any of the packages in your directories. You can optionally limit the list to upgrades of a certain type (Agent, MFT, or AppPack) and target version.
-
CLI
-
REST
ctm provision upgrades:agents::get [-s "<query string>"]
The following example shows a command that returns details for agents that can be upgraded to version 9.0.20.200:
ctm provision upgrades:agents::get -s "type=Agent&version=9.0.20.200"
The following example shows a command that returns details for agents where Control-M MFT can be deployed:
ctm provision upgrades:agents::get -s "type=MFT"
The following example shows the REST API syntax for the provision upgrades:agents::get command in cURL.
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token" #for a session token
curl -H "$AuthHeader" "$endpoint/provision/upgrades/agents?type=Agent&version=9.0.20.200"
To select the AuthHeader value ("Authorization: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.
where <query string> can contain any of the following fields:
|
Field |
Values |
|---|---|
|
type |
Determines the upgrade type. Valid Values:
|
|
version |
Determines the target upgrade version, such as 9.0.20.200 or 9.0.21.000. |
Response
The response provides details for each agent and each possible upgrade.
The following example shows one agent that is eligible to upgrade from version 9.0.00 to version 9.0.18.100. The same Agent is
200: Response - UpgradeAgentInfoList
[
{
"agent": "vw-one-ae65",
"ctm": "vw-one-ae65",
"type": "Agent",
"platform": "windows_x86_64",
"fromVersion": "9.0.00",
"toVersion": "9.0.18.100"
},{
"agent": "vw-tlv-one-ae65",
"ctm": "vw-tlv-one-ae65",
"type": "MFT",
"platform": "windows_x86_64",
"fromVersion": "",
"toVersion": "9.0.18.000"
}
]
provision upgrade::install
The provision upgrade::install command enables you to transfer a deployment package to the agent host and installs it there. Use this API command for any of the following activities:
-
Upgrade an Agent to a newer version.
-
Install a new Control-M MFT or Control Application Pack plug-in on an existing Agent.
-
Upgrade a Control-M MFT or Control Application Pack plug-in on the Agent.
-
CLI
-
REST
ctm provision upgrade::install <server> <agent> <type> <version> [activityName] [-f <configuration file>]
The following example shows the REST API syntax for the provision upgrade::install command in cURL.
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token" #for a session token
curl -H "$AuthHeader" -H "Content-Type:application/json" -X POST
--data "@installConfigurationFile.json" $endpoint/provision/upgrade/install
The path to the configuration file is prefixed with an @ character.
To select the AuthHeader value ("Authorization: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.
The following table describes the provision upgrade::install command parameters.
|
Parameter |
Description |
|---|---|
|
server |
Defines the name of the Control-M/Server. |
|
agent |
Defines the Agent hostname or alias. |
|
type |
Determines the upgrade type: Valid Values:
|
|
version |
Determines the target upgrade version, such as 9.0.20.200 or 9.0.21.000. |
|
activityName |
(Optional) Defines a name for this upgrade activity. This activity name must be unique, and cannot be used in more than one ongoing upgrade activity. If you do not specify an activity name, the default activity name is <server>, <agent>, <type>. |
|
configuration file |
(Optional) Defines the pathname to a JSON file that contains the installation details. If you upgrade the Agent to version 9.0.21, you must use a configuration file and set the mandatory javaHome parameter. For more details about this configuration file, see Configuration File for Provision Upgrade or Rollback. |
If annotation is enabled for the Configuration Management category in the CCM or Configuration domain, you must also provide an annotation to justify your action. For more information, see Annotation Input.
Configuration File for Provision Upgrade or Rollback
If you run a REST API command, specify in the configuration file the values of the various upgrade parameters or rollback parameters (which can be included in a CLI command). These parameters include several required parameters (server, agent, type, and version) and the optional activityName.
You also need a configuration file if you specify values for additional parameters. These parameters cannot be included in the CLI command.
The following table describes additional provision upgrade::install command parameters for the command file.
|
Parameter |
Description |
|---|---|
|
installUser |
Defines the user account to install the package. This parameter is required when all of the following is true:
In all other cases, the system automatically sets the user and ignores any value set with this parameter. Due to JSON character escaping, if the username includes a backslash, each backslash must be doubled (for example, "domain\\userName"). |
|
notifyAddress |
(Optional) Defines an email address list of recipients who receive notifications about the upgrade or rollback process. Multiple email addresses must be separated by a semicolon (;) character. |
|
description |
(Optional) Describes the upgrade activity. |
|
(Optional) Determines the location of the installation files to upgrade the selected Agents or its plug-ins. Valid Values:
Default: False To upgrade from a network location, you must first define the same network location in the Control-M/EM system parameter CentralDeployLocation and the Control-M/Server system parameters CTM_AUTO_DEPLOY_PACKAGE_LOCATION_WINDOWS and CTM_AUTO_DEPLOY_PACKAGE_LOCATION_UNIX. The upgrade fails if you do not define these parameters and you set the useNetworkDeployment parameter to True. This feature requires Control-M/EM version 9.0.21. |
|
|
(Mandatory) Defines the JRE pathname. This feature requires Control-M/EM version 9.0.21. |
If you upgrade Control-M/Agent to version 9.0.21, you must use a configuration file and set the mandatory javaHome parameter.
The following sample configuration file contains all possible parameters, including the optional parameters and the parameters that you can alternatively set with the CLI command:
{
"server": "localControlM",
"agent": "agent1",
"type": "Agent",
"version": "9.0.21",
"activityName": "Agent1 upgrade for localControlM",
"installUser": "user3",
"notifyAddress": "[email protected];[email protected]",
"description": "Upgrading the agent to version 9.0.21"
"useNetworkDeployment": "false"
"javaHome": "C:\\java\\Eclipse_Adoptium_jre-17.0.6.10-hotspot"
}
Response
The installation package is deployed and installed, and an upgradeID is returned. The upgradeID has the following format:
<server>:<activityNumber>
LocalControlM:12
provision upgrade::uninstall
The provision upgrade::uninstall command enables you to uninstall an upgrade deployment package at the target Agent. This API command is applicable for each of the following activities:
-
Roll back the newest version of Control-M/Agent.
-
Roll back the newest version of a Control-M MFT or Control Application Pack plug-in.
-
Remove the Control-M MFT plug-in from the Agent if there is no previous version installed.
-
CLI
-
REST
ctm provision upgrade::uninstall <server> <agent> <type> <version> [activityName] [-f <configuration file>]
The following example shows the REST API syntax for the provision upgrade::uninstall command in cURL.
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token" #for a session token
curl -H "$AuthHeader" -H "Content-Type:application/json" -X POST
--data "@installConfigurationFile.json" $endpoint/provision/upgrade/uninstall
The path to the configuration file is prefixed with an @ character.
To select the AuthHeader value ("Authorization: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.
The following table describes the provision upgrade::uninstall command parameters.
|
Parameter |
Description |
|---|---|
|
server |
Defines Control-M/Server name. |
|
agent |
Defines the Agent hostname or alias. |
|
type |
Determines one of the following types of upgrade that is uninstalled:
|
|
version |
Determines the version to uninstall. |
|
activityName |
(Optional) Defines a name for this upgrade activity. This activity name must be unique, and cannot be used in more than one ongoing upgrade activity. If you do not specify an activity name, the default activity name is "<server>, <agent>, <type>". |
|
configuration file |
(Optional) Defines the pathname to a JSON file that contains the uninstallation details. For more details about this configuration file, see Configuration File for Provision Upgrade or Rollback. |
If annotation is enabled for the Configuration Management category in the CCM or Configuration domain, you must also provide an annotation to justify your action. For more information, see Annotation Input.
Response
The installation package is uninstalled, and an upgradeID is returned. The upgradeID has the following format:
<server>:<activityNumber>
LocalControlM:12
provision upgrade::get
The provision upgrade::get command enables you to obtain status details for a specific upgrade activity.
The response provides the upgrade activity status and various additional details, such as UTC timestamps of certain phases during the upgrade activity.
-
CLI
-
REST
ctm provision upgrade::get <upgradeID>
The following example shows the REST API syntax for the provision upgrade::get command in cURL.
upgradeID="ctm1:3"
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token" #for a session token
curl -H "$AuthHeader" "$endpoint/provision/upgrade/$upgradeID"
To select the AuthHeader value ("Authorization: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.
For more information, see Control-M Automation REST API Reference.
where <upgradeID> is the ID returned by the upgrade activity (install or uninstall).
provision upgrades::get
The provision upgrades::get command enables you to obtain status details for all upgrade activities or for multiple upgrade activities based on specified filters.
The response provides the status of each upgrade activity and various additional details, such as timestamps of certain phases during the upgrade activity.
-
CLI
-
REST
ctm provision upgrades::get [-s "<query string>"]
The following example shows the REST API syntax for the provision upgrades::get command in cURL.
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token" #for a session token
curl -H "$AuthHeader" "$endpoint/provision/upgrades?agent=Agent2&toVersion=9.0.18*"
To select the AuthHeader value ("Authorization: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.
For more information, see Control-M Automation REST API Reference.
The following table describes the fields that you can use in the provision upgrades::get query string.
For multiple values, type commas. You can type ? and * as wildcards.
|
Field |
Description |
|---|---|
|
server |
Defines the name of the Control-M/Server. This field was previously named ctm (deprecated name). |
|
agent |
Defines the Agent hostname or alias. |
|
fromVersion |
Determines the source version before the upgrade activity. 9.0.00.100 |
|
toVersion |
Determines the target version. 9.0.18.200 |
|
acivity |
Determines the upgrade activity type. Valid Values:
|
|
status |
Determines the activity status. Valid Values:
|
|
activityName |
Defines the name of the upgrade activity. |
The following example shows a command that returns status details for upgrades or rollbacks to version 9.0.18 and its fix packs on Agent1 and Agent2:
ctm provision upgrades::get -s "agent=Agent1,Agent2&toVersion=9.0.18*"
provision upgrade:output::get
The provision upgrade:output::get command enables you to retrieve output log messages from the Agent for a specific upgrade activity. The output log messages appear on-screen.
-
CLI
-
REST
ctm provision upgrade:output::get <upgradeID>
The following example shows the REST API syntax for the provision upgrade:output::get command in cURL.
upgradeID="ctm1:3"
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token" #for a session token
curl -H "$AuthHeader" "$endpoint/provision/upgrade/$upgradeID/output"
To select the AuthHeader value ("Authorization: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.
where <upgradeID> is the ID returned by the upgrade activity (install or uninstall).
provision upgrade::retry
The provision upgrade::retry command enables you to retry to run an upgrade activity that previously failed.
The original upgrade activity already has an assigned upgradeID. The retry activity does not create a new one. The response only returns a message that the retry started.
-
CLI
-
REST
ctm provision upgrade::retry <upgradeID>
The following example shows the REST API syntax for the provision upgrade::retry command in cURL.
upgradeID="ctm1:3"
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token" #for a session token
curl -H "$AuthHeader" "$endpoint/provision/upgrade/$upgradeID/retry"
To select the AuthHeader value ("Authorization: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.
where <upgradeID> is the ID returned by the upgrade activity (install or uninstall).
If annotation is enabled for the Configuration Management category in the CCM or Configuration domain, you must also provide an annotation to justify your action. For more information, see Annotation Input.
provision upgrade::delete
The provision upgrade::delete command enables you to delete the record of an upgrade activity that finished running. The upgrade activity status is either Completed, Canceled, or Failed.
-
CLI
-
REST
ctm provision upgrade::delete <upgradeID>
The following example shows the REST API syntax for the provision upgrade::delete command in cURL.
upgradeID="ctm1:3"
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token" #for a session token
curl -H "$AuthHeader" -X DELETE "$endpoint/provision/upgrade/$upgradeID"
To select the AuthHeader value ("Authorization: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.
where <upgradeID> is the ID returned by the upgrade activity (install or uninstall).
If annotation is enabled for the Configuration Management category in the CCM or Configuration domain, you must also provide an annotation to justify your action. For more information, see Annotation Input.
provision upgrade::cancel
The provision upgrade::cancel command enables you to abort an upgrade activity that is running. The upgrade activity status is Running or TransferCompleted.
-
CLI
-
REST
ctm provision upgrade::cancel <upgradeID>
The following example shows the REST API syntax for the provision upgrade::cancel command in cURL.
upgradeID="ctm1:3"
AuthHeader="x-api-key: $token"
# AuthHeader="Authorization: Bearer $token" #for a session token
curl -H "$AuthHeader" -X POST "$endpoint/provision/upgrade/$upgradeID/cancel"
To select the AuthHeader value ("Authorization: Bearer $token" or "x-api-key: $token"), see Authentication Tokens.
where <upgradeID> is the ID returned by the upgrade activity (install or uninstall).
If annotation is enabled for the Configuration Management category in the CCM or Configuration domain, you must also provide an annotation to justify your action. For more information, see Annotation Input.
