State Notifications
- Rijnhard Hessel
Why Redis?
The dialler uses Redis to send information back to the 3rd party application. In order to make a robust messaging system we make use of two Redis data/messaging structures this enables us to ensure critical information is sent correctly. We make use of Redis PubSub and Redis Lists for all our messaging between the dialler and the 3rd party application.
Redis PubSub is a non-robust message broadcasting channel. Although it is classified as non-robust this is only because it does not handle retries, but rather works in a fire and forget approach. Although it is classified as non-robust, it is in fact very reliable and super fast. We use Redis PubSub for non-critical information as well as critical time dependant information (information which only makes sense at a specific instance in time).
Redis Lists are always populated using a push left pop right approach. Redis lists ensure the data stays persistent until it is pulled from the list. This means that the only way a message will not be delivered is if Redis DB crashes and a the record cannot be saved. In this case we have backup files which will push the message to Redis as soon as it is available again. Thus Redis lists are used for information which needs to be synced from the dialler, such as call data records.
The dialler can send back an extensive amount of information, however, the two most critical pieces of information are: agent connection notifications, and CDRs. The dialler however also sends back campaign status updates and agent status change events. These are very useful for providing a proper user experience. As the HTTP API is asynchronous they also provide the most efficient way to confirm that a request has been completed.
Notification Structure
Keys which are used to communicate information back to 3rd party applications. These keys use PubSub mainly but also use LISTs for critical information such as CDRs.
Key Structure:
enigma:notifications[<:type>[<:reference>]]
where items in “[]” are optional additions to the base key
Reference field is exclusively used for PubSub such that multiple workers on a “reference” specific level can exist or such that a global worker can handle notifications.
i.e. a notification relating to agent 1002 will look like: “enigma:notifications:agent:1002”. If you wish to use a single worker for all agent notifications you can subscribe it using a the Redis pattern subscribe method.
- psubscribe “enigma:notifications:agent:*” will get all the PubSub events for all the agents
- subscribe “enigma:notifications:agent:1002” Will only get 1002’s notifications.
{type: <sub_type>, payload: {JSON payload}}
| sub_type | depends on the type of the notification |
|---|---|
| campaigns: sub_types |
|
| agents: sub_types |
|