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.
...
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.
| Info |
|---|
| All data sent over Redis is JSON based |
| Info |
|---|
| Redis runs on port 6379 8001 |
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.
| Info | ||
|---|---|---|
| ||
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.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{type: <sub_type>, payload: {JSON payload}} |
| sub_type | depends on the type of the notification |
|---|---|
| campaigns: sub_types |
|
| agents: sub_types |
|