Contents

 Where to find more information

For more information about Control-M, see the BMC channel on Youtube.

https://www.youtube.com/channel/UCcYdJERrQnK6SPfX3BruH0A

Introduction

The Control-M Automation API allows you to automate and work interactively with Control-M. Services are groups of API commands available via either a CLI (Command Line Interface) or as REST API commands. Using the services, you can build to test whether job definitions are valid, run job definitions for debugging, combine multiple definition files into a package, deploy job definitions and packages to Control-M, provision a Control-M/Agent, manage environments, and more.

See below more information on how to work with the CLI and REST API

The Build Service

The build service allows you to compile job definitions and verify that they are valid for your Control-M. Control-M validation includes basic Control-M rules such as length of fields, allowed characters, and mandatory fields. Build will also check that the JSON is valid. If Control-M Change Manager is part of your solution, definitions will be evaluated against the relevant site standard. build can receive definition files in .json format or packages of multiple job definition files in .zip or .jar format.

CLI Syntax

CLI
>ctm build <definitionsFile>

Where:

Parameter

Description

<definitionsFile>

The file or archive that contains code for jobs.

Valid formats are:

  • .json format
  • .zip or .jar

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST  -F "definitionsFile=@examples/AutomationAPISampleFlow.json" "$endpoint/build"

The following example shows you how build using python

token = r_login.json()['token']
 
# -----------------
# Built
uploaded_files = [
        ('definitionsFile', ('Jobs.json', open('examples/AutomationAPISampleFlow.json', 'rb'), 'application/json'))
]
 
r = requests.post(endPoint + '/build', files=uploaded_files, headers={'Authorization': 'Bearer ' + token})
print(r.content)
print(r.status_code)
exit(r.status_code == requests.codes.ok)

The Run Service

The Run Service allows you to run jobs and track their status. You can also use the service to debug your job definitions.

The service allows you to view job output, logs and perform job actions. You can also manage resources and events.

run

Click each link below to see the properties of each of the run services: 

Use the run command to run jobs on the Control-M environment. The returned runId can be used to check job status.

The following example shows a typical command and response . build takes place as part of the run.

>ctm run examples/AutomationAPISampleFlow.json
{
  "runId": "2d4af716-e31d-48ef-a434-16575303752d",
  "statusURI": "https://ec2-54-187-1-168.us-west-2.compute.amazonaws.com:8443/run/status/2d4af716-e31d-48ef-a434-16575303752d"
}

CLI Syntax

CLI
>ctm run <jobDefinitionsFile>

Where:

Parameter

Description

<jobDefinitionsFile>

The file or archive that contains code for jobs.

 Valid formats are:

  • .json format

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST  -F "jobDefinitionsFile=@examples/AutomationAPISampleFlow.json" "$endpoint/run"

run order

Allows you to run deployed jobs on the Control-M environment. The returned runId is used to check job status. Below is a typical command and response. build will take place as part of the run.

>ctm run order controlm AutomationAPISampleFlow
{
  "runId": "e0ddf056-4497-49f7-9d8b-25758b132bd6",
  "statusURI": "https://ec2-54-201-124-17.us-west-2.compute.amazonaws.com:8443/automation-api/run/status/e0ddf056-4497-49f7-9d8b-25758b132bd6?token=948220e4f1f4143591d71bd79a61c4c8_A5360B11"
}

CLI Syntax

CLI
>ctm run order <ctm> <folder> [jobs]

Where:

Parameter

Description

<ctm>

Control-M/Server
<folder>Folder name that is ordered

[jobs]

(optional) can use wildcard *. If not defined, the entire folder is ordered

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST --header "Content-Type: application/json" --header "Accept: application/json" -d "{
  \"ctm\": \"$ctm\",
  \"folder\": \"$folderName\"
}" "$endpoint/automation-api/run/order"

 

run status

The run status command allows you to track the status of running jobs. The following command shows you how to check job status using the runId.

To get a valid output from the outputURI and logURI fields, you must use the token from the ctm session login. Copy the token and paste to the ctm run status command.  When running the command use –t to get a valid output. 

NOTE: When there is more than one job in the flow, the status of all jobs is checked and returned. 

>ctm run status "2d4af716-e31d-48ef-a434-16575303752d" 
{
  "statuses": [
    {
      "jobId": "controlm:00fhb",
	  "folderId": "controlm:005gy",
      "numberOfRuns": 3,
      "name": "AutomationAPISampleFlow",
      "type": "Folder",
      "status": "Executing",
      "startTime": "May 18, 2016 11:57:26 AM",
      "endTime": "",
      "outputURI": "Folder has no output"
    },
    {
      "jobId": "controlm:00fhc",
	  "folderId": "controlm:005gy",
      "numberOfRuns": 3,
      "name": "AutomationAPISampleFlow/CommandJob",
      "type": "Command",
      "status": "Wait Host",
      "startTime": "",
      "endTime": "",
      "outputURI": "Job didn't run, it has no output"
    },
    {
      "jobId": "controlm:00fhd",
	  "folderId": "controlm:005gy",
      "numberOfRuns": 3,
      "name": "AutomationAPISampleFlow/ScriptJob",
      "type": "Job",
      "status": "Wait Condition",
      "startTime": "",
      "endTime": "",
      "outputURI": "Job didn't run, it has no output"
    }
  ],
  "startIndex": 0,
  "itemsPerPage": 25
}

CLI Syntax 

CLI
>ctm run status <runId> [startIndex]

Where:

Parameter

Description

<runId>

Value returned in a ctm run invocation. It enables job tracking during a specific run.
startIndex

(Optional) enable iteration over all statuses. Result includes "itemsPerPage": 25 items from this

index. If not defined, the default is 0.

REST API Syntax

See REST API reference.

Example using curl: 

curl -H "Authorization: Bearer $token" "$endpoint/run/status/$runId"

run jobs:status::get

The jobs status get command allows you to track running jobs that match a search query. 

The following command shows you how to get job statuses using a search query. 

>ctm run jobs:status::get -s "jobname=Finance*&application=app1,app2&status=Ended OK,Ended Not OK,Executing"

CLI Syntax

CLI
>ctm run jobs:status::get [limit] -s "<query string>"	

-s  is used to run a search using the query string format as shown in this example: "field1=criteria1&field2=criteria2"  

Where:

Field

Criteria

Criteria example
  • jobname
  • folder
  • ctm
  • application
  • subApplication
  • host
  • description
  • Supported wildcards are *, ?
  • To use multiple criteria separate by using comma

jobname=job1122

jobname=job11*

jobname=job11*,job777*,job1234

description=*a job that*

status
  • Ended OK
  • Ended Not OK
  • Wait User
  • Wait Resource
  • Wait Host
  • Wait Workload
  • Wait Condition
  • Executing
  • Status Unknown

To use multiple criteria separate by using comma

status=Ended OK

status=Ended OK,Ended Not OK,Executing

limit

 

limit=400

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" "$endpoint/run/jobs/status?jobname=jobA&status=Ended%20OK&application=A*"

run job:output::get

The run output command allows you to view the output from job runs. 

CLI Syntax

CLI
>ctm run job:output::get <jobId> [runNo]

Where:

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

[runNo]

(Optional) The run number of the job to get the output. If not defined, the default is the last run.

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" "$endpoint/run/job/$jobId/output/?runNo=0"

run job:log::get

The run log command allows you to view the job log. 

CLI Syntax

CLI
>ctm run job:log::get <jobId> 

Where:

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" "$endpoint/run/job/$jobId/log"

run job:status::get

The run status command allows you to view a specific job run status.

CLI Syntax

CLI
>ctm run job:status::get <jobId> 

Where:

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

Response

The following example shows the parameters in the ctm run job:status::get response:

{
      "jobId": "controlm:00fhc",
      "folderId": "controlm:005gy",
      "rerun": 1,
      "name": "AutomationAPISampleFlow/CommandJob",
      "type": "Command",
      "status": "Ended OK",
      "startTime": "Aug 4, 2016 1:53:30 PM",
      "endTime": "Aug 4, 2016 2:00:30 PM",
      "outputURI": "http://localhost:48080/run/output/controlm:00fhc?token=a9f54556167ee2c3e5ecf543ff1415a5_B006F108",
      "logURI": "http://localhost:48080/run/log/controlm:00fhc?token=a9f54556167ee2c3e5ecf543ff1415a5_B006F108"
    }

Where:

ParameterDescription
<jobId>Each job in the run has a jobId. The jobId is used to reference the specific job and is returned by the ctm run status. The format used is Control-M/Server name ":" the order ID of the job.
<folderId>The folder run ID enables grouping runs by folder instances.
<rerun>Number of job runs
<status>

The following list includes valid job statuses:

  • Ended OK
  • Ended Not OK
  • Wait User
  • Wait Resource
  • Wait Host
  • Wait Workload
  • Wait Condition
  • Executing
  • Status Unknown
<outputURI>URI to the job output
<logURI>URI to the job log

REST API Syntax

See REST API reference

Example using curl:

curl -H "Authorization: Bearer $token" "$endpoint/run/job/$jobId/status"

run job::kill

The run kill command allows you to terminate the job.

CLI Syntax

CLI
>ctm run job::kill <jobId> 

Where:

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST "$endpoint/run/job/$jobId/kill"

run job::runNow

The run runNow command allows you to immediately start the job.

CLI Syntax

CLI
>ctm run job::runNow <jobId> 

Where:

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST "$endpoint/run/job/$jobId/runNow"

run job::hold 

The run hold command allows you to hold the job.

CLI Syntax

CLI
>ctm run job::hold <jobId> 

Where: 

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status

REST API Syntax

See REST API reference.

Example using curl: 

curl -H "Authorization: Bearer $token" -X POST "$endpoint/run/job/$jobId/hold"

run job::free 

The run free command allows you to continue job run from hold state.

CLI Syntax

CLI
>ctm run job::free <jobId> 

Where: 

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

REST API Syntax 

See REST API reference. 

Example using curl:

curl -H "Authorization: Bearer $token" -X POST "$endpoint/run/job/$jobId/free"

run job::delete 

The run delete command allows you to mark the job for deletion. At the next scheduled date, the job will be deleted.

CLI Syntax

CLI
>ctm run job::delete <jobId> 

Where: 

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

REST API Syntax 

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST "$endpoint/run/job/$jobId/delete"

run job::undelete 

The run undelete command allows you to remove a mark for deletion from a job.

CLI Syntax

CLI
>ctm run job::undelete <jobId> 

Where:

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST "$endpoint/run/job/$jobId/undelete"

run job::confirm 

The run confirm command allows you to run a job that is waiting for confirmation.

CLI Syntax

CLI
>ctm run job::confirm <jobId> 

Where:

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST "$endpoint/run/job/$jobId/confirm"

run job::setToOk 

The run setToOk command allows you to set job status to OK, after the job has been processed. 

CLI Syntax

CLI
>ctm run job::setToOk <jobId> 

Where:

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST "$endpoint/run/job/$jobId/setToOk"

run job::rerun

The rerun command allows you to rerun the job.

CLI Syntax

CLI
>ctm run job::rerun <jobId> 

Where:

Parameter

Description

<jobId>

Each job in the run has a jobId. The jobId is used to reference a specific job and is returned by the ctm run status.

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST "$endpoint/run/job/$jobId/rerun"

Resource Management

A quantitative resource is represented by a name of a resource and the maximum number of that resource which jobs can use. Jobs that require a quantitative resource can not run unless there is enough resources available. 

run resource::add

The add resource command allows you to add a quantitative resource to a Control-M/Server. 

CLI Syntax

CLI
>ctm run resource::add <ctm> <name> <max> 

Where:

Parameter

Description

<ctm>Name of the Control-M/Server
<name>Name of the resource

<max>

Maximum quantity of resources available

REST API Syntax

See REST API reference.

Example using curl:

ctm=controlm

curl -H "Authorization: Bearer $token" -H "Content-Type: application/json" -X POST -d "{\"name\": \"newResource\",
\"max\":\"5\"}" "$endpoint/run/resource/$ctm"

run resource::delete

The delete resource command allows you to delete a quantitative resource. 

CLI Syntax

CLI
ctm run resource::delete <ctm> <name> 

Where:

Parameter

Description

<ctm>Name of the Control-M/Server

<name>

Name of the resource

REST API Syntax

See REST API reference.

Example using curl:

ctm=controlm
name=newResource
curl -H "Authorization: Bearer $token" -X DELETE "$endpoint/run/resource/$ctm/$name"
 

run resource::update

The update resource command allows you to update the values of a quantitative resource. 

CLI Syntax

CLI
ctm run resource::update <ctm> <name> <max> 

Where:

Parameter

Description

<ctm>Name of the Control-M/Server
<name>Name of the resource

<max>

Maximum quantity of resources available

REST API Syntax

See REST API reference.

Example using curl:

ctm=controlm
name=newResource

curl -H "Authorization: Bearer $token" -H "Content-Type: application/json" -X POST -d "{\"max\":\"6"}" "$endpoint/run/resource/$ctm/$name" 

run resources::get

The get resource command allows you to get all resource records from a specific Control-M/Server.

CLI Syntax

CLI
ctm run resources::get -s [search query]

-s  is used to run a search using the query string format as shown in this example: "field1=criteria1&field2=criteria2".

Criteria may contain "*" for wildcard matching and comma separator to specify multiple values. 

Where:

Field

Description

ctm

Name of the Control-M/Server
nameName of the resource
Search examples
-s "name=resourceA"
-s "name=A*"
-s "ctm=controlm*&name=resourceA,resourceB"

Response 

The following example shows the parameters in the ctm run resources::get response:

[
  {
    "name": "newResource",
    "ctm": "controlm",
    "available": "15",
    "max": 15,
    "workloadPoliy": "N/A"
  },
  {
    "name": "myRes",
    "ctm": "controlm",
    "available": "4",
    "max": 4,
    "workloadPoliy": "N/A"
  },

Where:

ParameterDescription
<ctm>Name of the Control-M/Server
<name>Name of the resource
<available>Number of resources available
<max>Maximum resources available
<workloadPolicy>Name of workload policy that is linked to the resource. N/A indicates that the resource is not linked to a workload policy. For more information on workload policies, see documentation on Workload Policy.

REST API Syntax

See REST API reference.

Example using curl:

search_criteria="name=A*&ctm=*"
> ctm=controlm curl -H "Authorization: Bearer $token" -X GET "$endpoint/run/resources?$search_criteria" 

Event Management

An event (AKA a condition) is represented by a name and a date. Jobs that require an event cannot run unless the specific event exists. A job can add or delete an event.

run event::add

The add event command allows you to add events to the Control-M/Server.

CLI Syntax

CLI
>ctm run event::add <ctm> <name> <date> 

Where:

Parameter

Description

<ctm>Name of the Control-M/Server
<name>Name of the event

<date>

Date options to order the event:

  • MMDD - specific date
  • ODAT - represents the current Control-M date, example if the current Control-M date is August 7th, 2016, the ODAT converts to 0807.
  • STAT - can be used instead of a specific date for an event that is not date specific

REST API Syntax

See REST API reference.

Example using curl:

ctm=controlm
curl -H "Authorization: Bearer $token" -H "Content-Type: application/json" -X POST -d "{\"name\": \"newEvent\",\"date\":\"0505\"}"  "$endpoint/run/event/$ctm"

run event::delete

The delete event command allows you to remove an event. 

CLI Syntax

CLI
>ctm run event::delete <ctm> <name> <date> 

Where:

Parameter

Description

<ctm>Name of the Control-M/Server
<name>Name of the event

<date>

Date options to order the event:

  • MMDD - specific date
  • ODAT - represents the current Control-M date, example if the current Control-M date is August 7th, 2016, the ODAT converts to 0807.
  • STAT - can be used instead of a specific date for an event that is not date specific

REST API Syntax

See REST API reference.

Example using curl:

>ctm=controlm
>name=newEvent
>curl -H "Authorization: Bearer $token" -X DELETE "$endpoint/run/event/$ctm/$name"

run events::get

The get events command allows you to get all events from the Control-M/Server.

CLI Syntax

CLI
>ctm run events::get -s [search query]

-s  is used to run a search using the query string format as shown in this example: "field1=criteria1&field2=criteria2"

Criteria may contain "*" for wildcard matching and comma separator to specify multiple values. 

Where:

Field

Description

ctm

Name of the Control-M/Server
nameName of the event
dateDate of event
limit

Limits the number of returned matches.

Default: 1000 (if not defined)

Search examples
-s "name=eventA"
-s "name=A*&date=0805"
-s "ctm=controlm&name=evetA,eventB,date=0805"

REST API Syntax

See REST API reference.


Example using curl:

> search_criteria="name=A*&ctm=controlm" 
> curl -H "Authorization: Bearer $token" -X GET "$endpoint/run/events?$search_criteria" 

Response 

The following example shows the parameters in the ctm run events::get response:

 [
 {
    "name": "flow1_from_FlowAcc_goodJob_to_FlowAcc_badJob_2902",
    "ctm": "controlm",
    "date": "0726"
  },
  {
    "name": "flow1_from_FlowAcc_goodJob_to_FlowAcc_badJob_2935",
    "ctm": "controlm",
    "date": "0726"
  },
  {
    "name": "flow1_from_FlowAcc_goodJob_to_FlowAcc_badJob_2974",
    "ctm": "controlm",
    "date": "0726"
  },
  {
    "name": "flow1_from_FlowAcc_goodJob_to_FlowAcc_badJob_3007",
    "ctm": "controlm",
    "date": "0726"
  }
]

The Config Service

The config service allows you to configure the Control-M environment. You can access, update, and add configuration data. For example, you can list available Control-M/Servers, add agents, and manage host groups.

config servers::get

Returns a list of Control-M/Servers. Each entry is a pair which consists of the Control-M logical name and host name.

CLI Syntax

CLI
>ctm config servers::get

REST API Syntax

See REST API reference.

Example using curl:

REST API
curl -H "Authorization: Bearer $token" "$endpoint/config/servers"

config server:remotehost::add

The remotehost add command enables you to add a remote host to a Control-M/Server. 

CLI Syntax

CLI
>ctm config server:remotehost::add <ctm> <remotehost> [port] [-f <configuration file>]

Where:

Parameter

Description

<ctm>

Name of the Control-M/Server

<remotehost>

Name of host or alias of the remote host

[port]

(Optional) SSH port number.

Default value: 22

[configuration file](Optional) JSON file that contains advanced configuration settings. The remote host is included in the file.

The following example shows the configuration settings contained in the configuration file:

{
    "remotehost" : "xx", 
    "Port" : 22,
    "Agents": [
        "<local>"
    ]
    "EncryptAlgorithm": "BLOWFISH",
    "Compression": "false",
    "Authorize: "true"
}

Where:

Agents

Control-M/Agents that manage the remote host. If not defined, the default Control-M/Agent will be used.

Default: local

PortDefault: 22
EncryptAlgorithm

Encryption algorithm type used to encrypt data between the Control-M/Agent and the remote host. The options are:

  • BLOWFISH
  • AES
  • DES
  • 3DES

Default: BLOWFISH

Compression

true | false

Default: false

Authorize

Enables you to add the machine to the SSL remote host authorization list. If true, you will not be prompted to connect at each attempted connection.

true | false

Default: true

REST API Syntax

See REST API reference.

Example using curl:

REST API
ctm=controlm
remotehost=myhost
agent=realAgent
curl -H "Authorization: Bearer $token" -H "Content-Type: application/json" -X POST -d "{  \"agents\": [    \"$agent\"  ],  \"compression\": true,  \"encryptAlgorithm\": \"BLOWFISH\"}" "$endpoint/run/resource/config/server/$ctm/remotehost/$remotehost?port=22"

config server:remotehost::delete

Deletes a remote host from the Control-M/Server. 

CLI Syntax

CLI
>ctm config server:remotehost::delete <ctm> <remotehost>

Where:

Parameter

Description

<ctm>

Name of the Control-M/Server

<remotehost>

Name of host or alias of the remote host

REST API Syntax

See REST API reference

Example using curl:

REST API
ctm=controlm
remotehost=myhost
curl -H "Authorization: Bearer $token" -X DELETE "$endpoint/config/server/$ctm/remotehost/$remotehost"

config server:remotehosts::get

Returns a list of all remote hosts registered to the Control-M/Server. 

CLI Syntax

CLI
>ctm config server:remotehosts::get <ctm>

Where:

Parameter

Description

<ctm>

Name of the Control-M/Server

REST API Syntax

See REST API reference

Example using curl:

REST API
ctm=controlm 
curl -H "Authorization: Bearer $token" "$endpoint/config/server/$ctm/remotehosts"

config server:remotehost::get

Returns the remote host configuration properties from the Control-M/Server. 

CLI Syntax

CLI
>ctm config server:remotehost::get <ctm> <remotehost>

Where:

Parameter

Description

<ctm>

Name of the Control-M/Server

<remotehost>Name of host or alias of the remote host

REST API Syntax

See REST API reference

Example using curl:

REST API
YOSI - ADD SNIPPET FOR CURL HERE!!

config server:agent::add

Adds a Control-M/Agent to a specific Control-M/Server. This allows the Control-M/Server to run jobs on this host where the agent is installed. Also, it verifies the connectivity between the Control-M/Server and the  Control-M/Agent.

CLI Syntax

CLI
>ctm config server:agent::add <ctm> <host> [port]

Where:

Parameter

Description

<ctm>

Name of Control-M/Server

<host>

Name of host or alias of the Control-M/Agent. This will be registered in Control-M/Server as the logical name of the Control-M/Agent.
[port]

(Optional) SSH port number.

Default value: 22

REST API Syntax

See REST API reference

Example using curl:

REST API
ctm=controlm
host=myhost
port=myport

curl -H "Authorization: Bearer $token" -H "Content-Type: application/json" -X POST -d "{\"host\":\"$host\",\"port\":\"$port\"}" "$endpoint/config/server/$ctm/agent"

config server:agent::delete

Deletes a Control-M/Agent from the Control-M/Server database. This removes the Control-M/Agent from a Control-M/Server without shutting the agent down.

CLI Syntax

CLI
>ctm config server:agent::delete <ctm> <agent>

Where:

Parameter

Description

<ctm>

Name of Control-M/Server

<agent>

Host name or alias of the  Control-M/Agent. This is the logical name of the Control-M/Agent.

REST API Syntax

See REST API reference.

Example using curl:

REST API
ctm=controlm
agent=myhost
curl -H "Authorization: Bearer $token" -X DELETE "$endpoint/config/server/$ctm/agent/$agent"

config server:agent:params::get

Get parameters of a Control-M/ Agent registered to a Control-M/Server. Returns a list of Control-M/Agent parameters. Each entry is a pair which consists of parameter name and value. 

CLI Syntax

CLI
>ctm config server:agent:params::get <ctm> <agent>

Where:

Parameter

Description

<ctm>

Name of Control-M/Server

<agent>

Host name or alias of the  Control-M/Agent. This is the logical name of the Control-M/Agent.

REST API Syntax

See REST API reference.

Example using curl:

REST API
ctm=controlm
agent=host
curl -H "Authorization: Bearer $token" "$endpoint/config/server/$ctm/agent/$agent/params"

config server:agent:param::set

Set the value of a specific Control-M/Agent parameter.

CLI Syntax

CLI
>ctm config server:agent:param::set <ctm> <agent> <name> <value>

Where:

Parameter

Description

<ctm>

Name of Control-M/Server

<agent>

Host name or alias of the  Control-M/Agent. This is the logical name of the Control-M/Agent.

<name>

Name of parameter

<value>Value of parameter

REST API Syntax

See REST API reference.

Example using curl:

REST API
ctm=controlm
agent=quickstart
name=LIMIT_LOG_VERSIONS
value=10
curl -H "Authorization: Bearer $token" -H "Content-Type: application/json" -X POST -d "{\"value\":\"$value\"}" "$endpoint/config/server/$ctm/agent/$agent/param/$name"

config server:agents::get

Returns a list of all Control-M/Agents registered to the Control-M/Server and the state of each agent.

The states supported are:   

  • Available
  • Unavailable
  • Disabled
  • Discovering

CLI Syntax

CLI
>ctm config server:agents::get <ctm>

Where:

Parameter

Description

<ctm>

Name of Control-M/Server

REST API Syntax

See REST API reference.

Example using curl:

REST API
ctm=controlm 
curl -H "Authorization: Bearer $token" "$endpoint/config/server/$ctm/agents"

config server:hostgroups::get

Returns a list of host groups defined in the Control-M/Server. Each entry is a host group name.

Syntax

CLI
>ctm config server:hostgroups::get <ctm>

Where:

Parameter

Description

<ctm>

Name of Control-M/Server

REST API Syntax

See REST API reference.

Example using curl:

REST API
ctm=controlm 
curl -H "Authorization: Bearer $token" "$endpoint/config/server/$ctm/hostgroups"

config server:hostgroup:agents::get

Returns a list of agents of a host group. Each entry is the logical name of an agent.

CLI Syntax

CLI
>ctm config server:hostgroup:agents::get <ctm> <hostgroup>

Parameter

Description

<ctm>

Name of Control-M/Server

<hostgroup>Name of host group

REST API Syntax

See REST API reference.

Example using curl:

REST API
ctm=controlm
hostgroup=HostGroup1 
curl -H "Authorization: Bearer $token" "$endpoint/config/server/$ctm/hostgroup/$hostgroup/agents"

config server:hostgroup:agent::add

Adds a Control-M/Agent to a host group and creates the host group if it doesn't exist.

CLI Syntax

CLI
>ctm config server:hostgroup:agent::add <ctm> <hostgroup> <host>

Where:

Parameter

Description

<ctm>

Name of Control-M/Server

<hostgroup>

Name of host group

<host>

Name of host or alias of the Control-M/Agent. This is the logical name of the Control-M/Agent.

REST API Syntax

See REST API reference.

Example using curl:

REST API
ctm=controlm
hostgroup=mygroup 
host=myhost
curl -H "Authorization: Bearer $token" -H "Content-Type: application/json" -X POST -d "{\"host\":\"$host\"}" "$endpoint/config/server/$ctm/hostgroup/$hostgroup/agent"

config server:hostgroup:agent::delete

Removes a Control-M/Agent from a hostgroup. If the group, after the deletion is empty, it is also deleted.

CLI Syntax

CLI
>ctm config server:hostgroup:agent::delete <ctm> <hostgroup> <host>

Where:

Parameter

Description

<ctm>

Name of Control-M/Server

<hostgroup>

Name of host group

<host>

Name of host or alias of the Control-M/Agent. This is the logical name of the Control-M/Agent.

REST API Syntax

See REST API reference.

Example using curl:

REST API
ctm=controlm
hostgroup=mygroup 
host=myhost
curl -H "Authorization: Bearer $token" -X DELETE "$endpoint/config/server/$ctm/hostgroup/$hostgroup/agent/$host"

config server:params::get

Returns a list of parameters of a Control-M/Server. The following fields are returned:

  • name
  • value
  • defaultValue

CLI Syntax

CLI
>ctm config server:params::get <ctm>

Where:

Parameter

Description

<ctm>

Name of Control-M/Server

REST API Syntax

See REST API reference.

Example using curl:

REST API
ctm=controlm 
curl -H "Authorization: Bearer $token" "$endpoint/config/server/$ctm/params"

Config Secrets

Config secrets allows you to add, delete or update named secrets in the Control-M vault. The Control-M vault is a secured collection of name and value pairs of secrets.

To learn how to use Secrets in Code, see Secrets in Code.

config secret::add

Creates a pair which consists of named secret and value in the Control-M vault.

>ctm config secret::add <name> <value>

Parameter

Description

<name>

Name of the secret

<value>Value of the secret

REST API Syntax

See REST API reference.

Example using curl:

REST API
>curl -H "Authorization: Bearer $token"  -X POST -d "{\"name\":\"$name\",\"value\":\"$value\"}" "$endpoint/config/secret"

config secret::delete

Deletes the pair of named secret and value from the Control-M vault.

>ctm config secret::delete <name> 

Parameter

Description

<name>

Name of the secret

REST API Syntax

See REST API reference.

Example using curl:

REST API
>curl -H "Authorization: Bearer $token"  -X DELETE  "$endpoint/config/secret/$name"

config secret::update

Updates the value of the named secret in the Control-M vault.

>ctm config secret::update <name> <value>

Parameter

Description

<name>

Name of the secret

<value>New value of secret

REST API Syntax

See REST API reference.

Example using curl:

REST API
>curl -H "Authorization: Bearer $token"  -X POST -d "{\"value\":\"$value\"}" "$endpoint/config/secret/$name"

config secrets::get

Returns a list of pairs which consists of named secret and value.

>ctm config secrets::get 

REST API Syntax

See REST API reference.

Example using curl:

REST API
>curl -H "Authorization: Bearer $token"  "$endpoint/config/secrets"

 

The 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 definition file to Control-M. Build will take place as part of the deploy to ensure code validity. deploy can receive definition files in .json format or Control-M import/export .xml format, or a package of multiple job definition files in .zip or .jar format.

CLI Syntax

CLI
>ctm deploy <definitionsFile>

Parameter

Description

<definitionsFile>

The definitions file name

Valid file formats are:

  • .json format
  • Control-M import/export .xml format
  • .zip or .jar

REST API Syntax

See REST API reference.

Example using curl:

curl -H "Authorization: Bearer $token" -X POST  -F "definitionsFile=@examples/AutomationAPISampleFlow.json" "$endpoint/deploy"

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

If not specified default value: JSON

Possible values:

  • JSON
  • XML

-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
  • ctm
  • folder
  • Supported wildcards are *, ?
  • To use multiple criteria separate by using &

ctm=*&folder=*

ctm=*&folder=Auto*

ctm=workbench&folder=AutomationAPISampleFlow

REST API Syntax

See REST API reference.

>curl -k  -H "Authorization: Bearer $token"  "$endpoint/deploy/jobs?ctm=*&folder=Auto*"
 
>curl -k  -H "Authorization: Bearer $token"  "$endpoint/deploy/jobs?ctm=*&folder=Auto*&format=XML"

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

>ctm run jobs:status::get -s "ctm=*&folder=Automation*"

deploy deployed (deprecated)

Exports a deployed folder or folders in a Control-M import/export .xml format. You can use "*"as wildcard character. For example, setting the folder name to "*" will export all folders. Setting the folder name to "A*" will export all folders whose name starts with "A".

Deprecated by deploy jobs::get

CLI Syntax

CLI
>ctm deploy deployed <controlM> <folderName>

Parameter

Description

<controlM>

Name of the Control-M/Server

<folderName>

The folder or folders to export

REST API Syntax

See REST API reference.

Example using curl:

ctm=controlm
folderName=A* 
curl -H "Authorization: Bearer $token" "$endpoint/deploy/deployed/$ctm/$folderName" 

The Package Service

Create a package from a directory of .json and .xml definition files. It returns a .zip archive. This package can be deployed, run, or built by these respective services.

Syntax

>ctm package <zipOutputFilename> <deploymentFilesDirectory>

Parameter

Description

<zipOutputFilename>

The filename of package

<deploymentFilesDirectory>

The directory where the source file reside

Valid file formats are:

  • .json format
  • Control-M import/export .xml format

 

The Provision Service

For Control-M to run and monitor jobs on your application host, a Control-M/Agent should be installed.

The provision service allows you access to the full cycle of installing and setting up a new Control-M/Agent.

It includes the following major commands:

  • Image: prepares the file system installation of the Agent
  • Setup: registers and configures the Agent with a Control-M/Server
  • Install: runs image and setup in a single step

Separating the Image and Setup phases can help in a situation in which installing and setting up Agents dynamically is required by your architecture. In this scenario, you can prepare your image (whether it is a VM image, a Docker image, AWS AMI, etc.) with the Agent inside it. Then when required, use the setup command to dynamically perform Agent setup and register it to the Control-M/Server.

For a more static architecture, where there is no distinction between building an image and instantiation, you can use the provision install command that allows you to install in a single step.

Also, there are commands to remove an image and uninstall a Control-M/Agent from the application host.

To enable provisioning, see the Admin guide

Here is an example of requesting a list of available images and installing one of them.

>ctm provision images Linux -e devEnvironment
[
  "Agent.Linux",
  "BigDataAgent.Linux"
]
 
>ctm provision install Agent.Linux
info:    downloading https://endpoint:8443/automation-api/utils/control-m.services.provision-1.0.0.jar into C:\Users\user\.ctm\control-m.services.provision-9.0.4.jar
0MB/10MB precent: 2%
...

images

Get a list of the images available for a specific OS. Returns a list of image names.

CLI Syntax

CLI
>ctm provision images <os>

Where:

Parameter

Description

<os>

OS can be one of the following:

  • Linux

for Linux 64-bit

  • Windows

for Windows 64-bit

  • Solaris
  • AIX

image

Downloads and installs an image into the current user account. The image is not configured or registered with a Control-M/Server.

CLI Syntax

CLI
>ctm provision image <image>

Where:

Parameter

Description

<image>

One of the images returned by the provision images command

setup  

Connects and registers an image with a Control-M environment.

CLI Syntax

CLI
>ctm provision setup [ctm] [name] [port]

Where:

Parameter

Description

[ctm]

The agent registers to this Control-DM server. If omitted or empty and only one Control-M/Server exists in the system, it will be selected.

[name]

The host name or alias of the Control-M/Agent. This is the logical name of the Control-M/Agent. If omitted or empty, the machine's name will be used.

[port]

This port is used as the Control-M/Agent listening TCP/IP port. If omitted or empty, an available free port will be used.

For example:

provision setup
provision setup ""          ""       2056
provision setup "controlm1" ""       2056
provision setup ""          "alias1" 2056

install 

Combines the image and the setup commands into one action. Downloads the agent and then connects and registers it with a Control-M/Server.

Syntax

>ctm provision install [ctm] [name] [port]

Where:

Parameter

Description

[ctm]

The agent registers to this Control-DM server. If omitted or empty and only one Control-M/Server exists in the system, it will be selected.

[name]

The host name or alias of the Control-M/Agent. This is the logical name of the Control-M/Agent. If omitted or empty, the machine's name will be used.

[port]

This port is used as the Control-M/Agent listening TCP/IP port. If omitted or empty, an available free port will be used.

image::remove

Uninstalls a Control-M image from this user account. The image is removed without unregistering it from a Control-M/Server.

CLI Syntax

CLI
>ctm provision image::remove

uninstall

Uninstalls a Control-M image from this user account and unregisters it from the Control-M/Server.

CLI Syntax

>ctm provision uninstall

The Environment Service

Define and select the Control-M environment to use. An environment is a combination of an endPointusername and password

An endPoint looks like the following: 

https://<controlmEndPoint>:8443/automation-api

For example, to add an environment and name it devEnvironment, use the command below:

>ctm environment add devEnvironment "https://[controlmEndPoint]:8443/automation-api" "[ControlmUser]" "[ControlmPassword]"
 
info:    Environment 'devEnvironment' was
created
info:    devEnvironment:
{"endPoint":"https://[controlmEndPoint]:8443/automation-api","user":"[ControlmUser]"}

show

Returns a list of all defined environments.

CLI Syntax

CLI
 >ctm environment show

add

Adds a new environment.

CLI Syntax

CLI
 >ctm environment add <env> <endPoint> <user> <password>

Where:

Parameter

Description

<env>

Environment name

<endPoint>

Control-M REST API endPoint

 

<user>

Control-M username

 

<password>

Control-M password

set 

Sets the default environment for interactive work. All commands are sent to this environment unless a different environment is defined using the -e option.

CLI Syntax

CLI
 >ctm environment set <env>

Where:

Parameter

Description

<env>

Environment name

delete

Deletes an environment.

CLI Syntax

CLI
 >ctm environment delete <env>

Where:

Parameter

Description

<env>

Environment name

update

Updates an environment property. The property <name> can be an endPoint, username, or password. If an environment doesn't exist, it will be created.

CLI Syntax

CLI
 >ctm environment update <env> <name> <value>

Where:

Parameter

Description

<env>

Environment name

<name>

Can be one of the following:

  • endPoint
  • user
  • password

<value>

Parameter value

 

copy 

Duplicates an environment. 

CLI Syntax

CLI
 >ctm environment <env> <newEnv>

Where:

Parameter

Description

<env>

Environment name

<newEnv>

Name of the new environment

load 

This command allows you to load a predefined env.json to your environment definitions. Environments are kept in the user home folder ~/.ctm/env.json on Linux and %USERPROFILE%\.ctm\env.json in Windows. 

CLI Syntax

CLI
 >ctm environment load <enviromentsFile>

Where:

Parameter

Description

<enviromentsFile>

An env.json file

configure

This command allows you to set  parameters for all environment.

CLI Syntax

CLI
 >ctm environment configure <setting name> [setting value]

Where:

Parameter

Description

<setting name>

Parameter name

[setting value]

Parameter value

Possible parameters:

 

ParameterValueDefaultDescription
rootCertificateRequiredfalse | truefalse

Disable API calls using self signed HTTPS certificate.

By default self signed certificate is allowed.

 


The Session Service

Session service allows you to login and logout to Control-M and receive a token that can be reused in subsequent requests.

session login

Login to Control-M and return a session token that can later be used for subsequent requests using the -t option. 

A token is valid for 30 minutes.

>ctm session login
{
  "username": "emuser",
  "token": "d6ad05ecbee1dd74bf100447ed2be5d6_D749761E",
  "version": "9.0.4"
}


>ctm config servers::get -t "d6ad05ecbee1dd74bf100447ed2be5d6_D749761E"

session logout

Logout from the user session defined by the given token.

>ctm session logout <token>

Field

Description

<token>

The token obtained by the session login request

Using the CLI

The CLI allows you work interactively or write scripts for automation. To access the CLI, open a terminal or command window and enter ctm. The first level help is displayed verifying that the CLI is properly installed. See Control-M Automation API - Installation.

>ctm
help:
help:    Display help for a given command
help:      help [command]
help:
help:    Commands:
help:      build          Compile definitions to verify they are
ol-M
help:      config         Configure the Control-M environment
help:      deploy         Submit definitions to Control-M
help:      documentation  Get documentation
help:      environment    Define and select the Control-M enviro
help:      local          Start and Stop local Development bench
help:      package        Package a directory of definition file
ble archive
help:      provision      Install Control-M components
help:      run            Run and track CTM jobs
help:      examples        Manage data examples
help:      session        Manually maintain Control-M user sessi
help:
help:    Options:
help:      -h, --help     output usage information
help:      -v, --version  output the application version

Getting Help

The CLI has built-in help. Typing ctm with no other parameters or commands displays the main Help page.
You can get help on any command by entering the command (add -h will also fetch help). To get the CLI version, type ctm -v.

Managing CLI Environments

The first task when starting to work with Control-M Automation API is to the configure Control-M environment you are going to use. An environment is a combination of a REST API endPointusername and password. More than one environment can be configured. This allows you to automate multiple Control-M/Servers. You can also configure one environment as the default.

An endPoint looks like the following: 

https://<controlmEndPoint>:8443/automation-api

The command below show how to add an environment named devEnvironment and the reponse:

>ctm environment add devEnvironment "https://<controlmEndPoint>:8443/automation-api" "[ControlmUser]" "[ControlmPassword]"
 
info:    Environment 'devEnvironment' was
created
info:    devEnvironment:
{"endPoint":"https://<controlmEndPoint>:8443/automation-api","user":"[ControlmUser]"}

Environments are are kept in the user home folder ~/.ctm/env.json on Linux and %USERPROFILE%\.ctm\env.json in Windows. 

Once configured, you can set a default environment for interactive work as follows:

ctm environment set devEnvironment
ctm  build  jobs.json		
ctm  run    jobs.json
ctm  deploy jobs.json

To automate multiple Control-M environments, you can specify a specific environment regardless of the default using the -e option. 

ctm  deploy jobs.json -e TestEnvironment		
ctm  deploy jobs.json -e QAEnvironment

Short Naming of Commands

You do not have to type an entire command as long as it's unique. Entering a short version will execute the command.

ctm  environment show		
ctm  env 		 show
ctm  env 	     sh

CLI Return Codes

The CLI returns the following codes:

  • 0 on success
  • 1 on failure
#!/bin/bash
if ! ctm deploy jobs.json; then
     printf '%s\n' 'ctm: failed!' >&2;    
fi

Working with the REST API

The REST API allows you to programmatically automate Control-M via REST API requests. Request URIs are composed of a Control-M endPoint and the API command. All requests must include an authentication token in the HTTPS header. To obtain a token, you must use the session/login request.

Note: Control-M Automation API comes with a self signed SSL certificate. With all curl commands, you can add -k to not reject the certificate.

The Control-M Automation REST API Reference

Click the following link REST API reference to see the full REST API reference generated with Swagger.

Authentication

Use a POST /session/login request to obtain a login token. A token is valid for 30 minutes. The credentials are posted in the request body in JSON format. POST data looks like the following:

{"username": "<controlMUser>", "password": "<controlMPassword>"}

On success, the request returns the following:

{
    "username":"<ControlMUsername>",
    "token":"97357564b0de945c6cdb482d61cbbd7c_96DBD659"
}

Any additional API calls require the HTTPS header 'Authorization': 'Bearer ' + token.  For example:

Authorization: Bearer 97357564b0de945c6cdb482d61cbbd7c_96DBD659

The following example shows you how to log in using using curl:

endpoint=https://<controlmEndPoint>:8443/automation-api
user=[USER]
passwd=[PASSWORD]

# Login
login=$(curl -H "Content-Type: application/json" -X POST -d "{\"username\":\"$user\",\"password\":\"$passwd\"}"   "$endpoint/session/login" )
echo $login
token=$(echo ${login##*token\":\"} | cut -d '"'-f 1)
echo $token


The following example shows you how to login in Python:

import requests  # pip install requests if you don't have it already

endPoint = 'https://<controlmEndPoint>:8443/automation-api'

user = '[ControlMUser]'
passwd = '[ControlMPassword]'

# -----------------
# login
r_login = requests.post(endPoint + '/session/login', json={"username": user, "password": passwd})
print(r_login.content)
print(r_login.status_code)
if r_login.status_code != requests.codes.ok:
    exit(1)

token = r_login.json()['token']
 
r = requests.get(endPoint + '/config/server', headers={'Authorization': 'Bearer ' + token})
print(r.content)
print(r.status_code)
exit(r.status_code == requests.codes.ok)


REST STATUS Codes

On success, REST returns status 200.

On failure, REST returns 400, 404 or 500 HTTPS status codes

  • 400 stands for errors in the request data
  • 404 is when the defined item wasn't found
  • 405 is returned when submitting unrecognized REST method ('login' instead of 'session login')
  • 500 if for an internal error in the server.

JSON Returned on Error

In case of error, the returned JSON contains an array of errors in the following format:

{ 
  message: string, // The text of the error
  id: number, // An internal identifier of the error (e.g. rule number in case of validation error)
  item: string, // The item referenced in the error (if relevant)
  file: string, // Error location file
  line: number, // Error location line number
  col: number // Error location column number
}

For example, an error response to /build API:

{
	"errors": [
		{
			"message": "MainArguments is an unknown keyword therefore it is assumed to be a an object, but it has no object syntax",
			"file": "Spark.json",
			"line": 5,
			"col": 22
		},
		{
			"message": "SparkCommandLineOptions is an unknown keyword therefore it is assumed to be a an object, but it has no object syntax",
			"file": "Spark.json",
			"line": 9,
			"col": 32
		}
	]
}

REST VERBS

The following verbs are used:

GET resource 

The following example shows you how to GET specific resource data using bash and curl:

# Get list of servers
curl -H "Authorization: Bearer $token" "$endpoint/config/servers"
 
#Get list of hostgroups of a specific $
ctm=controlm
curl -H "Authorization: Bearer $token" "$endpoint/config/server/$ctm/hostgroups"

The following example shows you how to GET specific resource data using Python:

import requests  # pip install requests if you don't have it already

endPoint = 'https://<controlmEndPoint>:8443/automation-api'
r = requests.get(endPoint + '/config/server', headers={'Authorization': 'Bearer ' + token})

print(r.content)
print(r.status_code)
exit(r.status_code == requests.codes.ok)

POST a new resource

The following example shows how to POST new resource data:

# Adding a new agent to a hostgroup 
 
ctm=controlm
hostgroup=HostGroup1
agent=myhost2


curl -H "Authorization: Bearer $token" -H "Content-Type: application/json" -X POST -d '{"host":"$agent"}'  $endpoint/config/server/$ctm/hostgroup/$hostgroup/agent"

POST to upload a file

The following example shows you how to POST a new file of data in bash and curl.

# deploy job definition file 
 
curl -H "Authorization: Bearer $token" -X POST  -F "definitionsFile=@examples/AutomationAPISampleFlow.json" "$endpoint/deploy"

Th following example shows how to POST a new file of data with Python:

import requests  # pip install requests if you don't have it already
 
endPoint = 'https://<controlmEndPoint>:8443/automation-api'
 
user = '<ControlMUser>'
passwd = '<ControlMPassword>'
 
# -----------------
# login
r_login = requests.post(endPoint + '/session/login', json={"username": user, "password": passwd})
print(r_login.content)
print(r_login.status_code)
if r_login.status_code != requests.codes.ok:
    exit(1)
 
token = r_login.json()['token']
 
# -----------------
# Built
uploaded_files = [
        ('definitionsFile', ('Jobs.json', open('c:\\src\ctmdk\Jobs.json', 'rb'), 'application/json'))
]
 
r = requests.post(endPoint + '/deploy', files=uploaded_files, headers={'Authorization': 'Bearer ' + token})
 
print(r.content)
print(r.status_code)
 
exit(r.status_code == requests.codes.ok)

DELETE  a resource

The following example shows you how to DELETE a resource:

#deleting an agent from a hostgroup
 
ctm=controlm
hostgroup=HostGroup1
agent=myhost1

curl -H "Authorization: Bearer $token" -X DELETE "$endpoint/config/server/$ctm/hostgroup/$hostgroup/agent/$agent"

Difference between REST API and CLI Syntax

The CLI and API can execute the same commands, but use different syntax to represent the commands. The REST APIs are expressed in path notation, while the CLI commands are structured differently. The following examples illustrate the differences.

Below is an example of getting list of host groups of a specific '{'ctm'}' Control-M/Server. The specific Control-M/Server is a parameter that is part of the resource URL of the REST API call.

REST API
GET /config/server/{ctm}/hostgroups

Below is the equivalent CLI command where the resource path is separated using ':'  as in server:hostgroups the get action is separated using '::' and parameters are defined after the action.

CLI
>ctm config server:hostgroups::get <ctm> 
Was this page helpful? Yes No Submitting... Thank you