Alerting gateways specify the addressee as well as the content of the message that is to be sent to the recipients. When you configure multiple alert gateways, you must pay attention to the pattern you use as well as the processing order of each email gateway. The most specific address patterns must have the lowest processing order, or the wrong email gateway might be used. For example, an email gateway with an Address Pattern of *example.com and a processing order of 1 will take precedence over any other email gateway for example.com, like de.example.com or us.example.com if their processing order is greater than 1. Redwood recommends using a catch-all gateway with an extremely high processing order, like 99, to ensure all emails are sent.

You use multiple alert gateways in the following cases:

you want to tailor the email for a specific audience and the conditional expressions as outlined below prove complex to implement.
you want to use a different Alert Resend Delay, Alert Rate Interval, or Alert Rate Limit for the recipients.

Note that the gateway with the lowest processing order, that has a matching address pattern will be used. In the case that there are multiple gateways with the same processing order that have matching address patterns, then the gateway used will be non-determined.

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 and/or Email tabs; 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.

Note that if you specify an Alert Source Email (email body) on the alert source, it will override any Email (email body) set on the email alert gateway.

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 Emails

You can customize emails on the Email tab, using the following two constructs:

conditional evaluation
REL expressions (without the equals (=))

Conditional Evaluation

[?if test="expression"?]
text
[?endif?]

REL Expressions

[?=expression?]

Example

<html>
<head><title>[?=alertSourceType?] Email</title></head>
<body>
[?if test="alertSourceType === 'AdHocAlertSource'"?]
Ad-hoc alert: [?=data?]
[?endif?]
[?if test="alertSourceType === 'ProcessServerAlertSource'"?]
Process server alert: [?=oldStatus?]  =&gt; [?=newStatus?]
[?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 that the available objects for use in these expressions depend on the alert source as well as the raiser. For example, a JDBC job does not have a remote status; when it triggers a process alert source and the alert source, the escalation or gateway attempt to use the remoteStatus variable, the active monitoring module will produce an error. Another example would be the process server alert source which does not have a queue variable; if an alert source, escalation, or gateway were to use this variable for an alert caused by a process server alert source, the active monitoring module would produce an error. For these situations, you have the conditional expressions to verify the cause of the alert prior to using variables.

You can find all available variables in the following topics:

Email Alert Gateway Actions

Email alert gateway actions allow you to customize the email and perform specific tasks before it is sent using RedwoodScript. You can, for example, cancel it under specific circumstances.

Procedure

Setting up email

Navigate to "Definitions > Processes".
Choose Submit from the context-menu of System_Mail_Configure.
Specify only the From address if you do not know the address of the SMTP server. The process will attempt to detect the appropriate mail server to use automatically.
Check the status of the process in "Monitoring > Processes".

If the process ends in status Completed then the mail server has successfully been detected and stored.

If the process ends in status Error, the mail server could not be automatically detected. You should look at the log file for more information. You can re-run the process and specify the mail server to use. You should ask your system or network administrator for the name or IP address of your SMTP mail server.

Creating an email gateway

Navigate to "Alerting > E-Mail Alert Gateways".
Choose New Email Alert Gateway from the context-menu.
Fill in the fields Name, Address Pattern and Processing Order.
Optionally set custom headers on the Headers and specify files to attach on the File Attachments tab.
Choose Save & Close.

Example

Creating an email gateway for example.com

Navigate to "Alerting > E-Mail Alert Gateways".
Choose New Email Alert Gateway from the context-menu.
Fill in the fields Name, fill *@example.com into the Address Pattern and 99 into Processing Order.
On the Headers tab, choose Add and fill From into the Name field and prd-operators@example.com into the Value field.
On the Headers tab, choose Add and fill subject into the Name field and prd-process failed: ${subject}.
On the File Attachments tab choose Add, enter stderr.log into the Name field, choose Add again and enter stdout.log into the Name field.
Choose Save & Close.

You want to wait until the second run of the process has failed before you send alerting emails, this is done by suppressing the first email and operator message in the alert gateway action:

{
  // Get the alert information
  Alert alert = jcsEmailAlertGatewayPreSendActionContext.getAlert();
  OperatorMessage omessage = alert.getOperatorMessage();
  SchedulerEntity sentity = omessage.getSenderObject();

  // Do not send emails for the first failure
  if (sentity instanceof Job)
  {
    Job process = (Job) sentity;

    // If RestartJobId is null, then this is the first process.
    if (process.getStatus().getState() == JobStatusState.Final && null == process.getRestartJobId())
    {
      // Suppress sending the email
      jcsEmailAlertGatewayPreSendActionContext.setSend(false);

      // Reply to and delete the operator message
      omessage.setReply("Acknowledge");
      omessage.deleteObject();
    }
  }
}

Product Documentation

Creating and Configuring Email Alert Gateways

Email Addresses and Aliases

Customizing Emails

Email Alert Gateway Actions

Procedure

Example

See Also