La documentation de conception technique (DCT) décrit les détails d’un système. Elle constitue un élément important de la planification de votre intégration d’agent virtuel personnalisée. Cette page est un guide pour la création d’une TDD pour l’intégration d’un agent virtuel personnalisé.
Chaque section de ce modèle de TDD contient des exemples ou des informations supplémentaires sur le contenu prévu pour cette section. Dans la mesure du possible, les exemples se rapportent à l’exemple d’intégration d’agent virtuel textuel.
Utilisez ce guide TDD et l’exemple d’intégration comme point de départ pour la planification de votre propre intégration personnalisée. Toutefois, étant donné qu’ils sont fournis à titre d’exemple, ni la TDD ni l’exemple de tunnel mandataire ne sont conçus pour un environnement spécifique. La TDD et le tunnel mandataire que vous créez doivent tenir compte de l’architecture et des exigences propres au réseau de votre organisation. Il se peut que vous deviez ajouter ou supprimer des sections pour répondre aux besoins de votre environnement.
Vue d’ensemble
Cette documentation de conception technique décrit l’intégration personnalisée de [votre agent virtuel] avec NICE CXone. L’intégration comprend les éléments suivants qui doivent être décrits dans cette documentation :
- Architecture, y compris le logiciel intermédiaire du tunnel mandataire/de la passerelle.
- Exigences en matière de configuration CXone, y compris les compétences, les points d’accès et les canaux.
- Concentrateur d’agents virtuels et le terminal pour les intégrations d’agents virtuels personnalisées (Terminal d’échange personnalisé).
- Scripts Studio, y compris le code Snippet.
- Exigences d’authentification.
- Configuration des agents virtuels, des terminaux, des détails sur l’origine des messages.
- Mappage des schémas de requête et de réponse.
- [Autres composants propres à votre architecture et à votre intégration].
Aperçu de l’architecture
À faire : Créez un diagramme d’aperçu de votre intégration. Incluez tous les composants de votre environnement qui sont impliqués dans la gestion d’une interaction. Il s’agit du tunnel mandataire, de l’agent virtuel, d’un serveur d’autorisation, etc. Incluez une description générale. Créez des diagrammes supplémentaires si vous avez besoin de montrer certaines parties plus en détail.
Exemple
Il s’agit d’un exemple d’intégration d’un agent virtuel sur un canal de clavardage ACD. Comme il s’agit d’un exemple d’intégration, certains éléments diffèrent d’une intégration réelle :
- Le code du tunnel mandataire est l’un des exemples d’options fournis par NICE CXone. Le code C# est utilisé dans les exemples de cette page.
- Le tunnel mandataire ne se connecte pas à un agent virtuel réel.
- Le terminal du tunnel mandataire est conçu pour renvoyer le texte saisi par l’utilisateur.
- Le clavardage de ce canal
Un moyen pour les contacts d’interagir avec des agents ou des bots. Un canal peut être la voix, la messagerie électronique, le clavardage, les médias sociaux, etc. n’est pas configuré sur un site Web en direct. Le canal de clavardage est testé par le biais d’un lien direct obtenu à partir de la page du point d’accès dans CXone.
Il s’agit d’une intégration simple qui ne nécessite aucune autorisation.
Configuration CXone
À faire : Dressez la liste des canaux Un moyen pour les contacts d’interagir avec des agents ou des bots. Un canal peut être la voix, la messagerie électronique, le clavardage, les médias sociaux, etc., compétences Utilisé pour automatiser la livraison des interactions en fonction des compétences, des capacités et des connaissances des agents, points d’accès Le point d’entrée qu’un contact entrant utilise pour lancer une interaction, tel qu’un numéro de téléphone ou une adresse courriel., campagnes, et tout autre paramètre de configuration CXone pertinent. Pour plus d’informations, voir Exigences de configuration CXone sur la page Ressources.
Exemple
- Canal : Clavardage ACD.
- Compétence : Compétence de clavardage appelée IBChat_CEESample.
- Point d’accès : Point d’accès appelé IBChat_CEESample.
- Campagne : CEESample.
Exigences en matière de canaux
Comme il s’agit d’un exemple d’intégration, aucun profil de clavardage n’est requis. Toutefois, dans le cadre d’une intégration réelle, cette section spécifierait les exigences relatives au profil de clavardage. Le profil de clavardage définit l’aspect de la fenêtre de clavardage. Cette section énumère également les pages du site Web où se trouve la bulle de clavardage, ainsi que toute autre exigence connexe.
Configuration Concentrateur d’agents virtuels
À faire : Indiquez l’URL du webhook pour votre agent virtuel et tous les paramètres que votre agent virtuel doit envoyer avec les requêtes. Si vous déterminez que vous avez besoin d’un délai différent, ajoutez-le à cette section. Le processus complet de configuration du terminal d’échange personnalisé dans Concentrateur d’agents virtuels est décrit sur la page Implémentation.
Exemple
- URL du webhook :
- Paramètres de terminal : Aucun paramètre requis
- En-têtes personnalisés (version d’intégration 2.0.0 et 3.0.0 uniquement) : Aucun en-tête requis
- Dépassement de délai : Aucune modification nécessaire
- En-tête d’autorisation : Aucun en-tête requis
- Configuration OAuth : Aucune configuration requise
- URL OAuth : S/O
- Paramètres de la requête OAuth : S/O
- En-têtes OAuth : S/O
Notez que dans la version d’intégration 1.0.0, l’authentification dynamique doit être configurée dans le script, et non dans Concentrateur d’agents virtuels.
Scripts Studio
À faire : Ajoutez des captures d’écran des scripts que vous concevez pour votre intégration d’agent virtuel personnalisée, ainsi que des explications. Incluez des descriptions des variables, des extraits de code et d’autres détails si nécessaire. Pour plus d’informations, voir les directives et les exigences relatives aux scripts.
Exemple de script de clavardage
Il s’agit du même script que celui utilisé dans l’exemple d’intégration. Vous pouvez l’utiliser comme base pour votre propre script. Des exemples de scripts sont également fournis pour les agents virtuels vocaux .
Ce script commence par une action Snippet qui crée plusieurs objets de données dynamiques nécessaires à l’intégration d’un agent virtuel :
- intentInfo
- nextPromptSequence
- nextPromptBehaviors
- customPayload
- botSessionState
La première action Textbot Exchange définit l’intention La signification ou le but derrière ce qu’un contact dit/tape ; ce que le contact veut communiquer ou accomplir à laquelle l’agent virtuel doit répondre en tant qu’intention de bienvenue. Lorsque l’agent virtuel répond, elle remplit les objets botSessionState et customPayload et les convertit en JSON à l’aide de la fonction
La première action Textbot Exchange comporte trois branches :
- Error : La branche d’erreur traite l’erreur et fournit un message approprié au contact.
- Return Control to Script : Cette branche est prise lorsque l’agent virtuel signale que la conversation est terminée ou que le contact doit être transféré à un agent en chair et en os.
- Prompt and Collect Next Response : Cette branche poursuit la conversation, comme décrit ci-dessous.
Le script transmet les données reçues de l’agent virtuel dans les objets botsessionState, customPayloadFromBot, intentInfo et nextPrompt. L’action Askcaller invite le contact à répondre à l’agent virtuel (nextPrompt). Cette action comporte quatre branches :
- Error
- Return Control to Script
- Caller Responded
- Default
Toutes les branches sont dirigées vers la deuxième action Textbot Exchange, qui envoie les informations appropriées à l’agent virtuel, y compris la prochaine requête du contact dans la variable RES. Textbot Exchange a les mêmes branches que la première instance de l’action dans le script.
Autorisation du terminal de service
À faire : Déterminez les exigences d’autorisation de votre service d’agent virtuel. Si une autorisation est requise, remplissez cette section de la TDD. Créez un diagramme illustrant les exigences en matière d’autorisation pour votre environnement. Incluez les détails de ce qui est requis pour les requêtes d’autorisation. Il peut s’agir des détails suivants :
- Le type d’autorisation (en-têtes ou jetons).
- Les paires clé-valeur pour tous les en-têtes requis. Si vous utilisez la version 1.0.0 de l’échange personnalisé, vous n’avez besoin que de la valeur de l’en-tête.
- Toute configuration requise pour le service d’agent virtuel si vous utilisez des en-têtes ou le serveur d’autorisation si vous utilisez des jetons.
- L’URL du serveur d’autorisation, si vous utilisez des jetons.
- Les paires clé-valeur nécessaires pour le corps et les en-têtes de la requête OAuth.
- Si vous devez ou souhaitez personnaliser d’autres paramètres OAuth, indiquez ces modifications. Vous pouvez modifier le nom de l’en-tête, le préfixe de la valeur de l’en-tête et le délai d’expiration du jeton.
Pour plus d’informations, voir la section Autorisation sur la page Ressources.
Exemple de terminaux de service non autorisés (publics)
L’exemple d’intégration n’a pas besoin d’autorisation. Le diagramme suivant montre un exemple de ce à quoi peut ressembler un terminal de service public.
Dans cet exemple, la requête vient de Concentrateur d’agents virtuels. Il interagit d’abord avec la passerelle API, puis avec le service d’agent virtuel.
Exemple de terminaux de service autorisés
Lorsqu’un service d’agent virtuel requiert une autorisation pour recevoir des requêtes, vous devez envoyer des en-têtes d’autorisation avec chaque requête. Vous pouvez également utiliser l’authentification dynamique, qui nécessite un serveur d’autorisation (fournisseur de jetons). L’architecture d’une intégration qui utilise des en-têtes ressemble à celle de l’exemple de terminal de service public de la section précédente. Le diagramme suivant montre un exemple de mise en œuvre de l’authentification dynamique.
Dans cet exemple, lorsque le script commence, une requête REST est adressée au serveur d’autorisation, qui fournit un jeton. Le jeton est envoyé au terminal d’échange personnalisé. Tant que le jeton est valide, les requêtes peuvent être envoyées au service d’agent virtuel.
Tunnel mandataire
À faire : Déterminez les détails de votre tunnel mandataire, y compris :
- Comment votre tunnel mandataire sera hébergé.
- Le langage dans lequel le tunnel mandataire sera développé et les applications, dépendances, SDK, packs d’extension, etc. nécessaires.
- Une stratégie de basculement du tunnel mandataire.
Exemple
Hébergement du tunnel mandataire
L’exemple de tunnel mandataire sera hébergé sur la machine locale de la personne qui met en place l’exemple d’intégration d’un agent virtuel textuel.
Langue
Le tunnel mandataire sera développé en C#. L’éditeur VS Code et un SDK .NET seront nécessaires.
Stratégie de basculement
Comme il s’agit d’un exemple d’intégration, aucune stratégie de basculement n’est nécessaire.
Cas d’utilisation de l’agent virtuel - Mappage des terminaux du mandataire à l’agent virtuel
À faire : Créez un diagramme de séquence détaillé qui illustre les réponses et les requêtes utilisées à chaque point d’une interaction. Documentez les schémas de requête et de réponse dans CXone et votre service d’agent virtuel que votre intégration personnalisée requiert. L’exemple de cette section ne présente que des schémas pour CXone. Pour plus d’informations, voir la section Tunnel mandataire et la section Diagrammes de séquence sur la page Ressources.
Exemple
Le diagramme de séquence et tout ce qui suit est un exemple basé sur Swagger, disponible au moment de la publication. Utilisez toujours les schémas documentés dans le document Swagger 
accessible au public pour les intégrations d’agents virtuels personnalisées. Les schémas du terminal d’échange personnalisé peuvent être mis à jour périodiquement. Pour plus d’informations sur l’impact de cette mesure sur votre intégration personnalisée, consultez la page Ressources.
Schémas de requête et de réponse
Les schémas des requêtes sont inclus dans cette page, à titre d’exemple d’une documentation des schémas. Pour des explications détaillées sur les schémas d’intégration des agents virtuels personnalisés, voir la page Schémas.
Requête — ExternalIntegrationBotExchangeRequest
|
Paramètre |
Type |
Description |
|---|---|---|
| virtualAgentId | Chaîne |
Le nom donné à l’application de configuration Terminal d’échange personnalisé dans Concentrateur d’agents virtuels. Ce nom identifie l’agent virtuel que l’application invoque. |
| botConfig | Objet | Les paramètres définis dans |
| userInput | Chaîne | L’entrée de texte de l’utilisateur reçue du point d’accès Le point d’entrée qu’un contact entrant utilise pour lancer une interaction, tel qu’un numéro de téléphone ou une adresse courriel. auquel le script est assigné. |
| userInputType | Énumération | Le type d’entrée utilisateur fourni par le script. |
| executionInfo |
|
Données télémétriques pour l’exécution d’une action Exécute un processus au sein d’un script Studio, tel que la collecte de données client, l’écoute d’un message ou de musique, ou le routage d’un contact vers un agent. dans un script. |
| systemTelemetryData |
|
Données pouvant être utilisées pour le débogage. Contient des informations sur l’infrastructure CXone. |
| base64wavFile | Chaîne | Contient le fichier WAV codé en base 64 qui contient l’en-tête de la requête et l’audio de l’énoncé Ce qu’un contact dit ou tape. de l’utilisateur. |
| botSessionState | Objet | Peut être utilisé pour les variables d’information de session aller-retour reçues de l’agent virtuel. |
| customPayload | Objet | Peut être utilisé pour envoyer des variables et des paramètres supplémentaires à partir du contexte du script Studio. |
| mediaType | Chaîne | Indique le type de support du script en cours d’exécution. |
Requête — ActionExecutionInfo
|
Paramètre |
Type |
Description |
|---|---|---|
|
|
Nombre entier | L’identifiant unique de l’interaction. |
|
|
Nombre entier | L’identifiant unique du unité commerciale Regroupement organisationnel de haut niveau utilisé pour gérer le support technique, la facturation et les paramètres globaux pour votre environnement CXone. |
|
|
Nombre entier |
Un numéro itératif qui identifie chaque demande dans une interaction particulière.
|
|
|
Chaîne | Le type d’action qui effectue la requête auprès du terminal d’échange personnalisé. |
|
|
Nombre entier | L’identifiant unique de l’action Exécute un processus au sein d’un script Studio, tel que la collecte de données client, l’écoute d’un message ou de musique, ou le routage d’un contact vers un agent. dans le script. Les ID des actions sont basés sur l’ordre dans lequel les actions ont été ajoutées au script. |
|
|
Chaîne | Le nom du script. |
Requête — SystemTelemetryData
|
Paramètre |
Type |
Description |
|---|---|---|
|
|
Chaîne | Le nom d’hôte de l’application qui appelle l’API. |
|
|
Chaîne | Le nom du processus ou de l’application de l’appelant API. Par exemple, EsnMediaServer.exe. |
|
|
Chaîne | Toute information sur la version de l’application qui appelle l’API. |
|
|
Chaîne | Le cas échéant et si disponible, indiquez l’alias du cluster NICE CXone, tel que C7 ou M33. |
|
|
Chaîne | Le cas échéant et si disponible, indiquez le nom de l’hôte du moteur de script NICE CXone, tel que lax-c4cor01 ou aoa-c32cor01. |
|
|
Objet | Données arbitraires et extensibles sur le consommateur d’API. |