Préparer le Contact Center
- Vérifiez que le Routing Service fonctionne, est connecté au serveur et est actif dans le basculement. Un Routing Service passif ne traite pas les nouvelles demandes de chat ou de WebCallback.
- Créez la compétence et la langue souhaitées. Transmettez leurs noms
exacts tels qu'ils sont configurés dans le Contact Center. Le Routing
Service compare directement les noms. Une valeur comme
de-DEne convient que si la langue configurée porte réellement ce nom. - Attribuez les qualifications nécessaires aux agents et vérifiez leur connexion et leur disponibilité pour le canal concerné.
- Pour le chat : associez un flow de chat au couple compétence et langue. Sans correspondance, aucun flow de chat ne démarre. Voir Affectation du flow et Paramètres par canal.
- Pour WebCallback : vérifiez la distribution des rappels, les numéros et la téléphonie sortante. WebCallback crée un rappel dans la file virtuelle ; il ne démarre pas de flow de chat.
Réseau et adresse publique
Le Routing Service expose les trois hubs en HTTP sur le port 6010. Le listener HTTPS n’est pas activé dans le code documenté. Un site public en HTTPS nécessite donc un reverse proxy HTTPS devant ce service. Une page HTTPS ne doit pas appeler le hub en HTTP non chiffré : le navigateur bloque ce contenu mixte.
Exemple de correspondance sur votre serveur web :
| Adresse publique | Destination interne |
|---|---|
https://kontakt.example.org/chatHub |
http://routingserver:6010/chatHub |
https://kontakt.example.org/callbackHub |
http://routingserver:6010/callbackHub |
https://kontakt.example.org/acdHub |
http://routingserver:6010/acdHub |
Transférez aussi les chemins descendants, notamment /negotiate. Le proxy
doit prendre en charge la connexion SignalR et les mises à niveau WebSocket.
Avec plusieurs Routing Services, l’adresse publique doit mener au service
actif. Une connexion de chat existante ne devient pas automatiquement une
session reprise après un changement de service.
Le code des hubs ne possède pas d’authentification propre et sa politique CORS autorise les requêtes de toute origine avec des informations d’identification. Limitez la publication aux chemins nécessaires et configurez des restrictions d’accès et une protection contre les demandes massives au point d’entrée public. CORS ne remplace pas le contrôle d’accès.
Fournir JavaScript
Chargez une seule fois le client JavaScript ASP.NET Core SignalR, par
exemple avec un fichier local signalr.min.js. L’ancien client jQuery
SignalR et /signalr/hubs ne conviennent pas à ces hubs. Les exemples
supposent que la bibliothèque fournit l’objet signalR.
Enregistrez les gestionnaires d’événements avant connection.start().
Activez le formulaire et l’envoi uniquement après une connexion réussie.
Affichez les erreurs de connexion et distinguez-les de l’acceptation de la
demande par le Contact Center.
Tester l’intégration
Testez un chat et un rappel avec un agent connecté et correctement qualifié.
Testez ensuite une compétence fermée, une langue incorrecte, une affectation
de chat manquante et une connexion interrompue. Contrôlez les conversations
ou la file de rappels dans l’Administration et les journaux du Routing
Service. Un retour true lors de l’enregistrement ne confirme pas à lui
seul un contact réussi avec un agent.