Handling errors and exceptions
Detecting failovers
When a failover occurs, AFTM-supported requests are routed to the failover account. Assuming that your code used your account-specific endpoint, the authorization token should still be valid for the failover account.
However, we still recommend that your code watch for exceptions or lack of response.
- One way your client code can watch for exceptions or lack of response is to periodically make a standard read-only request, such as “Fetch All Profile Lists”, and watch for responses other than the standard HTTPS 200 Success response. If you receive an “API_NOT_ALLOWED_IN_SECONDARY” (HttpStatus.UNAUTHORIZED, HTTPS status code 401), a failover has occurred and your client code may only use AFTM-supported endpoints.
- If you receive an “INVALID_TOKEN” error (HttpStatus.UNAUTHORIZED, HTTPS status code 401), your code must re-login to your account-specific endpoint using the same credentials that you used to access your primary Interact account.
- If you receive an “UNRECOVERABLE_EXCEPTION” error (HttpStatus.INTERNAL_SERVER_ERROR, HTTPS status code 500), your code should wait about 30 seconds and then resubmit the request only once.
- If there is no system response, your code can retry up to three times, with two minute intervals, to prevent the API login being disabled. If you still do not receive a response, contact Oracle Support.
For more information, see “Handling System Outages” in the standard REST API guide.
Other errors
AFTM only supports promotional campaigns in primary: You can use APIs such as HaMergeTriggerEmail for both promotional and transactional campaigns in primary. However, merge and trigger for promotional campaigns will fail in the secondary pod during failover.
When this occurs, the API will return the below sample error.
{
"type": "",
"title": "Invalid request parameters",
"errorCode": "INVALID_PARAMETER",
"detail": " <Campaign Name> must be Transactional campaign",
"errorDetails": []
}