Introduction

Using the xUML Service Monitor you can configure notification rules that control what happens in case an exception occurs during execution of xUML services. Such exceptions range from system errors like "DB connection not available" to customer modeled specific errors like "no Order ID found for Payment token".

Every exception has a signature that consists of the three elements Service, Type and Code. If an exception occurs, the monitoring attempts to look up the notification rule for the exceptions' signature and notifies accordingly. If no rule can be found, a new rule for the specific signature will be instantiated based on a template rule.

A typical setup consists of a template rule that notifies someone in DevOps, so each exception signature triggers a notification for DevOps on first occurrence. After reviewing the exception, DevOps decides how to deal with such exception, i.e. ignore, send emails to specific people, or create a JIRA issue, and maybe add instructions for the recipient. Once that's done and the rule is configured accordingly, notifications are dispatched when further exceptions with the same signature occur.

Advanced usage allows for grouping error signatures, and setting up "downtimes" on errors or groups to mute notifications during time periods, e.g. regular maintenance windows of IT systems that are known to trigger specific exceptions in connecting services.

Using the Service Errors' List

	When an error occurs for the first time, a new entry in the error list is created, using the default settings from the template entry. The first entry in the list is that template entry. You can customize this template entry to your needs, so new entries will get the most appropriate settings.
	Once the entry is created, it can be modified to configure individual handling for this specific type of error. To open the configuration dialog, double click the entry in the list.

Content of the Service Error List

The first four columns of the error list contain the meta information about the error, e.g. which specific service, identified by its name, is affected. Entries can either be one of the uncaught errors thrown by the xUML Runtime or a user generated log entry by using the log operation and type Error.

List Column	Description	Possible Values
Service Name	Service which raised this error.	Any String.
Error Category	Category of the error.	Any String.
Error Code	Error code.	Any String.
Error Type	Type of the error.	Any String.
Info Mail	If true, an email is sent to the recipients saved in the error definition.	true, false
Always Notify	If true, the notification is triggered each time the error threshold is reached. If unchecked, the notification is triggered once per day only. So if Always Notify is checked and Threshold is 1, each occurrence will be notified (use with care).	true, false
Custom Notify	If true, a custom notification is triggered. This is a customized extension of the Monitoring Base Service, allowing the integration with other monitoring or ticketing systems. The PAS default implementation supports creation of JIRA issues.	true, false
Error Entry State	This column displays the status of the error entry.	New	A new entry of an error or one that has been configured by an admin.
		Template	The master error template. There can only be one record in this state.
		Match Template	Specific template for a partial error signature.
		Checked	Entry has been checked manually.
First Occ	This column displays date and time of the first occurrence of this specific error.	datetime in format dd.mm.yyyy hh:mm:ss
Last Occ	This column documents the most recent occurrence of this specific error.	datetime in format dd.mm.yyyy hh:mm:ss
Error Count	This column documents how often this specific error occurred.	Integer
Threshold	Specifies the count of occurrences that trigger a notification. This setting is related to Always Notify.	Integer