Expand my Community achievements bar.

SOLVED

API need urgent help

Avatar

Level 9

Hi Community,

 

I need some urgent help on the below,

 

In an event where the Adobe API is experiencing issues or is down, what happens to the events received for the transactional messages during that period of time, is there any retry logic as such.

can you provide some information or link to a document which explains this.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi there,

Adobe does not provide any queueing mechanism for incoming events, so if you receive anything than a 200, it would certainly mean your event has failed to be registered into ACS, the responsibility to retry, queueing, etc... is left on the calling system to implement.

From an architecture point of view, your calling system should implement what follows 9at minima):

  1. Transparent JWT token generation: token being valid for 24 hrs, you need to regenerate it once it expires (the API will return a 403 error code and the message might be also explicit) and re-issue the original request. Do not base your token regeneration based on the validity period, better to base it if you got an authentication error
  2. Queueing / retry mechanism: if you got any error indicating system down (most likely 50x), it is your responsibility to retry later. 

Crucial note: during an upgrade, the instance is down meaning all incoming requests will fail and if you don't  do the above, the requests will be lost.

Thanks

Denis

 

View solution in original post

3 Replies

Avatar

Correct answer by
Employee Advisor

Hi there,

Adobe does not provide any queueing mechanism for incoming events, so if you receive anything than a 200, it would certainly mean your event has failed to be registered into ACS, the responsibility to retry, queueing, etc... is left on the calling system to implement.

From an architecture point of view, your calling system should implement what follows 9at minima):

  1. Transparent JWT token generation: token being valid for 24 hrs, you need to regenerate it once it expires (the API will return a 403 error code and the message might be also explicit) and re-issue the original request. Do not base your token regeneration based on the validity period, better to base it if you got an authentication error
  2. Queueing / retry mechanism: if you got any error indicating system down (most likely 50x), it is your responsibility to retry later. 

Crucial note: during an upgrade, the instance is down meaning all incoming requests will fail and if you don't  do the above, the requests will be lost.

Thanks

Denis

 

Avatar

Level 9

Hi @Denis_Bozonnet 

 

Thank you, this information is really helpful, just curious if there is anything mentioned somewhere about this in Adobe documentation, it could be used as a reference link.

 

 

Avatar

Employee Advisor

Hi there,

 

I don't think so, looking at the Campaign API document, it provides how to use the product, it does not provide general design considerations that are not Adobe specifics in a sense that integration via APIs design should always follow industry best practices.  and as such, if you want to build a strong and robust solution API based, you need to take into account that the 3rd party system you are calling might have issues (like the caller system can have some too), and error handling and retry / queueing is some of these best practices that should be taken into considerations.

 

Also, for ACS Transactional Message APIs, you must be aware of the product limitations that are contractual, (See https://helpx.adobe.com/legal/product-descriptions/campaign-standard.html and search for Dedicated Server, 50,000 / hour), therefore, you also need to take that also into account from a volume pespective. If your volume of transactional messages will exceed the 50,000 / hour at peak time, you have to increase the capacity of ACS. Some customers have used queueing to throttle the transaciotnal messages into ACS to fit within the 50,000 / h range....

 

Hope this helps.

Thanks
Denis