Show Menu
SUJETS×

Description des événements

À propos du modèle de données de messagerie transactionnelle

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

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".
  • PushEvent permet d'insérer un seul événement dans le message,
  • PushEvents permet d'insérer une collection d'événements dans le message.
Le chemin WSDL d'accès aux deux méthodes est :
  • http://hostname/nl/jsp/schemawsdl.jsp?schema=nms:rtEvent pour accéder au schéma de type temps réel.
  • http://hostname/nl/jsp/schemawsdl.jsp?schema=nms:batchEvent pour accéder au schéma de type batch.
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>

En cas d’appel à la méthode PushEvents , nous devons ajouter un élément XML parent pour nous conformer au XML standard. Cet élément XML encadrera les différents éléments <rtevent> contenus dans l’événement.
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 fils indispensable : <ctx> permettant d’intégrer les données du message.
L’élément <batchevent> vous permet d’ajouter l’événement à la file d’attente "batch". Le <rtevent> ajoute l’événement à la file d’attente "temps réel".
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 renseignés : l'adresse email et le numéro de téléphone portable. Le champ wishedChannel permet de définir le canal qui sera utilisé 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.
La description détaillée de tous les attributs autorisés et de leurs valeurs se trouve dans la description du schéma de données de nms:rtEvent et nms:BatchEvent .
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.
Il est important d'optimiser le nombre et la taille des noeuds XML contenus dans le message afin de ne pas surcharger les serveurs lors de la diffusion.
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

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.
Lors de la réception d'appels SOAP, Adobe Campaign vérifie le format des adresses email. Si une adresse email n'est pas correctement mise en forme, une erreur est renvoyée.
  • Exemple d'identifiant renvoyé par la méthode lorsque le traitement d'un événement a réussi :
    <SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns="http://xml.apache.org/xml-soap" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
       <SOAP-ENV:Body>
          <urn:PushEventResponse SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:urn="urn:nms:rtEvent">
             <plId xsi:type="xsd:long">72057594037935966</plId>
          </urn:PushEventResponse>
       </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>
    
    
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.
  • Exemple de traitement d'un événement qui a échoué lorsque la requête ne contient pas de login ou que l'opérateur spécifié n'a pas les droits adéquats :
    <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>
          <SOAP-ENV:Fault>
             <faultcode>SOAP-ENV:Client</faultcode>
             <faultstring xsi:type="xsd:string">Error while reading parameters of method 'PushEvent' of service 'nms:rtEvent'.</faultstring>
             <detail xsi:type="xsd:string">Invalid login or password. Connection denied.</detail>
          </SOAP-ENV:Fault>
       </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>
    
    
  • Exemple de traitement d'un événement qui a échoué du fait d'une erreur dans la requête (la nomenclature XML n'est pas respectée) :
    <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>
          <SOAP-ENV:Fault>
             <faultcode>SOAP-ENV:Client</faultcode>
             <faultstring xsi:type="xsd:string">The XML SOAP message is invalid (service 'PushEvent', method 'nms:rtEvent').</faultstring>
             <detail xsi:type="xsd:string"><![CDATA[(16:8) : Expected end of tag 'rtevent'
    Error while parsing XML string '<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:nms:rtEvent">
       <soapenv:Header/>
       <soapenv:Body>
          <urn:PushEvent>
             <urn:sessiontoken>mc/</urn:sessiontoken>
             <urn:domEvent>
    <rtevent type="create_account" email="esther.hall@adobe.com" origin="eCommerce" wishedChannel="email" 
          externalId="1596" language="english" country="EN" emailFormat="2"
          mobilePhone="+447700123123">
      <ctx>
       <website name="eCommerce" url="http://www.eCo']]></detail>
          </SOAP-ENV:Fault>
       </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>
    
    
  • Exemple de traitement d'un événement qui a échoué et du renvoi d'un identifiant à zéro (le nom de la méthode est erroné) :
    <SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns="http://xml.apache.org/xml-soap" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
       <SOAP-ENV:Body>
          <urn:PushEventResponse SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:urn="urn:nms:rtEvent">
             <plId xsi:type="xsd:long">0</plId>
          </urn:PushEventResponse>
       </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>