As noted in the previous section, the DLQ is used anytime ProfileSync cannot complete a data transfer. Admittedly, failures like this are rare, in part because ProfileSync makes multiple efforts to deliver the data before terminating the delivery process. Nevertheless, there are a number of situations that could result in an event being sent to the DLQ:
- Communication interruptions. For example, either your network or the target API network could experience an extended period where Internet connectivity is lost. You can often diagnose network connection errors by checking the log of failed API calls against known instances of network connectivity issues.
- Target API downtime. For example, the target API might have been taken offline for maintenance or upgrading. In the API log, you might see that all API calls for a specified period of time (for example, 4:00 AM to 4:30 AM) failed, but all subsequent API calls succeeded.
- Changes to the target API. Changes to the target API (for example, changing the API endpoint) will result in all your ProfileSync calls failing. If your API log shows that none of your calls have succeeded since a specified point in time, check to see if any changes have been made to the target API.
- An expired certificate, or credential changes. If a certificate has expired or if your authentication credentials have changed, then all your ProfileSync calls will fail. If all your calls are failing, check to see when the ProfileSync connector certificates expire, and verify that your credentials are up-to-date.
- User error. If the API log shows seemingly-random problems with data delivery attempts, that could suggest a mapping problem between the Akamai user profile and the target API; for example, you have incorrectly mapped the user's email address. In a case like that, changes to the email address will fail, while changes to any other Akamai attribute will succeed.
Each Monday an automated program checks the DLQ to see if any events have been logged there. If there are any events in the DLQ, a ticket is sent informing you that an error has occurred. If you believe that the data delivery problem has been resolved (for example, the database that was temporarily offline is now back online) you can respond to the ticket and ask ProfileSync to try again. Provided you respond within 5 days after receipt of the ticket, ProfileSync will contact the target platform and attempt to transfer the data.
Note. And what if you don't respond within 5 days? Well, after 5 days, the ticket is automatically closed, and the event is removed from the dead-letter-queue. After the event is removed there's no longer anything for ProfileSync to reprocess.
As an Akamai client, you do not have access to the dead-letter-queue; you only receive (and can respond to) the notification ticket. Because of that, it's useful to know that no personally-identifiable information is stored in a webhook event (and, therefore, no personally-identifiable information is stored in the DLQ), Instead, each event consists of a JSON object (in the case of the dead-letter-queue, these events are stored as .txt files). See Appendix B for more information.