Event description event-description

Transactional messaging data model about-transactional-messaging-datamodel

Transactional messaging relies on the Adobe Campaign data model, and uses two additional separate tables. These tables, NmsRtEvent and NmsBatchEvent, contain the same fields and let you manage real time events on one hand, and batch events on the other hand.

SOAP methods soap-methods

This section details the SOAP methods associated with the transactional messages module schemas.

Two PushEvent or PushEvents SOAP methods are linked to the two nms:rtEvent and nms:BatchEvent dataschemas. It is the information system that determines whether an event is a “batch” or “real time” type.

The WSDL path for accessing both methods is:

For more on generating a WSDL file, see this section.

Both methods contain an <urn:sessiontoken> element for logging on to the transactional messaging module. We recommend using an identification method via trusted IP addresses. To retrieve the session token, perform a logon SOAP call, then a get token followed by a logoff. Use the same token for several RT calls. The examples included in this section are using the session token method which is the recommended one.

In case you’re using a loadbalanced server, you can use the User/Password authentication (at the level of the RT message). Example:

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

The PushEvent method is made up of a <urn:domevent> parameter which contains the event.

The PushEvents method is made up of a <urn:domeventcollection> parameter which contains events.

Example using PushEvent:

<urn:PushEvent>

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

 <urn:domEvent>

   <rtEvent>

   ...

   </rtEvent>

 </urn:domEvent>

</urn:PushEvent>

Example using PushEvents:

<urn:PushEvents>

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

 <urn:domEventCollection>

   <Events>

     <rtEvent>... </rtEvent>

     <rtEvent>... </rtEvent>

     ...

   </Events>

 </urn:domEventCollection>

</urn:PushEvents>

The <rtevent> and <batchevent> elements have a set of attributes as well as a mandatory child element: <ctx> for integrating message data.

The mandatory attributes of the <rtevent> and <batchevent> elements are @type and @email. The value of @type must be the same as the itemized list value defined when configuring the execution instance. This value lets you define the template to be linked to the content of the event during the delivery.

<rtevent> configuration example:

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

In this example, two channels are provided: the email address and the mobile phone number. The wishedChannel lets you select the channel you wish to use when transforming the event into a message. The “0” value corresponds to the email channel, the “1” value to the mobile channel, etc.

If you wish to postpone an event delivery, add the scheduled field followed by the preferred date. The event will be transformed into a message on this date.

We recommend filling in the @wishedChannel and @emailFormat attributes with numeric values. The function table which links numeric values and labels is found in the data schema description.

The <ctx> element contains the message data. Its XML content is open, which means it can be configured depending on the content to be delivered.

Data example:

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

Information returned by the SOAP call information-returned-by-the-soap-call

When it receives an event, Adobe Campaign generates a unique return ID. This is the ID of the archived version of the event.

If the value of the return identifier is strictly greater than zero, this means the event has been successfully archived in Adobe Campaign.

However, if the event fails to be processed, the method returns an error message or a value equal to zero.