Experience Edgeへの公開

単一項目出版

単一アイテムの公開には スマート と 再出版の2種類があります。

• スマートパブリッシュ - 各アイテムにはリビジョンIDがあり、そのアイテムの変更が保存されるたびにデフォルトで更新されます。 スマート パブリッシュでは、Sitecoreがコンテンツ管理インスタンスのリビジョンIDとEdge内の同じアイテムのリビジョンIDを比較します。両方のリビジョンIDが同じなら、そのアイテムは公開されません。
• 再公開 - アイテムとその依存関係は常に公開されます。

!注公開時には必ず関連項目のチェックボックスを選択し、関連項目が適切に更新されていることを確認してください。これをオフにすると関連コンテンツがスキップされ、矛盾や部分的な公開が発生する可能性があります。

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

すべての項目の公開

コンテンツエディターの 「公開サイト 」オプションを選択することで、すべてのアイテムを公開できます。その場合、利用可能な公開の種類は3つあります:

• インクリメンタルパブリッシュ - 変更履歴に基づいて変更されたアイテムを公開します。これはすべての変更されたアイテムを公開する最も効率的な方法であり、コンテンツエディタのリボンの 公開 メニューからサイト全体を公開する場合のみ利用可能です。
• スマートパブリッシュ - 各アイテムのリビジョンIDに基づいて変更されたアイテムを公開します。このタイプのパブリッシングは、保存された変更リストではなくアイテムツリー全体をスキャンするため、時間がかかることがあります。
• 再公開 - コンテンツツリー内のすべての項目を再公開します。この操作は他の公開タイプよりもコストが高く時間もかかります。

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

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

依存関係の定義

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

ページレイアウトで使用すると依存関係を生み出すコンポーネントもあります:

• 部分的なデザイン - 部分的なデザインを使うページはその依存関係です。
• 出版グループ - 出版グループ内のすべての項目は互いに依存しています。

依存関係の計算と解決

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

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

ExperienceEdge.ComputeContentDependencies設定は、公開プロセス中にサポートされているリンクおよびリストフィールドタイプで参照されるアイテムの依存関係が計算されるかどうかを制御します。この設定はデフォルトで無効化されています。有効化すると、参照されたアイテムは依存関係として保存されるため、変更された参照項目を公開すると依存項目も再公開できます。この設定を有効または無効にした後は、サイトを再公開し、Experience Edge内のすべてのアイテムの依存関係データを再計算する必要があります。この設定は環境変数(Sitecore_ExperienceEdge_dot_ComputeContentDependencies)を使って設定することも可能です。

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

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

SitecoreAIの顧客はEdgeランタイム公開を選択できます。 この公開方法を選択すると、データソースのアイテムが公開された際にそれに依存しているアイテムの公開がトリガーされません。これにより、膨大な数のアイテムの連鎖公開がなくなります。レイアウトは公開時ではなく配信時(ランタイム)に組み立てられ、公開速度は向上しますが、初期配信は遅くなります。

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

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

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

機能

スナップショット

エッジランタイムパブリッシング

コメント

出版時期

基準速度。

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

エッジランタイムの公開は、公開アイテムの数を減らすことで公開を最適化します。

発行された団体

すべての依存関係です。

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

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

統合GraphQL

公開時に計算。再掲載後のみ更新。

Edgeは実行時に動的にフェッチされ、使用されるすべての場所でリアルタイムで正しくレンダリングされます。ただし、統合されたGraphQLを含む多数のコンポーネントや、複数または入れ子状のクエリを含む統合GraphQLクエリは、実行時にページパフォーマンスの問題を引き起こす可能性があるため避けることを推奨します。

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

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

もっと速く。

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

エッジの実行時間は、特に静的ホスティング環境では初期に遅くなることがあります。ISRを使うことで、特に頻繁にコンテンツ更新が行われるウェブサイトではこの問題を緩和できます。

コンテンツリゾルバ

サポートされています。

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

削除

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

また、CMSからの削除記録を含む変更履歴に依存するため、インクリメンタル公開を実行する際に自動削除がトリガーされることがあります。インクリメンタル公開はコンテンツエディターのリボンにある 「公開 」メニューで利用可能です。