The Notifications Mediator service allows external tools to setup and schedule notifications for clients. This notifications act as reminders, so the user are aware of future activities. This, together with the Communication Mediator Service, allows the sending of the notifications through different communication channels.
Page content:
How does it works?
The following steps explains how does all the technology stack works together:
An external tool wants to perform an action on Notification Mediator Service.
The request goes to OpenHim that acts as an API Gateway.
OpenHim sends the request directly to the Notification Mediator Service to handle the operation.
Notification Mediator Service executes either:
A request information to a data persistence tool to retrieve data.
A delivery of information to the Communication Mediator Service.
After all the processes are executed, the Notifications Mediator service responds back to OpenHim.
OpenHim delivers a response to the external tool, letting the external tool to know if something went wrong or if everything was successful.
The following diagram shows how the technology stack is connected:
To know the DHIS2 event structure, you can check DHIS 2 Maintenance (psi-mis.org), program stage: CWS Notifications.
Cronjob
Notification Mediator Service use a cron scheduler to send all the notifications that have already reached the scheduled date and which status is set to 'scheduled'. This CronJob runs every X minutes.
The cronjob uses notification endpoint named send notifications.
There are two main reasons to do it by date ranges:
DHIS2 endpoints restrictions
Notifications pending to send are retrieved before the current minute and after the previous 7 days. This way, if for some reason we have notifications pending to send (the server was down, DHIS2 was not working in the previous hours…) we can send the previous notifications.
