New Documentation

   

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

Alerts Template reference

This topic discusses the details of external alerts that are sent from Helix Control-M and how you can control these details through the use of templates.

Default Fields in External Alerts

The following table lists the default alert fields provided by Helix Control-M.

Note: This table also includes the names of the corresponding fields in Control-M (on-premises), in case you are migrating from Control-M to Helix Control-M.


Field NameOn-prem Field Name Description
1eventTypecall_type

The type of event that triggered the alert:

  • I — newly issued alert
  • U — update of an existing alert 
2idalert_id

A numeric value that uniquely identifies the alert (also known as the key or index)

3serverdata_center

Name of the Control-M/Server that the job is associated with

Value in Helix Control-M: IN01

4fileNamememname

File name of the job (previously known as the member name)

5runIdorder_id

A numeric value that uniquely identifies the job run

6severityseverity

Severity of the alert:

  • V: Very urgent
  • U: Urgent
  • R: Regular
7statusstatus

Status of alert handling:

  • 0: Not noticed
  • 1: Noticed
  • 2: Handled
8timesend_time

Time and date that the alert was issued.

Format: yyyymmddhhmmss

9userlast_user

Name of the user who last modified the status or text of the alert

10updateTimelast_time

Time and date that the alert was last modified by the user

Format: yyyymmddhhmmss

11messagemessage

Full text of the alert

12runAsrun_as

The Run As user set as owner of the job

13subApplicationsub_application

Sub Application of the job (previously known as group)

14applicationapplication

Application of the job

15jobNamejob_name

Name of the job

16hosthost_id

Node or host where the job is run

17typealert_type

Alert type:

  • R — Regular
  • B — SLA

Default: R

18closedByControlMclosed_from_em

(Deprecated* in Helix Control-M) Whether a ticket was closed from Control-M/EM (on-prem).

Values: Y (yes) or N (no)

19ticketNumberticket_number

(Deprecated* in Helix Control-M) A ticket number associated with the alert

20runNorun_counter

A numeric value that uniquely identifies the job execution instance

This counter is relevant for jobs that run more than once on a scheduling day.

21notesnotes

The note text associated with the alert

* In the case of a migration from Control-M (on-premises) to Helix Control-M, backward compatibility for this field enables you to continue using the same scripts for external alert handling.

Setting Fields Using a Template

You can use the run alerts:stream:template::set command to submit a JSON-format template that overrides the default combination of fields provided by Helix Control-M. In this template you control the following:

  • Which fields to include in an alert (a subset of the default fields)
  • The names of the fields in an alert
  • Order of appearance of the fields in an alert

The following sample template sets a group of 5 fields of alert details. Of these 5 fields, 3 fields are given new names and 2 fields remain with their original names.

{
    "fields":
    [
        {"id":"alertId"},
        {"application":"businessUnit"},
        {"message":"message"},
        {"time":"date_and_time"},
        {"jobName":"jobName"}
    ]
}

The following alert includes the fields defined in the sample template described above, in the same order of appearance:

{
    "fields":
    [
        {"alertId":"650"},
        {"businessUnit":"ACCT"},
        {"message":"SHOUT TO Alertscript FAILED Shout to Destination Alertscript failed."},
        {"date_and_time":"20220120070014"},
        {"jobName":"J1"}
    ]
}

Changing Field Names After Migrating from On-premises Control-M

If you are migrating from Control-M (on-premises) to Helix Control-M and want to continue using the same scripts to handle external alerts, change the names of all fields to their old names in Control-M (on-premises). 

The following template renames all fields to their old names in Control-M (on-premises):

{
  "fields":
  [
    {"eventType":"call_type"},
    {"id":"alert_id"},
    {"server":"data_center"},
    {"fileName":"memname"},
    {"runId":"order_id"},
    {"severity":"severity"},
    {"status":"status"},
    {"time":"send_time"},
    {"user":"last_user"},
    {"updateTime":"last_time"},
    {"message":"message"},
    {"runAs":"run_as"},
    {"subApplication":"sub_application"},
    {"application":"application"},
    {"jobName":"job_name"},
    {"host":"host_id"},
    {"type":"alert_type"},
    {"closedByControlM":"closed_from_em"},
    {"ticketNumber":"ticket_number"},
    {"runNo":"run_counter"},
    {"notes":"notes"}
  ]
}

Restoring All Default Fields

You can use the following template to restore the default fields (as listed in Default Fields in External Alerts) after you have made any changes to the fields in your external alerts.

{    
	"fields": [
		{"eventType": "eventType"},
		{"id": "id"},
		{"server": "server"},
		{"fileName": "fileName"},
		{"runId": "runId"},
		{"severity": "severity"},
		{"status": "status"},
		{"time": "time"},
		{"user": "user"},
		{"updateTime": "updateTime"},
		{"message": "message"},
		{"runAs": "runAs"},
		{"subApplication": "subApplication"},
		{"application": "application"},
		{"jobName": "jobName"},
		{"host": "host"},
		{"type": "type"},
		{"closedByControlM": "closedByControlM"},
		{"ticketNumber": "ticketNumber"},
		{"runNo": "runNo"},
		{"notes": "notes"}    
	] 
}
Was this page helpful? Yes No Submitting... Thank you

Comments