Why Redis?
...
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 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 |
|