這是Jerry 2021年的第 24 篇文章，也是汪子熙公衆号總共第 295 篇原創文章。
最近看到 SAP天天事 公衆号釋出的一篇文章：
基于 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/electronics-spa/en/USD/product/358639/DSC-N1
很明顯，這個産品明細頁面的 url，由下列三個片段拼接而成：
靜态的字元串 product
動态參數 358639, 即産品 ID
動态參數 DSC-N1，即産品名稱
産品 ID 和産品名稱維護在 SAP Commerce Cloud Backoffice 裡：
上圖第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/electronics-spa/en/USD/product/23355/Flagship%20tripod%20with%20remote%20control%20and%20pan%20handle
是以本文借這個例子，介紹如何通過簡單的二次開發，來更改 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 字段：
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/electronics-spa/en/USD/manufacturer/Sony/productname/flagship-tripod-with-remote-control-and-pan-handle/productcode/23355
是不是比之前的 url，可讀性要好一些？