Paramètres de messagerie transactionnelle

Dernière mise à jour : 2023-12-07
  • Créé pour :
  • Experienced
    Admin
    Developer

« Messages transactionnels » (Message Center) désigne un module de Campaign conçu pour gérer les messages déclenchés. Pour en savoir plus sur les fonctionnalités des messages transactionnels, consultez cette section.

Découvrez l’architecture de la messagerie transactionnelle sur cette page.

En tant qu’utilisateur ou utilisatrice Managed Cloud Services, contactez Adobe pour installer et configurer la messagerie transactionnelle de Campaign dans votre environnement.

Définition des autorisations

Pour créer de nouveaux utilisateurs et utilisatrices pour les instances d’exécution Message Center hébergées sur Adobe Cloud, contactez la personne chargée de votre transition Adobe. Les utilisateurs et les utilisatrices de Message Center sont des opérateurs et des opératrices spécifiques qui ont besoin d’autorisations dédiées pour accéder aux dossiers « Événements en temps réel » (nmsRtEvent).

Extensions de schéma

Les extensions de schéma effectuées sur les schémas utilisés par les workflows techniques de Message Center sur les instances de pilotage ou d’exécution doivent être dupliquées sur les autres instances utilisées par le module des messages transactionnels d’Adobe Campaign.

Envoyer des notifications push transactionnelles

Couplés au module Canal des applications mobiles, les messages transactionnels permettent d’émettre des notifications push sur des applications mobiles.

Pour envoyer des notifications push transactionnelles, vous devez exécuter les configurations suivantes :

  1. Installez le package Canal des applications mobiles sur les instances de pilotage et d’exécution.

    ATTENTION

    Consultez votre contrat de licence avant d’installer un nouveau package intégré Campaign.

  2. Répliquez le service Application mobile et les applications mobiles associées sur les instances d’exécution.

En outre, l’événement doit contenir les éléments suivants :

  • L’identifiant de l’appareil mobile : registrationId pour Android et deviceToken pour iOS. Cet identifiant représente l’« adresse » à laquelle la notification est envoyée.
  • Le lien vers l'application mobile ou la clé d'intégration (uuid) permettant de récupérer les informations de connexion spécifiques à l'application.
  • Le canal sur lequel la notification sera envoyée (wishedChannel) : 41 pour iOS et 42 pour Android.
  • Toute autre donnée de personnalisation.

Vous trouverez ci-dessous un exemple de configuration d’événement permettant d’envoyer des notifications push transactionnelles :

<SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Body>
     <urn:PushEvent>
         <urn:sessiontoken>mc/</urn:sessiontoken>
         <urn:domEvent>

              <rtEvent wishedChannel="41" type="DELIVERY" registrationToken="2cefnefzef758398493srefzefkzq483974">
                <mobileApp _operation="none" uuid="com.adobe.NeoMiles"/>
                <ctx>
                    <deliveryTime>1:30 PM</deliveryTime>
                    <url>http://www.adobe.com</url>
                </ctx>
              </rtEvent>

         </urn:domEvent>
     </urn:PushEvent>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Purger des événements

Vous pouvez adapter les paramètres de l’assistant de déploiement pour configurer la durée pendant laquelle vous souhaitez conserver les événements dans la base de données.

La purge des événements est effectuée automatiquement par le workflow technique Nettoyage de la base. Ce workflow purge les événements reçus et stockés sur les instances d’exécution et les événements archivés sur une instance de pilotage.

Vous pouvez modifier les paramètres de purge des événements (sur une instance d’exécution) et des événements archivés (sur une instance de pilotage) à l’aide des flèches.

Workflows techniques

Vous devez vous assurer que les workflows techniques de vos instances d’exécution et de pilotage ont démarré avant de procéder au déploiement des modèles de messages transactionnels.

Ces workflows sont ensuite accessibles à partir du dossier Administration > Production > Message Center.

Workflows de l’instance de pilotage

Sur l’instance de pilotage, vous devez créer un workflow d’archivage pour chaque compte externe Instance d’exécution de Message Center. Cliquez sur le bouton Créer le workflow d’archivage pour créer et démarrer le processus.

Workflows de l’instance d’exécution

Sur la ou les instances d’exécution, vous devez démarrer les workflows techniques suivants :

  • Traitement des événements batch (nom interne : batchEventsProcessing) : ce workflow permet de répartir les événements batch dans une file d'attente avant qu'ils ne soient associés à un modèle de message.

  • Traitement des événements temps réel (nom interne : rtEventsProcessing) : ce workflow permet de répartir les événements temps réel dans une file d'attente avant qu'ils ne soient associés à un modèle de message.

  • Mise à jour du statut des événements (nom interne : updateEventStatus) : ce workflow permet d'attribuer un statut à l'événement.

    Les statuts possibles des événements sont les suivants :

    • En attente : l’événement se trouve dans la file d’attente. Aucun modèle de message ne lui a encore été affecté.
    • En attente de diffusion : l’événement est dans la file d’attente, un modèle de message lui a été associé et il est en cours de traitement par la diffusion.
    • Envoyé : ce statut est copié depuis les logs de diffusion. Il signifie que la diffusion a été envoyée.
    • Ignoré par la diffusion : ce statut est copié depuis les logs de diffusion. Il signifie que la diffusion a été ignorée.
    • Erreur de diffusion : ce statut est copié depuis les logs de diffusion. Il signifie que la diffusion a échoué.
    • Evénement non pris en charge : l’association de l’événement à un modèle de message a échoué. L’événement ne sera pas retraité.

Sur cette page