Design Concerns: Best Practices
- Rijnhard Hessel
The dialer is a fully asynchronous and real-time piece of software. In order to ensure the best possible integration its important to follow theses guidelines:
State Management
The dialer is a big state machine, managing the state of the campaigns, agents and calls is difficult.
So leave the state management to the dialer, DO NOT try to store and manage state on the client side.
Instead rely on the state that the dialer notifies you about, and react accordingly, it will be accurate.
Essentially try to be asynchronous.
Dialer Weak Point
All systems have a weak point, and we chose to focus on the core and the overall architecture and the resulting stability of the dialing engine.
What faltered and is currently the weak point is return values from the API:
- Check[GET] commands can have an inconsistent state to the Dialer Core, they will however be up to date after a notification is sent, hence always trust notifications.
- Return values for PUT/POST/DELETE can return information or null if no state change has happened, wait for the notification instead.
Basically the notifications are golden, rely on them, not on fetching info from the API.
We have a plan in place to massively upgrade the API itself, whilst maintaining the current spec, we appreciate your understanding of these inconsistencies while we progress towards that.
Web Based Integrations
Web Sockets are highly recommended for web based systems integrating with the dialer, in order to eliminate latency between the notification and the reaction in the UI.
This is because with notifications like Call Connection notifications it is fairly important that the agent interface reacts quickly so that the relevant information is available as soon as possible.
Redis
Although learning new systems and paradigms like redis can be daunting, redis is mostly an easy system to learn.
Why Redis?
In our integrations we use it as the simplest most effective queueing mechanism possible.
The alternative is RabbitMQ, ZeroMQ, etc which are all much harder to setup and require a much bigger development effort by integrators.
Why not Web Hooks?
Latency. Although we could and possibly will wrap redis with an HTTP webhook API in the future, we decided that the primary notification system will be redis because of latency.
Campaign Creation
Create the campaign with the settings and agents (via a POST)
Then loop over the callees in blocks of a 100 and add it to the campaign (via a PUT)
Code for the Future!
Due to our rolling release strategy it's important that you follow the guidelines to make sure you integration works when we roll out new functionality.
We won't introduce breaking changes, but adding more features, there will be unexpected information coming your way.
Follow Integration Guide: Futureproofing - Making Your Integration Upgrade Safe