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.

Ouvrir le diagramme dans la nouvelle fenêtre

État initial :

  • L’état initial du SDK est défini sur initial.

  • L’application mobile est placée au premier plan.

Préparation du chat :

  • L’utilisateur initialise la préparation du chat en appelant prepare(brandId:channelId:).

  • Si l’état du chat est différent d’initial ou de hors ligne, IllegalChatStateError est renvoyé.

  • Sinon, le SDK définit l’état du chat sur preparing et notifie l’interface utilisateur avec onChatUpdated().

Configuration du canal :

  • Le SDK demande la configuration des canaux depuis le backend avec getChannelConfiguration()).

  • S’il y a une erreur de serveur, ServerError est renvoyé, et l’état du chat est réinitialisé sur initialize.

  • Sinon, la configuration de canal est reçue et le SDK crée un ID de destination.

  • Si l’ID du visiteur ou du client est null, l’un ou l’autre est créé et stocké localement.

Traitement des visiteurs et des clients :

  • Le SDK appelle createOrUpdateVisitor(visitorId:customerId:deviceToken:) sur le backend.

  • S’il y a une erreur de serveur, l’état du chat est réinitialisé sur initialize.

  • Sinon, le traitement des visiteurs et des clients est réussi.

État de préparation du chat :

  • L’état initial du chat est défini sur prepared.

  • L’interface utilisateur est notifiée avec onChatUpdated().

  • L'analyse des pages consultées se fait entre l’application mobile et le backend.

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.

Ouvrir le diagramme dans la nouvelle fenêtre

Application passant à l’arrière-plan :

  • L’interface utilisateur affiche une zone indiquant que l’application passe en arrière-plan.

  • L’interface utilisateur indique au SDK que la vue de la page n’utilise plus pageViewEnded.

  • Le backend reçoit l’événement pageViewEnded.

    • Toute erreur serveur est alors traitée.

    • Sinon, l’événement est considéré comme réussi.

Déconnexion et traitement de l’état :

  • L’interface utilisateur notifie la déconnexion avec disconnect().

  • Selon l’état actuel :

    • S’il est en cours de préparation, le SDK définit l’état sur initial.

    • S’il a déjà été préparé, le SDK déconnecte le socket et définit l’état sur prepared.

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.

Ouvrir le diagramme dans la nouvelle fenêtre

Référence d’activation de l’application :

Afficher l’événement de page :

  • L’utilisateur affiche une page et l’interface utilisateur notifie le SDK avec viewPage(title:url:).

  • Le mode chat est vérifié :

    • S’il n’est pas préparé, un illegalChatStateError est renvoyé.

    • Sinon, les détails de la visite sont vérifiés pour déterminer leur expiration.

      • S’ils ont expiré, les détails de la nouvelle visite sont créés (UUID et expiration).

      • S’ils sont valides, le SDK ajuste la date d’expiration actuelle.

    • Si la dernière page affichée n’a pas été envoyée, le SDK envoie la vue de page.

    • Le titre de la dernière page affichée, l’URI et l’horodatage sont stockés.

    • En cas d’échec, tel qu’une erreur serveur, il est traité.

Interactions avec le backend :

  • Le SDK communique avec les services de backend :

    • visitorVisit(date:) est appelé pour enregistrer la visite.

    • pageView(title:uri:timestamp) est appelé pour enregistrer la vue de page.

    • Toute erreur serveur est alors traitée.

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.

Ouvrir le diagramme dans la nouvelle fenêtre

Référence d’activation de l’application :

Ouverture du chat :

  • L’utilisateur application ouvre le chat et l’interface utilisateur amorce une connexion avec connect().

  • L’état du chat est vérifié :

    • En cas de connexion, le SDK établit une connexion WebSocket.

    • Si en phase initiale ou en cours de préparation, IllegalChatStateError est renvoyé.

    • Si préparé, le mode chat est vérifié :

      • Si un chat en direct et un statut de chat en direct sont hors ligne, l’état du chat est défini sur offline.

      • Sinon, la connexion WebSocket est établie.

      • Le traitement de OAuth varie selon que l’état est activé ou désactivé.

OAuthTraitement d’ :

  • Si OAuth est activé :

    • Le SDK se reconnecte avec reconnectCustomerEventData(accessToken:).

    • Toute erreur serveur est alors traitée.

    • Sinon, CustomerReconnectedEvent est reçu.

  • Si OAuth est désactivé :

    • Le SDK réalise l’autorisation avec authorizeCustomerEventData(authorizationCode:codeVerifier:).

    • Toute erreur serveur est alors traitée.

    • Sinon, CustomerAuthorizedEvent est reçu, et le jeton d’accès, ainsi que l’identité du client sont stockés.

État connecté du chat :

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.

Ouvrir le diagramme dans la nouvelle fenêtre

Référence d’activation de l’application :

Récupération du fil :

  • Le SDK charge l’ID de fil depuis le stockage local.

  • Si un ID de fil provenant d’une plateforme externe est stocké localement, le SDK récupère le fil de messagerie en utilisant RecoverMessagingThreadEvent(threadId:).

  • Si aucun UUID n’est disponible, le SDK tente d’opérer une récupération avec RecoverMessagingThreadEvent(nil).

Vérification de l’existence du fil :

  • Si le fil existe, ThreadRecoveredEvent est reçu.

    • Les états du chat et du fil sont définis sur ready.

    • L’interface utilisateur est notifiée avec onThreadUpdated().

  • Si le fil n’existe pas, ThreadRecoverFailedEvent est reçu.

    • L’état du chat est défini sur Prêt.

    • L’interface utilisateur est notifiée avec onChatUpdated().

    • Une note indique qu’aucune récupération du fil n’est nécessaire.

Interaction de chat :

  • L’interface utilisateur affiche la fenêtre de chat pour permettre à l’utilisateur de communiquer avec un agent.

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.

Ouvrir le diagramme dans la nouvelle fenêtre

Référence d’activation de l’application :

Récupération de la liste de fils:

  • Le SDK extrait la liste de fils du backend en utilisant FetchThreadListEvent.

  • Toute erreur serveur est alors traitée.

  • Sinon, la liste de fils est extraites.

Traitement des fils :

  • Si les fils existent :

    • Le SDK définit l’état de chaque fil sur received et charge les derniers messages.

    • Les métadonnées des fils sont chargées et l’état est défini sur loaded.

    • L’état du chat est défini sur ready et l’interface utilisateur est notifiée.

  • Si aucun fil n’existe :

    • L’état du chat est défini sur ready et l’interface utilisateur est notifiée.

Créer ou ouvrir des fils :

  • En cas de création de fil :

    • L’utilisateur est à l’origine de la création de fil.

  • En cas d’ouverture du fil existant :

    • L’utilisateur sélectionne un fil.

    • L’interface utilisateur ouvre le fil avec openThread(thread:).

    • Le fil est récupéré depuis le backend.

    • Toute erreur serveur est alors traitée.

    • Sinon, le fil est récupéré et l’état est défini sur ready.

Interaction de chat :

  • L’utilisateur amorce un chat avec un agent.

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.

Ouvrir le diagramme dans la nouvelle fenêtre

Détails de l’utilisateur et préparation du chat :

  • Si le nom du client n’est pas fourni, l’interface utilisateur affiche la bue de formulaire de détails des utilisateurs.

  • Si les informations de préparation du chat sont disponibles, l’interface utilisateur affiche une vue de formulaire de préparation au chat.

Création des fils :

  • L’utilisateur commence une conversation.

  • L’interface utilisateur crée le fil en utilisant createThread(customFields:).

  • Si le mode de chat n’est pas multi-fil et si le fil existe déjà :

    • unsupportedChannelConfigError est renvoyé.

    • Une alerte d’erreur s’affiche.

  • Sinon :

    • Le SDK crée le fil localement avec un UUID.

    • L’UUID est stocké localement.

    • L’état du fil est défini sur pending.

    • L’interface utilisateur est notifiée avec onThreadUpdated().

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.

Ouvrir le diagramme dans la nouvelle fenêtre

Initialisation du chat :

  • L’utilisateur envoie un message utilisant sendMessage(message:).

  • Si un message de bienvenue est disponible :

    • Le SDK envoie un message de bienvenue sortant avec SendOutboundMessageEvent(welcomeMessage:).

    • Toute erreur serveur est alors traitée.

    • Sinon, MessageCreatedEvent est reçu et l’interface utilisateur est mise à jour.

  • Le SDK envoie le message de l’utilisateur en utilisant sendMessageEvent.

    • Toute erreur serveur est alors traitée.

    • Sinon, MessageCreatedEvent est reçu et l’interface utilisateur est mise à jour.

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.

Ouvrir le diagramme dans la nouvelle fenêtre

Fin du chat :

  • L’utilisateur appuie sur Terminer la conversation.

  • L’interface utilisateur demande au SDK de mettre fin à la conversation avec endConversation().

  • Le backend reçoit EndConversationEvent.

    • Toute erreur serveur est alors traitée.

    • Sinon, l’étude de cas est modifiée, et l’état du fil est défini sur closed.

    • L’interface utilisateur est notifiée avec onThreadUpdated().

Vue de l’expérience Fin de contact :

  • L’interface utilisateur affiche la vue Fin de contact.

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