Contact Center vorbereiten
- Prüfen Sie, dass der Routing Service läuft, mit dem Server verbunden und im Failover der aktive Dienst ist. Ein passiver Routing Service verarbeitet keine neuen Chat- oder WebCallback-Anforderungen.
- Legen Sie das gewünschte Wissensgebiet und die Sprache an. Übermitteln Sie
deren Namen genau wie im Contact Center. Die Suche im Routing Service
vergleicht die Namen direkt. Ein Sprachwert wie
de-DEpasst nur, wenn die betreffende Sprache dort tatsächlich so heißt. - Weisen Sie den Agenten die passenden Qualifikationen zu und prüfen Sie ihre Anmeldung und Verfügbarkeit für den jeweiligen Kanal.
- Für Chat: Ordnen Sie einen Chat-Flow dem Paar aus Wissensgebiet und Sprache zu. Ohne passende Zuordnung beginnt kein Chat-Flow. Siehe Flow-Zuordnung und Einstellungen je Kanal.
- Für WebCallback: Prüfen Sie die Rückrufverteilung, die Telefonnummern und die ausgehende Telefonie. Der WebCallback legt einen Rückruf in der virtuellen Warteschlange an; er startet keinen Chat-Flow.
Netzwerk und öffentliche Adresse
Der Routing Service stellt die drei Hubs über HTTP auf Port 6010 bereit. Im hier dokumentierten Code ist der HTTPS-Listener nicht aktiviert. Für eine öffentliche HTTPS-Website benötigen Sie daher einen HTTPS-Reverse-Proxy vor diesem Dienst. Eine HTTPS-Seite darf den Hub nicht über unverschlüsseltes HTTP aufrufen: Der Browser blockiert solche gemischten Inhalte.
Beispiel für die Zuordnung durch Ihren Webserver:
| Öffentliche Adresse | Internes Ziel |
|---|---|
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 |
Leiten Sie auch die untergeordneten Pfade, insbesondere /negotiate, weiter.
Der Proxy muss die SignalR-Verbindung einschließlich WebSocket-Upgrades
unterstützen. Bei mehreren Routing Services muss die öffentliche Adresse zum
aktiven Dienst führen. Eine bestehende Chat-Verbindung wird bei einem Wechsel
nicht automatisch zu einer fortgesetzten Chatsitzung.
Der Hub-Code enthält keine eigene Anmeldung und erlaubt im CORS-Verhalten Anfragen von beliebigen Ursprüngen mit Zugangsdaten. Begrenzen Sie die Veröffentlichung daher auf die benötigten Pfade und richten Sie am öffentlichen Einstieg passende Zugriffsbeschränkungen und Schutz vor massenhaften Anforderungen ein. Die CORS-Einstellung ersetzt keine Zugriffskontrolle.
JavaScript bereitstellen
Binden Sie den JavaScript-Client für ASP.NET Core SignalR einmal ein,
beispielsweise als lokal bereitgestellte Datei signalr.min.js. Der alte
jQuery-SignalR-Client und ein Aufruf von /signalr/hubs passen nicht zu diesen
Hubs. Die Beispiele setzen voraus, dass die Bibliothek das Objekt signalR
bereitstellt.
Registrieren Sie die Ereignisbehandler vor connection.start(). Aktivieren
Sie Formular und Senden erst nach erfolgreichem Verbindungsaufbau. Zeigen Sie
Verbindungsfehler an und behandeln Sie sie getrennt von der fachlichen
Annahme einer Anfrage.
Einbindung prüfen
Prüfen Sie einen Chat und einen Rückruf mit einem angemeldeten, passend
qualifizierten Agenten. Prüfen Sie anschließend das geschlossene Wissensgebiet,
eine falsche Sprache, eine fehlende Chat-Zuordnung und eine unterbrochene
Verbindung. Kontrollieren Sie die Konversationen beziehungsweise die
Rückrufwarteschlange in der Administration und die Routing-Service-Protokolle.
Ein Rückgabewert true beim Registrieren bestätigt allein keinen erfolgreichen
Kontakt mit einem Agenten.