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.