分階段無頭式部署
Storefront Reference Architecture (SFRA) 及 SiteGenesis 的使用者現在可以分階段推出無頭技術。例如，您可以使用 PWA Kit 為產品頁面部署全新的體驗，但讓結帳流程繼續使用 SFRA，直到踏入轉往無頭式架構的下一階段。這種分階段的方法可以協助您更快開始，並將邁向無頭式架構之路上的阻礙降至最低。
這份指南將說明如何使用工作階段橋接和路由規則，來讓 PWA Kit 推動一組頁面，並讓 SFRA 推動另一組頁面，實現順暢無縫的使用者體驗。
這份指南中的指示將說明如何結合 PWA Kit 和 SFRA 流程，但相同的指示也適用於 SiteGenesis。
要讓購物者能順暢無縫地在不同網店架構驅動的頁面之間瀏覽，需要使用一種稱為「工作階段橋接」的技術。工作階段橋接會使用 Cookie，在不同系統之間共用購物者的重新整理權杖和工作階段權杖。
解鎖工作階段橋接的關鍵就在於 Shopper Login and API Access Service (SLAS)，這是一種新的標準式驗證、授權解決方案，可透過 HTTP 要求進行存取。SLAS 的購物者驗證採用 OpenID Connect，而 Commerce Cloud 的 Shopper API 授權則採用 OAuth 2。
當購物者瀏覽無頭式網店時，您使用 SLAS 來要求存取權杖和重新整理權杖，並將它們作為 Cookie 儲存在購物者的瀏覽器中。您可以使用 HTTP set-cookie 標頭或用戶端 JavaScript 來設定 Cookie。當購物者從 SFRA 頁面轉換到 PWA Kit 頁面 (反之亦然) 時，包含重新整理權杖的 Cookie 將會和 HTTP 要求一起傳送，而網店程式碼可使用重新整理權杖來讓使用者登入。
分階段無頭式部署的第一步是設定您的 PWA Kit 應用程式來使用 SLAS (若尚未執行)。請依照我們的設定 API 存取指南中的指示進行。
若要啟用 SFRA 的分階段無頭式部署，您必須安裝 SLAS 外掛程式插件。插件的 README 中提供了完整的安裝說明。
除了工作階段橋接之外，SLAS 外掛程式插件還允許您實作其他便利於購物者的功能，像是 90 天使用者工作階段和購物車保留。
因為 SLAS 外掛程式插件是專為 SFRA 設計的，您必須編寫額外的程式碼，才能將其用於 SiteGenesis。SiteGenesis 實作可以在購物者驗證和授權流程中的各個點，利用插件中的程式碼。
因為插件使用 B2C Commerce Web 服務架構來處理 SLAS API 呼叫，所以 SiteGenesis 實作可以對插件實作的 Web 服務提出要求。這些 Web 服務包括訪客登入、已註冊客戶登入、權杖重新整理、登出、合併訪客購物車。插件也實作了一項服務來合併 API 工作階段和網店工作階段。
SiteGenesis 實作也可以使用自訂 Hook (app.plugin.slas.login) 來實現讓訪客和已註冊使用者以 SLAS 登入。檢查 dw.system.request.onSession 中插件的 onSession Hook 裡的自訂程式碼，看看它如何用 SLAS 取代 Script API 來進行購物者登入。
若要使用 PWA Kit 進行工作階段橋接，您必須修改 commerce-api/auth.js 中處理 API 授權的程式碼，以便使用 Cookie 而不是本機儲存。
如果您的 PWA Kit 專案是使用 1.5.0 或以上版本的 Retail React App 範本產生，您可以在 auth.js 中取消註解這行程式碼，無需對檔案進行其他變更。
對於以 1.5.0 之前版本產生的專案，您必須對 commerce-api/auth.js 進行幾項變更。為了節省您的時間，我們建立了一個包含所有變更的檔案替代版本，可在 GitHub 上的公開 gist 取得。
授權流程從重新整理權杖開始。若重新整理權杖 Cookie 可用，則 PWA Kit 應用程式會將重新整理權杖交換為存取權杖。否則，應用程式會根據 OAuth 2 標準的定義，開始授權代碼授予流程。也會遵循 Proof Key for Code Exchange (PKCE) 流程。
當 SLAS 授予新的存取權杖和新的重新整理權杖時，應用程式會將它們儲存在 Cookie 中。接著，應用程式會向 OCAPI 的建立工作階段端點 (/session) 提出 POST 要求。此端點會建立一個由 SFRA 使用的工作階段。應用程式將此工作階段權杖儲存在 Cookie 中。
由 PWA Kit 應用程式建立的 Cookie：
cc-nx-g- SLAS 訪客購物者重新整理權杖cc-nx- SLAS 已註冊購物者重新整理權杖token- SLAS 存取權杖dwsid- Demandware 工作階段 ID
下圖說明了 PWA Kit 修改後的授權流程：
分階段無頭式部署的另一個重要層面是路由。為了將流量提供給兩個不同的系統，我們需要設定 CDN 以將流量路由到兩個不同的來源：Managed Runtime 環境和您的 B2C Commerce 執行個體。
想像以下情境：
您有一個在 www.mystorefront.com 上運作的現有 SFRA 網店。您知曉無頭式架構的好處，想要利用 PWA Kit 來提供高效能又吸引人的體驗。同時，您也想降低時程的風險，因此您計畫以分階段的方式推出 PWA Kit 網店。
您的計畫是為漏斗最上方的頁面使用 PWA Kit：首頁 (/)、類別清單頁面 (/category)、產品詳細資料頁面 (/product)。這些 PWA Kit 頁面部署到 mystorefront.mobify-storefront.com 上運作的 Managed Runtime 環境。當購物者決定購買時，您將購物者重新導向到在 www.mystorefront.com 上運作的現有 SFRA 結帳頁面。
如果您是嵌入式 CDN (eCDN) 的客戶，請聯絡支援人員來設定您的路由規則。
現在可以為指向 Managed Runtime 環境 (mystorefront.mobify-storefront.com) 的 PWA Kit 頁面新增一個來源到 CDN 區域了。
接著，建立路由規則來根據 URL 路徑提供流量。請先收集 PWA Kit 頁面的完整路由清單。對於根據 Retail React App 範本建立的 PWA Kit 專案，其路由列在 app/routes.jsx 中。由於 PWA Kit 的伺服器端轉譯系統使用內部路由來處理 Proxy 和靜態資產，因此您還必須在路由規則中包含 /mobify/*。
在我們的範例情境中，下列路由必須在您的 CDN 中設定：
為清單上每一個 PWA Kit 路由設定您的 CDN，以將要求轉送至 Managed Runtime 環境 (即我們範例情境中的 mystorefront.mobify-storefront.com)。
下圖顯示如何設定您的 CDN：
根據預設，PWA Kit 專案的 Retail React App 範本具有與 SFRA 不同的 URL 路由模式。例如，Retail React App 中產品詳細資料頁面的 URL 路徑為 /products/{productId}，而 SFRA 的模式則是 /{categoryId}/{productId}。
我們建議您變更 PWA Kit 網店中的路由模式，來符合 SFRA 網站。若您無法符合特定頁面 (像是當類別 ID 在 URL 中不可用時的產品清單頁面) 的 URL 模式，您可以使用 Redirect Cartridge 來設定縮小差距的重新導向。插件的 README 中提供了完整的安裝說明。
若要完成分階段無頭式部署的設定過程，您必須再對 PWA Kit 專案進行幾項變更。
根據預設，PWA Kit 使用 History API 來進行瀏覽。當購物者點擊使用 React Router 的 <Link> 元件所建立的連結時，它會觸發軟性導覽，連至與 app/routes.jsx 中定義的路由物件路徑相符的元件。若要連結至非 PWA Kit 頁面 (例如由 SFRA 驅動的頁面)，您必須從 app/routes.jsx 中移除與 URL 路徑名稱相符的所有路由。
舉例來說：從路由陣列中移除結帳。
最後，在 app/routes.jsx 中更新 PWA 全部擷取 (catch-all) 路由 (/*)。將 PWA <PageNotFound /> 元件替換為連至預設來源的重新導向。