Description des événements event-description

Modèle de données de message transactionnel about-transactional-messaging-datamodel

La messagerie transactionnelle repose sur le modèle de données d’Adobe Campaign et utilise deux tables supplémentaires distinctes. Ces tables, NmsRtEvent et NmsBatchEvent, contiennent les mêmes champs et permettent de gérer les événements temps réel d’une part et les événements batch d’autre part.

Méthodes SOAP soap-methods

Cette section décrit les méthodes SOAP associées aux schémas du module des messages transactionnels.

Deux méthodes SOAP PushEvent ou PushEvents sont associées aux deux schémas de données nms:rtEvent et nms:BatchEvent. C'est le système d'information qui détermine si un événement est de type "batch" ou "temps réel".

Le chemin WSDL d'accès aux deux méthodes est :

Pour plus d’informations sur la génération d’un fichier WSDL, voir cette section.

Les deux méthodes contiennent un élément <urn:sessiontoken> permettant de se connecter au module de message transactionnel. Nous vous recommandons d'utiliser une méthode d'identification via des adresses IP approuvées. Pour récupérer le jeton de session, effectuez un appel SOAP de connexion, puis un jeton get suivi d’une fermeture de session. Utilisez le même jeton pour plusieurs appels RT. Les exemples inclus dans cette section utilisent la méthode du jeton de session qui est recommandée.

Si votre serveur présente une répartition de la charge, vous pouvez utiliser l’authentification par utilisateur/mot de passe (au niveau du message RT). Par exemple :

<PushEvent xmlns="urn:nms:rtEvent">
<sessiontoken>mc/PASSWORD</sessiontoken>
<domEvent>
<rtEvent wishedChannel="41" type="rt_MobileJourney_iOS_Push" registrationToken="c3ddc8aaecc24822df25d0f49865cca61ea3f86c61bfa53ae4d37294e37f4a1c" hashlpId="27EE7571EC14DBA23B9B5CC0EF79BB782DAECF4C03C88E5D92CC9B9DAC4E5DDA" correlationId="415b7593-4f6f-e911-811f-00505691247c" xmlns="">
<mobileApp uuid="236B24DC-C073-412F-8BCB-AC7207096258" _operation="none"/>
<ctx>...</ctx>
</rtEvent>
</domEvent>
</PushEvent>

La méthode PushEvent est constituée d’un paramètre <urn:domevent> qui contient l’événement.

La méthode PushEvent est constituée d’un paramètre <urn:domeventcollection> qui contient des événements.

Exemple avec PushEvent :

<urn:PushEvent>

 <sessiontoken>___921f9b38-72ac-49ad-b481-ab32973efc50</sessiontoken>

 <urn:domEvent>

   <rtEvent>

   ...

   </rtEvent>

 </urn:domEvent>

</urn:PushEvent>

Exemple avec PushEvents :

<urn:PushEvents>

 <sessiontoken>___921f9b38-72ac-49ad-b481-ab32973efc50</sessiontoken>

 <urn:domEventCollection>

   <Events>

     <rtEvent>... </rtEvent>

     <rtEvent>... </rtEvent>

     ...

   </Events>

 </urn:domEventCollection>

</urn:PushEvents>

Les éléments <rtevent> et <batchevent> possèdent un jeu d'attributs ainsi qu'un élément enfant indispensable : <ctx> permettant d’intégrer les données du message.

Les attributs obligatoires des éléments <rtevent> et <batchevent> sont @type et @email. La valeur de @type doit être identique à la valeur de liste détaillée définie lors de la configuration de l’instance d’exécution. Cette valeur vous permet de définir le modèle à lier au contenu de l’événement pendant la diffusion.

<rtevent> configuration example:

<rtEvent type="order_confirmation" email="john.doe@domain.com" origin="eCommerce" wishedChannel="0" externalId="1242" mobilePhone="+33620202020">

Dans cet exemple, deux canaux sont proposés : l'adresse email et le numéro de téléphone portable. La variable wishChannel permet de sélectionner le canal à utiliser lors de la transformation de l'événement en message. La valeur "0" correspond au canal email, la valeur "1" au canal mobile, etc.

Si vous souhaitez différer le traitement d'un évènement, ajoutez le champ scheduled suivi de la date désirée. L'évènement sera transformé en message à cette date.

Nous vous conseillons de remplir les attributs @wishedChannel et @emailFormat avec des valeurs numériques. La table de correspondance entre les valeurs numériques et les labels associés se trouve dans la description des schémas de données.

L’élément <ctx> contient les données du message. Son contenu XML est ouvert, ce qui signifie qu’il peut être configuré selon le contenu à diffuser.

Exemple de données :

   <ctx>
               <client>
                        <firstname>John</firstname>
                        <lastname>Doe</lastname>
               </client>
               <action>
                         <type>Order confirmation</type>
                          <number>CN23453</number>
               </action>
               <orderdetails>
                          <article num="1">
                                   <name>Generic USB key</name>
                                   <price>20</price>
                           </article>
               </orderdetails>
    </ctx>

Informations retournées par l'appel SOAP information-returned-by-the-soap-call

Lors de la réception d'un événement, Adobe Campaign génère un identifiant unique de retour. Il correspond à l'identifiant de la version historisée de l'événement.

Lorsque la valeur de l'identifiant de retour est strictement supérieure à zéro, cela signifie que l'événement est bien historisé dans Adobe Campaign.

En revanche, si le traitement de l'événement échoue, la méthode renvoie un message d'erreur ou une valeur égale à zéro.