Die Beispielkonzepte auf dieser Seite zeigen die verschiedenen Möglichkeiten für die Integration Ihres virtuellen Agenten in CXone. Sie basieren auf echten Szenarien, es muss aber beachtet werden, dass jede Organisation über eine spezifische Umgebung verfügt. Die Konzepte eignen sich in der gezeigten Form möglicherweise nicht für Ihre Umgebung.
Konzept 1: .NET API-Proxytunnel wird als Azure-Webdienst gehostet
Das Beispielkonzept 1 verfügt über eine .NET-API, die als Azure-Webdienst gehostet wird. Die Bot-Ebene des virtuellen Agenten ist in dieser Architektur so gestaltet, dass sich der virtuelle Agent und die kognitiven Dienste in verschiedenen Azure-Containern befinden. Der Proxytunnel erfordert für jede Anfrage drei spezifische Aufrufe:
- Der erste Aufruf sendet das Audio zur Transkription an den Sprache-zu-Text-Dienst.
- Der zweite Aufruf sendet den transkribierten Text an den virtuellen Agenten, der ihn analysiert, um die Absicht
Die Bedeutung oder der Zweck hinter dem, was ein Kontakt sagt/tippt; was der Kontakt mitteilen oder erreichen möchte festzustellen, und dann eine Antwort zurückgibt. - Der dritte Aufruf sendet die Antwort des virtuellen Agenten an den Text-to-Speech-Dienst, der ihn in eine Audioantwort synthetisiert. Die synthetisierte Antwort wird an CXone zurückgesendet.
In dieser Architektur kann es aufgrund der Anzahl der Aufrufe, die der Proxytunnel während jeder Anfrage tätigt, bei den Interaktionen zu Latenz kommen.
Konzept 2: Proxytunnel-Endpunkt ist in einem .NET gRPC-Client maskiert
In dieser Architektur ist der Proxytunnel-Endpunkt in einem .NET gRPC-Clientdienst maskiert, der sich in einem Container befindet. Der gRPC-Client ist als Docker-Container aufgebaut, der als Webdienst gehostet wird. Anfragen von CXone werden durch das API-Gateway zum Proxytunnel-Endpunkt innerhalb des gRPC-Clients geleitet.
Dieses Beispiel umfasst auch einen Autorisierungsdienst. Das CXone Studio-Skript ruft ein Autorisierungs-Token vom Autorisierungsdienst ab und gibt es an das Skript zurück. Anschließend sendet das Skript Anfragen über das API-Gateway.
Konzept 3: API-Gateway ist als Proxy maskiert
Dies ist eine relativ einfache Architektur, in der ein API-Gateway als Proxy maskiert ist. Sie umfasst alle Funktionen, die ein Proxytunnel anbieten muss, um benutzerdefinierte CXone-Endpunkte zu unterstützen. Sie kann also Nutzdaten übersetzen, Audiogespräche und Code-Umwandlungen verarbeiten sowie die Eingabe und Ausgabe zwischen Systemen weiterleiten.
