サーバー側の Web 階層キャッシング

Commerce Cloud アプリケーション層コンポーネントの 1 つは、SCAPI リクエストの Web 階層キャッシングを実行します。これは、さまざまな API ファミリーへの GET リクエストに影響を与えます。

このサーバー側のキャッシングメカニズムは、リクエストが Commerce Cloud のサーバー側アプリケーション層に到達した後でのみ使用されます。別のキャッシングメカニズムが設置されている場合は (たとえば、クライアント側)、そのメカニズムは引き続き独立して使用されます。ストアフロント実装のフロントエンドまたはクライアント側で複数のキャッシング層を扱う場合は、これを考慮する必要があります。

次の API の GET リクエストに対するレスポンスはキャッシュされます。

• /product/shopper-products/v1/organizations/{org-id}/categories/{id}
• /product/shopper-products/v1/organizations/{org-id}/categories

• /product/shopper-products/v1/organizations/{org-id}/products/{id}
• /product/shopper-products/v1/organizations/{org-id}/products

• /search/shopper-search/v1/organizations/{org-id}/product-search

• /search/shopper-search/v1/organizations/{org-id}/search-suggestions

• /pricing/shopper-promotions/v1/organizations/{org-id}/promotions/campaigns

• /pricing/shopper-promotions/v1/organizations/{org-id}/promotions/campaigns

• /site/shopper-seo/v1/organizations/{org-id}/url-mapping

• /configuration/preferences/v1/organizations/{org-id}/site-custom-preferences?{siteId}

• /configuration/preferences/v1/organizations/{org-id}/global-custom-preferences

動的コンテンツのページキャッシュは、特定のサイトで有効にする必要があります。

これを行うには、Business Manager で、管理 > サイト > サイトの管理 > サイト名 - キャッシュの順に移動し、その後「ページキャッシングを有効にする」を選択します。

キャッシュエントリの有効期間、ならびにレスポンスがパーソナライズされるかどうかは、API、または API および選択された展開に利用可能な展開があるかどうかによって決まります。たとえば、availability (入手可能性) の展開が選択された状態で Product API に対してリクエストが行われた場合、キャッシュエントリはデフォルトで 60 秒のみ保存されます。

API に展開がある場合、すべての展開の中で最短の TTL により、キャッシュエントリの有効期間が決まります。リクエストされた展開の少なくとも 1 つが「パーソナライズ済み」としてマークされていない場合、レスポンス全体はパーソナライズされていないとみなされます。

リソースに対してパーソナライゼーションが有効になっている場合、URL 文字列に加えて、次の情報がキャッシュキーの一部になります。

• アクティブなプロモーションの完全なセット。
• アクティブな商品の並べ替えルールの完全なセット。
• 適用可能な価格表の完全なセット。
• アクティブな A/B テストグループの完全なセット。

キャッシュはさまざまなレスポンスのバリエーションをキャッシュに保存し、この追加情報に基づいて正しいバージョンを API ユーザーに配信します。

2 人の買い物客が同じ商品 API (つまり、同じ URL) にアクセスする場合を考えてみましょう。この場合、買い物客 A はプロモーション X の対象となり、買い物客 B はプロモーション Y の対象となります。同じ商品 (URL は変更なし) が 2 回キャッシュされます。その後、プロモーション X の買い物客全員に、プロモーション Y の買い物客と同じキャッシュエントリが提供されます。このシナリオでは、価格表とプロモーションの数によっては、商品の価格にかかわらず、キャッシュエントリの数が大幅に増加する可能性があります。

新しいリクエストの場合、Web 階層はまず、指定されたリクエストのキャッシュエントリが存在するかどうかをチェックします。キャッシュキーは、フックのカスタマイズが呼び出される前に計算され、フック内で後で発生する可能性のある変更は含まれません。したがって、該当する価格表やプロモーションなどのパーソナライゼーショ関連リソースの変更は、常に Shopper Context API を使用して適用し、必要な価格表とプロモーションが Web 階層キャッシュで考慮されるようにする必要があります。

同様に、レスポンスボディの更新の可能性 (カスタム属性の追加など) は、キャッシュキー内では考慮されません。条件付きフックロジックのみにより、2 つの同一のリクエスト (URL とクエリ文字列) が異なるレスポンスを生成することが想定されている場合、Web 階層はそのようなリクエストを同一と見なし、キャッシュされたレスポンスを返します。Web 階層キャッシュが正しく動作するようにするには、カスタムクエリパラメーターを URL に追加することをお勧めします。

以下に例を示します。

B2C Commerce 24.8 では、Shopper Products (買い物客の商品) の getProductエンドポイントと getCategory エンドポイント、および Campaigns (キャンペーン) の getCampaignエンドポイントに対して、「有効期間」と呼ばれる期間を設定できます。有効性は、古くなったコンテンツが提供されないようにするために、サーバー側のキャッシュの有効期限について考慮されます。有効期間を定義する属性は、Valid From と Valid To です。その他のリソースタイプについては、デフォルトのキャッシュ有効期限が適用されます。

サーバー側のキャッシュの有効期限は、Valid From 属性と Valid To 属性の日付と時刻の値が定義されており、デフォルトのキャッシュの有効期限より前に有効になる場合は、それらの日付と時刻の値を反映するように調整されます。それ以外の場合は、デフォルトの有効期限が適用されます。

複数の SKU など、複数のリソース識別子を含むリクエストの場合、キャッシュの有効期限を計算する際にすべての有効期間が考慮されます。最も早い有効日によって、レスポンスのキャッシュの有効期限が決まります。

たとえば、1 つの商品 SKU を使用するリクエストは、デフォルトで 24 時間キャッシュされているとします (追加の展開はありません。上の表を参照)。デフォルトのキャッシュ有効期限よりも早い Valid To 時間が商品に割り当てられていると仮定すると、キャッシュの有効期限は、より短い Valid To 時間を反映するように再計算されます。

Valid From 時間を使用して商品の発売を将来の日付に設定すると、HTTP 404 レスポンスコードが返されます。HTTP 404 レスポンスも、それぞれの Valid From 値を反映したキャッシュの有効期限を使用してキャッシュされます。その時点でキャッシュの有効期限が切れると、ストアフロントで買い物客が商品を閲覧できるようになります。

Script API には、キャッシュ設定をプログラムで制御するためのオプションが用意されています。

Script API の dw.system.Response#setExpires(milliseconds) メソッドを使用すると、任意のキャッシュ有効期限のタイムスタンプを設定できます。このメソッドはミリ秒単位のタイムスタンプを受け入れるため、現在のタイムスタンプと必要な「TTL (有効期間)」の合計をパラメーターとして渡す必要があります。

たとえば、カテゴリ API のレスポンスを 1 日ではなく 1 時間のみキャッシュする場合は、次のカスタムコードを使用できます。

キャッシュの TTL は 1 秒以上である必要があり、86,400 秒を超えることはできません。

Script API の dw.system.Response#setVaryBy(String varyBy) メソッドは、指定されたバリアント識別子を使用してレスポンスをパーソナライズ済みとしてマークします。price_promotion のみがサポートされており、他の値は無効です。

デフォルトでは、prices (価格) の展開と promotions (プロモーション) の展開を使用した商品呼び出し、および prices (価格) の展開を使用した商品検索呼び出しはパーソナライズれています。

現時点では、キャッシュを手動で無効にする方法は 1 つだけで、サイトのページキャッシュ全体を無効にすることです。

Business Manager で、管理 > サイト > サイトの管理 > サイト名 - キャッシュ の順に移動し、キャッシュタブを選択します。「キャッシュの無効化」セクションに、サイトのページキャッシュを無効にするボタンがあります。無効化がトリガーされると、SCAPI レスポンスに関連するキャッシュを含む、サイトのページキャッシュ全体が 15 分以内にクリアされます。

新しいサーバー側のキャッシュを導入すると、キャッシュされたエンドポイントのレスポンスは常に Cache-Control ヘッダー値の no-cache, no-store, must-revalidate を返します。特にパーソナライズする場合は、SCAPI と Script Controller API の均一な動作を保証するために必要です。