Les exemples de conception sur cette page montrent les différentes possibilités d’intégration d’un agent virtuel avec CXone. Ils reposent sur des cas de figure réels, mais il est important de comprendre que l’environnement de chaque organisation est différent. Il est possible que les conceptions illustrées ne conviennent pas à votre environnement.
Conception 1 : tunnel de proxy d’API .NET hébergé sous forme de service web Azure
L’exemple 1 montre une API .NET hébergée sous forme de service web Azure. La couche de l’architecture correspondant au bot agent virtuel est conçue de manière que l’agent virtuel et les services cognitifs se trouvent dans des conteneurs différents dans Azure. Le tunnel de proxy requiert trois appels distincts pour chaque demande :
- Le premier appel envoie l’audio au service de reconnaissance vocale (STT) afin qu’il soit transcrit.
- Le deuxième appel envoie la transcription obtenue à l’agent virtuel, qui l’analyse pour déterminer l’intention
La signification ou le but derrière ce qu'un contact dit/tape ; ce que le contact veut communiquer ou accomplir et renvoie une réponse. - Le troisième appel envoie la réponse de l’agent virtuel au service de synthèse vocale (TTS) afin qu’elle soit restituée sous forme audio. La réponse synthétisée est renvoyée à CXone.
Cet exemple d’architecture peut entraîner de la latence pendant les interactions en raison du nombre d’appels émis par le tunnel de proxy sur chaque demande.
Conception 2 : point de terminaison de tunnel de proxy masqué à l’intérieur du client gRPC .NET.
Dans cet exemple, l’architecture présente un point de terminaison de tunnel de proxy à l’intérieur d’un service client gRPC .NET conteneurisé. Le client gRPC est conçu sous forme de conteneur Docker hébergé comme un service web. Les demandes provenant de CXone passent par la passrelle API pour atteindre le point de terminaison de tunnel de proxy à l’intérieur du client gRPC.
Cet exemple incorpore également un service d’autorisation. Le script Studio CXone obtient un jeton d’autorisation auprès du service d’autorisation et le renvoie au script. Le script envoie ensuite la demande via la passerelle API.
Conception 3 : passerelle API masquée sous forme de proxy
Cette architecture relativement simple comprend une passerelle API qui est masquée sous forme de proxy. Elle peut effectuer tout ce qu’un tunnel de proxy doit faire pour prendre en charge les points de terminaux personnalisés CXone. Elle peut ainsi se charger de la conversion des charges utiles, de la conversation et du transcodage audio, et de la transmission des entrées et sorties entre les systèmes.
