How to set up alert notifications about integration issues for both QA and Production environments

Introduction

Notifications in ONEiO are used to inform the customer about issues in their integration. Either temporary or permanent issues can be the cause and can be set independently from each other. Furthermore, the configuration settings of the environment and notifications can be selected and adjusted accordingly.

Setup

The notification settings can be found in the subscription settings and can be accessed by the subscription owner only.

Step-by-Step

1. Add a new notification recipient by pressing the Add Notification button on the right side of the notification screen.
2. Fill in the recipient email address for the mailbox you wish to receive your notifications.
3. Choose the notification settings for the environment in question.
   1. Production Environment
   2. QA Environment
4. Choose the type of Notification you wish to receive per environment
   1. Warnings
   2. Errors
   3. Queues
5. Save your selection by pressing the Confirm button

After saving your selection, you can see the active notifications under Notification Settings:

The indicator (pop-up) behind the email address shows the current status of the verification process.

• Green: The email address has been verified.
• Yellow: The email address is pending verification. This will expire in 7 days.
• Red: The email verification has expired. You can resend the verification link in the UI by clicking the edit icon  on the right side and pressing Resend

Notification Types

ONEiO provides two types of notifications to inform customers about integration issues: Warnings and Errors.

Warnings

Warnings are temporary issues that can be resolved through user intervention or can be solved by themselves, also known as recoverable errors.

Examples include:

• Endpoint timeouts
• Authentication errors
• General connection problems.

A Warning is also triggered if a message remains in Pending status for more than 5 minutes. Only one notification is sent for this condition, even if the message continues to be retried for a longer period.

Errors

An error means we failed to send the request to your instance, due to a failure before or after sending the message. These errors are not retried and therefore do not create outbound queues.

Errors are defined as problems that cannot be resolved through user intervention.

Examples include (but are not limited to):

• Unrecoverable HTTP error codes, defined in the endpoint configuration.
• Invalid responses from the target system based on configured HTTP success codes
• Invalid responses based on the configured Response success value (used when HTTP status codes are not available)
• Invalid inbound payloads received while processing polling results

Inbound polling errors: 

Inbound polling involves sending a request to a target system and processing the response payload to acquire new entities (tickets, incidents, etc). During this process, both warnings and errors as described above may occur.

In addition, the following polling-specific error may be triggered:

• Invalid response payload received from the target system, resulting in unusable polling results

These errors occur when the response cannot be processed due to the expected format or validation rules.

Below is an example from ServiceNow for Unrecoverable HTTP error codes.

And an example for HTTP Success codes, also from ServiceNow.

Queues

Message queuing is used to improve reliability and prevent message loss when temporary issues occur during message processing or delivery.

• Inbound queue: An inbound queue forms when the platform receives messages faster than they can be processed. This typically occurs during traffic spikes, large batch imports, or temporary slowdowns in downstream systems.
  • Queued messages are stored and processed in the order they are received.
     
• Outbound queue: An outbound queue forms when the platform is unable to successfully deliver a message to an external system or endpoint. In such cases, the platform retries the failed message until delivery succeeds or the target system returns an unrecoverable error.
  • To preserve message order and consistency, subsequent outbound messages may remain queued until the failing message has been resolved.
  • For example, if a target system fails to authenticate the integration user (e.g., returns an HTTP 401 error), and this error is not configured as unrecoverable, the platform will continue retrying the request indefinitely until a valid response is received.

1. Trigger when a queue has existed longer than a defined threshold and
2. Repeat at a specified interval for as long as the queue remains active

This allows administrators to detect persistent queue issues and receive repeated reminders until the condition is resolved.

For example, you might configure an alert to trigger when messages have been queued for 30 minutes. If the queue is not cleared, notifications can then be sent every 40 minutes until the issue is resolved.

Queue alert settings can be configured separately for inbound and outbound queues, allowing different thresholds and notification intervals for each.

Alerts

All Alert notifications will be sent from the same email address and follow the same structure. This makes it possible to consume alert notifications and process them further if needed.