You can use steps to generate notifications or alerts when they finish with process alert sources. A process alert source can be created to trigger alerts for multiple steps with pattern matching. Every process alert source needs at least a name pattern and a status mapping, or no notifications or alerts will be sent. See Raising Alerts and Notifications from Chains information on how to create a process alert source.

All conditions must be met for the alert to fire!

Tabs & Fields

The following table illustrates the fields of each tab of process alert sources editor dialogs.

Tab	Field	Description
Process Alert Source	Partition	The Partition where you wish to store the process alert source
Process Alert Source	Name	The name of the process alert source can contain any combination of US ASCII letters, digits, and underscores; limited to 80 characters.
Process Alert Source	Application	The Application of the process alert source
Process Alert Source	Description	The description of the process alert source can contain any combination of printable UTF-8 characters, limited to 255 characters.
Process Alert Source	Raise an alert for process definitions that match	Specify a process definition Name Pattern that will be used to match processes, you may also specify a Partition Pattern to only search for processes whose process definition partition matches the pattern provided.
Process Alert Source	Raise alerts only at certain times	Time Window and Time Zone allow you specify that alerts should only be fired when the time window is open or closed, depending on the Time Window Status.
Process Alert Source	Raise a custom operator message	Specify a custom Operator Message Expression and Operator Message Reply Expression. The reply expression can use regular expressions to force the user to select a reply.
Process Alert Source	Sent to	Specify an Address and a Default Alert Escalation; the alert will be sent to the specified address and escalated, if necessary, using the specified escalation. You may use substitution parameters in the address. If you do not provide a Default Alert Escalation you must specify a dynamic one - see below.
Process Alert Source	Use a dynamic escalation path	Specify an alert escalation using substitution parameters, if no escalation can be found, the default specified above will be used.
Documentation	Documentation	A comment about the object, can be used for documentation purposes.
Statuses	Process alerts on	The process type to react on. This is only used for process and allows you to specify which process to fire alerts for.
Statuses	Status	The status to react on.
Statuses	Operator Message Expression	Status-specific operator message expression, overrides default.
Statuses	Delay Amount	The amount of Delay Units to wait until the alert is sent.
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 value of the parameter.
Parameter Matches	Match Type	The method used to match the value of the parameter.
Rules	Processing Order	The order in which the rules are processed.
Rules	Variable	Variable used by the rule.
Rules	Operation	The operator use to compare the value of the variable.
Rules	Value	The expected value of the variable using the above operator.
Rules	Alert Escalation	The rule-specific escalation, overrides default.
Alert Source Email	Body	The body of the email to send, see Customizing email messages for information on how you can customize it.
Alert Source Actions	Type	The type of action, limited to Post Alert on alert sources, they fire after an alert is sent. You must reply to the operator message and delete it if you want to suppress it.
Alert Source Actions	Enabled	This checkbox allows you to enable or disable the action; when unchecked, the action will never fire.
Alert Source Actions	Library	You can specify a library here containing methods you would like to use. It is recommended to save your code in libraries so you can use it elsewhere.
Alert Source Actions	Action Subject	The user under which the code in the action is performed. You must set an action subject if you want to use jcsSession
Alert Source Actions	Source	The source of your code.
Alert Source Actions	Stub Source	This code shows you where the action will be performed.
Security	*	This is where you can specify who can access/change/remove the process alert source.

Criteria

Process alert sources raise alerts or notifications when steps change status.

They match a status on three criteria:

A pattern matching the partition/name of the definition.
The new status of the process, parent, step, and/or step process.
The parameters of the process.

note

The name of step is the name of the parent chain definition.

The pattern and the new status must be specified. The parameters are optional. If parameters are specified, then they must match. If no parameters are specified then no additional matching is done. Parameter matches are used to raise alerts or notifications on generic process definition like SAP_AbapRun. Since all of these processes have the same name, additional criteria are needed to distinguish specific SAP Systems, programs, or variants.

Name and Parameter Matching

You can use the following match rules for names and parameters:

Exact Insensitive - The value must match, case-insensitive. No wildcards allowed.
Exact Sensitive - The value must match, case-sensitive. No wildcards allowed.
GLOB Insensitive - The value must match, case-insensitive. GLOB wildcards allowed (? and *).
GLOB Sensitive - The value must match, case-sensitive. GLOB wildcards allowed (? and *).
RegEx Insensitive - The value must match, case-insensitive. Regular Expression pattern.
RegEx Sensitive - The value must match, case-sensitive. Regular Expression pattern.

note

You must use parameter names (technical names) and not descriptions, when specifying parameters. You can look these up in "Definitions > Processes" or for built-in processes you can see System processes and SAP processes.

You trigger alerts for restarts by specifying after how many restarts you want the alert to be fired.

Status Matching

Alerts can fire for any combination of types (lone processes, chains, steps, and Chain processes). The status of a chain process and/or steps is escalated to the chain, so special attention must be brought to statuses when you want to raise them on chain. Incorrectly configured alert sources might fire duplicate alerts.

The delay amount and delay units can be used to prevent spurious alerts. 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 like Waiting, EventWait or Queued. It is not necessary for final statuses like Error, Killed, or Completed.

The functionality differs slightly for chains and lone processes:

Lone Processes

The value selected in the Chains alerts on field is only used for processes where the definition type is JobChain. The alert will fire for the process if the name and partition match the patterns and the process reached a status as configured. If a delay was configured, the process or chain must have remained on the specific status for the entire duration of the delay.

A Chain

the module reacts on the status of a chain call process, step, and/or the chain. The standard behavior is to match only the chains or, for statuses Console and Console Restart, steps. This means that if you use On Error status handlers in chains in combination with the Standard behavior, you must ensure that 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 status as configured.
Chain and Steps - the alert fire for steps and chains that match the name pattern and have reached the status as configured.
Chain Only - the alert fire for chains that match the name pattern and have reached the status as configured.
Chain, Steps, And Processes - the alert fires for Chain processes, steps, and chains that match the name pattern and have reached the status as configured.
Processes Only - the alert fires for Chain processes that match the name pattern and have reached the status as configured.
Standard - the alert fire for chains that match the name pattern and have reached the status as configured; additionally, it will fire 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 status as configured.
Steps Only - the alert fires for steps that match the name pattern and have reached the status as configured.

Operator Message and Reply Expressions

The operator message to use is specified as an expression that allows substitution parameters, see the parameters below. The message can be specified at the alert source level, and overridden per status. If no message is specified at any level, the default message is Acknowledge.

The reply expression works the same way as the reply expression for the System_OperatorMessage. This can be specified at the alert source level, and overridden per status. If no reply expression is specified, the default reply expression is Acknowledge.

Substitution Parameters

Substitution parameters can be used in various field on alert sources; for the full list see the Scripting Contexts and Implicit Objects topic.

Substitution parameters can be used in the Email Address, Operator Message Expression, and the Alert Source Email Body fields. You use the ${substitution_parameter} syntax in Email Adress and Operator Message Expression fields; in Alert Source Email Body fields, you can also use the ${substitution_parameter} syntax as well as the [?<REL_expression>?] syntax. You can refer to process and chain parameters with the [?=parameters.MyParameter?] and [?=chainParameters.MyParameter?] syntaxes, respectively.

See Raising Alerts from Processes and Chains for more information.

Escalation

Escalations send operator messages and emails (via Email Alert Gateways). When a specific condition does not have an escalation, no operator message is sent and the condition is ignored.

When nobody has resolved the alert in a timely fashion, you can escalate the alert to another operator, this is done with escalations.

Process alert sources use two rules to determine the alert escalation to use:

An expression to determine a dynamic escalation name. This expression supports ${variable} substitutions and the Redwood Expression Language Syntax syntax for expressions.
A default alert escalation

The expression is always evaluated first. If the escalation returned by the expression exists, then it is used. If it does not exist, then the default is used. This allows the used escalation to be dynamic.

For example, different escalation paths can be defined depending on the name of the :

Expression: Error_${jobDefinitionOwner}
Default: Error_Processes
Statuses: Error, Canceled, Killed
The following alert escalations are defined: Error_Reporting, Error_Finance, Error_Sysadmin, Error_Processes

This will raise the following alerts:

Process from process definition belonging to Reporting reaches status Error - Error_Reporting
Process from process definition belonging to Finance reaches status Canceled - Error_Finance
Process from process definition belonging to Sysadmin was killed - Error_Sysadmin
Other matching processes - Error_Processes

Security

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

You can grant privileges on two levels, Access and Admin; a privilege granted on Admin level allows the grantee to grant the privilege to other users. These privileges can be granted per partition or system-wide.

The Security tab allows you to specify which users can access, edit, and delete the chain alert source.

Product Documentation

Process Alert Sources

Tabs & Fields

Criteria

note

Name and Parameter Matching

note

Status Matching

Lone Processes

A Chain

Operator Message and Reply Expressions

Substitution Parameters

Escalation

Security

See Also