New Documentation

   

Control-M Automation API Documentation has moved to a new location, with a new design to enhance ease of use.

Deploy service

The deploy service allows you to transfer job and configuration definitions to Control-M. Once a job is deployed, it will be scheduled by Control-M according to its scheduling criteria and dependencies. The deploy overwrites any existing definition of the same name.

deploy

Deploy the provided definitions file to Control-M. Build will take place as part of the deploy to ensure code validity. deploy can receive definitions files for folders, jobs, calendars, or site standards in .json format, or a package of multiple definition files in .zip or .tar.gz format.

The response to the deploy command is the same as the response to the build command. The response summarizes the numbers of various elements created (such as folders and jobs), indicates whether a Deploy Descriptor is applied, and provides validation error messages if site standards are applied and validations are strictly enforced.

CLI Syntax

CLI
ctm deploy <definitionsFile> [deployDescriptorFile]

Parameter

Description

<definitionsFile>

The definitions file name

Valid file formats are:

  • .json format
  • .zip or .tar.gz

[deployDescriptorFile]

(Optional) The file that includes the rules to apply on the original definitionsFile. The rules enable transforming Control-M JSON code properties. For detailed information, see Deploy Descriptor.

If annotation is enabled for the Scheduling definitions, Configuration management, or Control-M security category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation input.

REST API Syntax

See REST API reference.

Example using  curl:

curl -H "x-api-key: $token" -X POST  -F "definitionsFile=@examples/AutomationAPISampleFlow.json" 
-F "deployDescriptorFile=@examples/deployDescriptor.json"  "$endpoint/deploy" 

deploy poll

If deployment takes longer than expected to update the Control-M database server, the response returns a poll ID and a deployment status. This occurrence is called an asynchronous deployment, and enables you to continue working while the asynchronous deployment continues in the background. To get an update of the deployment status, run the deploy poll command. Any user that has the required privileges can run the deploy poll command.

NOTE: The asynchronous deployment times out after 20 seconds.

CLI Syntax

CLI
ctm deploy poll <pollId>

REST API Syntax

See REST API reference.

Example using curl:

curl -H "x-api-key: $token"  "$endpoint/deploy/poll?pollId"

Example

In the following example, a definitions file that contains 5000 jobs is deployed—5 folders of 1000 jobs each. The response shows only 250 jobs have been deployed, so the deployment status is partial and a poll ID is provided:

{
    "deploymentFile": "5000_jobs_async_deploy.json",
    "pollId": "98b565da-eff8-4d78-881e-778b97944229",
    "deploymentStatus": "PARTIAL_RESULT",
    "successfulFoldersCount": 0,
    "successfulSmartFoldersCount": 0,
    "successfulSubFoldersCount": 0,
    "successfulJobsCount": 250,
    "successfulConnectionProfilesCount": 0,
    "successfulDriversCount": 0,
    "isDeployDescriptorValid": false
}

Parameter

Description

deploymentFile

The name of the definitions file

pollIdA unique Id  to monitor the status of the deployment

deploymentStatus

The status of the deployment.

Possible values:

  • ENDED_OK: All the jobs in the definitions file deployed successfully
  • ENDED_NOT_OK: None of the jobs in the definitions file deployed successfully
  • PARTIAL_RESULT: Some of the jobs in the definitions file deployed successfully
  • TIMED_OUT: The deployment takes longer than 20 seconds and is cancelled
  • UNKNOWN: An unknown error occurred in the deployment
successfulFoldersCountNumber of simple folders deployed 
successfulSmartFoldersCountNumber of SMART folders deployed 
successfulSubFoldersCountNumber of subfolders deployed 
successfulJobsCountNumber of jobs deployed
successfulConnectionProfilesCountNumber of connection profiles deployed
successfulDriversCountNumber of JDBC drivers deployed
isDeployDescriptorValid

Confirms if the deploy descriptor in the definitions file deployed. For detailed information, see Deploy Descriptor.

Values: true | false

The following example shows the response shortly after deploy. Notice that 2 Smart folders, or 2000 jobs, have deployed:

{
  "deploymentFile": "1000_jobs_async_deploy.json",
  "pollId": "98b565da-eff8-4d78-881e-778b97944229",
  "deploymentState": "DEPLOYED_CALENDARS, DEPLOY FOLDERS 2/5",
  "deploymentStatus": "PARTIAL_RESULT",
  "successfulFoldersCount": 0,
  "successfulSmartFoldersCount": 2,
  "successfulSubFoldersCount": 0,
  "successfulJobsCount": 2000,
  "successfulConnectionProfilesCount": 0,
  "successfulDriversCount": 0,
  "successfulCalendarsCount": 1,
  "isDeployDescriptorValid": false,
  "deployedFolders": [
    "BigFolder1",
    "BigFolder2"
  ],
  "deployedCalendars": [
    "PeriodicCalendarForRun"
  ]
}

Parameter

Description

deploymentState

Describes what has already been deployed.

Possible values:

  • DEPLOYED_CALENDARS: Confirms that calendars from the definitions file have deployed 
  • DEPLOYED_CONNECTION_PROFILES: Confirms that connection profiles listed in the definitions file have been deployed
  • DEPLOYED_STANDARDS: Confirms that site standards from the definitions file have deployed 
  • DEPLOY FOLDERS x/x: Confirms that number of folders that have deployed out of the total number of folders included in the definitions file. 
deployedFoldersAn array of the folder names that deployed
deployedCalendarsAn array of the calendar names that deployed

After running the ctm deploy poll command again a few minutes later, notice that all the jobs have deployed successfully:

{
  "deploymentFile": "1000_jobs_async_deploy.json",
  "pollId": "98b565da-eff8-4d78-881e-778b97944229",
  "deploymentState": "DEPLOYED_CALENDARS, DEPLOY FOLDERS 5/5",
  "deploymentStatus": "ENDED_OK",
  "successfulFoldersCount": 0,
  "successfulSmartFoldersCount": 5,
  "successfulSubFoldersCount": 0,
  "successfulJobsCount": 5000,
  "successfulConnectionProfilesCount": 0,
  "successfulDriversCount": 0,
  "successfulCalendarsCount": 1,
  "isDeployDescriptorValid": false,
  "deployedFolders": [
    "BigFolder1",
    "BigFolder2",
    "BigFolder3",
    "BigFolder4",
    "BigFolder5"
  ],
  "deployedCalendars": [
    "PeriodicCalendarForRun"
  ]
}

deploy jobs::get

Returns the definition of jobs and folders in the requested format that match the search criteria.

CLI Syntax

CLI
ctm deploy jobs::get [format] -s <search query>

Parameter

Description

format

The format in which to return the output: json

-s  is used to run a search using the query string format. The following table includes the fields that can be used in the search query:

Field

Criteria

Criteria example
  • server
  • folder
  • job
  • Supported wildcards for server and folder are *, ?
  • To specify multiple servers or folders, use commas.
  • The job field specifies a single job and does not support wildcards.
  • To specify a subfolder, include a colon between each parent folder and subfolder in the path. Do not use wildcards in the subfolder.
  • If you use colons in the folder field or if you use the job field to specify a job, specify a single value (without wildcards) in the server field.
  • To use multiple criteria, separate by using &

Note:

  • The server field was previously named ctm (deprecated name).
  • If you use colons in the folder field to specify a subfolder, the query also returns details of any child subfolders within the specified subfolder.
  • If you use colons in the folder field or if you use the job field, the output contains the PathElement property to define the subfolder or job.

server=*&folder=*

server=*&folder=Auto*

server=IN01&folder=AutomationAPISampleFlow

server=IN01&folder=folder1:subfolder2

server=IN01&folder=folder1&job=myJob

useArrayFormat

Enforces the display of jobs in an array format under a Jobs object, instead of displaying each job separately under an object that bears the name of the individual job.

This array format enables you to define more than one job with the same job name. For examples of the job array structure, see the examples in Folders and Flows.

The array format is available only if you set the allowDuplicateJobNames system setting to true, as described in System Settings reference.

The useArrayFormat field enforces the job array structure even when all returned jobs have distinct names (and no job name is used by more than one job).

Values: true|false

Default: false (the array format is used only if multiple jobs with the same name are detected)

server=*&folder=*&useArrayFormat=true

For example, the following command shows how to get a job in a JSON format for all the folders that start with Automation:

ctm deploy jobs::get -s "server=*&folder=Automation*"

REST API Syntax

See REST API reference.

curl -k  -H "x-api-key: $token"  "$endpoint/deploy/jobs?server=*&folder=Auto*&useArrayFormat=true"

deploy calendars::get

Returns the definitions of calendars based on specified search criteria.

Calendars are used to set scheduling criteria that you can apply to multiple jobs, instead of having to define scheduling criteria in each individual job. For information about defining calendars and calendar scheduling parameters, see Calendars.

CLI Syntax

CLI
ctm deploy calendars::get [limit] -s <search query>

Parameter

Description

limit

Maximum number of calendars to include in the response. The default is 10000.

Use the required -s option to specify a query string to search for. The following table lists the fields that can be used in the search query:

Field

Criteria

Criteria examples
  • name
  • type
  • server
  • alias
  • Supported wildcards are *, ?
  • To use multiple criteria separate by using &
  • For type (of calendar) choose from the following options:
    • Regular
    • Periodic
    • RuleBasedCalendar

name=*

name=*&server=auto*

name=S1,S2&server=*

REST API Syntax

See REST API reference.

endpoint=https://<controlm>/automation-api
token=
curl -X GET -H "x-api-key: $token"  "$endpoint/deploy/calendars/?type=Periodic&name=S*"

deploy calendar::delete

Deletes a defined calendar.

CLI Syntax

CLI
ctm deploy calendar::delete <calendarName> [serverName]

Parameter

Description

<calendarName>Name of the defined calendar

[serverName]

Name of the server (currently IN01)

If annotation is enabled for the Scheduling definitions category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation input.

REST API Syntax

See REST API reference.

endpoint=https://<controlm>/automation-api
token=
calendar=
server=
curl -X DELETE -H "x-api-key: $token"  "$endpoint/deploy/calendar/$calendar?server=$server"

deploy connectionprofiles:centralized::get

Returns the full definitions of centralized connection profiles, based on specified search criteria.

Centralized connection profiles are stored centrally in Helix Control-M and can be used by all your agents. Definitions for such connection profiles contain the Centralized parameter set to true.

CLI Syntax

CLI
ctm deploy connectionprofiles:centralized::get -s <search query>

Use the required -s option to specify a query string to search for. The following table lists the fields that can be used in the search query:

Field

Description

Criteria examples
typeType of connection profile, one of the following options:
  • Hadoop
  • Database
  • FileTransfer
  • ApplicationIntegrator:<customType>
  • Informatica
  • AWS
  • Azure
  • SAP

For all types, use an asterisk *.

type=Hadoop&name=myCP

type=*&name=hd*

name

Name of connection profile(s).

Supported wildcards are * (asterisk) and ? (question mark). For multiple values, use commas between values.

The default is * (all).

REST API Syntax

See REST API reference.

endpoint=https://<controlm>/automation-api
token=
name=
type=
curl -X GET -H "x-api-key: $token" "$endpoint/deploy/connectionprofiles/centralized/?type=$type&name=$name"

deploy connectionprofiles:centralized:status::get

Returns a summary of details for centralized connection profiles (including basic properties and metadata, and the current deployment status), based on specified search criteria.

Centralized connection profiles are stored centrally in Helix Control-M and can be used by all your agents. Definitions for such connection profiles contain the Centralized parameter set to true.

CLI Syntax

CLI
ctm deploy connectionprofiles:centralized:status::get <limit> -s <search query>

Parameter

Description

limit

Maximum number of connection profiles to include in the response.

Use the required -s option to specify a query string to search for. The following table lists the fields that can be used in the search query:

Field

Description

Criteria examples
typeType of connection profile, one of the following options:
  • Hadoop
  • Database
  • FileTransfer
  • ApplicationIntegrator:<customType>
  • Informatica
  • AWS
  • Azure
  • SAP

For all types, use an asterisk *.

type=Hadoop&name=myCP

type=*&name=hd*

name

Name of connection profile(s).

Supported wildcards are * (asterisk) and ? (question mark). For multiple values, use commas between values.

The default is * (all).

REST API Syntax

See REST API reference.

endpoint=https://<controlm>/automation-api
token=
name=
type=
curl -X GET -H "x-api-key: $token" "$endpoint/deploy/connectionprofiles/centralized/status/?type=$type&name=$name&limit=50"

deploy connectionprofile:centralized::deploymentstatus

Returns deployment status information for a centralized connection profile.

CLI Syntax

CLI
ctm deploy connectionprofile:centralized::deploymentstatus <type> <name>

Parameter

Description

<type>

Type of connection profile, one of the following:

  • Hadoop
  • Database
  • FileTransfer
  • ApplicationIntegrator:<customType>
  • Informatica
  • AWS
  • Azure
  • SAP
<name>Name of the connection profile

REST API Syntax

See REST API reference.

endpoint=https://<controlm>/automation-api
token=
type=
name=
curl -X GET -H "x-api-key: $token" "$endpoint/deploy/connectionprofile/centralized/$type/$name/deploymentstatus"

deploy connectionprofile:centralized::delete

Deletes a centralized connection profile.

CLI Syntax

CLI
ctm deploy connectionprofile:centralized::delete <type> <name>

Parameter

Description

<type>

Type of connection profile, one of the following:

  • Hadoop
  • Database
  • FileTransfer
  • ApplicationIntegrator:<customType>
  • Informatica
  • AWS
  • Azure
  • SAP
<name>Name of the connection profile

If annotation is enabled for the Control-M security category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation input.

REST API Syntax

See REST API reference.

endpoint=https://<controlm>/automation-api
token=
type=
name=
curl -X DELETE -H "x-api-key: $token" "$endpoint/deploy/connectionprofile/centralized/$type/$name"

deploy connectionprofile::test

Tests the definitions of a connection profile (without deploying it) on a specific server and agent. You provide the definitions of the connection profile through a JSON-format definitions file.

CLI Syntax

CLI
ctm deploy connectionprofile::test <definitionsFile> [ctm] [agent]

Parameter

Description

definitionsFile

Name of the JSON-format definitions file

ctm

Name of the server (currently IN01)

agent

Host name or alias of the agent. This is the logical name of the agent.

REST API Syntax

See REST API reference.

endpoint=https://<controlm>/automation-api
token=
ctm=
agent=
curl -H "x-api-key: $token" \
  -X POST "$endpoint/deploy/connectionprofile/test?ctm=$ctm&agent=$agent" \
  -F "definitionsFile=@/C:/myConnectionProfile.json"

deploy job::delete

Enables you to delete a job from an existing folder.

CLI Syntax

CLI
ctm deploy job::delete <jobPath> [server] [library]

Parameter

Description

<jobPath>

Defines the full path of the job to delete.

Use colons as separators between folder, subfolder, and job.

Example: SMART_FOLDER_1:SMART_FOLDER_2:job_to_delete

serverDefines the name of the server (currently IN01)
library(z/OS only) Defines the name of the z/OS library.

REST API Syntax

See REST API reference.

endpoint=https://<controlm>/automation-api
token=
server=IN01
jobpath=SMART_FOLDER_1:SMART_FOLDER_2:job_to_delete
curl -X DELETE -H "x-api-key: $token" "$endpoint/deploy/job/$server/$jobpath"

deploy folder::delete

The delete folder command enables you to delete a folder.

CLI Syntax

CLI
ctm deploy folder::delete <server> <folderName>

Parameter

Description

<server>

Name of the server (currently IN01)

<folderName>Name of the folder to delete

If annotation is enabled for the Scheduling definitions category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation input.

REST API Syntax

See REST API reference.

endpoint=https://<controlm>/automation-api
token=
server=
folder=
curl -X DELETE -H "x-api-key: $token" "$endpoint/deploy/folder/$server/$folder"

deploy subfolder::delete

Enables you to delete a subfolder and all jobs under the subfolder.

CLI Syntax

CLI
deploy subfolder::delete <subFolderPath> [server] [library]

Parameter

Description

<subFolderPath>

Specifies the full path of the subfolder to delete.

Use a colon to separate the parent folder from subfolders.

serverName of the server (currently IN01)
library

(z/OS only) Specifies the name of the z/OS library.

Optional.

REST API Syntax

See REST API reference.

endpoint=https://<controlm>/automation-api
token=
server=
subfolderpath=
curl -X DELETE -H "x-api-key: $token" "$endpoint/deploy/subfolder/$server/$subfolderpath"

deploy transform

The transform command enables you to apply the rules of the deployDescriptorsFile to the original definitionsFile. The rules define the method to use that change the values of the JSON code properties in the original definitionsFile. 

CLI Syntax

CLI
ctm deploy transform <definitionsFile> <deployDescriptorFile>

Where:

Parameter

Description

<definitionsFile>

The file or archive that contains code for jobs.

Valid formats are:

  • .json format
  • .zip or .tar.gz
<deployDescriptorFile>The file that includes the rules to apply on the original definitionsFile. The rules enable transforming Control-M JSON code properties. For detailed information, see Deploy Descriptor.

REST API Syntax

See REST API reference.

curl -H "x-api-key: $token" -X POST  -F "definitionsFile=@examples/AutomationAPISampleFlow.json" 
-F "deployDescriptorFile=@examples/deployDescriptor.json" "$endpoint/deploy/transform"

deploy jobtype

This command enables you to deploy a new job type provided in the .ctmai format to Control-M.

If you specify the agent and server in your command, the job type is also published to the Control-M/Agent.

The response notifies you whether the deployment succeeded or failed.

CLI Syntax

CLI
ctm deploy jobtype <definitionsFile> [agent] [server] [-f <payload file>]

Parameter

Description

definitionsFile

The name of a .ctmai binary file that contains the definitions of the job type and was exported from Application Integrator
agent(Optional) Host name or alias of the agent. This is the logical name of the agent
server

(Optional) Name of the server (currently IN01)

payload file

(Optional) Name of a .json file that contains parameter values, for use instead of specifying parameters in the API command

Here is an example of the content of such a file:

{
    "server": "server1",
    "agent": "agent1"
}

REST API Syntax

See REST API reference.

token=
endpoint=https://<controlm>/automation-api
curl -X POST -H "x-api-key: $token" -F "definitionsFile=aif.ctmai"
-F "payloadFile=payload.json"  "$endpoint/deploy/jobtype"

deploy ai:jobtype

This command enables you to publish a deployed Application Integrator job type to the agent to allow it to run.

The response notifies you whether the deployment succeeded or failed.

CLI Syntax

CLI
ctm deploy ai:jobtype <server> <agent> <jobTypeId>

Parameter

Description

<server>

Name of the server (currently IN01)

<agent>Host name or alias of the agent. This is the logical name of the agent.
<JobTypeId>

ID for the custom job type defined through the Application Integrator

The corresponding setting in the Application Integrator is Plug-in ID. For more information, see Job:ApplicationIntegrator.

REST API Syntax

See REST API reference.

token=
endpoint=https://<controlm>/automation-api
server=
agent=
jobType=
curl -X POST -H "x-api-key: $token" 
"$endpoint/deploy/ai/jobtype/?server=$server&agent=$agent&jobTypeId=$jobType"

deploy ai:jobtypes::get

This command enables you to get details of deployed Application Integrator job types that match a specified search query.

CLI Syntax

CLI
ctm deploy ai:jobtypes::get [-s <search query>]

The optional -s option enables you to limit the list to job types that match specified criteria. The format for the query string is "field1=criteria1&field2=criteria2", according to the following guidelines:

Fields

Criteria

Example
  • jobTypeName
  • jobTypeId

As wildcards, use asterisks (*).

"jobTypeName=startName*&jobTypeId=*partOfID*"

If you include both fields in the query, separate them with an ampersand (&).

REST API Syntax

See REST API reference.

token=
endpoint=https://<controlm>/automation-api
curl -X GET -H "x-api-key: $token" 
"$endpoint/deploy/ai/jobtypes/?jobTypeId=<ID string>&jobTypeName=<name string>"

Response

The following example response lists 3 Application Integrator job types, 2 of which are ready to deploy and one more in draft status:

{
'jobtypes': [
  {'status': 'ready to deploy', 'jobTypeId': 'CTMREMOTE', 'description': 'Track job running on remote Control-M Stack', 'jobTypeName': 'Monitor Remote Job'}, 
  {'status': 'ready to deploy', 'jobTypeId': 'AZUREBLOB', 'description': 'Azure blob storage', 'jobTypeName': 'Azure blob storage'}, 
  {'status': 'draft', 'jobTypeId': 'DRAFT4GET', 'description': 'Draft Job Type', 'jobTypeName': 'Draft Job'}
]
}

The following parameters are provided for each job type:

ParameterDescription
statusThe status of the job type, either ready to deploy or draft
jobTypeId

The job type application ID (or Plug-in ID) defined in the Application Integrator

For more information, see Job:ApplicationIntegrator.

descriptionA description of the job type, as defined (optionally) in the Application Integrator
jobTypeNameThe job type name defined in the Application Integrator

deploy sitestandard:fieldRestriction::get

This command obtains the list of allowed values defined for a restricted-text field in a Site standard.

CLI Syntax

CLI
ctm deploy sitestandard:fieldRestriction::get <standardName> <fieldName>

Where:

Parameter

Description

<standardName>

The name of the Site standard

<fieldName>

The name of the field, in lowercase characters

Currently, only the application field is supported.

REST API Syntax

See REST API reference.

standardName=standard1
fieldName=application
curl -X GET -H "x-api-key: $token" 
"$endpoint/deploy/sitestandard/$standardName/fieldRestriction/$fieldName"

deploy sitestandard:fieldRestriction::replaceValues

This command replaces the allowed values defined for a restricted-text field in a Site standard with a new set of allowed values.

CLI Syntax

CLI
ctm deploy sitestandard:fieldRestriction::replaceValues <standardName> <fieldName> -f <valuesFile>

Where:

Parameter

Description

<standardName>

The name of the Site standard

<fieldName>

The name of the field, in lowercase characters

Currently, only the application field is supported.

<valuesFile>

A .json file that contains new values for the field, to replace all existing values

Here is an example of the content of such a file:

{
  "values": [
    {
      "value": "App1"
    },
    {
      "value": "App2",
      "description": "description of application2"
    }
  ]
}

If annotation is enabled for the Scheduling definitions category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation input.

REST API Syntax

See REST API reference.

standardName=standard1
fieldName=application
curl -X POST -H "Content-Type: application/json" -H "x-api-key: $token"
-d "@examples/SiteStandardApplicationFieldValues.json"
"$endpoint/deploy/sitestandard/$standardName/fieldRestriction/$fieldName"

deploy sitestandardpolicies::add

Enables you to deploy new Site Standard Policies based on definitions in a Definitions File (as described in Site Standard Policies).

CLI Syntax

Code Block
ctm deploy sitestandardpolicies::add <definitionsFile>.json

Parameter

Description

definitionsFile

Defines the full path (directory and file name) of the JSON file that contains the definitions of new Policies, as described in Site Standard Policies.

The response summarizes the number of Standard Policies that were added successfully (based on the Definitions File) and lists their names.

REST API Syntax

See REST API reference.

Example using curl:

REST API
>curl -k -X POST -H "x-api-key: $token" "$endpoint/deploy/sitestandardpolicies" -F "definitionsFile=@examples/SiteStandardPolicies.json"

deploy sitestandardpolicies::get

Retrieves the definitions of deployed Site Standard Policies.

The response is formatted as described in Site Standard Policies, and can be used in subsequent deployments.

CLI Syntax

Code Block
ctm deploy sitestandardpolicies::get [-s "name=<SiteStandardPolicy>"]

The optional -s enables you to filter the response to specific site standard policies. You can specify multiple values separated by commas, and use asterisks (*) as wildcards.

REST API Syntax

See REST API reference.

Example using curl:

REST API
>curl -k -H "x-api-key: $token" "$endpoint/deploy/sitestandardpolicies?name=a*,*b"

deploy sitestandardpolicy::rename

Enables you to rename an existing Site Standard Policy.

CLI Syntax

Code Block
ctm deploy sitestandardpolicy::rename <siteStandardPolicyName> <siteStandardPolicyNewName> 

Parameter

Description

siteStandardPolicyName

Defines the Policy to rename

siteStandardPolicyNewNameDefines the new name of the Policy

REST API Syntax

See REST API reference.

Example using curl:

REST API
>curl -X POST -H "x-api-key: $token" "$endpoint/deploy/sitestandardpolicy/rename?siteStandardPolicyName=<BIZ_Policy>&siteStandardPolicyNewName=<DEV_Policy>"

deploy sitestandardpolicy::delete

Enables you to delete a Site Standard Policy.

CLI Syntax

REST API
ctm deploy sitestandardpolicy::delete <siteStandardPolicyName>

Parameter

Description

siteStandardPolicyName

Defines the Site Standard Policy to delete

REST API Syntax

See REST API reference.

Example using curl:

curl -X DELETE -H "x-api-key: $token"  "$endpoint/deploy/sitestandardpolicy?siteStandardPolicyName=BIZ_Policy"

deploy sitestandardpolicies:details::get

This command returns the details of all existing Site Standard Polices in your Control-M environment.

CLI Syntax

CLI
ctm deploy sitestandardpolicies:details::get [-s "name=<SiteStandardPolicy>"]

The optional -s enables you to filter the response to specific site standard policies. You can specify multiple values separated by commas, and use asterisks (*) as wildcards.

REST API Syntax

See REST API reference.

Example using curl:

>curl -k  -H "x-api-key: $token"  "$endpoint/deploy/sitestandardpolicies/details?name=a*,*b"

Response Example

Code Block
{
	"siteStandardPolicies": [
    {
        "name": "ACC_Policy",
        "description": "Policy for accounting team",
        "createdTime": "2021-06-16T03:09:45Z",
        "username": "emuser",
        "siteStandard": "ACC_Standard",
        "status": "Active"
    },
    {
        "name": "PRODUCTION_Policy",
        "description": "Policy for production teams",
        "createdTime": "2021-12-20T07:18:36Z",
        "username": "emuser",
        "siteStandard": "PROD_Standard",
        "status": "Not Active"
    }
    ]
}

Parameter

Description

name

Defines the name of the Policy.

description

Describes the Policy.

createdTimeDetermines the time that the Policy was created.
usernameDefines the name of the user who created the Policy.
siteStandardDefines the Site Standard associated with the Policy.
statusIndicates whether the Policy is Active or Not Active.
Was this page helpful? Yes No Submitting... Thank you

Comments