Glue42 Notification Services: Mechanics
20/04/2019 | Written by:
Purpose (business value) review:
As you recall from a previous blog, the Glue42 Notification System (GNS) works to bring notifications from disparate applications into a single structured flow. This reduces the time spent acting on a notification and gives the operator confidence that they haven’t missed one.
Today we’ll take a look at how GNS does its thing, and it’s best to start by reviewing the basics of Glue42 Interop.
In Glue42 interop methods let different applications talk to each other. They can do so by invoking regular methods (a request-response mechanism) or – most relevant to GNS – by publishing on a stream and having other apps subscribe to it.
Architecture big picture
In the middle of it all sits the GNS Desktop Manager (DM). Like the name suggests it is a singular program running on the user’s desktop. Its role is to listen for notifications from all the different publishers and pass them on via an interop stream.
This architecture is similar to the Glue42 Search Service architecture.
Publishers are all the applications which can generate notifications. They can connect to the DM by either Interop or REST api. Interop publishers must create a stream which the DM will subscribe to. REST publishers expose a well-defined api and will be polled by the DM. Making any app a publisher requires writing a thin layer which formats existing alerts into GNS notifications and connects to the DM.
A client is any application that can receive notifications from the DM. A desktop set-up may have one or many clients, but having one is more common. The client receives notifications by subscribing to the DM’s notifications stream. Once subscribed (usually at initialization) the client will receive a snapshot of notifications which the DM has cached. The Glue42 trial version comes with two clients that both work independently. The toasts are driven by “GNS UI” app while the “Alerts Panel” which slides in when the user clicks on the toolbar “bell” icon is its own separate app.
What about actions
Notifications can have actions listed in the Notification’s “glueRouting” field. In GNS terms an action is simply the name of an interop method along with some parameters. Actions appear as buttons in toasts or panel alerts. It is up to the client app to invoke the action’s interop method when the user clicks the button. This mechanism allows for reacting to a notification without having to go into the generating app.