Working with Process Alert Sources

You can use process alert sources to generate an alert when a process reaches a particular status. You can even configure a process alert source to generate separate alerts for separate statuses.

Every process alert source must specify at least a Name Pattern and one target status. All specified conditions must be met for an alert to fire.

Creating a Process Alert Source

To create a new process alert source:

  1. Navigate to Alerting > Process Alert Sources.
  2. Click .
  3. Enter a Name for the process alert source.
  4. In the Name Pattern field, enter a pattern matching the name of all processes you want to raise alerts for.
  5. Click the Statuses tab.
  6. For each status you want to raise an alert on:
    • Click Add and select the target status from the Status dropdown list.
    • If desired, enter a Delay Amount and choose an option from Delay Units.
    • Optionally enter a status-specific Operator Message to override the default message.
  7. To verify that the alert source does what you want it to, click the Preview tab.
  8. Click Save & Close.

Tabs and Fields

Note: For tabs and fields that are common to all objects, see Object Tabs.

Tab Field Description
Process Alert Source Raise an alert for Process Definitions that match

Specify a Name Pattern to match Process Definition names. You can also specify a Partition Pattern to only search for Process Definitions with a matching Partition. For pattern-matching options, see Pattern Matching.

The Alert on restart dropdown list lets you avoid creating a separate alert every time a process is forced to restart. Choose an option other than [None] and All restarts to limit alerts to being sent after a specific number of restarts.
Process Alert Source Raise alerts only at certain times Time Window and Time Zone let you specify that alerts should only be fired when a specific Time Window is open or closed (depending on the Time Window Status).
Process Alert Source Raise a custom Operator Message

Lets you specify the following:

  • A custom Operator Message Expression. This field allows substitution parameters.

  • A custom Operator Message Reply Expression. You can use regular expressions in the reply expression to force the user to select a reply option. If no reply expression is specified, the default reply expression is Acknowledge.
Process Alert Source Sent to

Specify an Address and a Default Alert Escalation. The Address can use substitution parameters and is resolved by an Email Alert Gateway. The alert will be sent to the specified address and escalated, if necessary, using the specified escalation.

If you do not provide a Default Alert Escalation, you must specify an Escalation Expression under Use a dynamic escalation path.

Note: The Escalation Expression field is evaluated before the Default Alert Escalation field. If the Escalation Expression field results in a match, the Default Alert Escalation is ignored.
Process Alert Source Use a dynamic escalation path Lets you specify an alert escalation using substitution parameters. If no matching escalation can be found, the Default Alert Escalation is used.
Statuses Chain definition alerts on

This dropdown list lets you specify how alerts are handled in Chain Definitions. When you choose an option from this list, the user interface explains how the option works. For more information, see Status Matching and Chains.

Note: If the process alert source is only supposed to match Process Definitions that are not part of a Chain Definition, this field is ignored.
Statuses Status The status to alert on.
Statuses Operator Message Expression A status-specific Operator Message expression. If you specify this, it overrides the default Operator Message expression for this process alert source.
Statuses Delay Amount The number of Delay Units to wait until the alert is sent. The system will only raise the alert if the process is still in the status mentioned after the specified delay. This is important for transient process statuses such as Waiting, EventWait or Queued. It is not necessary for final statuses such as Error, Killed, or Completed.
Statuses Delay Units The units of time used in the Delay Amount.
Parameter Matches Name The name of the parameter to match.
Parameter Matches Value The parameter value to match.
Parameter Matches Match Type The method used to match the value of the parameter. For more information, see Pattern Matching.
Rules Processing Order The order in which the rules are processed.
Rules Variable The property evaluated by the rule. Options include Priority, Process Server, Queue, Remote Event, Remote Id, Remote Status, Remote System, and Return Code.
Rules Operation The operator use to compare the value of the Variable.
Rules Value The expected value of the Variable using the Operation.
Rules Alert Escalation Lets you specify a rule-specific escalation. If you specify an option, this overrides the alert source's default escalation.
Alert Source Email Body The body of the email to send. For information on customizing this field, see Customizing Alert Emails.
Actions Type The type of action to take when an alert needs to be fired. The only valid option for alert sources is Post Alert. Any action you define here will be executed after the alert is sent. You must reply to the Operator Message and delete it if you want to suppress it.
Actions Enabled Lets you enable or disable the action.
Actions Action Subject The user under which the code in the action is performed. You must set this if you want to use jcsSession.
Actions Library Lets you specify a library containing methods you want to use in the Source field.
Actions Source The source code of the script.

Security

The privileges available in the Security tab are as follows.

For more information, see Security Tab.

Privilege Description
JobDefinitionAlertSource.Create Create Chain alert sources
JobDefinitionAlertSource.Delete Delete Chain alert sources
JobDefinitionAlertSource.Edit Edit Chain alert sources
JobDefinitionAlertSource.View Access Chain alert sources

Status Matching and Chains

Alerts can be generated for any combination of types (single processes, Chains, Steps, and Chain Processes). The status of a Chain Process or Step is escalated up to the Chain, so it's important to pay special attention when you want to raise an alert on a Chain. Incorrectly configured alert sources can fire duplicate alerts.

The Standard behavior is to match only Chains (or, for Steps, statuses Console and Console Restart). This means that if you use On Error Status Handlers in Chains in combination with the Standard behavior, you must make sure the Chain reaches status Error when an error occurs (or that one of the steps reaches status Console or Console Restart). In this case, you should specify status rules for Console and Console Restart in combination with a Request Restart Status Handler. The Chain partition and name are used for matching; the partitions and names of the Process Definitions called within the Chain (Chain Processes) are not taken into account.

The following alerting options are available for chains:

  • Chain and Steps: The alert fires for Chain Processes and Chains that match the name pattern and have reached the target status.
  • Chain and Steps: The alert fires for Steps and Chains that match the name pattern and have reached the target status.
  • Chain Only: The alert fires for Chains that match the name pattern and have reached the target status.
  • Chain, Steps, And Processes: The alert fires for Chain Processes, Steps, and Chains that match the name pattern and have reached the target status.
  • Processes Only: The alert fires for Chain Processes that match the name pattern and have reached the target status.
  • Standard: The alert fires for Chains that match the name pattern and have reached the target status. The alert also fires for steps that have reached statuses Console or Console Restart.
  • Steps And Processes: The alert fires for Chain Processes and Steps that match the name pattern and have reached the target status.
  • Steps Only: The alert fires for Steps that match the name pattern and have reached the target status.

Example Process Alert Sources

The following example shows how to generate an alert if any SAP_AbapRun process enters status Error, Unknown, Killed, or Canceled.

  1. Navigate to Alerting > Process Alert Sources.
  2. Click .
  3. In the Name Pattern field, enter SAP_AbapRun*.
  4. In the Operator Message Expression field, enter process ${jobOwner}.${jobDefinition} with ID ${jobId} reached status ${newStatus}, has the process been restarted?.
  5. In the Operator Message Reply Expression field, enter ^Yes|No$. This will force users to reply with Yes or No.
  6. On the Statuses tab, add a row and choose select Error from the Status dropdown list. Repeat this step for statuses Unknown, Killed, and Canceled.
  7. Click Save & Close.

The following example generates an alert if any SAP_AbapRun process where the parameter SAP_SYSTEMS has value ERP enters status Error, Unknown, Killed, or Canceled. Note that for the Operator Message to work, the Process Definition must have a parameter named Param1.

  1. Navigate to Alerting > Process Alert Sources.
  2. Click .
  3. In the Name Pattern field, enter SAP_AbapRun*.
  4. In the Operator Message Expression field, enter ='Process ${jobOwner}.${jobDefinition} with ID ${jobId} and parameter '+parameters.Param1+'reached status ${newStatus}!'.
  5. On the Statuses tab:
  6. On the Statuses tab, add a row and choose select Error from the Status dropdown list. Repeat this step for statuses Unknown, Killed, and Canceled.
  7. On the Parameter Matches tab, click Add, then enter SAP_SYSTEMS in the Name field and ERP in the Value field.
  8. Click Save & Close.

The following sample Source could be used in a Post Alert action. Assume that a process is configured to restart if it reaches status Error, and its maximum number of restarts is set to 4. Assume further that you do not want to have to answer an alert for the first restart. Note that getRestartCount returns the number of remaining restarts.

{
  // Get the alert information
  Alert alert = jcsAlertSourcePostAlertContext.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;
    Long restartCount = new Long(3L);
    // If RestartJobId is null, then this is the first Process.
    if (Process.getStatus().getState() == JobStatusState.Final && restartCount.equals(Process.getRestartCount()))
    {
      // Reply to the Operator Message and restart the job
      omessage.setReply("Acknowledged");
    }
  }
}