Alerts

This section specifies why the alerting service is important and how it is structured

Why an alerting service?

Errors often occur in integrations, it can be anything from faulty data entry in the Source system, to time out or formatting issues in the Destination system. When an error occurs it is of upmost importance to understand that something has happened, what happened and why it happened for an end-user to easily address the issue.

The HighCohesion alerting service is design to support in all of the above four steps, in real time and in granular detail on a Job and Event basis.

What is the alerting service and how is it structured?

The HighCohesion alerting service is configurable to fit every organisations specific needs, and alerts on three alert types:

JOB:

• This alert notifies the client about a failed job.

EVENT_TRANSFORMED:

• This alert notifies the client about a failed event in the transformation process (CORE)

EVENT_DESTINATION:

• This alert notifies the client about a failed event in the destination (SDF)

The alerts can easily be configurable by:

• Deciding who shall receive the email alerts

• Selecting which Streams from the Organisation that should be included

• Configuring a flood control based on count & time, to ensure the end-user does not get spammed with emails in case a high traffic Stream sees errors

• Opt-in for daily or weekly alert reports with a summary of the alert count per Stream for a specific alert type

Use cases

See below illustration for an example:

Alert configuration settings: flood_type = streamID flood_count = 20 flood_time = 15_MIN

Scenario: Simple Street Supplies sees the highest trading volume of the year during Black Friday. When the amount of orders peak, their FTP times out resulting in 53 events with alert_type = Error (failed in destination), the 53 Events with error are all created within 5 seconds.

Alerting service output:

Email alert templates

JOB_ERROR

EVENT_DESTINATION ERROR

EVENT_TRANSFORMATION ERROR

The above templates are examples of emails that are sent to the end-user for the first time. If the email is triggered after having been retained by the flood control feature, a paragraph will be added on the top of the email outlining how many Jobs / Events failed before the email was triggered (e.g. the number of the flood_count). See example below:

Alert report

The alert report feature provides a holistic overview of all the alerts that have been triggered over the last day or week for a specific alert type (e.g. JOB ERROR, EVENT_TRANSFORMATION ERROR or EVENT_DESTINATION ERRROR. This is especially helpful for organisations that are using the Flood Control feature, too easily see the exact number of alerts triggered, per stream and alert type.

A DAILY report will be sent every day at 16:00 UST

A WEEKLY REPORT will be sent every Friday at 16:00 UST

How can I easily differentiate an alert email from a report email?

The alert report will be sent from [e-mail]. The subject line will always start with "DAILY/WEEKLY REPORT".

ALERT REPORT TEMPLATE