オーサーとパブリッシュのアーキテクチャの概要 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 でのオーサーとパブリッシュの設定を参照してください。