Couplage Téléphonie Informatique et application à Magento : Troisième partie

Cet article est le troisième article d’une série consacrée au couplage téléphonie informatique avec Magento. Après avoir abordé les aspects fonctionnels, puis l’interconnexion nécessaire, nous allons présenter quelques possibilités de couplage entre Asterisk et Magento

Asterisk et le CTI

Asterisk est un IPBX open source très populaire. Il a la particularité de s’interfacer avec un grand nombre de technologies, dont les technologies de télécoms traditionnelles, via des cartes d’extension. En outre, le cœur d’Asterisk est le plan de numérotation, qui régit le traitement des numéros appelés (au sens large) en fonction du contexte d’appel de l’appelant. Asterisk est prévu pour être extrêmement souple, et de ce fait, peut être d’une très grande aide au couplage téléphonie informatique.

Plan de numérotation : intégration ODBC et CURL

Par exemple, depuis le plan de numérotation, on peut sans problème effectuer des requêtes SQL en ODBC à la fois en read et en write, ce qui signifie également que si c’est nécessaire, on peut implémenter certaines fonctions via des procédures stockées par exemple. Dans notre cas, on pourrait très bien attaquer la BD de Magento depuis le plan de numérotation, et ainsi par exemple récupérer un nom de client pour le mettre en place pour l’affichage sur les postes clients, voire augmenter l’information avec des informations courtes, comme par exemple le groupe de clients auquel il appartient.

De même, on pourrait très bien envisager de récupérer une assignation du commercial responsable du client, de sorte à diriger l’appel en priorité au responsable du compte, si un développement spécifique a été fait dans Magento dans ce sens.

Dans le même esprit, on peut également réaliser des appels CURL via le plan de numérotation pour récupérer les informations de cette manière - si la logique à suivre est trop complexe pour être mise en base de données ou en plan de numérotation - et Magento est particulièrement rompu à cet usage, puisque le framework propose des URL structurées avec des paramètres facilement récupérables.


odbc read ODBC_MAGE_NAME_LOOKUP 1235550001 exec
[Aug 4 17:55:55] DEBUG[1459]: pbx_variables.c:474 ast_str_substitute_variables_full: Evaluating 'ARG1' (from 'ARG1}' left join customer_address_entity_varchar f on f.entity_type_id=t.entity_type_id and f.attribute_id=(select a.attribute_id from eav_attribute a where a.entity_type_id=f.entity_type_id and a.attribute_code='firstname' limit 1) and e.entity_id=f.entity_id left join customer_address_entity_varchar n on n.entity_type_id=t.entity_type_id and n.attribute_id=(select b.attribute_id from eav_attribute b where b.entity_type_id=f.entity_type_id and b.attribute_code='lastname') and e.entity_id=n.entity_id limit 1' len 4)
[Aug 4 17:55:55] DEBUG[1459]: pbx_variables.c:381 ast_str_retrieve_variable: Result of 'ARG1' is '1235550001'
[Aug 4 17:55:55] DEBUG[1459]: res_odbc.c:864 _ast_odbc_request_obj2: Reusing ODBC handle 0xa3faa9c from class 'magento'
[Aug 4 17:55:55] DEBUG[1459]: func_odbc.c:1502 cli_odbc_read: Found handle magento
name Gogi Cooper
Returned 1 row. Query executed on handle 0 [magento]
*CLI> [Aug 4 17:55:55] DEBUG[1459]: res_odbc.c:713 ast_odbc_release_obj: Releasing ODBC handle 0xa3faa9c into pool

Exemple de fonction ODBC définie dans asterisk exécutée sur la ligne de commande, afin de récupérer prénom et nom depuis la BD Magento.

Menus vocaux et transfert d’information

Les menus vocaux peuvent être utilisés comme premier niveau de qualification d’appels entrants. Les informations saisies par l’utilisateur grâce aux codes DTMF générés par l’appui sur les touches doivent pouvoir être transmises à d’autres périphériques. Ces informations peuvent être stockées en BD, ou transmises par CURL, mais néanmoins comme ces informations sont en relation directe avec l’appel, il peut aussi être intéressant de les faire transiter directement dans la signalisation de l’appel au niveau SIP. Ceci est possible car on peut au niveau d’Asterisk ajouter des headers de son choix qui seront transmis dans la requête INVITE d’établissement de l’appel. Charge cependant à l’UA de traiter ces headers.

Dans le cadre de Magento, il ne faut pas négliger ce type de solution, car elle permet de décharger un opérateur de tâches répétitives sans grande valeur ajoutée, comme par exemple la saisie d’un numéro de client ou la saisie d’un numéro de commande. Cette démarche est d’autant plus judicieuse que Magento utilise à de très nombreux endroits des entity_id et que l’on peut automatiser des contrôles de cohérences en vérifiant par exemple la cohérence entre un numéro de commande, un numéro de téléphone et un numéro de client.

Fichiers d’appel (call files)

Les fichiers d’appel sont des fichiers qui définissent un canal que l’on doit tout d’abord contacter, et s’il répond, Asterisk lance la communication vers l’endroit spécifié dans le fichier (c’est à dire, fait démarrer l’appel dans un endroit du plan de numérotation, comme si le canal avait appelé).

Grâce à la technologie des canaux locaux d’Asterisk, cette technique n’est pas limitée à un canal bien défini, car on peut utiliser le canal local pour que la partie “futur appelant” soit l’objet d’un traitement au niveau du plan de numérotation.

Cette technique est assez simple, mais peut éventuellement poser des questions quant à son utilisation dans le cadre d’un couplage avec deux systèmes isolés, à cause de l’accès requis au système de fichiers. Il est même nécessaire d’avoir accès à deux répertoires : un répertoire pour préparer les fichiers, de sorte à ce que les fichiers soient entièrement écrits d’abord, et ensuite on peut les déplacer vers le répertoire de spool d’Asterisk, les deux devant être dans le même système de fichiers de sorte que le déplacement du fichier soit une opération atomique ne pouvant pas donner lieu à un problème de fichier lu alors qu’il n’est qu’à moitié écrit.

Avec l’existence d’une telle possibilité, on peut déjà améliorer le quotidien des commerciaux, puisqu’elle réduit les risques d’erreur lors de la saisie des numéros de téléphone et réduit le temps nécessaire pour composer les numéros de téléphone.

On pourrait également envisager des campagnes d’information ciblées en fonction des produits achetés, en préparant des annonces enregistrées que l’on souhaite diffuser aux clients.

Asterisk Gateway Interface

L’allusion à CURL fait penser à un autre type de solution : l’utilisation de l’Asterisk Gateway Interface, qui est le fait que pendant un appel, Asterisk arrive à s’interfacer avec des scripts qui communiquent avec lui à travers de stdin et stdout, pour faire exécuter diverses commandes, dont des assignations de variables, l’exécution d’applications du plan de numérotation, ou une redirection de l’appel à un autre endroit du plan de numérotation.

Il existe même des variantes qui permettent d’utiliser des connexions TCP à la place de stdin et stdout, ce qui permet de garder la spécialisation des serveurs tout en gardant les possibilités d’interactions accrues d’AGI.

On en déduit qu’on pourrait ainsi créer des scripts qui allient la puissance de Magento (avec la classe Mage) et les commandes AGI d’Asterisk.

Ce type de fonctionnement permet également de répondre à un autre type de problématique: la délimitation des secteurs de responsabilité. En effet, on constate régulièrement que même si la tendance DevOps est une tendance de plus en plus forte, où les développeurs doivent avoir une très bonne idée du fonctionnement de l’hébergement pour comprendre, et résoudre les problématiques qui peuvent en résulter, le développement de solutions et leur hébergement sur une infrastructure restent encore des métiers séparés. Il en va de même avec la téléphonie : on ne peut pas laisser par exemple la main sur l’ensemble d’un plan de numérotation à des développeurs, pour des questions de responsabilité. On peut donc utiliser AGI pour définir une ligne de démarcation entre les domaines de responsabilité des développeurs des scripts AGI et de l’équipe infrastructure en charge du PABX.

Asterisk Manager Interface

L’Asterisk Manager Interface est un autre type d’interface, qui s’apparente plutôt à une sorte de telnet. L’AMI s’exécute hors contexte d’appel, mais permet néanmoins d’être une source d’informations sur les appels, dans la mesure où l'on peut demander à récupérer des événements que l’on peut également filtrer. Dans le cadre de l’AMI, il est également possible de travailler sur des appels en cours, ou d’émettre de nouveaux appels. Du fait que l’on a accès à l’ensemble des appels, on peut par exemple utiliser l’AMI pour monitorer les appels en cours, comme le fait le Flash Operator Panel, qui est un outil complémentaire d’Asterisk assez connu.

De plus, cet outil a une gestion de droits, donc il est possible de créer des comptes avec des droits spécifiques. L’utilisation de l’AMI pourrait donc être une source centralisée d’informations sur tous les appels en cours en mode push, puisque c’est Asterisk qui fournit les événements. Toutefois, cette interface a comme inconvénient d’être une interface de type telnet, ce qui nécessite certaines pratiques dans le développement de l’interfaçage avec AMI, comme par exemple de bien re-segmenter les “blocs d’information”, et de bien distinguer une remontée d’information, d'une réponse à une commande.

L’AMI dispose d’un système de contrôle d’accès, avec une authentification pouvant utiliser différentes méthodes, ainsi qu’une gestion des droits : on peut donc préparer des comptes pour des applications. Un exemple est la gestion des appels évoquée précédemment : on peut par exemple souhaiter limiter le nombre de ressources simultanées utilisées pour les appels : l’AMI peut fournir des informations et peut permettre de déclencher des appels à bon escient (en ne les déclenchant que si le nombre de canaux que l’on souhaite utiliser n’est pas atteint).

Asterisk Rest Interface

L’Asterisk Rest Interface n’est pas qu’une simple interface RESTful : certes, cette interface existe, et est exposée au travers du serveur HTTP intégré à Asterisk, serveur qui peut également être utilisé pour accéder à l’AMI par exemple. Mais cette interface REST est complétée par un service événementiel qui est implémenté au dessus de WebSockets, avec des messages encapsulés dans du JSON, ainsi qu’une application particulière au niveau du plan de numérotation, qui est l’application Stasis.

Asterisk propose à travers cet ensemble de technologies un moyen qui permet de déporter l’intelligence du plan de numérotation vers une application externe. Pour ce faire, l’application doit ouvrir une connexion websocket et doit s’enregistrer pour souscrire aux événements liés à un “nom d’application” défini par le développeur. Une fois que cette souscription est active, un appel routé vers l’application Stasis va envoyer des événements à l’application à travers les websockets pour signifier de manière asynchrone des informations telles que le début d’appel ou un raccrochage.

L’application devra piloter entièrement ce qui doit être fait à travers les commandes implémentées dans l’interface REST, et se tiendra au courant via les événements asynchrones envoyés.

De part la nature asynchrone des notifications d'événements, il est la plupart du temps utile de définir des ID uniques au niveau de l’application afin de faire des correspondances entre les commandes envoyées et les événements reçus.

Cette commande est donc une étape extrêmement aboutie de couplage téléphonie informatique, la partie informatique représentée par l’application créée contrôlant l’appel de son côté et pouvant avoir des informations sur le fonctionnement du PABX lui-même, et la partie téléphonie, fournie par Asterisk, faisant juste le lien avec le tiers impliqué dans l’appel.


<?php
require_once('abstract.php');
require_once('../lib/autoload.php');

class Jmh_Ari extends Mage_Shell_Abstract
{
protected $_stasisClient;
protected $_stasisEvents;
/**
* @var phpari $_ariObject
*/
protected $_ariObject;
protected $_stasisLoop;
public function run()
{
$this->_ariObject = new phpari('version');

$this->_stasisClient = $this->_ariObject->stasisClient;
$this->_stasisEvents = $this->_ariObject->stasisEvents;
$this->_stasisEvents->on('StasisStart',function($event)
{

$channelId=$event->channel->id;
$this->_ariObject->channels()->channel_set_variable($channelId,'mage_version',Mage::getVersion());
$this->_ariObject->channels()->channel_continue($channelId,'ari','10',3);
}
);

$this->_stasisClient->on("message", function ($message) {
$event = json_decode($message->getData());
$this->_stasisEvents->emit($event->type, array($event));
});
$this->_stasisLoop = $this->_ariObject->stasisLoop;
$this->_stasisClient->open();
$this->_stasisLoop->run();

}

}

$ari = new Jmh_Ari();
$ari->run();

Exemple d’utilisation de la librairie PHPARI qui utilise l’ARI d’Asterisk : dans ce code shell Magento, on cherche à transmettre la version courante de Magento. A l’utilisation :


[Aug 15 13:16:23] DEBUG[1383]: ari/ari_websockets.c:177 ast_ari_websocket_session_write: Examining ARI event (length 561):
{
"variable": "mage_version",
"value": "1.9.2.4",
"type": "ChannelVarset",
"timestamp": "2016-08-15T13:16:23.750+0200",
"channel": {
"id": "1471259781.2",
"name": "SIP/jm-00000002",
"state": "Up",
"caller": {
"name": "",
"number": ""
},
"connected": {
"name": "",
"number": ""
},
"accountcode": "",
"dialplan": {
"context": "ari",
"exten": "10",
"priority": 2
},
"creationtime": "2016-08-15T13:16:21.769+0200",
"language": "fr"
},
"application": "version"
}

On constate dans la capture de débug que la version utilisée est bien remontée au niveau d’Asterisk.

Call Detail Record

Les CDR sont des enregistrements des informations vis à vis d’un appel, ou éventuellement d’une partie du trajet de l’appel. Ces informations peuvent éventuellement être intéressantes pour enrichir un CRM, en complément des informations qu’un commercial aura saisi sur l’appel. En revanche, l’intérêt des CDR sous Asterisk reste quand même limité, car la pertinence des informations loguées dépend également du plan de numérotation : plus un plan de numérotation est complexe (par exemple, avec l’utilisation de canaux de type Local), plus les CDR seront compliqués à exploiter - et ce, sans parler des cas de transfert d’appel. En plus, les informations ne sont pas disponibles avant la fin de l’appel, voire même avant un certain temps (par exemple si on utilise le batching). Cependant, on notera que la structure de donnés standard propose quand même un champ défini par l’utilisateur, champ qui pourrait par exemple être rempli automatiquement par le système pour se noter la qualification d’un appel réalisée par un menu vocal.

Les CDR seront utiles si on les récupère à des endroits stratégiques et où le plan de numérotation est simple, éventuellement par exemple sur une passerelle SIP / TDM.
Comme ils peuvent être stockés dans des bases de données comme MySQL, on peut envisager plusieurs types d’intégration (vues, moteur de stockage Mysql permettant d’attaquer un autre serveur, mais aussi connection vers une deuxième BD au niveau de Magento, en utilisant une connexion spécifique).

Channel Event Logging

Le CEL est une technologie plus récente qui est apparue en raison des cas non assurés par les CDR : l’idée est de générer des événements liés à la vie des canaux, et même si on le souhaite des événements personnalisés, qui devraient pouvoir être plus exploitables pour tirer de la valeur ajoutée des informations loguées. Ceci signifie que l’on peut chercher en fonction du contexte à définir des événements que l’on va lancer à travers le plan de numérotation pour les exploiter ensuite. Même si les CEL suivent en fait l’évolution des canaux, il faut quand même admettre que leur exploitation peut s’avérer compliquée, et que l’instrumentation complète d’un plan de numérotation à l’aide d'événements personnalisés est difficile à obtenir - aussi difficile qu’il est de prévoir tous les cas qui peuvent se présenter. Mais on peut profiter de cette possibilité pour qualifier un appel par exemple, même en cours de communication avec un agent (via des fonctionnalités spécifiques en cours de communication configurées dans features.conf, par exemple). Comme les CEL peuvent également être stockés en base de données, on pourra par exemple utiliser les possibilités qu’offre Magento en termes de grid, d’export de données, et plus généralement, de reporting, pour exploiter ces données.


Exemple d’affichage des CEL dans Asterisk, après avoir monté les données dans Magento via le moteur FEDERATED

Envoi de SMS

L’envoi de SMS est en théorie possible avec certaines applications du plan de numérotation d’Asterisk, mais je n’ai pour l’instant pas réussi à le faire fonctionner. Ceci n’est cependant pas la seule possibilité d’envoyer des SMS : on peut par exemple envisager de transformer un téléphone android en passerelle SMS, en fonction des volumes que l’on souhaite atteindre - et également si l’opérateur permet un tel usage. Sinon, il existe des API “propriétaires” d’entreprises pour envoyer des SMS.

L’envoi de SMS a un coût, mais un coût réduit, et est dans une certaine mesure, l’équivalent d’un mail, à ceci près qu’un SMS est court et dispose généralement et historiquement d’une notification immédiate à l’utilisateur qui a un téléphone portable : c’est donc un moyen de communication précieux puisque pouvant accéder de manière privilégiée au client.

De plus, Magento dispose déjà d’un système assez sophistiqué pour générer des mails à partir de templates. Comme il s’agit à la base dans les deux cas de produire un texte personnalisé, il sera donc envisageable de profiter de ce système existant pour l’adapter et l’utiliser pour l’envoi de SMS personnalisés.



A suivre jeudi 13 octobre : une présentation de possibilités de couplage téléphonie informatique envisageables au niveau des clients de téléphonie.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.