A notification can be activated in various ways. For example:
Object |
Description |
Tab |
---|---|---|
Notification |
There is no reaction to the notification within the specified time. |
Notification |
RemoteTaskManager, Workflow and Schedule object |
One or several individual tasks do not have the specified end status. |
Attributes |
All executable objects |
Runtime specification does not apply. |
Two places on runtime |
Workflow and Schedule tasks |
Runtime specification does not apply. |
Runtime in the object's properties |
Workflow and Schedule task |
Task does not end on the specified status. |
Result in the object's properties |
Workflow |
Task has not yet started at the checking time. |
Checkpoint in the object's properties |
Workflow | Preceding workflow tasks do not end on the specified status. | Dependencies in the object's properties |
Workflow task | A condition action executes a notification. | Preconditions or Postconditions |
Jobs |
Task Output Scan requirements met. |
Output Scan |
If a notification starts as a result of the above mentioned conditions of tasks in Workflow or Schedule objects, detailed system information is made available. This information can be read in the script of the notification from the Read Buffer with the script statement :READ. Please bear in mind that this is only possible when the notification was not activated with the setting "Generate at runtime" in the Attribute tab!
Examples
:READ &UC_CAUSE_NAME,,
:READ &UC_CAUSE_NR,,
:READ &UC_CAUSE_STATE,,
:READ &UC_CAUSE_RETCODE,,
You can of course also start a notification manually or using the script function ACTIVATE_UC_OBJECT.
If a notification is activated, the defined operators are informed. Additionally, calendar specifications are taken into account. If no responsible operator is specified in the calendar, all operators are alerted.
Message, Request, Alert and E-mail are the notification types. The type defines expected responses from the operator.
Message:
A message can only be acknowledged by the receiver. There is no escalation.
Request:
An alert can be either accepted or rejected. The result of the question can be evaluated, although it does not escalate to another notification in this case. If the receiver is not reached within the defined time period or the escalation is not scheduled, only a time-dependent escalation is possible.
Alert:
An alert can be either accepted or rejected. Depending on the response,
there are different types of reactions.
If the receiver accepts the alert, he/she takes responsibility to resolve
the problem.
If the receiver or the last of several receivers rejects the alert, the
escalation begins.
If the receiver(s) is/are not reached within the defined time frame, only
a time-dependent escalation is possible. If an escalation is not defined,
the notification is called again.
Email:
The notification is only used to send an email. No monitor is displayed in the UserInterface.
For technical reasons and very rarely it happens that an email is sent to a receiver several times.
Escalation:
With every escalation, another notification is started. An alert, message or request will also be opened. Other users can then be informed and react to an incidence.
You can set the escalated notification to automatically closes its predecessor with the status ENDED_ESCALATED in the Operator tab. Afterwards, only the users who have been informed by this notification can react to the incidence.
SNMP Connection:
If defined in the Attributes tab, an SNMP trap is also created with the start of a notification.
There are three requirements for an SNMP connection:
Sending email:
If defined in the Attributes tab, the defined operators are also informed via email with the start of notification.
The email is sent in addition to the defined message, request or alert. The email contains the name of the notification, its RunID and the client in the subject field. The message text of the notification is used as text.
For technical reasons and very rarely it happens that an email is sent to a receiver several times.
Monitor
Notification executions can be observed in the Monitor View which displays the status.