Replicating a CQ page to two different paths in CQ publisher | Community
Skip to main content
A
anandsb
Level 2
October 16, 2015
Solved

Replicating a CQ page to two different paths in CQ publisher

  • October 16, 2015
  • 6 replies
  • 2499 views

We have a requirement of pushing the CQ page to two different locations in publisher i.e.

the page in CQ5 - content/site/page1 should be replicated to content/site-test/page1 and then to content/site/page1 in same publisher. We also dont want to create a copy of page1 in authoring i.e. we dont want to create content/site-test/page1 at Author to avoid duplicates at authoring instance.

Is there a way (using APIs or otherwise), replicate a page in authoring on two different location (one usual default location at publisher and another one in a different root node).? We are using CQ 5.5

Thanks

Anand

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 PaulMcMahon

I would say there are a couple of options available to you:

  1. You could write a custom event listener that runs on your publish servers and listens for Replication Events or JCR modification events. For any replication event that listener would handle synchronizing you two branches using JCR API to copy/delete as required. This has the advantage of requiring the least amount of code to be written, but is probably the least reliable. You'd have to monitor the results on all publish servers, and since it is all custom code you'd have to build all the reliability and monitoring your self. Listening for Replication Events reduces the number of events you have to respond to, however it does leave some holes. For example if someone replicates a package with content the replication event might miss that. Using JCR events would reduce the likelihood of missing something, but increase the complexity. 
  2. You could write a custom replication agent. So for each publisher your have two replication agents, the normal one which would replicate the page in author, and your custom one that would handle the other page. You'd need to dig into the content builder and modify the content builder so it pulled all the content from the original path, but then the transport handler would modify the data sent over so that the publisher would save it to a different path. This has the advantage of leveraging all the out of the box tools for monitoring and guaranteed delivery, but will take significant effort to create. 
  3. Bite bullet and duplicate the content in author. I know this seems like it's a waste, but it is best practice and will mean the least long term cost. The platform fully supports this option and you can do it with configuration only and not write any code. From a long term ROI perspective you are better off using the native functionality that trying to custom code something. 

6 replies

P
PaulMcMahonAccepted solution
Level 8
October 16, 2015

I would say there are a couple of options available to you:

  1. You could write a custom event listener that runs on your publish servers and listens for Replication Events or JCR modification events. For any replication event that listener would handle synchronizing you two branches using JCR API to copy/delete as required. This has the advantage of requiring the least amount of code to be written, but is probably the least reliable. You'd have to monitor the results on all publish servers, and since it is all custom code you'd have to build all the reliability and monitoring your self. Listening for Replication Events reduces the number of events you have to respond to, however it does leave some holes. For example if someone replicates a package with content the replication event might miss that. Using JCR events would reduce the likelihood of missing something, but increase the complexity. 
  2. You could write a custom replication agent. So for each publisher your have two replication agents, the normal one which would replicate the page in author, and your custom one that would handle the other page. You'd need to dig into the content builder and modify the content builder so it pulled all the content from the original path, but then the transport handler would modify the data sent over so that the publisher would save it to a different path. This has the advantage of leveraging all the out of the box tools for monitoring and guaranteed delivery, but will take significant effort to create. 
  3. Bite bullet and duplicate the content in author. I know this seems like it's a waste, but it is best practice and will mean the least long term cost. The platform fully supports this option and you can do it with configuration only and not write any code. From a long term ROI perspective you are better off using the native functionality that trying to custom code something. 
A
Alex_Popov1
Level 4
October 16, 2015

Hello Anand,

If you don't want to create additional live copy, you can create custom live action and implement additional logic there.
https://dev.day.com/docs/en/cq/5-5/developing/multi_site_manager_dev.html

joerghoh
Adobe Employee
joerghohAdobe Employee
Adobe Employee
October 16, 2015

I would really question such a requirement, as it raises a number of questions and probably also problems. I would explore 2 approaches:

  • Have proxy code, which reads content from a different location, and multiple proxies can read from the very same location
  • On a sling level you might want to have a look at https://issues.apache.org/jira/browse/SLING-1778, which is an interesting approach able to address many issues.

Still, I don't know the exact requirement, why you want to duplicate replicated pages. But all approaches, which duplicate the content don't look that elegant to me.

Jörg

S
Sam205505050
Level 6
October 16, 2015

I will write a custom workflow step and will include below code to replicate -

@Reference
com.day.cq.replication.Replicator replicator = null;

ReplicationOptions opts = new ReplicationOptions();
       opts.setFilter(new AgentFilter(){
           public boolean isIncluded(final Agent agent) {
               return agent.getId("YourAgentID"));
           }
       });

replicator.replicate(Session, ReplicationActionType.ACTIVATE, "Path/to/Your/Page", opts);

A
anandsbAuthor
Level 2
October 16, 2015

@Sam205505050....thanks for your response. I believe this would be helpful for me to trigger a specific replication agent however I still have to customize Transport library to create nodes at two locations one of which (one path out of two replicated paths at CQ publisher) does not exist in author.

 

Anand

A
anandsbAuthor
Level 2
October 16, 2015

Thanks Orotas. Option#2 seems more favorable for the requirement. Agreed with you that #1 is highly unreliable. Long path dig in for CQ libraries....

 

Thanks for your response.

 

Anand

Terms & ConditionsAccessibility statement

Loading footer...