Triggering Alerts
Alert sources define which objects create alerts, under which circumstances and which alert to send. By default, the only response to an alert operator message is Acknowledge. This can be changed on the alert source.
The following types of alert sources are available:
- process alert sources - defines the situations in which specific processes raise alerts.
- monitor alert sources - defines the situations in which monitors raise alerts.
- process servers alert sources - defines the situations in which specific process servers raise alerts.
- AdHoc alert sources - used in chains, for example, with the System_Alert_Send process definition.
Each alert source uses specific rules to determine:
- when an alert needs to be raised, specifc to each alert source type
- the escalation to use
- the message to send
The following topic covers features that are shared by all alert sources.
Context-Menu
Alert sources support the following context-menu actions:
Action | Description |
---|---|
Edit Security | Edit the security of the alert source |
Duplicate | Make a copy of the alert source to create a similar one |
Delete | Delete the alert source |
Export > Export | Export the alert source into a CAR file |
Export > Export with related objects | Export the alert source into a CAR file including referenced objects |
Promote > Promote to system | Promote the object to a remote system |
Promote > Edit further then promote | Edit the export rule set prior to promoting |
Promote | Promote the alert source to another Redwood Server instance |
Edit | Edit the alert source |
Show permalinks | Show links that can be used from third party applications to link to the object |
Add to navigation bar | Add the current object to the navigation bar |
New alert source | Create a new alert source |
Show diagram | Display the dependencies in a diagram |
Filter > New Filter | Create a new alert source filter |
Filter > Edit Filter | Edit current alert source filter |
Filter > Delete | Delete current alert source filter |
Filter > Duplicate Filter | Create a copy of the filter |
Filter > Export Filter | Export the filter into a CAR file |
Filter > Add to navigation bar | Add the filter to a navigation bar |
Filter > Create filter from search | Create a filter from the current IntelliSearch query |
Alert Source Emails
Gateways will always attempt to use the most specific email and email address, the search is done in the following order:
- Specific alert source.
- Gateway.
- Default.
The email type is detected by the first letter, if the first letter is a <
, then the email type is set to HTML, otherwise a text email is sent. You can use specific constructs using REL expressions in your emails. For more information, see Customizing Emails.
Email Addresses and Aliases
The value of the Email Address field specified on the alert source is used to determine the email alert gateway and the addressee(s). You specify either an email address or an alias, such as alias:operators
. When you specify an alias in the Email Address field, the alias is used to lookup the email alert gateway, only, and will not be used as a recipient address.
The list of recipients should be maintained on the email alert gateway on the Headers tab; if an email address was specified in the Email Address field of the alert source (it does not start with alias:
), this will be added as well. Multiple headers with the same name are supported, Redwood Server will combine them all to one.
The following table provides a few examples; for simplicity, it is assumed that the email alert gateway Address Pattern matches the value of the alert source Email Address field.
Alert Source - Email Address Field | Alert Source - Email Tab | Email Alert Gateway - Headers Tab | Email Alert Gateway - Email Tab | Result |
---|---|---|---|---|
alias:development | <none defined> | to:jdoe@example.comto:jsmith@example.comcc:emustermann@example.com | to:cberthier@example.com | to:jdoe@example.com, jsmith@example.com, cberthier@example.comcc:emustermann@example.com |
cberthier@example.com | to:jsmith@example.com | to:jdoe@example.com | cc:emustermann@example.com | to:cberthier@example.com, jsmith@example.com, jsmith@example.com |
Customizing Alert Source Emails
You can customize emails on the Alert Source Email tab, using the following two constructs:
- conditional evaluation
- REL expressions (without the equals (
=
))
Conditional Evaluation
[?if test="expression"?]
text
[?endif?]
REL Expressions
[?=expression?]
Substitution Parameters for use in Emails
The following substitution parameters can be used in emails:
${<object>.name}
- Name of (ie.getErrorName()
) the object,${<object>.url}
Link to the object (permalink URL),${<object>.link}
Fully formed link:<a href="link">name</a>
Where <object>
can be one of the following:
object
- the alertoperatorMessage
- the operator message of the alert
The following alert was not replied to in a timely manner: `${operatorMessage}`. Please check the following: `${operatorMessage.link}`.
Example
<html>
<head><title>Email</title></head>
<body>
[?if test="alertSourceType === 'AdHocAlertSource'"?]
Ad hoc alert data: [?=data?]
[?endif?]
Link <a
href="http://prd1.example.com:50200/redwood/api-permalink/show?link-objecttype=[?=alertSourceType?]&link-uniqueid=[?=alertSourceUniqueId?]">alert source</a>
</body>
</html>
note
Only ad hoc alert sources can resolve the data
parameter in the Email body, Processes alert sources, for example, cannot resolve process parameters in an email body.
Alert Source Actions
Alert source actions are used to customize the behavior using RedwoodScript.
The following predefined objects are available:
Object | Class | Example Code |
---|---|---|
jcsOutLog | com.redwood.scheduler.infrastructure.logging.api.Logger | jcsOutLog.info("This is an informational message.") ; |
jcsAlertSourcePostAlertContext | com.redwood.scheduler.api.scripting.variables.AlertSourcePostAlertActionScriptObject | jcsAlertSourcePostAlertContext.getAlertSource() ; |
jcsSession | com.redwood.scheduler.api.model.SchedulerSession | jcsSession.getQueueByName("PRD_Queue") ; |
note
The jcsSession
object is only available when you set an Action Subject.
Finding Alert Sources and Filerting Overviews
You search for alert sources using filters and the Search Alert Sources box in the overview for the Alert Source. This box is located under your username on the top right-hand side of the user interface. Filters allow you to specify a list of objects with static criteria, SQL queries, and/or IntelliSearch expressions, and any combination thereof. IntelliSearch allows you to specify complex queries in a simple way using prefixes. Prefixes are used to specify which property you are searching in and have short as well as long syntaxes. For example, if you want to display all alert sources of the current overview with the term error in the Description, you would use the search criteria as follows:
d:error
You can search more than one property, as follows:
d:error n:all
note
No spaces should be entered before or after the colon (: ).
See the Advanced Object Search for more information.
The following table illustrates the available prefixes for alert sources:
Prefixes | Description |
---|---|
n, name | searches the name property |
c, comm, comment | searches the documentation property |
d, desc, description | searches the description property |
a, application | searches the application property |
cb, changedbefore | (internal) search for alert sources that changed before a certain ISO-8601 period |