Author and Publish Architectural Overview author-and-publish-architectural-overview

This page highlights the following topics:

  • Introduction to Publish Servers
  • Architectural Overview
  • Registration Process

Prerequisites prerequisites

Before you begin with author servers and publish servers, you should have prior knowledge of:

  • AEM Topology
  • Creating and Managing AEM Screens Project
  • Device Registration Process
NOTE
This AEM Screens functionality is only available if you have installed AEM 6.4 Screens Feature Pack 2. To get access to this Feature Pack, contact Adobe Support and request access. After you have permission, download it from Package Share.

Introduction introduction

AEM Screens architecture resembles traditional AEM Sites architecture. Content is authored on an AEM author instance and then forward-replicated to multiple publish instances. Devices on AEM Screens can now connect to an AEM publish farm by way of a load balancer. Multiple AEM publish instances can be added to continue to scale the publish farm.

For example, an AEM Screens Content Author issues a command on the authoring system for a particular device. That device is configured to interact with a publish farm. Or, interact with an AEM Screens Content Author that obtains information about devices that are configured to interact with publish farms.

The following diagram illustrates both the author environment and the publishing environment.

screen_shot_2019-03-04at30236pm

Architectural Design architectural-design

There are five architectural components facilitating this solution:

  • Replicating content from author to publish for display by devices

  • Reverse replicating binary content from the publishing environment (received from devices) to the authoring environment.

  • Sending commands from the author to publish by way of specific REST APIs.

  • Messaging between publish instances to synchronize device information updates and commands.

  • Polling by the author of publish instances to obtain device information by way of specific REST APIs.

Replication (Forward) of Content and Configurations replication-forward-of-content-and-configurations

Standard replication agents are used to replicate AEM Screens channel content, location configurations, and device configurations. This functionality lets authors update the content of a channel and optionally go through some sort of approval workflow before publishing channel updates. A replication agent must be created for each publish instance in the publish farm.

The following diagram illustrates the replication process:

screen_shot_2019-03-04at33935pm

NOTE
A replication agent must be created for each publish instance in the publish farm.

Screens Replication Agents and Commands screens-replication-agents-and-commands

Custom Screens specific replication agents are created to send commands from the Author instance to the AEM Screens device. The AEM Publish instances serve as an intermediary to forward these commands to the device.

This workflow allows authors to continue to manage the device such as, send device updates and take screenshots from the author environment. The AEM Screens replication agents have a custom transport configuration, like standard replication agents.

Messaging between Publish Instances messaging-between-publish-instances

Often a command is only meant to be sent to a device a single time. However, in a load-balanced publish architecture, the publish instance the device is connecting to is unknown.

Therefore, the author instance sends the message to all Publish instances. However, only a single message should then be relayed to the device. To ensure correct messaging, communication must take place between publish instances. This communication is achieved using Apache ActiveMQ Artemis. Each publish instance is placed in a loosely coupled Topology using the Oak-based Sling discovery service. ActiveMQ is configured so that each publish instance can communicate and create a single message queue. The AEM Screens device polls the AEM publish farm by way of the load balancer and picks up the command from the top of the queue.

Reverse Replication reverse-replication

Often, following a command, some sort of response is expected from the Screens device to be forwarded to the Author instance. To achieve this AEM Reverse replication is used.

  • Create a reverse replication agent for each publish instance, akin to the standard replication agents and the AEM Screens replication agents.
  • A workflow launcher configuration listens for nodes modified on the AEM publish instance and in turn triggers a workflow to place the Device’s response in the AEM publish instance’s outbox.
  • A reverse replication in this context is only used for binary data (such as log files and screenshots) provided by the devices. Polling of non-binary data is retrieved.
  • Reverse replication poll from the AEM author instance retrieves the response and saves it to the author instance.

Polling of Publish Instances polling-of-publish-instances

The author instances must be able to poll the devices to get a heartbeat and know the health status of a connected device.

Devices ping the load balancer and get routed to a publish instance. The status of the device is then exposed by the AEM publish instance through a Publish API served @ api/screens-dcc/devices/static for all active devices and api/screens-dcc/devices/<device_id>/status.json for a single device.

The author instance polls all publish instances and merges the device status responses into a single status. The scheduled job that polls on author is com.adobe.cq.screens.impl.jobs.DistributedDevicesStatiUpdateJob and can be configured based on a cron expression.

Registration registration

Registration continues to originate on the AEM author instance. AEM Screens device is pointed to the author instance and registration is completed.

After a device is registered on the AEM author environment, the device configuration and channel/schedule assignments are replicated to the AEM publish instances. The AEM Screens Device configuration is then updated to point to the load balancer in front of the AEM publish farm. This arrangement is intended to be a one-time setup. After the Screens device is successfully connected to the publish environment, it can continue to receive commands originating from the author environment. There should be no need to connect the AEM Screens device to the AEM author environment directly.

screen_shot_2019-02-25at15218pm

The Next Steps the-next-steps

When you understand the architectural design of author and publish setup in AEM Screens, see Configuring Author and Publish for AEM Screens for more details.

recommendation-more-help
adce462a-f916-4dbe-9ab5-0b62cfb0f053