If a mailing is stopped for any reason (for example, if the server sending out the mailing crashes), you can rerun the mailing when the server restarts. However, if any of the mail messages were sent successfully, some users might receive multiple copies of the mail. The Personalization module includes services you can use to handle this situation. These services record information about the users to whom the mailing was sent and whether or not the mailing completed successfully. When you restart the server, the system can check for any incomplete mailings and restart them from the point where the failure occurred. This behavior ensures that each user receives only one copy of a mailing.
There are two services in atg.userprofiling.email
that handle restarting stopped e-mail campaigns, TemplateEmailRestarter
and TemplateEmailPersisterImpl
. When the TemplateEmailRestarter
service starts up, it checks the database for incomplete mailings and restarts any that it finds. Typically, you want to invoke TemplateEmailRestarter
when the server starts up, so you should add this service to the initialServices
property of an atg.nucleus.InitialService
component, for example the /atg/dynamo/service/Initial
component.
There should be one instance of the TemplateEmailRestarter
service running on each ATG server on a site. Each ATG server must have a unique DRP port number so the TemplateEmailRestarter
service can determine which server created a given mailing. Configure the migrationList
property to point to the list of UniqServerIds
of the mailing that should be migrated to that server. For example:
migrationList=64.69.0.100:8851
This setting moves all mailings on host 64.69.0.100 at DRP port 8851 to the current server. To test that this migration works, you can create a set of mailings on one server, change the DRP port number, and then edit the TemplateEmailRestarter
component to migrate from the old DRP port to the new one. You can verify the change by looking in the database.
The TemplateEmailPersisterImpl
service does the actual work of recording information about a mailing as it is being sent out and checking the status of mailings when the ATG system starts up. The dps_mailing
table has a property called num_profiles
that is the number of profiles to which a particular mailing should be sent, and another property, num_sent
, which is the number of e-mails sent in that mailing. Two more properties, num_errors
and num_skipped
, record respectively the number of messages that could not be sent because of errors that occurred during the mailing, and the number of recipients to whom message could not be sent, for example because the emailStatus
profile property was set to invalid.
E-mails are sent in order, and each one is assigned a unique ID, which is the mailing_id
property of the dps_mailing
and dps_email_address
tables. The TemplateEmailPersisterImpl
service takes the list of recipients from the dps_user_mailing
and the dps_email_address
tables and begins resending e-mails from the number recorded as the sum of the num_sent
, num_errors
, and num_skipped
properties.
This service is a property of both the TemplateEmailSender
service (which uses it to record information about mailings) and TemplateEmailRestarter
(which uses it to check the status of mailings). When you configure the TemplateEmailSender
and TemplateEmailRestarter
components, be sure to set their templateEmailPersister
properties to the Nucleus pathname of a TemplateEmailPersisterImpl
component, such as /atg/userprofiling/email/TemplateEmailPersister
.
For information on setting up persistent targeted e-mail with a composite repository that uses an LDAP repository as its primary view, see Configuring Targeted E-mail for a Composite Repository.
For distributed mailings, information about the batches within a mailing is persisted to the dps_mail_batch
table by the /atg/userprofiling/email/TemplateEmailBatchPersister
component. Information about the servers used to perform a distributed mailing is persisted to the dps_mail_server
table by the /atg/userprofiling/email/TemplateEmailBatchServerPersister
component. See Distributing a Mailing across Multiple Servers for more information.
Note that, if you use the Scenarios module, mailings sent through the Scenario window of the ACC automatically handle persistence. However, if you are creating mailings programmatically, you must use a TemplateEmailSender.sendEmailMessage()
method that includes an argument for enabling persistence. For example, if you are sending targeted e-mail that contains a promotion, the e-mail is handled in a separate thread and you have to ensure that the slot that holds the promotion is persistent, otherwise the promotion will not be sent with the e-mail. A persistence argument could look like this:
sendEmailMessage(TemplateEmailInfo pEmailInfo,
Enumeration pRecipients,
boolean pRunInSeparateThread,
boolean pPersist);
If either RunInSeparateThread
or Persist
evaluates to true, the e-mail has the potential to run in a separate thread, and the slots associated with the e-mail must be persistent. For more information on slots, see Using Slots in the Creating Scenarios chapter of the ATG Personalization Guide for Business Users.