In AEM, there are different ways to release your content to your audience. Technically, this refers to transferring (copying) the according content from your AEM authoring instance to the publishing instances to make it accessible. In AEM language, this process is usually referred to as either publication, activation or replication, see also this terminology.

If you just want to learn about the two different AEM features to schedule the publication of your content, please jump directly to Publish later.

Technical background of publication

In “classic” AEM 6.5, publication usually means feeding the content into the queue of all active replication agents which will serialize the data (using a data format called “Durbo“) and push them to the publishing instances. This is briefly outlined in the documentation of DataStore Garbage Collection:

When data is being replicated to Publish [instances], it is first gathered in collections in an efficient data format called “Durbo” and stored in the repository under /var/replication/data. The data bundles are often larger than the critical size threshold for the data store and therefore wind up stored as data store records.

For AEM as a Cloud Service, publication is handled through Sling Content Distribution as outlined in the official documentation. While the underlying technique is different, the overall logic and process is similar.

Apart from these standard approaches, there are variations or alternatives available. One common example is binary-less replication. With this setup, only references and meta data are replicated. The actual data is stored in a datastore that is shared between all AEM instances. For more details, please see the documentation of the deprecated Asset Offloading feature, this blog post or this slide deck.

Publishing immediately

The most common method of publication is to immediately push your content to the public once you are done with content authoring (and content QA, sometimes approval workflows or similar). This can be done via the publication wizard in AEM or through the Quick Publish action which will include any referenced items (such as assets).

One important detail is that you need to have according replication permissions to actually publish content. If you are lacking permissions, the system will still allow you to trigger the action but will not immediately publish the content. Instead, a “Request for activation” workflow is started. For most projects, this workflow should be customized to meet the desired behavior.

Publish later

If you are aiming to publish your content at a specific point in time, AEM comes with two features that can help you:

  1. On-/Off-Times in the page properties
  2. Managed Publications

While the underlying business use case is very similar, there are some differences in the behavior of the features.

On-/Off-Times

This feature can be set in the page properties of a specific page. It “hides” the according page from the resource resolution process on the publishing side. That means, the page is “physically” present in the content tree on the publish instance but will not be exposed through resource resolution. This allows to time the public availability of the page very precisely without relying on replication queues. Relying on replication could cause delayed publication due to busy processing queues. In addition, the On-/Off-Time feature does not invalidate the cache. In case of e. g. a product launch where you want to have the content available at a very specific point in time (product presentation) and even a delay of a couple of minutes might be an issue, On-/Off-Times would be the right feature to use. Also if you are expecting high traffic at the same time (because your clients want to learn about the launched product immediately), this feature avoids cache invalidation and additional load on your publishing instances. Please note: if the content needs to be referenced, e. g. be listed in the navigation or referenced through a teaser on another page, you would have to take care that these parts of the content are invalidated in the dispatcher cache by yourself. On-/Off-Times do not handle this for you.

Managed Publications

The Managed Publications feature on the other hand is triggering a “real” (de-) activation of the page. That means the article is not present on the publish side and publication is triggered through a workflow on the author instance at the specified point in time. This implies cache invalidation as a result of the replication and you can rely on standard behavior, e. g. for references (teasers, navigation, etc.) to the page. As mentioned above, with this feature it is not 100% precise when the content will be publicly available. If the replication queue is busy (e. g. due to a lot of content being scheduled for the same time or general high publication volumes at that time), it might take some time (seconds or minutes, depending on the level of replication activity) until the page is actually publicly available on your publishing instances.

Which feature to use?

That’s totally up to your business requirements and use cases. For most cases, Managed Publications will probably be the better fit as it uses well-known AEM behavior similar to “regular”, meaning manual publications. The On-/Off-Times feature is more interesting if precisely timed public (un-) availability of your content is key or if you want to avoid broad cache invalidation for the publication time.

Additional Resources