オーサーとパブリッシュのアーキテクチャの概要 author-and-publish-architectural-overview
このページでは、以下のトピックについて重点的に説明します。
- パブリッシュサーバーについて
- アーキテクチャの概要
- 登録プロセス
前提条件 prerequisites
オーサーサーバーとパブリッシュサーバーの使用を開始する前に、以下に関する事前の知識が必要です。
- AEM トポロジ
- AEM Screens プロジェクトの作成と管理
- デバイス登録プロセス
はじめに introduction
AEM Screens のアーキテクチャは、従来の AEM Sites のアーキテクチャに似ています。コンテンツは AEM オーサーインスタンスで作成された後、複数のパブリッシュインスタンスにフォワードレプリケートされます。AEM Screens でのデバイスは、ロードバランサーで AEM パブリッシュファームに接続できるようになりました。複数の AEM パブリッシュンスタンスを追加して、パブリッシュファームの拡大／縮小を続行できます。
例： AEM Screens のコンテンツ作成者は、特定のデバイスのオーサリングシステムでコマンドを発行します。そのデバイスは、パブリッシュファームと対話するように設定されています。または、パブリッシュファームと対話するように設定されているデバイスに関する情報を取得する AEM Screens コンテンツ作成者と対話します。
次の図に、オーサー環境とパブリッシュ環境の両方を示します。
アーキテクチャ設計 architectural-design
このソリューションを容易にする次の 5 つのアーキテクチャコンポーネントがあります。
-
デバイス別にオーサーからパブリッシュにディスプレイの コンテンツをレプリケート
-
バイナリコンテンツをパブリッシュ環境（デバイスから受信）からオーサリング環境にレプリケートする リバース
-
特定の REST API を介してオーサーからパブリッシュにコマンドを 送信。
-
デバイス情報の更新とコマンドを同期させるためのパブリッシュインスタンス間の メッセージング。
-
特定の REST API を介してデバイス情報を取得するためにパブリッシュインスタンスの作成者によって行われる ポーリング。
コンテンツと設定のレプリケーション（フォワード） replication-forward-of-content-and-configurations
標準レプリケーションエージェントは、AEM Screens チャネルコンテンツ、場所設定、デバイス設定のレプリケーションに使用します。この機能により、作成者は、チャネルのコンテンツを更新し、必要に応じて何らかの承認ワークフローを経てから、チャネルの更新内容を公開できます。レプリケーションエージェントは、パブリッシュファームのパブリッシュインスタンスごとに作成する必要があります。
レプリケーションプロセスの例を次の図に示します。
Screens レプリケーションエージェントとコマンド screens-replication-agents-and-commands
オーサーインスタンスから AEM Screens デバイスにコマンドを送信するには、Screens 固有のカスタムレプリケーションエージェントを作成します。AEM パブリッシュインスタンスは、これらのコマンドをデバイスに転送する仲介役となります。
このワークフローにより、作成者はオーサー環境からデバイスの管理（デバイス更新の送信やスクリーンショットの取得など）を続けることができます。AEM Screens レプリケーションエージェントには、標準レプリケーションエージェントなどのカスタムトランスポート設定があります。
パブリッシュインスタンス間のメッセージング messaging-between-publish-instances
多くの場合、コマンドは 1 回だけデバイスに送信するために使用されます。ただし、負荷分散型のパブリッシュアーキテクチャでは、デバイスの接続先がどのパブリッシュインスタンスであるかは不明です。
したがって、オーサーインスタンスはすべてのパブリッシュインスタンスにメッセージを送信します。ただし、デバイスに転送されるメッセージは 1 つだけです。適切なメッセージングを確実に行うために、パブリッシュインスタンス間で通信が必要になります。この通信には、Apache ActiveMQ Artemis が使用されます。各パブリッシュインスタンスは、Oak ベースの Sling 検出サービスを使用して、疎結合トポロジに配置されます。ActiveMQ は、各パブリッシュインスタンスが通信し、単一のメッセージキューを作成できるように設定されています。AEM Screens デバイスは、ロードバランサーを使用して AEM パブリッシュファームをポーリングし、キューの先頭からコマンドを取得します。
リバースレプリケーション reverse-replication
多くの場合、コマンドに従って、Screens デバイスから何らかの応答がオーサーインスタンスに転送されます。これを実現するために、AEM リバースレプリケーション が使用されます。
- 標準レプリケーションエージェントや AEM Screens レプリケーションエージェントと同様に、パブリッシュインスタンスごとにリバースレプリケーションエージェントを作成します。
- ワークフローランチャー設定は、AEM パブリッシュインスタンスで変更されたノードをリッスンし、次にワークフローをトリガーして、デバイスの応答を AEM パブリッシュインスタンスのアウトボックスに格納します。
- このコンテキストでは、リバースレプリケーションは、デバイスから提供されるバイナリデータ（ログファイルやスクリーンショットなど）にのみ使用されます。非バイナリデータのポーリングが取得されます。
- AEM オーサーインスタンスからのリバースレプリケーションポーリングが応答を取得して、オーサーインスタンスに保存します。
パブリッシュインスタンスのポーリング polling-of-publish-instances
オーサーインスタンスは、デバイスをポーリングしてハートビートを取得し、接続されたデバイスのヘルスステータスを把握する必要があります。
デバイスはロードバランサーに ping を送信し、パブリッシュインスタンスにルーティングされます。次に、提供されるパブリッシュ API（すべてのアクティブデバイスの場合は api/screens-dcc/devices/static、単一デバイスの場合は api/screens-dcc/devices/<device_id>/status.json）を通じて、AEM パブリッシュインスタンスがデバイスのステータスを公開します。
オーサーインスタンスは、すべてのパブリッシュインスタンスをポーリングし、デバイスのステータス応答を 1 つのステータスに結合します。オーサー上でポーリングするスケジュール済みは com.adobe.cq.screens.impl.jobs.DistributedDevicesStatiUpdateJob で、Cron 形式に基づいて設定できます。
登録 registration
登録は AEM オーサーインスタンスで継続的に開始されます。AEM Screens デバイスがこのオーサーインスタンスを指すように設定され、登録が完了します。
デバイスが AEM オーサー環境に登録されると、デバイス設定とチャネル／スケジュールの割り当てが AEM パブリッシュインスタンスにレプリケートされます。次に、AEM Screens デバイス設定が、AEM パブリッシュファームの前面にあるロードバランサーを指すように更新されます。これは 1 回限りの設定です。Screens デバイスがパブリッシュ環境に正常に接続されると、オーサー環境からのコマンドを引き続き受信できます。AEM Screens デバイスを AEM オーサー環境に直接接続する必要はありません。
次の手順 the-next-steps
AEM Screens におけるオーサーとパブリッシュのセットアップについて詳しくは、AEM Screens でのオーサーとパブリッシュの設定を参照してください。