Les documents de conception technique (ou TDD, selon l’acronyme anglais Technical Design Document) décrivent les détails d’un système. Ils forment une étape importante dans la planification de votre intégration d’agent virtuel personnalisée. Cette page est un guide pour créer un TDD adapté à votre intégration d’agent virtuel personnalisée.
Chaque section de ce modèle TDD contient des exemples ou des informations complémentaires sur le contenu attendu de la section. Lorsque c’est possible, les exemples font référence à l’exemple d’intégration d'agent virtuel de type texte.
Appuyez-vous sur ce guide TDD et l’exemple d’intégration pour démarrer la planification de votre intégration personnalisée. Néanmoins, parce qu’ils sont fournis à titre d’exemples, ni le TDD ni l’exemple de tunnel de proxy ne sont conçus pour un environnement particulier. Le TDD et le tunnel de proxy que vous créez doivent tenir compte de l’architecture réseau et des besoins précis de votre organisation. Il peut être nécessaire d’ajouter ou de supprimer des sections selon ce qu’exige votre environnement.
Aperçu
Ce document de conception technique décrit l’intégration personnalisée de [votre agent virtuel] avec NICE CXone. L’intégration porte sur les composants suivants, qui doivent être décrits dans ce document :
- Architecture, notamment l’intergiciel de passerelle/tunnel de proxy.
- Exigences de configuration de CXone, notamment les compétences, les points de contact et les canaux.
- Virtual Agent Hub et le terminal destiné aux intégrations d’IA personnalisées (Custom Exchange Endpoint).
- Script Studio, notamment le code Snippet.
- Exigences d’authentification.
- Configuration de l’agent virtuel, points de terminaison, détails sur l’origine des messages.
- Mappage des schémas de demandes et réponses.
- [autres composants spécifiques à votre architecture et votre intégration].
Vue d’ensemble de l’architecture
Tâche à accomplir : Créez un diagramme d’ensemble de votre intégration. Prenez en compte tous les composants de votre environnement qui interviennent dans le traitement d’une interaction. Cela inclut le tunnel de proxy, l’agent virtuel, un serveur d’autorisation, etc. Incorporez une description d’ensemble. Créez des diagrammes supplémentaires si vous devez présenter certaines parties de manière plus détaillée.
Exemple
Voici un exemple d’intégration d'agent virtuel de type texte dans un canal de chat ACD. Comme il s’agit d’un exemple d’intégration, certains éléments présentent des différences avec une intégration réelle :
- Le code du tunnel de proxy correspond à l’un des exemples fournis par NICE CXone. Les exemples de cette page utilisent le code de programmation C#.
- Le tunnel de proxy ne se connecte pas à un véritable agent virtuel.
- Le point de terminaison du tunnel de proxy est conçu pour renvoyer en écho le texte saisi par l’utilisateur.
- Le chat de ce canal
Le moyen utilisé par les contacts pour interagir avec les agents ou les robots. Le canal peut être vocal, e-mail, chat, réseaux sociaux, etc. n’est pas configuré sur un site web actif. Le canal de chat est testé par le biais d’un lien direct obtenu à partir de la page Point de contact dans CXone.
Il s’agit d’une intégration simple qui ne nécessite aucune autorisation.
CXone Configuration
Tâche à accomplir : répertoriez le canal Le moyen utilisé par les contacts pour interagir avec les agents ou les robots. Le canal peut être vocal, e-mail, chat, réseaux sociaux, etc., les compétences Utilisé pour automatiser la livraison des interactions en fonction des compétences, des capacités et des connaissances des agents, les points de contact Le point d'entrée qu'un contact entrant utilise pour initier une interaction, tel qu'un numéro de téléphone ou une adresse e-mail., les campagnes et d’autres paramètres de configuration de CXone. Pour plus d’informations, voir Exigences de configuration de CXone sur la page Ressources.
Exemple
- Canal : chat ACD.
- Compétences : compétence de chat appelée IBChat_CEESample.
- Point de contact : point de contact chat appelé IBChat_CEESample.
- Campagne : CEESample.
Exigences concernant le canal
Comme il s’agit d’un exemple d’intégration, aucun profil de chat n’est requis. Cependant, dans une intégration réelle, cette section spécifierait les exigences relatives au profil de chat. Le profil de chat définit la présentation de la fenêtre de chat. Cette section dresserait également la liste des pages du site web sur lesquelles figurerait la bulle de chat, et d’autres exigences liées au chat.
Virtual Agent Hub Configuration
Tâche à accomplir : répertoriez l’URL de webhook de votre agent virtuel ainsi que les paramètres qui doivent accompagner les demandes qu’il reçoit. Si vous déterminez qu’il vous faut un délai différent, ajoutez-le dans cette section. Le processus de configuration complet de Custom Exchange Enpoint dans Virtual Agent Hub est décrit sur la page Mise en œuvre.
Exemple
- URL du webhook :
- Paramètres du 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 : pas de modification nécessaire.
- En-tête d’autorisation : aucun en-tête requis.
- Configuration OAuth : aucune configuration requise.
- URL OAuth : non applicable
- Paramètres de requêtes OAuth : non applicable.
- En-têtes OAuth Headers : non applicable.
Notez que dans la version d’intégration 1.0.0, la configuration de l’authentification dynamique doit s’effectuer dans le script, pas dans Virtual Agent Hub.
Studio Scripts
Tâche à accomplir : ajoutez des captures d’écran des scripts que vous concevez pour votre intégration d’agent virtuel personnalisée, avec les explications nécessaires. Précisez la description des variables, un extrait de code et autres détails s’il y a lieu. Pour plus d’informations, voir les Exigences et recommandations concernant les scripts.
Exemple de script de chat
Ce script est identique à 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’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éagir comme intention de bienvenue. Lorsque l’agent virtuel répond, il remplit les objets botSessionState et customPayload, et les convertit au format JSON à l’aide de la fonction
La première action Textbot Exchange comprend trois branches :
- Error : la branche d’erreur traite l’erreur et fournit au contact un message adapté.
- 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 humain.
- 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 aux objets botsessionState, customPayloadFromBot, intentInfo et nextPrompt. L’action Askcaller adresse une invite au contact avec la réponse de l’agent virtuel (nextPrompt). L’action présente quatre branches :
- Error
- Return Control to Script
- Caller Responded
- Default
Toutes les branches mènent à la deuxième action Textbot Exchange, qui envoie les informations appropriées à l’agent virtuel, notamment la nouvelle demande du contact dans la variable RES. Ce Textbot Exchange présente les mêmes banches que la première instance de l’action dans le script.
Autorisation du point de terminaison de service
Tâche à accomplir : déterminez les exigences d’autorisation de votre service d’agent virtuel. Si l’autorisation est requise, remplissez cette section du TDD. Créez un diagramme qui illustre les exigences d’autorisation pour votre environnement. Précisez les informations indispensables pour les demandes d’autorisations. Cela peut inclure :
- Le type d’autorisation (en-têtes ou jetons).
- Les paires clé-valeur pour tous les en-têtes requis. Si vous utilisez Custom Exchange Endpoint version 1.0.0, vous avez seulement besoin de la valeur destinée à l’en-tête.
- Toutes les exigences de configuration 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 OAuth.
- Si vous devez ou souhaitez personnaliser les paramètres OAuth, spécifiez ces modifications. Vous pouvez modifier le nom d’en-tête, le préfixe de la valeur d’en-tête et le délai d’expiration du jeton.
Pour plus d’informations, voir la section Autorisation sur la page Ressources.
Exemple pour des points de terminaison de service non autorisés (publics)
L’exemple d’intégration ne nécessite pas d’autorisation. Le schéma ci-dessous montre à quoi peut ressembler un point de terminaison de service public.
Dans cet exemple, la demande provient de Virtual Agent Hub. Elle interagit d’abord avec la passerelle API, puis avec le service d’agent virtuel.
Exemple de points de terminaison de service autorisés
Lorsque le service d’agent virtuel requiert une autorisation pour recevoir des demandes, vous devez envoyer des en-têtes d’autorisation avec chaque demande. Vous pouvez également utiliser l’authentification dynamique, qui nécessite un serveur d’autorisation (fournisseur de jetons). Pour une intégration utilisant des en-têtes, l’architecture ressemblerait à celle de l’exemple de point de terminaison de service public donné à 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 demande REST est envoyée au serveur d’autorisation, qui fournit un jeton. Le jeton est envoyé à Custom Exchange Endpoint. Tant que le jeton est valide, les demandes peuvent être envoyées au service d’agent virtuel.
Tunnel de proxy
Tâche à accomplir : déterminez les détails de votre tunnel de proxy, notamment :
- Les modalités d’hébergement de votre tunnel de proxy.
- Le langage dans lequel le tunnel de proxy va être développé, ainsi que les applications, dépendances, SDK et packs d’extensions nécessaires, entre autres.
- Une stratégie de basculement en cas d’échec du tunnel de proxy.
Exemple
Hébergement du tunnel de proxy
L’exemple de tunnel de proxy sera hébergé sur la machine locale de la personne qui configure l’exemple d’intégration d'agent virtuel de type texte.
Langue
Le tunnel de proxy sera développé en C#. Il nécessitera l’éditeur VS Code et un SDL .NET.
Stratégie de basculement
Comme il s’agit d’un exemple d’intégration, aucune stratégie de basculement n’est requise.
Cas d’utilisation de l’agent virtuel : mappage du proxy au terminal de l’agent virtuel
Tâche à accomplir : créez un diagramme de séquence détaillé qui illustre les réponses et demandes utilisées à chaque point d’une interaction. Documentez les schémas de demandes et réponses dans CXone et votre service d’agent virtuel qui sont nécessaires à votre intégration personnalisée. L’exemple fourni dans cette section montre uniquement des schémas destinés à CXone. Pour plus d’informations, voir la section Tunnel de proxy et la section Diagrammes de séquences sur la page Ressources.
Exemple
Le diagramme de séquence et tout ce qui suit représentent un exemple basé sur la documentation Swagger disponible au moment de la publication. Utilisez toujours des schémas documentés dans l’instance Swagger 
disponible publiquement lors des intégrations personnalisées d’agents virtuels. Les schémas Custom Exchange Endpoint peuvent faire l’objet de mises à jour périodiques. Pour plus d’informations concernant leur incidence sur votre intégration personnalisée, voir la page Ressources.
Schémas des demandes et réponses
Les schémas correspondant aux demandes figurent sur cette page, en guise d’exemple pour la documentation des schémas. Pour obtenir des explications détaillées des schémas d’intégration de l’agent virtuel personnalisé, voir la page Schémas.
Demande – ExternalIntegrationBotExchangeRequest
|
Paramètre |
Type |
Description |
|---|---|---|
| virtualAgentId | Chaîne |
Le nom donné à l’application de configuration de Custom Exchange Endpoint dans Virtual Agent Hub. Ce nom identifie l’agent virtuel que l’application invoque. |
| botConfig | Objet | Les paramètres définis dans |
| userInput | Chaîne | Le texte saisi par l’utilisateur, reçu du point de contact Le point d'entrée qu'un contact entrant utilise pour initier une interaction, tel qu'un numéro de téléphone ou une adresse e-mail. auquel est assigné le script. |
| userInputType | Énumération | Le type de saisie d’entrée utilisateur fourni par le script. |
| executionInfo |
|
Les données de télémétrie destinées à l’exécution d’une action Exécute un processus dans un script Studio, tel que la collecte de données client, la lecture d'un message ou d'une musique, ou l'acheminement d'un contact vers un agent. dans un script. |
| systemTelemetryData |
|
Les données qui peuvent servir au débogage. Contient des informations sur l’infrastructure CXone. |
| base64wavFile | Chaîne | Contient le fichier WAV codé en base 64 qui inclut l’en-tête de la demande et les données audio de l’énoncé Ce qu'un contact dit ou tape. de l’utilisateur. |
| botSessionState | Objet | Peut être utilisé pour les variables d’informations sur la session aller-retour reçues de l’agent virtuel. |
| customPayload | Objet | Peut être utilisé pour envoyer des variables et paramètres supplémentaires tirés du contexte du script Studio. |
| mediaType | Chaîne | Indique le type de média du script en cours d’exécution. |
Demande – ActionExecutionInfo
|
Paramètre |
Type |
Description |
|---|---|---|
|
|
Entier | L’identifiant unique de l’interaction. |
|
|
Entier | L’identifiant unique de l’unité d’exploitation Regroupement organisationnel de haut niveau utilisé pour gérer le support technique, la facturation et les paramètres globaux de votre CXone environnement. |
|
|
Entier |
Un numéro itératif qui identifie chaque demande dans une interaction particulière.
|
|
|
Chaîne | Le type d’action qui effectue la demande à Custom Exchange Endpoint. |
|
|
Entier | L’identifiant unique de l’action Exécute un processus dans un script Studio, tel que la collecte de données client, la lecture d'un message ou d'une musique, ou l'acheminement d'un contact vers un agent. dans le script. Les identifiants d’actions se fondent sur l’ordre dans lequel les actions ont été ajoutées au script. |
|
|
Chaîne | Le nom du script. |
Demande – SystemTelemetryData
|
Paramètre |
Type |
Description |
|---|---|---|
|
|
Chaîne | Le nom de l’hôte de l’application appelant l’API. |
|
|
Chaîne | Le nom de processus ou d’application de l’appelant de l’API. Par exemple, EsnMediaServer.exe. |
|
|
Chaîne | Toute information de version relative à l’application appelant l’API. |
|
|
Chaîne | S’il y a lieu et si vous en disposez, fournissez l’alias de cluster NICE CXone, par exemple C7 ou M33. |
|
|
Chaîne | S’il y a lieu et si vous en disposez, fournissez le nom d’hôte du moteur de script NICE CXone, par exemple lax-c4cor01 ou aoa-c32cor01. |
|
|
Objet | Données extensibles et arbitraires concernant l’usager de l’API. |