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 Name | On-prem Field Name | Description | |
---|---|---|---|
1 | eventType | call_type | The type of event that triggered the alert:
|
2 | id | alert_id | A numeric value that uniquely identifies the alert (also known as the key or index) |
3 | server | data_center | Name of the Control-M/Server that the job is associated with Value in Helix Control-M: IN01 |
4 | fileName | memname | File name of the job (previously known as the member name) |
5 | runId | order_id | A numeric value that uniquely identifies the job run |
6 | severity | severity | Severity of the alert:
|
7 | status | status | Status of alert handling:
|
8 | time | send_time | Time and date that the alert was issued. Format: yyyymmddhhmmss |
9 | user | last_user | Name of the user who last modified the status or text of the alert |
10 | updateTime | last_time | Time and date that the alert was last modified by the user Format: yyyymmddhhmmss |
11 | message | message | Full text of the alert |
12 | runAs | run_as | The Run As user set as owner of the job |
13 | subApplication | sub_application | Sub Application of the job (previously known as group) |
14 | application | application | Application of the job |
15 | jobName | job_name | Name of the job |
16 | host | host_id | Node or host where the job is run |
17 | type | alert_type | Alert type:
Default: R |
18 | closedByControlM | closed_from_em | (Deprecated* in Helix Control-M) Whether a ticket was closed from Control-M/EM (on-prem). Values: Y (yes) or N (no) |
19 | ticketNumber | ticket_number | (Deprecated* in Helix Control-M) A ticket number associated with the alert |
20 | runNo | run_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. |
21 | notes | notes | 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"}
]
}
Comments
Log in or register to comment.