Notification (CALL)
Notification objects are customized messages and requests that can be assigned to other executable objects. When the execution of an object triggers a Notification, either an e-mail or an online message is sent. The Notification provides information or requires user interaction as a reaction to the execution of the object.
As an administrator or as a developer and object designer, you create Notifications and assign them to executable objects. There are four different templates for creating Notifications, depending on the type of content you need. For each template you can choose the message type, which further determines the content.
As an operator, you receive Notifications and react to them accordingly. They are either e-mails or online messages. You access the online messages through the Requests area in the menu bar. For more information, see Requests.
Example: A Job usually needs few minutes to finish successfully. If it takes longer, something might have gone wrong. You want to be informed of this situation as soon as possible. For this purpose, you create a Notification object and assign it to the Job. You do this in the Actions on Runtime Deviations section on the Runtime Page of the object definition.
Object class: Executable object
Object type/Short form: CALL
Default Object Templates: ALARM, MAIL, STANDARD, SLM
This page includes the following:
Notification Templates
When you create a Notification object, you must select a template: ALARM, MAIL, SLM or STANDARD. All templates except STANDARD come with some predefined settings and a template-specific script on the Process page. You can change the predefined settings.
Content
The script determines the content of the message that is sent. The script uses script variables that read data (task name, runID, and so forth) from the objects that they refer to, and write it to the message text. The message text is delivered in the language that you have selected at login.
When you define the settings of the Notification object, you select the type of message that it will send. It can be Request, Message, Alert or E-mail.
-
Request
Requests can be online messages or e-mails. The recipients can accept or reject them. Requests can be escalated.
-
Message
Messages can be online messages or e-mails. They can only be acknowledge by the receivers. Messages cannot be escalated.
-
Alert
Requests can be online messages or e-mails. The recipients can accept or reject them. Alerts can be escalated.
-
When accepting the request, the receiver takes responsibility for resolving it
-
If the receiver or the last of several receivers rejects the request, or if they do not react within the specified period of time, the following can happen:
- If you have configured the object to send an escalation Notification object, it is sent
- If you have not configured an escalation, the original Notification is sent again
-
-
E-mail
E-mail notifications cannot be escalated
Escalation
You can configure Alerts and Requests to triggers an escalation. Given certain conditions (the request that they send remains unattended or is rejected), another Notification object is sent.
ALARM
The ALARM template is designed to produce requests in case situations in which you want to send an alert message. The user who executes the object to which the ALARM is assigned is automatically specified as the receiver of the message.
Predefined Settings
The following parameters are set by default on the Notification page:
- Type = Alert
- Priority = High
- Attach Reports = &UC_CAUSE_NR
- Script on the Process page
For script examples, see Examples of Notification Object Scripting.
MAIL Notifications are templates for sending e-mail messages.
Prerequisites
-
The e-mail connection must be set up correctly in the UC_CLIENT_SETTINGS variable
-
The following keys must be set in the UC_CLIENT_SETTINGS VARA object:
- SMTP_FROM_ADDR
- SMTP_SERVER
For more information, see UC_CLIENT_SETTINGS - Various Client Settings.
Predefined Settings
The following parameters are set by default in the Notification page. You can change them, if necessary:
- Type = E-mail
- Priority = High
- Attach Reports = &UC_CAUSE_NR
SLO objects specify actions that the system should carry out if a service (executable objects) is fulfilled/not fulfilled. Sending Notifications is one of the possibilities.
The following SLM Notification templates are available and ready to use:
-
FULFILLMENT_MAIL Notification
This template builds an e-mail
-
FULFILLMENT Notification
This template builds a request.
Predefined Settings
The Automation Engine provides the following script variables in relation with SLO objects. They retrieve data from the monitored services. They also provide the reasons why the required criteria were not fulfilled:
- &uc_slm_slo_name#
- &uc_slm_service_name#
- &uc_slm_service_runid#
- &uc_slm_service_time#
- &uc_slm_violation_msg_number#
- &uc_slm_violation_msg_insert#
For more information, see Service Level Objective (SLO).
STANDARD
STANDARD Notifications are useful if you want to define your own messages.
Predefined Settings
The following parameters are set by default in the Notification page:
- Type = Request
- Priority = High
A Notification object definition is made up of the following pages:
- Standard pages that are always available, no matter what type of object you are defining:
- Additional pages that are always available for executable objects:
- The object-specific page described here.
To Define the Notification-Specific Settings
-
On the Notification page, define the Recipients of the notifications.
The script in ALARM Notifications is configured to set the user who executes the object as recipient of the messages. You can specify additional ones here.
Allowed input: Select a User or pick a variable
- In Recipients, select a User or a User Group. Either type the name of the user or select it from the list. You can also enter an e-mail address.
- Optionally, select a Calendar and one of the Calendar events that are assigned to it. The Notification is sent when this Calendar condition applies.
- Click Add to assign this combination of recipients and dates. You can add as many combinations as you need.
-
If you select a template other than STANDARD, the Subject and body of the text in the Message section are predefined.
To change them, do the following:
-
Type the Subject or click the variable icon to insert one. If you leave it empty, an e-mail subject is created automatically. This subject is as follows:
Name of the Notification object + RunID + Client.
- Enter the body of the Message. You can use variables. There is no limit as to the number of characters you can use.
Important! If you create your texts using the Automation Engine scripting language on the Process page, these settings are ignored.
-
-
The Settings vary depending on the selected template.
- The Priority serves for information purposes only. It is displayed in the e-mails and in the online messages.
- The Type determines how it is sent and whether it can be escalated or not.
-
Optionally, activate SNMP connection to create an SNMP trap when a Notification starts.
Prerequisites:
- SNMP must be installed on the computer and must run as a service.
- The AE SNMP sub Agent must be installed.
- The SNMP connection must be activated in the Automation Engine INI file (ucsrv.ini) by setting the SNMP parameter to
snmp=2
.
This option is not available for e-mail Notifications.
Tip: Use the state of the art JMX solution rather than the SNMP technology. SNMP uses the less secure UPD network protocol and does not support the whole range of AE functions.
-
Activate Send Additional E-mail to inform the users (recipients of the message) that the Notification has been triggered. The addresses in the User object definitions are applied. If two addresses have been defined for the responsible User, the e-mail is sent to both of them.
You can also specify that reports should be attached to the e-mail:
-
(Job objects only) In Attach Reports, enter the RunID of the task that triggered the e-mail.
A file is sent per report type. The name of the file is as follows:
RunID.report type.txt.
Example:002523059.LOG.txt.
The Source options are displayed, where you indicate where the reports should be taken from:
-
Database
Only the default Job reports that are stored in the Automation Engine database are attached.
-
External Files
Files that are stored in the Agent computer are attached. This also applies to the Job report if it has been stored as a file. It applies to registered output files too, if available.
The recipient must have the Access to reports right for external reports (EXTREP) and Jobs. Otherwise, the files are not attached and an error message is written to the notification report.
The Agent on which the Job has been executed must be active and the files must exist.
-
All
Both reports from the database and from the Agent computer are attached. If the same report is available in both, it is sent only once.
If data is available in the Agent, two e-mails are sent, one from the Automation Engine and another one from the Agent.
-
-
In AE Attachment, specify the path and the name of the file that should be attached. It must be stored in a directory that can be accessed by the E-mail connection.
Maximum length: 255 characters. If you use variables, the length of the path must not be longer than 255 characters when the variables are resolved.
-
-
The Escalate option is not available for e-mail Notifications. For all others, you can define the time after which a second Notification is sent if there is no response.
- If you activate Quit current Notification, sending the follow-up Notification automatically closes the original one with the status ENDED_ESCALATED.
Triggering Notifications
You can configure objects to send Notifications as follows:
-
Runtime Page
When you define the general settings of an executable object, you can assign it a maximum and a minimum runtime. If the time required to execute the object deviates from these values, you can have the system execute a task. This task can be a Notification object. The same applies to the runtimes of tasks in Workflows or Schedules. -
Output Pages in Jobs
When defining the output, you can specify a status and tell the system to send a Notification when they are reached. -
Attributes Page
For Workflows (JOBP), Schedules (JSCH) and Remote Task Monitor (JOBQ). You can have the system execute a Notification object when a task has a certain status. -
Process Pages
You can use the Automation Engine scripting language on these pages to create customized Notifications. Click here for Examples of Notification Object Scripting. -
Result properties of tasks in Schedules
In the Result tab of a task properties you define what should happen with the task depending on its status after execution. You can also specify that a Notification object is executed depending on the status of the task. For more information, see Defining Schedule Objects.
-
Time & Dependencies properties of tasks in Workflows
Usually, tasks in Workflows start as soon as their predecessors have finished. However, you can define multiple parameters in their properties that affect the task sequence in the Workflow. On the Time & Dependencies properties tab you define time and status parameters that affect when a task actually starts. You can also specify that another object (for example, a Notification) is executed if these parameters are not met. For more information, see Time & Dependencies.
-
Runtime properties of tasks in Schedules and in Workflows
On the Runtime page of executable objects, you define the parameters to calculate the maximum and minimum runtimes of tasks. If there are deviations, you specify what should happen. You can change these definitions when the task is executed from within a Schedule or a Workflows. You can also specify that a Notification object is executed if there are deviations. For more information, see Defining Schedule Objects and Runtime Properties (for Workflows).
Information from the Read Buffer
Notification that start as a result of the conditions that are defined for tasks in Workflows or Schedules contain detailed system information. This information can be read in the script of the Notification from the Read Buffer. For this purpose, the :READ script statement is used.
- UC_CAUSE_NAME - The name of the causing task.
- UC_CAUSE_NR - The RunID of the causing task.
- UC_CAUSE_STATE - The status of the causing task.
- UC_CAUSE_RETCODE - The return code of the causing task.
Examples
:READ &UC_CAUSE_NAME,,
:READ &UC_CAUSE_NR,,
:READ &UC_CAUSE_STATE,,
:READ &UC_CAUSE_RETCODE,,
Reacting to Notifications
If there are messages or requests that you should process, the notifications area on the menu bar draws your attention to them, see Requests.
Depending on the type of notification you receive, there are various ways to react to them:
-
Requests
Messages are sent to the Notification bar. They can be accepted or rejected.
-
Messages
Messages are sent to the Notification bar too and users can accept or reject them. Optionally, they can also be sent through e-mail.
Rejecting an alert triggers the escalation based on the time settings you define.
When accepting the alert, the recipient takes responsibility for resolving the problem.
-
Alerts
Messages are sent to the Notification bar as well and users can accept or reject them. Optionally, they can also be sent via e-mail.
Rejecting an alert message triggers the escalation based on the time settings you define.
When accepting the alert, he recipient takes responsibility for resolving the problem.
-
E-mails
No escalation is available for this Notification type. E-mail Notifications are not displayed in the Notification area.
Important! The e-mail connection must be set up in the UC_CLIENT_SETTINGS variable.
See also:
- Examples of Notification Object Scripting
- Watch the Video
- Notification Attributes
- UC_CLIENT_SETTINGS - Various Client Settings
Reacting to Notifications: