1. Experience Edgeコネクタ

Experience Edgeへの公開

Version:
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

SitecoreでWebサイトを作成すると、さまざまなタイプのコンテンツ アイテムが作成されます。これらのアイテムは、Webページ、サイト レイアウト、ナビゲーション、およびその他の要素としてSitecore Experience Edgeに公開されます。Webサイトをレンダリングするには、Edgeからコンテンツを消費する軽量のJSSフロントエンドを使用します。

次の図は、発行パイプラインを示しています。

A diagram showing the publishing pipeline in Sitecore XM and XM Cloud.

ベストプラクティス:ワークフロー

公開を制御する ワークフロー を実装することを強くお勧めします。手動での公開に頼っていると、準備が整う前に誤ってコンテンツを公開する可能性があります。次のセクションでは、依存関係によってアイテムが意図せずに発行される原因となること、およびワークフローを実装することでこれを防ぐ方法について説明します。

ワークフローを使用すると、次のことができます。

  • Edgeに公開するコンテンツを制御し、準備ができたときにのみ公開されるようにします。

  • コンテンツレビューのフローを設定します。

コンテンツの選択

Sitecoreには、公開するコンテンツを選択するためのオプションがいくつか用意されています。各オプションは、発行パイプラインとそのパフォーマンスに対して異なる影響を与えます。

単一アイテムの発行

単一アイテムの公開には、RepublishSmartの2つのタイプがあります。

  • Republish - アイテムは常に公開されます。

  • Smart publish - 各アイテムにはリビジョンIDがあり、デフォルトでは、そのアイテムへの変更が保存されるたびに更新されます。 Smart publishを使用すると、Sitecoreはコンテンツ管理インスタンスのアイテムのリビジョンIDをEdgeの同じアイテム アイテムのリビジョンIDと比較します。両方のリビジョンIDが同じ場合、アイテムは公開されません。

さらに、アイテムのすべてのサブアイテム (子) を公開するように選択することもできます。

すべてのアイテムの公開

すべてのアイテムを公開するには、コンテンツ エディターでPublish Siteオプションを選択します。その際、次の3種類のパブリッシングを使用できます。

  • Incremental publish - アイテムに加えられた変更の履歴に基づいて、変更されたアイテムを公開します。これは通常、変更されたすべてのアイテムを公開する最も効率的な方法です。

  • Smart publish - 各アイテムのリビジョンIDに基づいて、変更されたアイテムを公開します。このタイプの公開では、保存された変更のリストではなく、アイテム ツリー全体がスキャンされるため、時間がかかる場合があります。

  • Republish - コンテンツ ツリー内のすべてのアイテムを再公開します。

発行パイプライン

発行パイプラインの主な目的は、発行用に選択されたコンテンツ管理 (CM) アイテムをEdgeエンティティに変換することです。アイテムが正常に受信され、公開されたことをEdgeから確認した後、CMは公開済みアイテム カウンターを更新します。発行パイプラインは、CMインスタンスから発行できるコンテンツの正確なスナップショットを作成するために、次のタスクを実行します。

  • 公開する追加のエンティティの計算

  • 依存関係の計算

  • 依存関係の解決

  • 古いコンテンツまたは期限切れのコンテンツを削除する

追加エンティティの計算

公開されたすべてのコンテンツアイテムは、Experience Edgeのitemエンティティと見なされ、パスまたはアイテムIDを使用してGraphQL APIで使用できます 。追加のアイテムタイプが使用可能な場合があります。

  • Media - 追加のメディア固有のプロパティ。

  • Site - SXAサイト固有のプロパティ、およびサイトマップ。

  • Page - ページレイアウト。

  • Template and Field - テンプレートまたはフィールド固有のプロパティ。

依存関係の計算

アイテムがEdgeに公開されると、そのアイテムの依存関係が計算されます。これらの依存関係は、公開されたエンティティにクエリ可能なメタデータとして格納されます。公開されるアイテムによっては、多数の依存関係が存在する可能性があります。たとえば、単純なページ項目は、含まれるすべてのデータ ソースに依存します。別の例はテンプレートアイテムです。テンプレートから継承するサイト内のすべてのアイテムは、テンプレートの依存関係です。

また、一部のSXAコンポーネントは、ページ レイアウトで使用すると依存関係を作成します。

  • Partial designs - パーシャルデザインを使用しているページは、パーシャルデザインに依存しています。

  • Widget - ウィジェットを使用するページは、ウィジェットの依存関係です。

メモ

単一アイテムの公開中、ローカル データ ソース アイテムの先祖アイテムもデフォルトでEdgeに公開されるため、公開が遅くなる可能性があります。先祖の収集を無効にするには、ExperienceEdge.IncludeDependencyAncestors設定をfalseに設定するパッチ ファイルを作成します。この設定は \App_Config\Modules\ExperienceEdgeConnector\ExperienceEdgeConnector.configファイルにあります。

依存関係の解決

アイテムを公開すると、システムはEdgeにクエリを実行して、そのアイテムに依存する他のすべてのアイテムを検索し、それらを公開パイプラインに追加します。これらのアイテムは公開されるため、新しいアイテムに依存するすべてのアイテムも公開されます。依存関係として識別されたアイテムは、変更されたかどうかに関係なく、パブリケーションに含まれます。このプロセスは、新しい発行可能なアイテムが見つからないまで繰り返されます。

依存関係は、アイテムレベルで計算されます。たとえば、ナビゲーションでページのデータ ソース アイテムを変更できます。ページはデータ ソース アイテムに依存し、ナビゲーション コンポーネントによってレンダリングされるため、ナビゲーション コンポーネントを含むすべてのページを再パブリッシュする必要があります。現時点では、アイテムが再発行される原因となる変更を特定することはできません。

依存関係の解決プロセスは、ワークフローを実装する主な理由の1つです: あるユーザーが変更を加えると、別のユーザーが作業しているページが公開される可能性があります。 DraftステータスとPublishステータスで構成される単純な2ステップのワークフローでも、Webサイトに完了したコンテンツのみが表示されるようにするには十分です。

Smart publish依存関係を計算する前に公開するアイテムを決定します。これにより、何も変更されていない場合に項目とその依存関係をスキップできます。

削除

親アイテム (サブアイテム) の子を公開する場合、公開パイプラインはEdgeの子アイテムとCMのアイテムを比較します。CMにないアイテムがEdgeで見つかった場合、そのアイテムとその子はEdgeから削除されます。自動削除は、CMでの削除を含む変更履歴に依存するため、増分発行の実行時にもトリガーできます。

この記事を改善するための提案がある場合は、 お知らせください!