Ways to share published page data to an API | Community
Skip to main content
Leela-Pavan-Kumar
Leela-Pavan-Kumar
Level 4
August 10, 2022
Solved

Ways to share published page data to an API

  • August 10, 2022
  • 2 replies
  • 1249 views

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-handler-not-triggering-intermittently/m-p/279325 , 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.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by lukasz-m

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:

2 replies

arunpatidar
Community Advisor
arunpatidarCommunity Advisor
Community Advisor
August 11, 2022

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.html 

Arun Patidar
    Leela-Pavan-Kumar
    Leela-Pavan-KumarAuthor
    Level 4
    August 11, 2022

    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
      Community Advisor
      arunpatidarCommunity Advisor
      Community Advisor
      August 11, 2022

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

      Arun Patidar
        lukasz-m
        Community Advisor
        lukasz-mCommunity AdvisorAccepted solution
        Community Advisor
        August 11, 2022

        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:

          Terms & ConditionsAccessibility statement

          Loading footer...