This conversation has been locked due to inactivity. Please create a new post.
This conversation has been locked due to inactivity. Please create a new post.
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.
Solved! Go to Solution.
Views
Replies
Total Likes
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:
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...
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?
Is there any way to handle this other than Replication Event Listener to capture the Page Data when its published?
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:
Views
Likes
Replies
Views
Likes
Replies