SAP Commerce Cloud ( 電商雲 ) 路由路徑的自定義配置與開發

這是Jerry 2021年的第 24 篇文章，也是汪子熙公眾號總共第 295 篇原創文章。

最近看到 SAP天天事公眾號釋出的一篇文章：

基於 SAP Commerce Cloud，老孃舅構建的餐飲行業業務中臺成功啟用

老孃舅餐飲股份有限公司建立於1998年，目前位列中國餐飲百強第45位，是中國快餐十大品牌之一。
他們總結行業特色，對比解決方案，經過兩年左右的產品選型和行業競品參考，在對 SAP Commerce 產品管理的靈活性、渠道支援的多樣性、訂單處理的及時性和系統執行穩定性等多方面進行充分評估後，老孃舅最終選擇了電商領域的領先產品套件 SAP Commerce Cloud 作為全渠道業務中臺。

本文就從 SAP Commerce Cloud ( 電商雲 ) 前臺路由路徑的自定義配置與開發的一個實際例子，來加深大家對其靈活性的認識。

Jerry 文章裡介紹的 SAP Commerce Cloud UI，如無特殊說明，預設均為基於 SAP Spartacus 的新一代單頁面 UI，而非傳統的 JSP UI.

在 SAP Commerce Cloud 標準的 UI 裡，我們在產品列表頁面選擇某個產品，點選進入明細頁面：

在這裡插入圖片描述

從產品列表頁面跳轉到產品明細頁面，是透過 Angular 標準的 Router 元件實現的。

下圖產品明細頁面的 url：

http://localhost:4202/electro...

很明顯，這個產品明細頁面的 url，由下列三個片段拼接而成：

靜態的字串 product
動態引數 358639, 即產品 ID
動態引數 DSC-N1，即產品名稱

產品 ID 和產品名稱維護在 SAP Commerce Cloud Backoffice 裡：

SAP Commerce Cloud UI 的頁面預設路由即 url 格式，透過 Spartacus 介面 RoutesConfig 來定義：

上圖第35行的 paths 陣列裡包含的內容，即產品明細頁面 ( 我們開發團隊習慣簡稱為 PDP - Product Detail Page ) 的路由 url 模板。其中 :productCode 是一個佔位符，執行時會被 36 行指定的引數對映陣列( paramsMapping )裡指定的 code，即 SAP Commerce Cloud 後臺 Product 模型裡的 code 欄位的值取代。

之所以引入引數對映的機制，而不直接將 Product 模型欄位 code 加入到 url 模板裡，是為了讓 url 模板語義上更加清晰，達到自描述的效果。因為 code 這個單詞比較通用，到底指 Product code，還是指 Product category code 呢？而在 url 模板裡使用表述更加精確的 productCode，再將其對映到 Product 模型的 code 欄位，這樣避免了可能產生的歧義。

當我們另外開啟一個名稱比較長的產品時，發現此時 url 的顯示效果有些不盡如人意——產品名稱中的空格，被 encode 處理成了 %20:

http://localhost:4202/electro...

因此本文借這個例子，介紹如何透過簡單的二次開發，來更改 SAP Commerce Cloud ( 電商雲 ) 裡產品明細頁面 url 的顯示格式。

假設我們需要實現如下需求：

將產品名稱中包含的空格，替換成連線號 "-" , 並顯示在 url 裡。
在 url 裡顯示產品的製造商資訊，即 Product 模型的 manufacturer 欄位。

具體實現步驟如下：

新建一個 Angular module，使用 Spartacus 提供的工具方法，ConfigModule.withConfig, 定義一條新的路由配置，鍵為 product，其值會覆蓋掉 Spartacus 釋出的同名預設路由配置：

第31行的 url 模板，包含了靜態字串 manufacturer, 其後緊跟 Product 模型上的同名欄位，表明該產品的製造商名稱，這樣就實現了需求2.

而對於需求1即產品名稱的空格替換為"-", 最常規的思路是，在產品資料從 SAP Commerce Cloud 後臺返回前臺之後，找一個可以編寫自定義邏輯的鉤子函式 ( hook ) 進行實現。

Jerry 之前的文章 Jerry在2020 SAP全球技術大會的分享：SAP Spartacus技術介紹的文字版 有這樣一張圖：

從 Commerce 系統讀取產品主資料，讀取的欄位列表以 url 引數的形式出現在 API endpoint裡。這些欄位列表可以在 Connector 的靜態配置點裡進行配置：

Connector 並不會直接同 Commerce 互動，而是把請求轉發給 Adapter，具體通訊由 Adapter 完成，Connector 只負責排程 Adapter.

Connector 將 Adapter 取回的資料交給 NgRx 的 store 結構統一管理，後者的複雜度被 Facade 層所隱藏，而 Spartacus UI 元件只會同 Facade 層互動，進行資料繫結和頁面展示。這體現了關注點分離的設計原則。因為 Commerce UI 元件和 Commerce 後臺元件的資料模型存在差異，因此需要 Converter ( 有時也稱 Normalizer )，在資料從 Commerce 取回，準備呈現在 UI 之前，先要透過 Converter 轉換成適合 UI 展示的結構。

因此我建立了一個 ProductNameNormalizer，繼承自Converter，實現其 convert 方法，在裡面將 Product 模型的 name 欄位，用正規表示式將包含的所有空格字元，替換成 "-".

上圖第9行，我沒有將替換後的結果值，儲存到 Product 模型的 name 欄位裡，而是引入了一個新的 nameForUrl 欄位，以避免影響其他可能同樣基於該 name 欄位的二次開發。

這個新引入的僅僅用於展示在瀏覽器位址列裡的欄位，在很多 SAP 產品裡都有廣泛的應用，稱呼也各不相同。然而它們都有著同樣的特徵：

*沒有後臺持久化儲存，純粹用於UI顯示

為了彌補後臺模型和 UI 模型欄位差異而引入
其值通常都是動態計算而成

典型的一個例子是，後臺儲存了員工的出生年月，而 UI 顯示的欄位是年齡，那麼 UI 模型裡引入一個年齡欄位，其值為當前年月減去員工出生年月。

在 SAP CRM 裡，這種執行時根據某種規則，動態填充其值，供 UI 顯示的欄位，叫做 Calculated Field:

在 SAP CRM AET (Application Extension Tool) 裡，Key User 可以透過簡單的規則編輯器，維護 Calculated Field 的計算邏輯。當然，這些規則儲存後，會編譯生成對應的 ABAP 程式碼。

而到了 SAP Cloud for Customer 裡，除了同樣支援 SAP CRM Calculated Field 的規則編輯功能之外，還提供了兩種允許二次開發人員，透過程式設計來填充用於 UI 臨時顯示欄位值的方式：

Transient Field

在 SAP Cloud for Customer BO 定義程式碼裡，使用註解 Transient，將一個欄位標註成 Transient 欄位：

然後其值透過編寫 AfterLoading 這個 hook 來填充。

Dedicated Field

在 SAP C4C UI Designer 裡將欄位型別設定為 Dedicated Field，然後給其分配一個 Transformation，該 Transformation 由二次開發人員用 ABSL ( ABAP Scripting Language ) 實現，負責計算 Dedicated Field 的值。

回到本文介紹的 SAP Commerce Cloud UI 二次開發的例子。我的 Calculated Field，nameForUrl 的值，直接透過 ProductNameNormalizer 實現的 convert 方法填充。

至此這個需求的開發步驟已經結束。最後，將存放了把空格替換成 "-" 的 nameForUrl 欄位(下圖綠色高亮)，對映到產品明細頁面 url 模板 (下圖紅色高亮) 即可。

最後的效果：

現在的 url：

http://localhost:4204/electro...

是不是比之前的 url，可讀性要好一些？

http://localhost:4202/electro...

感謝閱讀。

SAP Commerce Cloud ( 電商雲 ) 路由路徑的自定義配置與開發

更多閱讀

相關文章