Default Agent

This agent is responsible for replicating content from author to publish Instance


From the Tools tab in the author environment you can configure replication agents that reside in either the author environment (Agents on author) or the publish environment (Agents on publish). The following procedures illustrate the configuration of an agent for the author environment, but can be used for both.

To configure a replication agent from your author environment:

  1. Access the Tools tab in CQ.

  2. Click Replication (left pane to open the folder).

  3. Double-click Agents on author (either the left or the right pane).

  4. Click the appropriate agent name (which is a link) to show detailed information on that agent.

  5. Click Edit to open the configuration dialog:

  6. The values provided should be sufficient for a default installation. If you make changes then click OK to save them (see Replication Agents - Configuration Parameters for more details of the individual parameters).


A standard installation of CQ specifies admin as the user for transport credentials within the default replication agents.

This should be changed to a site-specific replication user account with the privileges to replicate the required path(s).

Now let's see how replication Work internally,

If you will see carefully, With Each activation command servlet (/bin/replicate.json) get called with cmd=Activate. /bin/replicate.json is mapped to command servlet

CommandServlet checks for action type (Currently only two action type supported (From by and they are ACTIVATE and DEACTIVATE. Servlet also check for access right of user trying to replicate and set corresponding status code (403 for access denied and 400 if there is any exception).

based on type of operation CQ creates Events (org.osgi.service.event.Event)
With topic = com/day/cq/wcm/workflow/req/for/activation
and properties as
                     Dictionary<String, Object> properties = new Hashtable<String, Object>();
                    properties.put("path", path);
                    properties.put("replicationType", action)
Finally this event is send by (org.osgi.service.event.EventAdmin) please click here to see how event admin registration works. Request for activation is registered for model (/etc/workflow/models/request_for_activation) click here for detail.

If you see default request for activation Model it calls (

ActivatePageProcess extends ReplicatePageProcess (ActivatePageProcess only set replication action, For deactivation DeactivatePageProcess is called). Some interesting predefined processes can be found here

ReplicatePageProcess is a workflow process thus extends WorkflowProcess . In execute method again permission is checked (As you can initiate page activation directly through workflow) and then method is called with options.

That's it !!!!!! from high level ... may be yes but let's see what is going on inside Replicator class

Replicator.replicate method is responsible for replication of content ...

get all replication options -> check agents (If all agents are disabled nothing happens ) -> Set up replication Action (Call Constructor with revision) -> Check user permission for path -> Get all preprocessor -> Build content to replicate (buildContent method for each agent and then getContent method) -> Finally Build content method returns content per agent (Map<String, ReplicationContent>) -> Once it receives all replication agent it calls agent replicate (agent.replicate(..)) method for replication -> Then based on kind of action (Activate, Deactivate ...) it update status of node -> In the end it post event for audit log using toevent method.