You can configure the warning thresholds (orange) and alert thresholds (red) of the indicators that appear in the Message Center service level and Message Center processing time reports (refer to Access transactional messaging reports).
To do this, follow the steps below:
Open the deployment wizard on the execution instance.
Go to the Message Center page.
Use the arrows to change the thresholds.
You can use the deployment wizard to configure how long the data is to be stored in the database.
Event purging is carried out automatically by the Database cleanup 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.
Event purge settings on a control instance:
Event purge settings on an execution instance:
For more on the database cleanup workflow, see this section.
You must ensure that the technical workflows on the control instance and the different execution instances have indeed been created and started before deploying any transactional message templates.
The various technical workflows related to transactional messaging (Message Center) are broken down between the control instance and the execution instance(s).
On the control instance, whether you have one or several execution instances registered, 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.
These workflows can then be accessed from the Administration > Production > Message Center folder. Once created, the archiving workflows are automatically started.
On the execution instance(s), the technical workflows for transactional messaging can be accessed from the Administration > Production > Message Center folder. You just have to start them. The workflows in the list are:
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.
The following event statuses are available:
This section describes one solution to configure tracking and mirror page URLs per brand, for transactional messages in Adobe Campaign.
To configure multibranding, you need to configure both execution instances and control instance.
On the execution instance(s), follow the steps below:
Create one external account per brand.
Learn how to create an execution instance type external account in this section.
Extend the nms:extAccount schema to add the tracking URL:
<attribute advanced="true" desc="URL of the tracking servers" label="Tracking server URL" length="100" name="trackingURL" type="string"/>
Learn how to extend an existing schema in the Extending a schema section.
Modify the nms:extAccount form:
<container label="Message domain branding" type="frame"> <static type="help"> These parameters are used to override the DNS alias and addresses used during message delivery. When not populated, the values of the 'NmsServer_MirrorPageUrl' and 'NmsEmail_DefaultErrorAddr' options are used.</static> <input xpath="@mirrorURL"/> <input xpath="@trackingURL"/> <input img="nms:sendemail.png" menuId="deliveryMenuBuilder" type="scriptEdit"> xpath="errorAddress"/> </container>
Modify the NmsTracking_OpenFormula and NmsTracking_ClickFormula options to use the external account instead of a global option.
To do this, replace:
<%@ include option='NmsTracking_ServerUrl' %>
<%@ value object="provider" xpath="@trackingURL" %>
These changes could lead to conflicts when upgrading. You may need to manually merge these formulas with their new version.
On the control instance, you need to link delivery templates and external accounts.
To do this, follow the steps below:
Create one external account per brand with the same internal name as defined on the execution instance (step 1).
Create one default delivery template per brand.
Learn how to create a delivery template in this section.
In the delivery template’s Properties, set the routing to the external account of the brand.