1. Experience Edge

Experience Edgeへの公開

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

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

Sitecoreでウェブサイトを作成する際は、コンテンツ管理システム(CMS)でさまざまな種類のコンテンツ項目を作成します。これらのアイテムはウェブページ、サイトレイアウト、ナビゲーション、その他の要素としてSitecore Experience Edge公開されます。あなたはExperience Edgeからコンテンツを消費するヘッドアプリケーションを使ってウェブサイトをレンダリングします。

以下の図は出版パイプラインを示しています:

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

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

出版を管理する ワークフロー の導入を強くお勧めします。手動出版に頼ると、未完成のコンテンツを誤って公開してしまう可能性があります。以下のセクションでは、依存関係が意図せずアイテムを公開することがあり、ワークフローを実装することでそれを防ぐ方法について説明します。

ワークフローを使えば、以下のようなことができます:

  • どのコンテンツをEdgeに公開するかを管理し、準備ができた時だけ公開するようにしましょう。

  • コンテンツレビューのプロセスを管理します。

コンテンツの選択

Sitecoreは公開するコンテンツを選択するためのいくつかのオプションを提供しています。それぞれの選択肢は、出版パイプラインとそのパフォーマンスに異なる影響を与えます。

単一項目出版

単一項目の出版にはSmartとRepublishの2種類があります。

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

  • Republish - アイテムおよびその依存関係は常に公開されます。

注記

公開時には必ずRelated itemsチェックボックスを選択し、関連するすべての項目が適切に更新されていることを推奨します。もし無効にすると、関連コンテンツがスキップされ、矛盾が生じたり部分的な公開ができてしまう可能性があります。

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

すべての項目の公開

Content EditorのPublish Siteオプションを選択することで、すべてのアイテムを公開できます。その場合、利用可能な出版方法は3種類あります。

  • Incremental publish - 変更されたアイテムを、アイテムの変更履歴に基づいて公開します。これは変更されたすべてのアイテムを公開する最も効率的な方法であり、Content EditorリボンのPublishメニューからサイト全体を公開する場合にのみ利用可能です。

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

  • Republish - コンテンツツリー内のすべてのアイテムを再公開する。この作業は他の出版形態よりも高価で時間もかかります。

出版パイプライン

パブリッシングパイプラインは、パブリッシング操作を完了する複雑で多段階のプロセスです。Experience Edgeの文脈では、パイプラインは主に3つのコンポーネントと相互作用します。

  • Sitecore パブリッシング– 公開対象のルートアイテムと適用された公開方法に基づいて、公開対象アイテムの初期キューを設定します。

  • Experience Edgeコネクタ ー – Sitecore CMのアイテムをExperience Edgeエンティティに変換します。Experience Edgeからメタデータを受け取り、エンティティを送信し、確認応答を受け取ります。

  • レイアウトサービス – レイアウトを持つアイテムのJSONを生成します。 これは選ばれた出版の種類によって異なります:

    • Snapshot publishing (v1) - JSONをExperience Edge上で単一のエンティティとして保存する。

    • Edge Runtime publishing(v2) - 主要な構造構造レイアウトを保存し、各データソースへの別々の参照を持ちます。

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

単一のSitecoreアイテムは複数のExperience Edgeエンティティに変換可能です。例えば、アイテムにレイアウトがある場合、Experience Edgeにはitemエンティティとlayoutエンティティの両方が生成されます。

依存関係の定義

アイテムがEdgeに公開されると、その依存関係が計算されます。公開されるアイテムによっては、多数の依存関係が存在する場合があります。例えば、単純なページ項目は含まれるすべてのデータソースに依存しています。もう一つの例はテンプレート項目です。テンプレートから継承するサイト内のすべてのアイテムはテンプレートに依存しています。テンプレートが変更された場合、その依存するすべての項目を再公開する必要があります。

一部のSXAコンポーネントは、ページレイアウトで使用する際に依存関係を生み出します:

  • 部分的なデザイン - 部分的なデザインを使うページはその依存関係です。

  • ウィジェット - ウィジェットを使用しているページはすべてその依存関係です。

  • 出版グループ - 出版グループ内のすべての項目は互いに依存しています。

依存関係の計算と解決

アイテムを公開すると、システムはEdgeとマスターデータベースにクエリを送り、そのアイテムに依存している他のアイテムをすべて検索し、それらを公開パイプラインに追加します。これらのアイテムが公開されるため、新しいアイテムに依存するすべてのアイテムも公開されます。依存関係として特定された項目は、変更の有無にかかわらず出版物に含まれます。このプロセスは、新たな出版可能な項目が見つからなくなるまで繰り返されます。

依存関係はアイテムレベルで計算されるため、どの変更がアイテムを公開させるのかを特定することはできません。例えば、ナビゲーションでページのデータソース項目を変更することができます。ページはデータソース項目に依存し、ナビゲーションコンポーネントによってレンダリングされるため、ナビゲーションコンポーネントを含むページは再公開されます。

注記

依存関係解決プロセスはワークフローを実装する主な理由の一つです。あるユーザーが変更を加えることで、別のユーザーが作業中のページが公開される可能性があります。ドラフトと公開のステータスからなるシンプルな2ステップのワークフローでも、ウェブサイトが完成したコンテンツのみを表示するのに十分です。

Edgeランタイムパブリッシングの利点

SitecoreAI顧客はEdgeランタイムパブリッシング(v2)を利用することを選択できます。この公開方法を選ぶと、データソースの項目が公開された際に、それに依存している項目の公開はトリガーされません。これにより、大量のアイテムが連鎖的に公開される可能性がなくなります。レイアウトは公開時ではなく、配信時(ランタイム)に組み立てられ、公開速度が向上しますが、初期納品の遅延が伴います。

スマートパブリッシュは依存関係を計算する前に、どの項目をパブリッシュするかを決定します。Edgeのランタイムパブリッシングとスマートパブリッシュを組み合わせることで、変更されていないアイテムや依存関係をスキップできます。

注記

コンテンツリゾルバ はEdgeのランタイムパブリッシングではサポートされていません。

以下は、どの公開メカニズムがあなたの実装に最適かを判断するための比較表です:

機能

スナップショット(v1)

Edgeランタイムパブリッシング(v2)

コメント

出版時期

基準速度。

より速く、通常は公開される項目数が少なくなります。

Edgeランタイムパブリッシングは、公開アイテムの数を減らすことでパブリッシングを最適化します。

発行された団体

すべての依存関係です。

レイアウトのみ、またはデータソースのみ。

Edgeランタイムはより選択的でオーバーヘッドを削減できますが、コンテンツの欠落を避けるために慎重な依存関係管理が必要になる場合があります。

統合GraphQL

公開時点で計算。再出版後にリフレッシュされただけです。

ランタイム時にEdgeから動的にフェッチされるため、使用されるすべての場所でリアルタイムで正しくレンダリングされます。

しかし、統合されたGraphQLを含む多数のコンポーネントや、複数クエリやネストされたクエリを含む統合GraphQLクエリは、実行時にページパフォーマンスの問題を引き起こす可能性があるため、避けることを推奨します。

動的フェッチは統合GraphQLクエリを正しくレンダリングするのに非常に適していますが、統合GraphQLを重度または複雑な使用を行う場合、実行時のパフォーマンスリスクが生じます。モニタリングと最適化が鍵となります。

キャッシュクリア後の最初の応答

もっと速く。

もっとゆっくり。Vercelのようなフロントエンドホスティングアプリケーションでは、静的サイト生成(SSG)を使用している場合、ビルドタイムアウトがより頻繁に発生することがあります。Edgeランタイムパブリッシングと組み合わせたオンデマンドのインクリメンタル静的再生(ISR)を使用することを推奨しており、これにより常にコンテンツが提供されます。

Edgeのランタイムは、特に静的なホスティング環境では初期段階で遅くなることがあります。ISRを使うことで、特に頻繁にコンテンツが更新されるウェブサイトではこれを緩和できます。

コンテンツリゾルバ

サポートされています。

サポートされていません。

 

削除

親項目の子項目(サブアイテム)を公開する際、公開パイプラインはEdge上の子項目とCMSバックエンドの子項目を比較します。Edgeに存在する項目がCMSに欠けているか、制限により公開対象でない場合、その項目とその子項目はEdgeから削除されます。

自動削除は、インクリメンタルパブリッシュを実行する際にもトリガーされることがあります。これは変更履歴に依存しており、CMSからの削除記録も含まれます。インクリメンタル出版は、Content EditorリボンのPublishメニューで利用可能です。

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