Diagrammes d’événements CXone Mobile SDK

Cette page fournit des diagrammes et des explications sur les événements courants qui se produisent au cours d’une interaction par clavardage.

L’application devient active

Ce diagramme de séquence capture le flux lorsque l’application mobile devient active, prépare le clavardage, traite les informations relatives aux visiteurs et aux clients et communique avec les services dorsaux. Si des erreurs surviennent, elles sont traitées et consignées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

État initial :

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

  • L’application mobile passe au premier plan.

Préparation du clavardage :

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

  • Si l’état du clavardage n’est pas initial ou hors ligne, l’erreur IllegalChatStateError est renvoyée.

  • Dans le cas contraire, le SDK attribue la valeur preparing à l’état du clavardage et notifie l’interface utilisateur avec onChatUpdated().

Configuration du canal :

  • Le SDK demande la configuration du canal au serveur dorsal avec getChannelConfiguration().

  • En cas d’erreur du serveur, un message ServerError est renvoyé et l’état du clavardage est réinitialisé à initialize.

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

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

Gestion des visiteurs et des clients :

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

  • En cas d’erreur du serveur, l’état du clavardage est réinitialisé à initialize.

  • Dans le cas contraire, la gestion des visiteurs et des clients est réussie.

État de clavardage préparé :

  • L’état du clavardage 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 serveur dorsal.

L’application passe en arrière-plan

Ce diagramme de séquence capture le flux lorsque l’application mobile passe en arrière-plan, gère le suivi des pages consultées et communique avec les services dorsaux. Si des erreurs se produisent, elles sont traitées de manière appropriée. Lorsqu’une application passe en arrière-plan, cela signifie qu’elle n’est plus l’élément principal que vous voyez ou avec lequel vous interagissez sur votre appareil. Imaginez que vous utilisez une application de messagerie, puis que vous appuyez sur le bouton d’accueil ou que vous passez à une autre application. L’application de messagerie est maintenant en arrière-plan. Elle fonctionne toujours, mais vous ne l’utilisez pas activement. Cela se produit lorsque vous réduisez une application, passez à une autre application ou verrouillez votre téléphone. L’application est toujours là, mais elle n’est plus au premier plan.

Ouvrir le diagramme dans une nouvelle fenêtre

L’application passe en arrière-plan :

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

  • L’interface utilisateur informe le SDK que la consultation de la page est terminée avec pageViewEnded.

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

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, l’événement est réussi.

Déconnexion et gestion des états :

  • L’interface utilisateur initie la déconnexion en utilisant disconnect().

  • En fonction de l’état actuel :

    • En cas de préparation, le SDK attribue la valeur initial à l’état.

    • S’il est déjà préparé, le SDK déconnecte le connecteur logiciel et définit l’état à prepared.

Afficher la page

Ce diagramme de séquence représente le flux lorsqu’un utilisateur consulte une page dans l’application mobile, y compris les interactions avec le SDK et les services dorsaux. Il affiche l’événement analytique lorsqu’un utilisateur consulte une page, suit les détails de la visite et communique avec les services dorsaux. Si des erreurs se produisent, elles sont traitées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

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

Événement de consultation de page :

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

  • Le mode de clavardage est vérifié :

    • S’il n’est pas préparé, une erreur illegalChatStateError est renvoyée.

    • Dans le cas contraire, l’expiration des détails de la visite est vérifiée.

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

      • S’ils sont valides, le SDK ajuste l’expiration actuelle.

    • Si la dernière page consultée n’a pas été envoyée, le SDK met fin à la consultation de la page.

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

    • Tout échec, comme une erreur de serveur, est traité.

Interaction dorsale :

  • Le SDK communique avec les services dorsaux :

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

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

    • S’il y a une erreur de serveur, elle est traitée.

Ouvrir le clavardage

Ce diagramme de séquence capture le flux lorsqu’un utilisateur ouvre le clavardage, gère l’authentification OAuth et établit une connexion avec les services dorsaux. Si des erreurs se produisent, elles sont traitées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

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

Ouverture du clavardage :

  • L’utilisateur application ouvre le clavardage et l’interface utilisateur établit une connexion avec connect().

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

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

    • S’il est initial ou en cours de préparation, une erreur IllegalChatStateError est renvoyée.

    • S’il est préparé, le mode clavardage est vérifié :

      • S’il s’agit d’un clavardage en direct et que l’état du clavardage en direct est hors ligne, l’état du clavardage est défini sur offline.

      • Sinon, la connexion WebSocket est établie.

      • Le traitement d’OAuth varie selon qu’il est activé ou désactivé.

Traitement OAuth :

  • Si OAuth est activé :

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

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, CustomerReconnectedEvent est reçu.

  • Si OAuth est désactivé :

    • Le SDK autorise avec authorizeCustomerEventData(authorizationCode:codeVerifier:).

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, CustomerAuthorizedEvent est reçu et le jeton d’accès et l’identité du client sont stockés.

État de clavardage connecté :

Fil unique

Ce diagramme de séquence capture le flux lorsqu’un utilisateur interagit avec un clavardage à fil uniqueFermé Dans une application à fil 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 clavardage., gère la reprise des fils et communique avec les services dorsaux. Si des erreurs se produisent, elles sont traitées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

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

Récupération de fil :

  • Le SDK charge l’ID du fil à partir de la mémoire locale.

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

  • Si aucun UUID n’est disponible, le SDK tente 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 clavardage 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 clavardage est défini sur Prêt.

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

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

Interaction par clavardage :

  • L’interface utilisateur affiche la fenêtre de clavardage permettant à l’utilisateur d’interagir avec un agent.

Multi-fils

Ce diagramme de séquence capture le flux lorsqu’un utilisateur interagit avec un clavardage multi-filsFermé Dans une application multi-fils, 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., gère la récupération des fils et communique avec les services dorsaux. Si des erreurs se produisent, elles sont traitées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

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

Récupération de la liste des fils :

  • Le SDK récupère la liste des fils du serveur dorsal avec FetchThreadListEvent.

  • S’il y a une erreur de serveur, elle est traitée.

  • Dans le cas contraire, la liste des fils est récupérée.

Gestion des fils :

  • Si des fils existent :

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

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

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

  • Si aucun fil n’existe :

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

Créer ou ouvrir des fils :

  • Pour créer un nouveau fil :

    • L’utilisateur lance la création du fil.

  • Pour ouvrir un fil existant :

    • L’utilisateur sélectionne un fil.

    • L’interface utilisateur ouvre le fil à l’aide de openThread(thread:).

    • Le fil est récupéré sur le serveur dorsal.

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, le fil est récupéré et l’état est définit sur ready.

Interaction par clavardage :

  • L’utilisateur entame un clavardage avec un agent.

Clavardage en direct

Ce diagramme de séquence illustre le flux dorsal d’une interaction par clavardage en direct. Le clavardage en direct est l’option de clavardage numérique en temps réel, tandis que la messagerie par clavardage est l’option de messagerie asynchrone, qui est similaire aux messages privés ou aux messages directs.

Ouvrir le diagramme dans une nouvelle fenêtre

Créer un fil

Ce diagramme de séquence capture le flux lorsqu’un utilisateur crée un nouveau fil, gère la création du fil et communique avec le SDK. Si des erreurs se produisent, elles sont traitées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

Détails de l’utilisateur et formulaire préalable au clavardage :

  • Si le nom du client n’est pas fourni, l’interface utilisateur affiche un formulaire de détails sur l’utilisateur.

  • Si des informations préalables au clavardage sont disponibles, l’interface utilisateur affiche un formulaire préalable au clavardage.

Création d’un fil :

  • L’utilisateur entame une conversation.

  • L’interface utilisateur initie la création du fil à l’aide de createThread(customFields:).

  • Si le mode de clavardage n’est pas multi-fils et que le fil existe déjà :

    • Une erreur unsupportedChannelConfigError est renvoyée.

    • Une alerte d’erreur s’affiche.

  • Dans le cas contraire :

    • 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().

Clavardage avec un agent

Ce diagramme de séquence capture le flux lorsqu’un utilisateur final interagit avec un agent par le biais d’un clavardage, traite les messages de bienvenue et communique avec les services dorsaux. Si des erreurs se produisent, elles sont traitées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

Initialisation du clavardage :

  • L’utilisateur envoie un message à l’aide de sendMessage(message:).

  • Si un message de bienvenue est disponible :

    • Le SDK envoie un message de bienvenue sortant à l’aide de SendOutboundMessageEvent(welcomeMessage:).

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, MessageCreatedEvent est reçu et l’interface utilisateur est mise à jour.

  • Le SDK envoie le message de l’utilisateur à l’aide de sendMessageEvent.

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, MessageCreatedEvent est reçu et l’interface utilisateur est mise à jour.

Terminer contact

Ce diagramme de séquence capture le flux lorsqu’un utilisateur termine un clavardage, gère la clôture de la conversation et communique avec les services dorsaux. Si des erreurs se produisent, elles sont traitées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

Fin du clavardage :

  • L’utilisateur appuie sur Terminer la conversation.

  • L’interface utilisateur notifie au SDK de mettre fin à la conversation à l’aide de endConversation().

  • Le serveur dorsal reçoit EndConversationEvent.

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, l’état du cas est modifié et l’état du fil est définit sur closed.

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

Vue de l’expérience Terminer le contact :

  • L’interface utilisateur affiche la vue Terminer le contact.

Traiter les événements volumineux

L’une des limites de la passerelle API AWS est qu’elle ne peut envoyer qu’un maximum de 128 ko dans un message. Pour envoyer des événements plus volumineux du serveur au client :

  • Sur le serveur, téléversez les événements les plus importants dans un compartiment S3 accessible au public.

  • Le client peut alors recevoir uniquement l’URL de ce fichier via WebSocket et télécharger le corps de l’événement via REST.

Ouvrir le diagramme dans une nouvelle fenêtre