Skip to main content

Alerting Component

net.democritus.alerting:alerting-component::2.2.0

The alerting component is a base component to handle the concern of sending alert messages. It implements a pub-sub mechanism to send alert messages to channels such as email or Slack. The component is also an experiment to design modular re-usable components that define fixed interfaces to add functionality. Through a combination of model options and expanders, it is possible to add additional (or replace) channel types if support for a different platform or a different implementation is needed.

Resources​

The alerting component resource itself consists out of several expansion resources:

  • alerting-component is a stack resource that combines everything needed to send alerts out-of-the-box. This will typically be the resource that is included directly in applications.
  • alerting-component-core is a resource that contains both the model for the alerting component and the expanders that are needed to generate the infrastructure to implement alert channels.
  • alerting-component-default is a resource that contains the alertingImpl component, which has several default alert channel implementations that can be used out-of-the-box to send alerts over email, Slack and more.

Alerting component​

The alerting component that is packaged in the alerting-component-core expansion resource contains all technical infrastructure to publish and route alerts to their destination. Any component that has code which creates and publishes alerts should depend on the alerting component.

Publication system​

Topics​

One or more topics can be created to publish alerts to. An alert can be published to more than one topic, as an alert just represents the content of the message. A topic is identified by a name. An example of a topic could be account-created. When an alert is published to a topic, a workflow will forward that alert once to each of the subscriptions linked to that topic.

Subscriptions​

A subscription can be added to a topic and can link a topic to one or more channels. Channels are implemented externally and are a combination of a DataElement and a technical implementation to send an alert using some channel such as email. As they are implemented externally, connections to channels are represented in a subscription route, of which one or more can be added to a subscription. Each route is unique identified by an identifier, that can be used to unsubscribe a route (setting active to false) and the link to the channel is represented by two fields:

  • channelType is a DataRef to the DataElement that represents the channel. Eg: alertingImpl::EmailChannel
  • channel is the functional key of a channel entry of the channel element at runtime.
info

In the generated knockout UI, a customized input form was added that allows for selection of a channel type and channel as if they were actual link fields. These are generated based on the channel DataElements available in components of an application.

Create dialog for SubscriptionRouteCreate dialog for SubscriptionRoute

Alert publication​

Creating alerts​

To publish an alert, a new instance of the Alert element should be created with all needed information, including a link to a priority for the alert. All AlertPriorities are listed in the net.democritus.alerting.alerts.AlertPriority enumeration and automatically provisioned in the database for the AlertPriority element, so it can easily be linked to.

Publishing alerts​

Once an alert has been created, it can to published to one or more topics by creating instances of the PublishedAlert element that link an alert to a topic. A workflow will process the alerts that have been published to a topic and route them through the subscriptions. For each subscription route, for which the minimum alert priority is equal to or lower than the priority of the alert, an instance of AlertDispatch will be created that contains a link to the alert, the identifier of the subscription route as the source and the channelType and channel it should be sent to. Next another workflow will process all alert dispatches and attempt to send them through the technical implementation of the target channel.