Ways to share published page data to an API

[Leela-Pavan-Kumar]

Hi,

We have an use-case, where we need to share the Page data to an API once its published. 

Currently, By using Replication Event Handler we are sharing data to an API. But sometime we are facing an issue similar like this https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/custom-replication-event-h... , On bulk Activation event handler is triggering intermittently and sometimes throwing errors in logs. In this situation, we are restarting our bundle and doing Page Activation again in order to share data to an API.

Additionally, we have some more requirements,

1. Need to log pages which are not shared to API when ever there is an issue and data is not shared to API. 

2. Support Bulk Page Activations.

3. Best ways to implement this use-case(Sharing Page Data) when a Page is Replicated apart from Replication Event Handling.

[arunpatidar]

Hi,

Create your own page where you can select the source and do activation/feeding to api in a schedule job way and use threading to achieve it , similar to https://adobe-consulting-services.github.io/acs-aem-commons/features/bulk-workflow-manager/index.htm... 

[Leela-Pavan-Kumar]

Thanks for the suggestion @arunpatidar ,

That suits for Bulk Activation but in the case of a Single page every time author needs to come to this page and select the page for passing the data to API.

Is there any way to handle this without author's Intervention? 

[arunpatidar]

For single page you can stick with replication event listener. but when you have to do bulk publish then use bulk workflow manager 

[Leela-Pavan-Kumar]

Is there any way to handle this other than Replication Event Listener to capture the Page Data when its published?

[lukasz-m · Accepted solution]

Hi @Leela-Pavan-Kumar,

In my opinion you should consider to use Preprocessor in combination with Sling Job and dedicated Sling Job Queue.

The entire solution will cover all cases, single page publication bulk publication failure logging, and also as an extra feature retry option.

Preprocessor will be triggered by replication, and should offload work related to pushing data to external/shared API to Sling Jobs. If there will be lot of pages published at once (bulk publication), Sling Jobs will be stacked in dedicated queue. Sling Job also provides you OOTB retry mechanism - so in case of failure, it can be implemented in the way that there will be few retries - and if it fails you can simply log detailed information about failure.

Please have a look into following documents:

• https://labs.tadigital.com/index.php/2019/06/25/aem-preprocessor/ - nice article that compares Workflows, Event Listeners and Preprocessor, with sample Preprocessor implementation
• https://dileepakv.blogspot.com/2018/01/aem-replication-preprocessor.html another example of Preporcessor implementation and comparison of Workflows, Event Listeners, and Preprocessor - I think it describes very similar use case to yours