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.
The alerting component resource itself consists out of several expansion resources:
alerting-componentis 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-coreis a resource that contains both the model for the
alertingcomponent and the expanders that are needed to generate the infrastructure to implement alert channels.
alerting-component-defaultis a resource that contains the
alertingImplcomponent, 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 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
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.
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
false) and the link to the channel is represented by two fields:
channelTypeis a DataRef to the DataElement that represents the channel. Eg:
channelis the functional key of a channel entry of the channel element at runtime.
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.
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
enumeration and automatically provisioned in the database for the
AlertPriority element, so it can easily be linked
Once an alert has been created, it can to published to one or more topics by creating instances of the
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
identifier of the subscription route as the
source and the
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.