Expand my Community achievements bar.

July 31st AEM Gems Webinar: Elevate your AEM development to master the integration of private GitHub repositories within AEM Cloud Manager.

Akamai Purger cache flush through APIs


Level 3

Hi All,

Our Environment Setup 

We have a window's service named as "Akamai Purger" which will use the java module that checks for changes in the file system and sends purge requests to Akamai. In addition to this the main purpose of the cache-flusher is to detect when a file is deleted due to content activation on the author server. 

Finding and Problem Statement
When AEM activates pages from author to publish the path that is being sent through the cache flusher is the "long" version; e.g. /content/mybrands/mysite/en.html. However when a user hits the page the url is rewritten (shortened) to only en.html and the file at that path is served to the user and cached in the dispatcher (/htdocs). 
This does not affect the state of the pages that are served to the end user because at the same time as the flush is performed, an invalidation of all html-files.

This becomes a problem for the Akamai purger application, because it only reacts on the deletion of the cached files. And as the files that are removed by the flush agent (/content/mybrands/mysite/en.html) will never be re-created simply because no one will ever visit it. (Only the /en.html – the short version – will be visited).
This is also described here (https://docs.adobe.com/docs/en/aem/6-1/manage/seo-and-url-management.html):

While this is the approach that is documented in the official AEM and Sling documentation, the regular expression support provided by this implementation is limited in scope when compared to the options that are available to us by using the SlingResourceResolver directly. Additionally, implementing mappings in this way can lead to issues with dispatcher cache invalidation.

Here is an example of how this issue occurs:
A user visits your website and requests http://www.mydomain.com/my-page.html
The dispatcher forwards this request to the publish server.
Using /etc/map, the publish server resolves this request to /content/my-brand/my-page and renders the page.
The dispatcher caches the response at /my-page.html and returns the response to the user.
A content author makes a change to this page and activates it.
The dispatcher flush agent sends an invalidation request for /content/my-brand/my-page. Because the dispatcher does not have a page cached at this path, the old content remains cached and will be stale.

Alternate tried solution
Instead we could create a new type of agents (static-content creation agents) that on each activation, creates a static file in another location, and then make the Akamai purger "listen" to file operations in this location. But is it a good idea to cache content in different hierarchy parallel to the old one.

Could anyone please pour in suggestions and best way to achieve the akamai purge?

Already reffered the link - http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

Thanks in advance,


4 Replies


Level 10

In your view - do the docs contain wrong information? 


Level 3
      Hi Smac,  docs are correct but I am just sharing my findings which may be wrong and i need suggestion on what should be the right way to acheive this akamai purge through apis.


Level 10

I am looking for some API examples for you within Adobe - however - reply may be late as many ppl have started on shutdown for holiday. 


Level 3
Thanks for that response. Your suggestions would be much appreciated.