Transactional messaging settings mc-settings
Transactional messaging (Message Center) is a Campaign module designed for managing triggered messages. Learn more about Transactional messaging in this section.
Understand transactional messaging architecture in this page.
Define permissions mc-permissions
To create new users for Message Center execution instances hosted on ۶Ƶ Cloud, contact your ۶Ƶ Transition Manager. Message Center users are specific operators that require dedicated permissions to access ‘Real time events’ (nmsRtEvent) folders.
Schema extensions mc-schema-ext
All schema extensions made on the schemas used by Message Center technical workflows on either control or execution instances need to be duplicated on the other instances used by ۶Ƶ Campaign transactional messaging module.
Send transactional push notifications mc-transactional-push
When combined with Mobile app channel module, transactional messaging enables you to push transactional messages through notifications on mobile devices.
To send transactional push notifications, you need to perform the following configurations:
-
Install the Mobile App Channel package onto the control and execution instances.
note caution CAUTION Check your license agreement before installing a new Campaign built-in package. -
Replicate the Mobile application service and the associated mobile applications on the execution instances.
In addition, the event must contain the following elements:
- The mobile device ID: registrationId for Android and deviceToken for iOS. This ID represents the “address” that the notification is sent to.
- The link to the mobile application or integration key (uuid) which lets you retrieve connection information specific to the application.
- The channel to which the notification will be sent (wishedChannel): 41 for iOS and 42 for Android.
- Any other personalization data.
Below is an example of an event configuration to send transactional push notifications:
<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>
Purge events purge-events
You can adapt the deployment wizard settings to configure how long the data is to be stored in the database.
Event purging is carried out automatically by the Database cleanup technical workflow. This workflow purges the events received and stored on the execution instances and events archived on a control instance.
Use the arrows as appropriate to change the purge settings for the Events (on an execution instance) and Archived events (on a control instance).
Technical workflows technical-workflows
You must ensure that the technical workflows on your control and execution instances have been started before deploying any transactional message templates.
These workflows can then be accessed from the Administration > Production > Message Center folder.
Control instance workflows control-instance-workflows
On the control instance, you must create one archiving workflow for each Message Center execution instance external account. Click the Create the archiving workflow button to create and start the workflow.
Execution instance workflows execution-instance-workflows
On the execution instance(s), you must start the following technical workflows:
-
Processing batch events (internal name: batchEventsProcessing ): this workflow lets you break down batch events in a queue before they are linked to a message template.
-
Processing real time events (internal name: rtEventsProcessing ): this workflow lets you break down real time events in a queue before they are linked to a message template.
-
Update event status (internal name: updateEventStatus ): this workflow lets you attribute a status to the event.
Possible event statuses are:
- Pending: the event is in the queue. No message template has been assigned to it yet.
- Pending delivery: the event is in the queue, a message template has been assigned to it and it is being processed by the delivery.
- Sent: this status is copied from the delivery logs. It means that the delivery has been sent.
- Ignored by the delivery: this status is copied from the delivery logs. It means that the delivery was ignored.
- Delivery failed: this status is copied from the delivery logs. It means that the delivery failed.
- Event not taken into account: the event could not be linked to a message template. The event will not be processed.