AEM as a Cloud Service Publish Process / Blogs / Perficient

Publish process is driven by cloud architecture. Unlike AEM on-premise or on Adobe Managed Services (AMS), AEM as a Cloud Service (AEMaaCS) uses a containerized architecture that drives changes in how publishing works. The containers AEM runs within are transient and are being created and destroyed to meet current demand. An image of AEM is created with each container which contains any deployed code. Content such as pages and digital assets are persisted outside of those containers and accessed via the Content Repository Service by all AEM instances. Keeping that content outside those containers has the added benefit of keeping the images smaller so that autoscaling to create new containers is faster.

Mutable and Immutable Content

AEMaaCS distinguishes between Mutable and Immutable content. Immutable content includes /apps and /libs whereas the rest of the repository, including /content, /conf, /var, /etc, /oak:index, /system, /tmp, etc. are considered Mutable. The Immutable content under /apps can only be deployed to AEM via a Cloud Manager Pipeline and becomes part of the image of AEM that is created along with each container. Anything under /libs cannot be changed at all. The Mutable content is what is stored outside of the AEM instances in the common Content Repository Service.

Publishing Mutable Content

Instead of replicating content, Sling Content Distribution is used. Sling Content Distribution uses a pipeline service that runs on Adobe I/O, Adobe’s serverless runtime platform. Publish actions are atomic meaning that when publishing multiple pieces of content, they either all succeed, or all fail. This ensures that there is consistency. When content is published, it is added to a queue to which publish instances subscribe. There is a special publish instance called the Golden Master from which all other publish instances are created and which are not accessed by end users.

Using the Repository Modernizer Tool for a Smooth Migration to AEMaaCS

Configuring Content Distribution

In an author instance, Content Distribution can be configured under Tools -> Deployment by selecting Distribution.

Publish queues for the preview and publish environments will be listed there which can be selected.

Once an environment is selected, the Status of publish queues, Logs, Settings, and a Distribute tab can be selected.

In the Distribute tab, you can Add node, Add tree, or Delete a path selected with a Path Browser to Submit to the publish queues.

Publishing via the Editor or the Sites Console

Publishing while editing a page or in the console when selecting a page works the same as the non-cloud versions of AEM. Publish Page can be selected from the Page Information icon right in the editor. In the console when selecting pages from the tree, either Quick Publish or Manage Publication can be selected to run on the selected pages. As before, Quick Publish immediately does a shallow publish, and Manage Publication allows for more options.

Publishing via Workflow

Besides being able to publish a content tree via Manage Publication in the console, it can also be done via a workflow. Navigate to Tools to find Workflow and select Models to view a workflow model called Publish Content Tree.

This workflow should not be invoked directly. First, make a copy of that workflow, and invoke that copy.

Publishing via Replication API

When there is a need to programmatically publish content, this can be accomplished via the Replication API. This is as simple as getting references to com.day.cq.replication.Replicator and/or com.day.cq.replication.ReplicationStatusProvider via @Reference annotations. For publishing, it’s as simple as calling the replicate method on the Replicator instance and passing a session, the ReplicationActionType, and the path or paths to the content to be published. By default, the content will be published to the publish environment queues. If there is a need to publish to the preview environment instead, a new ReplicationOptions object will need to be created which specifies that the preview agent is to be used. That ReplicationOptions object can be passed to a version of the replicate method on the Replicator object which accepts ReplicationOptions.