Les diagrammes de réseau illustrent la manière dont les informations circulent les CXone applications. Les flèches dans les diagrammes représentent le flux d'informations et non la source de la demande. Presque tous les flux semblent bidirectionnels, même si la connexion peut toujours provenir d'un emplacement. Par exemple, la plupart des flux d'API sont RESTful et proviennent toujours du client. Cependant, les données transmises via l'API peuvent être placées dans le système, extraites du système ou les deux. C'est pourquoi la flèche est indiquée comme bidirectionnelle.
Il existe plusieurs types de divisions, ou limites, dans les diagrammes. Une frontière principale se situe entre les réseaux publics et privés. Les réseaux privés peuvent inclure une autre frontière entre les réseaux internes et DMZ. La DMZ permet d'interagir avec les réseaux publics tout en protégeant les réseaux internes sensibles.
Les systèmes de cloud public introduisent un réseau combiné qui n'est pas entièrement public ou privé. C'est ce que l'on appelle un réseau de périphérie, car les périphériques et services limitrophes terminent généralement le chiffrement à la périphérie du réseau public.
Les diagrammes indiquent les changements de cryptage par des lignes pleines et en pointillés. En fonction de l'infrastructure cloud, cela peut entraîner un trafic non chiffré passant sur les réseaux périphériques.
Sauf indication contraire, toutes les données client sont cryptées en transit et au repos.
Afficher une légende pour les images et les icônes utilisées dans les diagrammes
|
champs |
Détails |
|---|---|
|
Emplacements de cloud privé, d'entreprise ou de client |
|
|
Emplacements cloud publics et privés |
|
Segmentation interne au sein d'emplacements cloud publics ou privés |
|
Particuliers qui utilisent les services |
|
Applications et services qui utilisent les services |
|
Appareils utilisateur |
|
Flux d'informations cryptées non personnelles, avec des flèches indiquant la direction |
|
Flux d'informations non cryptées et non personnelles, avec des flèches indiquant la direction |
|
Flux d'informations personnelles cryptées, avec des flèches indiquant la direction |
|
Flux d'informations personnelles non cryptées, avec des flèches indiquant la direction |
|
Flux hybrides pour les informations personnelles ou non personnelles, lorsqu'un périphérique périphérique met fin au cryptage |
Composants de haut niveau
Ce diagramme montre les composants de haut niveau de CXone et leurs relations les uns avec les autres. Le CXone conteneur cloud englobe toute CXone infrastructure pour les systèmes de production FedRAMP et non FedRAMP. CXone est hébergé dans des clouds privés et publics, et est divisé en infrastructure d'application et infrastructure voix. L'infrastructure vocale est hébergée presque exclusivement via le cloud privé.
Les conteneurs sur le côté gauche sont des réseaux externes et sont essentiels pour la fonctionnalité du produit. Ces services externes comprennent:
- NICE CXone
- Partenaires
- Services externes
- Locataire
Dans tous les cas, des informations personnelles et non personnelles sont transmises. Le trafic non chiffré est presque toujours lié à la voix ou à d'autres canaux 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. de trafic et peut ne pas être entièrement crypté.
Flux communs
Ce diagramme illustre comment les utilisateurs interagissent avecCXone en utilisant l'infrastructure applicative et les applications suivantes:
- Auto Attendant
- CXone applications de portail Web comme ACD, Admin et ainsi de suite (sauf FTP)
- Accès aux données direct
La plupart des interactions utilisateur se produisent entre un navigateur et l'infrastructure d'application à l'aide de protocoles et de ports Web standard (443 et 80). Quelques CXone applications de la suite nécessitent d'autres services et des ports Où les informations sont transférées, sur un réseau, entre un ordinateur et un serveur. de votre environnement doit être ouvert. Trois services de base sont affichés dans le conteneur d'infrastructure d'application:
- Les serveurs API Les API vous permettent d'automatiser certaines fonctionnalités en connectant votreCXone système avec d'autres logiciels utilisés par votre organisation.
- Serveurs d'authentification
- Serveurs Web
Chacun de ces serveurs sont techniquement des serveurs Web, mais leurs fonctions et leurs points de terminaison sont distincts. Tous les points de terminaison vivent dans une DMZ à l'aide d'un modèle d'application à plusieurs niveaux standard. La communication entre l'API et le serveur Web peut contenir des informations personnelles. Les flux d'authentification peuvent contenir des données personnelles dans les réponses de jetons.
Intégrations de services externes
Les partenaires et autres fournisseurs peuvent créer des applications qui s'intègrent à CXone. Ce diagramme illustre comment les utilisateurs interagissent avecPerformance Management en utilisant l'infrastructure applicative et les intégrations externes. Les composants des services partenaires et externes sont combinés pour simplifier le diagramme, mais le service pourrait être fourni par l'un ou l'autre.
Les intégrations partenaires peuvent inclure leur propre authentification ou elles peuvent s'intégrer via divers menus. Ils s'ouvriront toujours dans une instance de navigateur distincte et s'intégreront via divers Apis Les API vous permettent d'automatiser certaines fonctionnalités en connectant votreCXone système avec d'autres logiciels utilisés par votre organisation.. Dans de très rares cas, une intégration peut consommer du contenu des CXone serveurs Web. Interface de chat client en est un exemple.
Intégrations IVR
Ce schéma illustre comment RVI Menu téléphonique automatisé qui permet aux appelants d'interagir via des commandes vocales, des entrées de touches, ou les deux, pour obtenir des informations, acheminer un appel vocal entrant, ou les deux. interagit avec les locataires et les services externes. IVR incorpore souvent des données provenant de sources externes qui peuvent être gérées par vous ou par un tiers. Dans ces cas, le trafic provient toujours de serveurs internes.
Connectivité de l'agent
Les agents peuvent interagir avec CXone en utilisant plusieurs méthodes différentes:
Ces options peuvent utiliser un téléphone physique ou un softphone.
MAX
Ce diagramme illustre la connectivité de l'agent pour MAX en utilisant un téléphone physique ou un softphone. MAX s'intègre à l'infrastructure d'application. Le téléphone s'interface principalement avec l'infrastructure vocale. Il existe également une certaine communication applicative et, pour les softphones, une dépendance vis-à-vis des intégrations de services externes.
Salesforce Agent
Ce diagramme illustre la connectivité de l'agent pour Salesforce Agent en utilisant un téléphone physique ou un softphone. Ces téléphones sont exclus du diagramme par souci de simplicité.
Les deux applications d'agent dépendent de ressources de service externes. Cependant, ils communiquent également directement avec l'infrastructure applicative et font partie du CXone suite de produits. Dans certains cas, les produits peuvent communiquer avec le serveur d'authentification pour fournir une authentification et interagir avec les points finaux.
Connectivité des canaux
Les schémas suivants illustrent le flux de données des informations sensibles.
Canal vocal
Ces schémas illustrent la connectivité vocale client-jambe dansCXone. La redondance et le basculement sont des fonctionnalités essentielles pour l'infrastructure vocale.
La connectivité de la source à un contrôleur de bordure de session (SBC) dans l'infrastructure vocale n'est pas illustrée par souci de simplicité. Cette connectivité peut être une série de liaisons impliquant une variété de transporteurs. Tout ce trafic se termine au SBC dans le CXone environnement. C'est au niveau du SBC que la connectivité agent-jambe est établie.
Ces informations sont gérées et surveillées par le CXone moteur d'orchestration et serveur multimédia, qui peuvent enregistrer la conversation.
Les enregistrements effectués par le serveur multimédia peuvent soit passer directement au serveur de fichiers, soit passer par un serveur de compression. Les enregistrements effectués par le serveur multimédia résident dans le stockage du serveur de fichiers ou Services de stockage dans le cloud.
La voix en temps réel n'est pas chiffrée en transit vers le serveur. Une fois qu'il est stocké sur le serveur multimédia ou sur le CXone Recording serveur, il est chiffré au repos et en transit.
Adresse e-mail
Pour en savoir plus sur les exigences en matière de réseau d’e-mail, consultez la page E-mail système.
Ce diagramme illustre la connectivité des e-mails entrants. Les e-mails entrants utilisent AWS SES ou des serveurs de messagerie cloud privés. Les e-mails sont envoyés au service de stockage où leCXone moteur d'orchestration gère les notifications et l'accès API Les API vous permettent d'automatiser certaines fonctionnalités en connectant votreCXone système avec d'autres logiciels utilisés par votre organisation. aux candidatures.
Dans la plupart des cas, les e-mails sont transférés vers la plate-forme à partir de votre serveur SMTP car les adresses e-mail entrantes sont détenues et gérées par votre organisation.
Ce diagramme illustre la connectivité des e-mails sortants. En fonction de vos besoins, les canaux de messagerie sortants peuvent venir:
- Depuis votre serveur SMTP via une connexion privée.
- Via des serveurs SMTP SES (de préférence) ou de cloud privé.
Les informations historiques sont stockées dans un compartiment Amazon S3.
Conversation
Ce diagramme illustre la connectivité de chat omnicanal. Le chat est géré par une combinaison du serveur Webtenant Regroupement organisationnel de haut niveau utilisé pour gérer le support technique, la facturation et les paramètres globaux de votre CXone environnement, CXone serveur Web et une série d'appels d'authentification et d'API qui stockent les transcriptions. Ces transcriptions peuvent ensuite être déplacées vers Amazon S3 et Amazon Glacier.
Digital Experience : social et Bring Your Own Channel (BYOC)
Ce schéma illustre la connectivité pour les canaux de réseaux sociaux et les intégrations Bring Your Own Channel (BYOC). Pour les canaux de réseaux sociaux, les interactions sont organisées par les différents fournisseurs de canaux, tels que Facebook ou Google. BYOC est une option qui permet à votre organisation de créer et d'héberger des services intermédiaires entre les API de CXone et les API de canaux tiers. Le logiciel intermédiaire relaie les messages entre la plate-forme CXone et le fournisseur de canaux tiers.
Les contacts ont uniquement une interface avec les fournisseurs de canaux tiers. L'agent s'interface avec CXone par l'intermédiaire d'un ensemble de serveurs web, d'authentification et d'API. La connexion entre le contact et l'agent est gérée par une série de connecteurs de canaux et de systèmes d'événements internes. Le stockage temporaire et permanent est géré en interne.
Digital Experience : CXone E-mail
Ce schéma illustre la connectivité e-mail numérique.
Digital Experience : Chat numérique
Ce schéma illustre la connectivité de chat numérique. Les contacts communiquent par chat numérique en direct ou par messagerie instantanée à l'aide d'une fenêtre de chat numérique, qui peut être basée sur le web ou sur une interface mobile. Le chat numérique communique principalement par le biais de connexions WebSocket gérées par la passerelle API AWS. Pour travailler sur les contacts entrants, les agents communiquent à l'aide d'un navigateur application d'agent qui se connecte à la plate-forme CXone via une API REST publique. La communication se fait dans les deux sens et en temps réel :
- Initié par le contact : le serveur WebSocket communique avec le connecteur de chat numérique qui gère la logique de chat personnalisée et stocke les données dans la plate-forme CXone.
- Initié par l'agent : l'événement est propagé de la plate-forme CXone via le connecteur de chat au serveur WebSocket , puis au contact.
Dans le schéma, les services suivants sont représentés :
- Interface consommateur (client) : la fenêtre de chat numérique, qu'elle soit mobile ou web. Il se connecte au serveur WebSocket pour une communication en temps réel.
- Interface d’agent : pour travailler sur les contacts entrants, le navigateur de l’agent se connecte à la plate-forme CXone générale par l’intermédiaire d’une API REST publique.
- Serveur de chat WebSocket : le serveur WebSocket assure la communication en temps réel entre la plate-forme générale CXone et le consommateur de chat numérique.
- Connecteur de chat : le service WebSocket qui traduit le domaine spécifique du chat dans le domaine général CXone .
- Infrastructure d'application : le reste des services et automations CXone qui traitent des contacts numériques.
IEX WFM Integrated Connectivité
Ce diagramme illustre la connectivité de base entre votre environnement etIEX WFM Integrated.
Engage QM intégré Connectivité
Ce diagramme illustre la connectivité de base entre votre environnement etEngage QM intégré. D'autres architectures sont également prises en charge.
Connectivité par nom d'hôte
CXone utilise une variété de noms d'hôte et de services différents en fonction du type de connectivité:
- Connectivité du centre de données privé
- Connectivité directe d'AWS Data Center
- Connectivité indirecte du centre de données AWS
Connectivité du centre de données privé
Voir le diagramme
(1) Le trafic provenant du réseau externe se termine par un pare-feu matériel, qui met fin à la session TLS. Le trafic sécurisé utilise TLS 1.2 ou supérieur. Le trafic non sécurisé est géré par le serveur. (2) Le trafic entre le pare-feu et le serveur n'est pas chiffré.
Les domaines suivants font référence aux centres de données privés:
- Centre de données américain
- Centre de données de l'UE
Ce diagramme illustre la connectivité du centre de données privé avec les noms d'hôte suivants:
|
Noms d'hôte |
|---|
| agent- {cluster} |
| agentstats- {cluster} |
| api- {cluster} |
| api |
| bi |
| bu {locataire} |
| engager |
| getnextevent- {cluster} |
| accueil- {cluster} |
| incontrol- {cluster} |
| intouch- {cluster} |
| se connecter |
| répertoire - {cluster} |
| reporter.engage |
| écran {num} |
| recherche |
| Sécurité |
| flux {num} |
| {grappe} |
| {Personnalisé} |
Connectivité directe d'AWS Data Center
Voir le diagramme
(1) Le trafic provenant du réseau externe se termine au niveau d'un équilibreur de charge d'application, qui met fin à la session TLS. Le trafic sécurisé utilise TLS 1.2 ou supérieur. Le trafic non sécurisé est géré par le serveur. (2) Le trafic entre le pare-feu et le serveur n'est pas chiffré.
Les domaines suivants font référence aux centres de données directs:
- AWS aux États-Unis
- FedRAMP AWS
- EU AWS
- AUS AWS
Le diagramme illustre la connectivité directe du centre de données AWS avec les noms d'hôte suivants:
|
Noms d'hôte |
|---|
| agent- {cluster} |
| agentstats- {cluster} |
| analytics- {area} |
| analytique |
| api- {zone} |
| api- {cluster} |
| api |
| auth |
| bi- {zone} |
| bu {locataire} -nicewfm |
| echo- {zone} |
| echoftp- {zone} |
| getnextevent- {cluster} |
| accueil- {cluster} |
| en contact |
| incontrol- {cluster} |
| intouch- {cluster} |
| login- {area} |
| se connecter |
| répertoire - {cluster} |
| sécurité- {zone} |
| Sécurité |
| {grappe} |
| {Personnalisé} |
Connectivité indirecte du centre de données AWS
Voir le diagramme
(1) Le trafic provenant du réseau externe se termine à un service Incapsula, qui met fin à la session TLS. (2) Trafic entre le service Incapsula, qui démarre une nouvelle session TLS, et l'équilibreur de charge d'application, qui met fin à la session TLS. Le trafic sécurisé utilise TLS 1.2 ou supérieur. Le trafic non sécurisé est géré par le serveur. (3) Le trafic entre l'équilibreur de charge d'application et le proxy n'est pas chiffré. Le trafic entre le proxy et le serveur n'est pas chiffré.
Les domaines suivants font référence aux centres de données publics:
- AWS aux États-Unis
- FedRAMP AWS
- EU AWS
- AUS AWS
Le diagramme illustre la connectivité indirecte du centre de données AWS avec les noms d'hôte suivants:
|
Noms d'hôte |
|---|
| {surface} |
Nexidia
Ce diagramme illustre comment CXone se connecte à Nexidia. Cette connexion est établie par le biais des API suivantes :
Ces API extraient les enregistrements et métadonnées de CXone.
Flux de données Nexidia
Voir l'image
(1) Les API extraient les métadonnées et enregistrements audio de CXone. (2) Les métadonnées sont cataloguées et les enregistrements sont traités dans le framework d’échange de données (DEF) (3) Les données traitées issues du DEF sont copiées sur le stockage média. (4) Dans le stockage média, les données sont indexées phonétiquement. (5) Toujours dans le stockage média, les données sont transcrites et les expressions extraites. (6) Les analystes utilisent l’application Nexidia pour écouter les appels, consulter les transcriptions et concevoir les requêtes et les rapports.
Ce diagramme illustre comment les enregistrements et métadonnées issus de CXone sont extraits dans les serveurs Nexidia pour que les analystes puissent les écouter et les consulter.