段階的なヘッドレスロールアウト

Storefront Reference Architecture (SFRA) および SiteGenesis のユーザーは、ヘッドレステクノロジーを段階的にロールアウトできるようになりました。たとえば、PWA Kit を使用して商品ページに印象的な新しい体験を提供できると同時に、次の段階でヘッドレスに移行するまでの間は注文手続きフローを SFRA に残しておくことが可能です。この段階的なアプローチにより、ヘッドレスへの移行をすばやく開始し、業務の中断を最小限に抑えることができます。

このガイドでは、セッションブリッジとルーティングルールを使用して、PWA Kit で 1 つのページセットを、SFRA でもう 1 つのページセットを活用し、シームレスなユーザー体験を提供できるようにする方法について説明します。

段階的なヘッドレスでの Einstein Activities の使用の詳細については、段階的なヘッドレスロールアウトのための Einstein Activitiesを参照してください。

買い物客が異なるストアフロントアーキテクチャで構成されたページ間をシームレスに移動できるようにするには、セッションブリッジと呼ばれる手法を使用する必要があります。セッションブリッジでは、Cookie を使用して、異なるシステム間で買い物客のリフレッシュトークンやセッショントークンを共有します。

セッションブリッジを活用するための鍵となるのは、HTTP リクエストでアクセスできる認証および承認のための新しい標準ベースのソリューション、Shopper Login and API Access Service (SLAS) です。SLAS による買い物客認証は OpenID Connect を、Commerce Cloud の買い物客 API の認証は OAuth 2 をそれぞれベースにしています。

買い物客がヘッドレスストアフロントを閲覧するとき、SLAS を使ってアクセストークンとリフレッシュトークンをリクエストし、買い物客のブラウザーにクッキーとして保存します。クッキーの設定は、HTTP set-cookie ヘッダー、またはクライアント側の JavaScript で行えます。買い物客が SFRA ページから PWA Kit ページに (またはその逆に) 遷移する際、リフレッシュトークンを含むクッキーが HTTP リクエストとともに送信され、ストアフロントコードはリフレッシュトークンを使用してユーザーをログインさせることができます。

プラグイン SLAS は、B2C Commerce セッション (dwsid に関連付けられている) および SLAS セッション (access_token に関連付けられている) を管理します。セッションブリッジは、dwsid と access_token を同じ買い物客セッションにリンクします。

プラグイン SLAS は、2 種類のセッションブリッジメソッドを使用します。

1. SLAS セッションブリッジ (API: getSessionBridgeAccessToken)
   • プラグイン SLAS によって新しいゲストログインのみに使用されます。
   • セッションブリッジ後に新しい dwsid を生成しないため、ストアフロントは再レンダリングを必要とせず、200 OK 応答を送信できます。
2. OCAPI セッションブリッジ (API: Obtain OCAPI Session)
   • プラグイン SLAS によって登録済み買い物客のログインとリフレッシュトークンのログインに使用されます。
   • セッションブリッジ後に新しい dwsid を生成するため、ストアフロントには更新が必要であり、302 リダイレクト応答を送信する必要があります。

段階的なヘッドレスロールアウトを作成する際の最初のステップは、PWA Kit アプリケーションで SLAS が使用されるように設定することです (未設定の場合)。API アクセスの設定のガイドの指示に従ってください。

SFRA で段階的なヘッドレスロールアウトを行えるようにするには、プラグイン SLAS カートリッジをインストールする必要があります。完全なインストールの手順は、カートリッジの README に記載されています。

SLAS カートリッジユーザーに対する重要な考慮事項

プラグイン SLAS カートリッジはさまざまな API に対して複数の呼び出しを行うため、ストアフロントのパフォーマンスに影響を与える可能性があります。本番のストアフロントにカートリッジを追加する前に、カートリッジを使用した場合と使用しない場合のストアフロントのパフォーマンスを比較して、適切かどうかを判断してください。

カートリッジは、次の条件下でもリダイレクトを行います。

• 買い物客がまだセッション Cookie を持っていないとき
• 買い物客のセッション Cookie の有効期限が切れたとき
• 検索エンジンがサイトのインデックスを作成しているとき

現在、カートリッジは認証情報が Salesforce 内に保存されている B2C Commerce システムへの直接ログインのみを置き換えます。

ほしい物リストのプラグインと一緒に使用すると、登録ユーザーのログイン時にゲストのほしい物リストは転送されません。

カートリッジを使用する前に、GitHub の問題に関するページを確認してください。

プラグイン SLAS カートリッジは SFRA 用に設計されているため、SiteGenesis で使用するには追加のコードを作成する必要があります。SiteGenesis の実装では、買い物客の認証と承認のフローにおけるさまざまな時点で、カートリッジのコードを活用できます。

SLAS の API 呼び出しには B2C Commerce Web サービスフレームワークを使用するため、SiteGenesis の実装により、カートリッジで実装した Web サービスに対してリクエストを行えます。これらの Web サービスには、ゲストログイン、登録顧客ログイン、トークンリフレッシュ、ログアウト、ゲスト買い物カゴのマージが含まれます。また、このカートリッジは、API セッションとストアフロントセッションをマージするサービスを実装しています。

SiteGenesis の実装では、カスタムフック (app.plugin.slas.login) を使用して、SLAS によるゲストユーザーおよび登録ユーザーのログインを実装することもできます。カートリッジの onSession フックにあるカスタムコードを dw.system.request.onSession で調べると、買い物客のログイン用に Script API を SLAS に置き換えていることがわかります。

PWA Kit でセッションブリッジを行えるようにするには、API の認可を処理する commerce-api/auth.js のコードに変更を加えて、ローカルストレージの代わりに Cookie を使用するようにします。

PWA Kit プロジェクトが Retail React App テンプレートのバージョン 2.7.x で生成された場合は、auth.js のこのコード行のコメントを解除して、CookieStorage に切り替えてトークンを保管できます。これは、SFRA サイトと PWA Kit サイト間のセッションを管理するために必要です。

買い物客のログイン後に、セッションブリッジ API を呼び出す commerce-api/auth.js のコードも変更する必要があります。これを行うには、auth.js のこのコード行のコメントを解除する必要があります。

作業を簡単に行えるように、すべての変更を反映した代替バージョンのファイルを作成し、GitHub の 公開 gist から入手できるようにしてあります。

PWA Kit プロジェクトが Retail React App テンプレートのバージョン 3.0.0 以降を使用して生成された場合、上記の変更はデフォルトで有効になり、それ以上のコード変更は必要ありません。

認可フローはリフレッシュトークンから始まります。リフレッシュトークン Cookie を利用できる場合、PWA Kit アプリはリフレッシュトークンをアクセストークンと交換します。それ以外の場合は、アプリは OAuth 2.1 標準で定義されているように、認可コード付与フローを開始します。また、PKCE (Proof Key for Code Exchange) のフローにも従います。

新しいアクセストークンと新しいリフレッシュトークンが SLAS から付与されると、アプリはそれらを Cookie に保存します。次に、アプリは OCAPI の create session (セッション作成) エンドポイント (/session) に POST リクエストを行います。このエンドポイントは、SFRA で使用されるセッションを作成します。アプリは、セッショントークンを Cookie に保存します。

PWA Kit アプリで作成される Cookie は次のとおりです。

• cc-nx-g - SLAS ゲスト買い物客リフレッシュトークン
• cc-nx - SLAS 登録済み買い物客リフレッシュトークン
• token - SLAS アクセストークン
• dwsid - Demandware セッション ID

段階的なロールアウト中にシームレスなユーザー体験を確保するには、Managed Runtime 環境と B2C Commerce インスタンスという 2 つの異なるオリジンにトラフィックをルーティングする方法が必要です。このトラフィックルーティングは、コンテンツ配信ネットワーク (CDN) によって処理できます。

次のようなシナリオを考えてみましょう。

www.mystorefront.com で運用されている既存の SFRA ストアフロントがあります。ユーザーはヘッドレスアーキテクチャのメリットを把握しており、PWA Kit を活用してパフォーマンスに優れた魅力的な体験を提供したいと考えています。同時に、スケジュールに対するリスクを最小限に抑えるため、PWA Kit のストアフロントを展開するための段階的なアプローチを選択するとします。

ファネルの最上部でページリクエストを PWA Kit に送信するように CDN を構成します (ホームページ (/)、カテゴリ一覧ページ (/category)、商品詳細ページ (/product))。これらの PWA Kit ページは、mystorefront.mobify-storefront.com上で運用されている Managed Runtime 環境にデプロイされます。買い物客が購入を決定すると、CDN は買い物客を www.mystorefront.com で実行されている既存の SFRA 注文手続きページにリダイレクトします。

トラフィックルーティングを処理するには、Salesforce の埋め込み CDN (eCDN) ソリューション (および Cloudflare を利用) を選択するか、別のベンダーの CDN を選択できます。

eCDN を使用してトラフィックを Managed Runtime にルーティングするには、Commerce API エンドポイント createMrtRules を使用します。

この API は、Cloudflare のルール式 を使用して Managed Runtime へのトラフィックのルーティングをサポートします。これはルール言語で利用可能なフィールドのサブセットをサポートします。以下のフィールドがサポートされます。

• http.host - ホスト名と照合する
• http.request.uri.path - リクエストパスと照合する
• http.request.uri - リクエストパスとクエリ文字列の両方と照合する
• http.cookie - Cookie と照合する

プロキシゾーンでは、インスタンスごとに 100 の個別ルールをリクエストでき、レガシーゾーンでは開発/本番インスタンス間で共有される合計 100 個の個別ルールをリクエストできます。

• eCDN は、本番インスタンスと開発インスタンスでのみ使用でき、サンドボックスや ODS インスタンスでは使用できません。
• ステージングインスタンスは、eCDN API を使用して eCDN にオンボードする必要があります。詳細については、B2C Commerce Infocenter の Staging (ステージング) のための eCDN の構成 および Rhino Inquisitor ブログのこちらの記事を参照してください。
• eCDN は位置情報に基づくルーティングはサポートしていません。

オリジンルールの設計に役立てるため、PWA Kit ページのルートを網羅的に収集します。Retail React App テンプレートをベースとした PWA Kit プロジェクトの場合、ルートは app/routes.jsx に記載されています。PWA Kit のサーバー側レンダリングシステムはプロキシと静的アセットに内部ルートを使用するため、ルーティングルールに /mobify/* も含める必要があります。

この例のシナリオでは、以下のルートを CDN に構成する必要があります。

リスト上のすべての PWA Kit ルートを含むオリジンルールを構築し、リクエストを Managed Runtime 環境 (シナリオ例では mystorefront.mobify-storefront.com) に転送します。

次の図は、先に説明したシナリオ例の eCDN 構成を示しています。

デフォルトでは、PWA Kit プロジェクト用の Retail React App テンプレートは、SFRA とは異なる URL ルーティングパターンをもちます。たとえば、Retail React App の商品詳細ページの URL パスは、/products/{productId} です。SFRA の場合、パターンは /{categoryId}/{productId} です。

PWA Kit のストアフロントで、SFRA サイトに合わせてルーティングパターンを変更することをお勧めします。特定のページの URL パターンと一致しない場合 (カテゴリ ID が URL にない場合の商品一覧ページなど)、リダイレクトカートリッジを使って、ギャップを埋めるリダイレクトを設定できます。完全なインストールの手順は、カートリッジの README に記載されています。

段階的なヘッドレスロールアウトのための設定プロセスを完了するには、PWA Kit プロジェクトにさらにいくつかの変更を加える必要があります。

デフォルトでは、PWA Kit はナビゲーションに History API を使用します。買い物客が React Router の <Link> コンポーネントで作成されたリンクをクリックすると、app/routes.jsx で定義されたルートオブジェクトのパスと一致するコンポーネントへのソフトナビゲーションがトリガーされます。PWA Kit 以外のページ (たとえば SFRA によるページ) にリンクするには、app/routes.jsx の URL パス名と一致するルートをすべて削除する必要があります。

たとえば、PWA Kit プロジェクトが、Retail React App テンプレートのバージョン 2.7.x または version 3.x で拡張機能を使用せずに生成された場合は、routes 配列から checkout を削除します。

PWA Kit プロジェクトが、拡張機能を使用して Retail React App テンプレートの バージョン 3.x で生成された場合、overrides/app/routes.jsx ファイルを上書きして、JavaScript を使用して非 PWA Kit ページへのリンクを除外できます。 /cart と /checkout のルートを除外するためのすべての変更を加えた overrides/app/routes.jsx ファイルの上書き例を作成し GitHub の 公開 gistから入手できるようにしてあります。

最後に、app/routes.jsx の PWA キャッチオールルート (/*) を更新します。PWA <PageNotFound /> コンポーネントをデフォルトのオリジンのリダイレクトに置き換えます。

PIG インスタンスの場合、お客様は eCDN を使用して、SFRA (または SG) と MRT オリジンの間でトラフィックを「分割」できます。ただし、eCDN は SIG インスタンスと ODS をサポートしていません。段階的なロールアウトのサイトを SIG インスタンス上でローカルに設定してテストするには、お客様独自のリバースプロキシまたは CDN を使用してトラフィックを分割する必要があります。

PWA Kit と SFRA/SiteGenesis にわたるハイブリッド展開の買い物客フローの開発とテストに使用できるサンプル Node.js アプリを作成しました。 リバースプロキシの設定と構成手順については、リポジトリの README に記載されています。

また、SIG インスタンスで段階的なロールアウトを設定する手順を紹介するデモビデオをまとめました。

本番構成と同様のエイリアス構成を使用するように ODS を構成すると、ローカル設定と本番設定を同一に保つことができます。たとえば、ハイブリッドサイトが / URI で利用できるようにサンドボックスを構成すると、pwa-kit によって送信される URL を、サイト ID を含めるために変換する必要がなくなります。これが通常の本番サイトの構成方法です。

Business Manager でエイリアスを有効にするには、Trailhead の Salesforce B2C Commerce ホスト名エイリアスのモジュールの手順に従ってください。

PWA Kit のルート構成を構成して、すべての発信 URL (たとえば SFRA 向けのもの) に接頭辞 /s/SiteID を含めることができます。これにより、ホスト名のエイリアスを明示的に構成する必要がなく、インスタンスはサンドボックスで通常使用される方法でコントローラー URL を受信できるようになります。これは本番環境の構成には適切ではないこともあるため、本番デプロイとサンドボックスデプロイでは異なるキャッチオールルートが必要になる場合があることにご注意ください。

ルートの接頭辞を構成するには、app/routes.jsxまたは overrides/app/routes.jsx の PWA キャッチオールルート (/*) を更新します。