Funktionsweise der Ereignisbeschreibung about-event-desc

Transaktionsnachrichten-Datenmodell about-mc-datamodel

Transaktionsnachrichten basieren auf dem Adobe Campaign-Datenmodell und verwenden zwei zusätzliche, separate Tabellen. Diese Tabellen, NmsRtEvent und NmsBatchEvent, enthalten dieselben Felder, wobei die eine zur Verwaltung von Echtzeit-Ereignissen dient, die andere zur Verwaltung von Batch-Ereignissen.

SOAP-Methoden soap-methods

In diesem Abschnitt werden die in Zusammenhang mit den Schemata des Transaktionsnachrichten-Moduls verwendeten SOAP-Methoden beschrieben.

Zwei PushEvent oder PushEvents SOAP-Methoden sind mit den beiden nms:rtEvent und nms:BatchEvent-Datenschemata verknüpft. Das Informationssystem bestimmt hierbei, ob es sich um ein “Batch”- oder “Echtzeit”-Ereignis handelt.

Die WSDL-Zugriffspfade der zwei Methoden lauten:

Beide Methoden enthalten ein <urn:sessiontoken>-Element zum Anmelden beim Modul für den Transaktionsnachrichtenversand. Wir empfehlen die Verwendung einer Authentifizierungsmethode über vertrauenswürdige IP-Adressen. Um das Sitzungstoken abzurufen, führen Sie einen SOAP-Aufruf zur Anmeldung und dann ein GET-Token gefolgt von einer Abmeldung durch. Verwenden Sie dasselbe Token für mehrere RT-Aufrufe. Die in diesem Abschnitt enthaltenen Beispiele verwenden die Sitzungstoken-Methode, wobei es sich um das empfohlene Verfahren handelt.

Falls Sie einen LoadBalancing-Server verwenden, können Sie die Benutzer-/Kennwortauthentifizierung verwenden (auf der Ebene der RT-Nachricht). Beispiel:

<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>

Die Methode PushEvent besteht aus einem <urn:domevent>-Parameter, der das Ereignis enthält.

Die Methode PushEvents besteht aus einem <urn:domeventcollection>-Parameter, der die Ereigniskollektion enthält.

Beispiel der Methode PushEvent:

<urn:PushEvent>

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

 <urn:domEvent>

   <rtEvent>

   ...

   </rtEvent>

 </urn:domEvent>

</urn:PushEvent>

Beispiel der Methode PushEvents:

<urn:PushEvents>

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

 <urn:domEventCollection>

   <Events>

     <rtEvent>... </rtEvent>

     <rtEvent>... </rtEvent>

     ...

   </Events>

 </urn:domEventCollection>

</urn:PushEvents>

Die <rtevent>- und <batchEvent>-Elemente besitzen einen Satz an Attributen sowie ein unbedingt erforderliches untergeordnetes Element <ctx>, welches die Integration der Nachrichtendaten ermöglicht.

Die obligatorischen Attribute der Elemente <rtevent> und <batchEvent> lauten „@type“ und „@email“. Der Wert von „@type“ muss mit dem bei der Konfiguration der Ausführungsinstanz definierten Auflistungswert übereinstimmen. Mit diesem Wert können Sie die Vorlage definieren, die beim Versand mit dem Inhalt des Ereignisses verknüpft werden soll.

<rtevent> configuration example:

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

In diesem Beispiel sind mit der E-Mail-Adresse und der Mobiltelefonnummer zwei Kanäle angegeben. Das Feld wishedChannel ermöglicht die Bestimmung des Kanals, der bei der Reaktion auf ein Ereignis verwendet werden soll. Der Wert “0” entspricht dem E-Mail-Kanal, der Wert “1” dem Mobile-Kanal usw.

Wenn Sie einen Ereignisversand verschieben möchten, fügen Sie das Feld Geplant hinzu, gefolgt vom bevorzugten Datum. Das Ereignis wird an diesem Datum in eine Nachricht umgewandelt.

Es wird empfohlen, die Attribute @wishedChannel und @emailFormat mit numerischen Werten auszufüllen. Die Funktionstabelle, die numerische Werte und Beschriftungen verknüpft, finden Sie in der Beschreibung des Datenschemas.

Das <ctx>-Element enthält die Nachrichtendaten. Der XML-Inhalt ist offen, d. h. er kann je nach zu sendendem Inhalt konfiguriert werden.

Datenbeispiel:

   <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>

Vom SOAP-Aufruf zurückgegebene Informationen information-returned-by-the-soap-call

Wenn ein Ereignis eingeht, generiert Adobe Campaign eine eindeutige Rückgabe-ID. Dies ist die ID der archivierten Version des Ereignisses.

Wenn der Wert der Rückgabe-Kennung streng größer als null ist, wurde das Ereignis im Verlauf in Adobe Campaign gespeichert.

Wenn die Verarbeitung des Ereignisses fehlgeschlagen ist, gibt die Methode eine Fehlernachricht oder einen Wert gleich null zurück.