Diagrammes d’événements CXone Mobile SDK

Cette page comporte des diagrammes et des explications sur des événements qui se produisent habituellement pendant une interaction de chat.

L’application devient active

Ce diagramme de séquence capture le flux lorsque le application mobile devient actif, prépare le chat, traite les informations des visiteurs et des clients, et communique avec les services backend. Si des erreurs se produisent, elles sont traitées et consignées dans des fichiers journaux.

L’application est placée en arrière-plan

Ce diagramme de séquence capture le flux lorsque l’application mobile passe au premier-plan, traite le suivi des vues de page et communique avec les services backend. Si des erreurs se produisent, elles sont traitées en conséquence. Lorsqu’une application passe en arrière-plan, cela signifie qu’il ne s’agit plus du seul élément visible sur votre appareil ou pour les interactions. Imaginons que vous utilisez une application de messagerie, puis que vous appuyez sur le bouton d’accueil ou basculez vers une autre application. L’application de messagerie est à présent en arrière-plan. Elle est toujours en cours d’exécution, mais vous ne l’utilisez pas activement. Cela se produit lorsque vous réduisez une application, basculez vers une autre application ou verrouillez votre téléphone. L’application est toujours présente, mais elle n’est plus au premier plan.

Voir la page

Ce diagramme de séquence correspond à un flux où l’utilisateur affiche une page dans l’application mobile, ce qui inclut les interactions avec le SDK et les services backend. Il affiche un événement d’analyse lorsqu’un utilisateur affiche une page, suit les détails de la visite et communique avec les services backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Chat ouvert

Ce diagramme de séquence capture le flux lorsque l’utilisateur ouvre le chat, traite OAuth et établit une connexion avec les services de backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Fil unique

Ce diagramme de séquence capture le flux lorsqu’un utilisateur interagit avec un chat à fil uniqueFermé Dans une application à thread unique, chaque contact ne peut avoir qu'un seul fil de discussion. Toute interaction qu'ils ont avec votre organisation a lieu dans ce fil de discussion., traite la récupération des fils et communique avec les services de backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Multi-fil

Ce diagramme de séquence capture le flux lorsqu’un utilisateur interagit avec un chat à fils multiplesFermé Dans une application multithread, les contacts peuvent créer autant de fils de discussion qu'ils le souhaitent pour discuter de nouveaux sujets. Ces fils peuvent être actifs en même temps., traite la récupération des fils et communique avec les services de backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Chat en direct

Ce diagramme de séquence présente le flux de backend d’une interaction de chat en direct. Le chat en direct désigne l’option de chat numérique en temps réel, tandis que la messagerie instantanée désigne l’option de messagerie asynchrone, qui est semblable aux messages privés ou directs.

Ouvrir le diagramme dans la nouvelle fenêtre

Créer un fil

Ce diagramme de séquence capture le flux lorsqu’un utilisateur crée un fil de chat, traite la création de fils et communique avec le SDK. Si des erreurs se produisent, elles sont traitées en conséquence.

Chat avec un agent

Ce diagramme de séquence capture le flux lorsqu’un utilisateur interagit avec un agent au moyen du chat, traite les messages de bienvenue et communique avec les services de backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Mettre fin au contact

Ce diagramme de séquence capture le flux lorsque l’utilisateur met fin au chat, traite la clôture de la conversation et communique avec les services de backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Traitement d’événement volumineux

L’une des limitations de la passerelle d’API AWS est qu’elle ne peut pas envoyer plus de 128 Ko par message. Pour envoyer des événements plus volumineux du serveur au client :

  • Sur le serveur, chargez les événements plus volumineux dans un compartiment S3 disponible publiquement.

  • Le client peut ensuite recevoir seulement l’URL de ce fichier via WebSocket et télécharger le corps de l’événement au moyen de REST.

Ouvrir le diagramme dans la nouvelle fenêtre