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

任何企業級軟體的前端開發，都離不開元件(Component)這個概念。撇開具體的 UI 開發技術不談，所謂元件，就是介面的組成部分(UI Building Blocks). 元件在視覺或者業務功能上，能夠被視為單一元素。

元件可能被構成應用程式的其他元件重用，也可能包含其他元件。理想情況下，一個設計良好的元件，其同其他元件或者外部服務的依賴關係，可以被恰當地隔離，從而能夠單獨對元件進行單元測試甚至自動化測試。

近些年隨著微服務架構浪潮而興起的微前端設計理念，甚至支援同一應用內不同的 UI 元件，採取不同的前端技術進行開發，這些異構的 UI 元件，可以獨立地進行開發，測試，部署和交付，透過統一的微前端容器進行管理，並構成最終由使用者使用的前端程式。

![](https://img-blog.csdnimg.cn/img_convert/4e97f191683e939f25b7962938a81ccb.png)

[Luigi](https://github.com/SAP/luigi) 就是 SAP 推動的一個微前端框架。
![](https://img-blog.csdnimg.cn/img_convert/318644f76b865e67903816492d2668dd.png)
微前端框架的使用已經超出了本文討論的範疇。本文就 SAP 下列四種產品所使用的前端開發框架/工具中包含的元件概念，展開進行介紹。

* SAP CRM / SRM
* SAP S/4HANA
* SAP Cloud for Customer
* SAP Commerce Cloud

本世紀初，隨著企業應用軟體從 Client/Server 模式往 Browser/Server 模式的遷移，SAP CRM 和 SAP SRM 的前端開發技術，也踏上了不同的兩條演進道路：分別基於 SAP WebClient UI 和 ABAP Webdynpro. 關於這兩項技術更多的介紹和 SAP UI 開發技術的演進之路，請參考 Jerry 之前的文章：[SAP UI 和 Salesforce UI 開發漫談](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247484460&idx=1&sn=aafe62ded3bc7b07f4d3da99f3926ab3&chksm=ead5b6bbdda23fad3c4b7e8148d61e4c9a2609f13151a221da1bf313a25f0df37fab8d9ec557&scene=21#wechat_redirect)。

SAP WebClient UI 的前身是 SAP BSP - Business Server Page.WebClient UI 在其基礎上，引入了元件的概念，並且在檢視層增添了對 BSP 擴充套件標籤庫的支援，使得其開發效率大大提高。基於 SAP WebClient UI 的開發方式，至今仍在 SAP S/4HANA Service 模組領域中採用。

一個基於 SAP WebClient UI 的應用，通常由多個元件構成。單個元件的開發，仍然基於傳統的 MVC，其中 Model 層的 Context Node，由 ABAP Class 實現，而 ABAP Webdynpro 中的 Context Node，採取的是 ABAP DDIC 資料欄位中的資料結構。

WebClient UI 元件的檢視層基於 HTML，能重用 SAP 標準 BSP Extension 中提供的 HTML 標籤。絕大多數情況下，應用開發人員無需編寫原生的 HTML 程式碼，這也降低了開發門檻。ABAP Webdynpro 元件檢視層開發，在 SAP 提供的所見即所得的佈局編輯器中進行，開發人員無法使用原生的 HTML 編輯方式開發檢視。

WebClient UI 裡有一類特殊的元件，起著容器的作用，負責將其包含的其他元件的檢視按照使用者配置顯示出來。

下圖是一個例子：SAP CRM 產品概覽頁面，左邊紅色區域，是該容器元件支援的所有元件和元件檢視列表，右邊是當前使用者配置的該容器到底要顯示哪些元件檢視，及這些元件檢視的載入方式：直接載入或者延遲載入。這種從一個支援元件列表裡選擇部分載入的配置方式，在本文後續介紹 SAP Commerce Cloud 元件時會再次提及。

![](https://img-blog.csdnimg.cn/img_convert/d4388452a42490b40efc844ed0819daa.png)
# SAP S/4HANA

前文已經介紹過，SAP S/4HANA Service 模組的 UI，仍然基於 SAP WebClient UI 開發。Service 模組在 SAP 內部簡稱為 S4CRM，官方稱謂為 S/4HANA for Customer Management，詳情參考 Jerry 的文章：[Hello World, S/4HANA for Customer Management 1.0](https://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247484133&idx=1&sn=0ed06fcad9dc896f7f5265b04f692718&chksm=ead5b072dda23964b3549ccfb55050a102961706a417f74d45b4be49714bd40df43b68ddc07f&token=1957261634&lang=zh_CN#rd).

SAP S/4HANA 除了 Service 之外的其他模組，其 UI 透過 SAP Fiori Elements 開發，該框架後臺模型為加上了註解的 SAP CDS view 即暴露給外界消費的 OData 服務，前臺開發框架為 SAP UI5. Component.js 是所有配置到 SAP Fiori Launchpad 中的 SAP UI5 應用的入口。

以 SAP S/4HANA Sales Management Overview 這個 Fiori 應用為例：

![](https://img-blog.csdnimg.cn/img_convert/499d1b68c5615160d1789764f97b0747.png)

和其他所有基於 Fiori Elements 開發的應用一樣，Sales Management Overview 應用工程內僅包含一個 Component.js, 該檔案內宣告瞭對 manifest.json 檔案的引用。其餘在 Freestyle SAP UI5 開發模式下需要應用開發人員編寫的 Controller，View 等資原始檔，在 Fiori Elements 應用裡均被 SAP UI5 框架提供的模板版本所取代。

![](https://img-blog.csdnimg.cn/img_convert/3b14b1ade034a172ead8a28323f8ee2d.png)

在 manifest.json 檔案裡，我們能得到下列這些資訊：

* 該 Fiori 應用消費的 OData 服務名稱，SD_OVP_SM
* 該 Fiori 應用消費的 OData 服務基於的 CDS view 名稱：C_PROFITMARGINBYMONTHQUERY_CDS
* Fiori 應用 ID：F2601

![](https://img-blog.csdnimg.cn/img_convert/d2fbdb56d808edab672b74e2950ded34.png)

有了 F2601 這個 Fiori ID 之後，從 Jerry 文章 SAP Fiori應用索引大全 裡介紹的網站上，根據該 ID，即可查詢到該 Fiori 應用的設計詳情：

![](https://img-blog.csdnimg.cn/img_convert/f3ff481a2d5175e0d216ef51f7e68d54.png)

關於 SAP Fiori Elements 應用 manifest.json 更多的細節介紹，請參考 Jerry 之前的文章：

* [在沒有任何前端開發經驗的基礎上, 建立第一個 SAP Fiori Elements 應用](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247492035&idx=1&sn=8373625310d71b4c8cc73612756a8168&chksm=ead65354dda1da4239a6442c577efee19b826d92b7372d4a551cd7af1957bd82fc002e34c2fe&scene=21#wechat_redirect)
* [答網友提問：使用 SAP Fiori Tools 建立的 Fiori Elements 應用，如何進行二次開發？](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247492113&idx=1&sn=5d004d151e59ac262a15fdf79869934c&chksm=ead65086dda1d99092e784b7937cc23a6641f7692e0048d31412c427e8042fa071a9fe8f4691&scene=21#wechat_redirect)
 
關於 SAP Fiori Elements 開發的更多介紹，可以參考 Jerry 翻譯的 OpenSAP 上的公開課。由於工作繁忙，目前只完成了前四期影片的翻譯工作：

* [OpenSAP Fiori Elements 公開課第一單元：總體介紹](https://www.zhihu.com/zvideo/1391759173034598400)

* [OpenSAP Fiori Elements 公開課第二單元：架構介紹](https://www.zhihu.com/zvideo/1392411571931500544)

* [OpenSAP Fiori Elements 公開課第三單元：OData 服務和註解介紹](https://www.zhihu.com/zvideo/1392532832619847680)

* [OpenSAP Fiori Elements 公開課第四單元：開發環境搭建](https://www.zhihu.com/zvideo/1399442810865504256)

# SAP Cloud for Customer

同 ABAP Webdynpro 一樣，SAP Cloud for Customer 的元件開發，也是在所見即所得的編輯器裡進行，這個編輯器叫做 UI Designer.

如果說 SAP Fiori Elements 是基於 CDS view 以及 OData 服務進行的元件開發，那麼 SAP Cloud for Customer 的元件開發則是基於 Business Object 驅動的。

開發人員使用 SAP Cloud Application Studio 完成 Business Object 模型建立後，可以使用嚮導，一鍵生成針對該 BO 進行增刪改查操作的全套 UI.這些 UI 型別各異, 由不同的元件所實現。

![](https://img-blog.csdnimg.cn/img_convert/4a986dac53c1832924f2eba40f9b070d.png)

開啟任意一個 UI 元件，發現其仍然分為 MVC 三層。其中檢視層，開發人員可以在 Toolbox 皮膚中拖拽合適的 UI 控制元件，以所見即所得的方式設計檢視;

![](https://img-blog.csdnimg.cn/img_convert/015f290ee527d451470e894206e07bd6.png)

在模型層，選擇 C4C 標準的 BO 或者 Partners 二次開發的 BO, 可以完成檢視控制元件欄位同 BO 欄位的資料繫結;

![](https://img-blog.csdnimg.cn/img_convert/dffd2f3cd1e31d16335d9cece36ea3cd.png)

在控制器層面，可以採用非編碼的宣告方式，指定該檢視響應使用者操作之後，應該執行何種業務邏輯。

![](https://img-blog.csdnimg.cn/img_convert/d5c643dbc42ae1cbe0684480084dd24f.png)

由於歷史原因，SAP C4C 使用者訪問入口，並不是像 S/4HANA 那樣採用了 Fiori Launchpad，而是同 SAP CRM 一樣，選擇工作中心(Work Center)作為入口。

使用者被分配的業務角色(Business Role)決定了其能夠訪問的工作中心。C4C 的 UI 元件被新增到工作中心檢視中，後者再被新增到工作中心內，從而被使用者訪問。

![](https://img-blog.csdnimg.cn/img_convert/1578c027a98e3283323063f5dcbcbaa0.png)

![](https://img-blog.csdnimg.cn/img_convert/5991744d2fd7282b756296b41f6a82bd.png)

因為並未透過 Fiori Launchpad, 進行管理，所以 C4C 元件也就不存在 Component.js.  每個 C4C UI 元件本質上是一個 XML 檔案，該檔案儲存在 C4C 後臺一個叫做 X-Repository 的基礎設施上。
![](https://img-blog.csdnimg.cn/img_convert/0fadb3c27561e646e11ec34c70f02511.png)

執行時當所屬的工作中心檢視被訪問時，UI 元件的原始碼從 C4C 後臺載入到瀏覽器，被 SAP UI5 框架解析。後者按照 C4C 特有的檢視格式，根據元件原始碼裡包含的控制元件定義內容，建立對應的 UI5 控制元件例項。這些控制元件例項再使用對應的渲染器，按照文章 [深入學習SAP UI5框架程式碼系列之二：UI5 控制元件的渲染器](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247490725&idx=1&sn=a99eaa85624d62fd9a8d5eb0fe382ace&chksm=ead5ae32dda2272447f691827b4a960dac4188adb9c82f8c29815531ba9a7939530153b00f17&scene=21#wechat_redirect) 裡介紹的邏輯，生成最終的原生 HTML 原始碼。

傳統的 SAP UI5 應用裡，UI5 框架基於 JavaScript 或者 XML 檢視檔案，建立對應的 SAP UI5 控制元件例項。而 C4C 則是基於元件檢視檔案，進行控制元件例項化，這算是 C4C 元件使用 SAP UI5 的獨特之處。

關於 C4C 元件設計的更多細節和其與 SAP UI5 框架互動的深入分析，請參考我的同事 Yang Joey 的文章: [SAP Cloud for Customer 使用 SAP UI5 的獨特之處](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247484704&idx=1&sn=20f898617ce51a28749ef89db5e01cf9&chksm=ead5b7b7dda23ea11c5a2d4d7ff2fd89295de088438af4396a3d55dc7402ab902c2fc8eeb129&scene=21#wechat_redirect)。

# SAP Commerce Cloud

SAP Commerce Cloud UI 作為 Headless Commerce 即無頭電商架構的前端展現層，是一個 100% API 驅動的電商 Storefront：店鋪待顯示的元件列表，透過 API 呼叫的方式從 Commerce Cloud 後臺端的內容管理系統(Content Management System，簡稱 CMS)中獲取，而店鋪具體顯示的檢視效果和與使用者互動的邏輯，由前端基於 Angular 的元件實現。

以 SAP Commerce Cloud UI 開啟後顯示的預設主頁為例，該頁面的 id 為 homepage，其頁面顯示的內容列表，在 SAP Commerce Cloud Backoffice CMS 控制檯中定義。

SAP Commerce Cloud 中一個頁面被劃分成若干個區域，這些區域被所謂的 ContentSlot(內容插槽)來區分，這個名稱很形象——每個內容插槽，允許插入一個或者多個元件。

在 CMS Page 編輯頁面裡，點選 Content Slots 皮膚，定義該頁面由哪些內容插槽組成：
![](https://img-blog.csdnimg.cn/img_convert/e0824337cb1e04710e6b52ba55ac7237.png)
下圖展示了 homepage 由內容插槽 Section1, Section2A，Section2B，Section2C 等區域組成。

![](https://img-blog.csdnimg.cn/img_convert/981f82317330befadedefe3f7cf407a9.png)

一個 Content Slot 可以容納多個元件，下圖展示了 Section1 這個 Content Slot，容納 Electronics Homepage Splash Banner Component 和 Electronics Homepage Splash Discount Component 這兩個元件。

![](https://img-blog.csdnimg.cn/img_convert/cb7f9a142e18b91b8a2af57880f95bcf.png)

大家可以類比前文介紹的 SAP CRM 容器元件，使用者可以指定容器元件內顯示哪些其他元件的檢視，二者的設計思路是一致的。

SAP Commerce Cloud CMS 只負責定義頁面的 Content Slots 資訊和 Content Slots 內包含的元件資訊，而不負責具體的頁面檢視開發以及使用者互動邏輯開發——後者均是由 Jerry 所在的團隊，開發的 SAP Spartacus 這個開源專案裡實現。

每一個在 SAP Commerce Cloud CMS 中定義的元件，在 SAP Spartacus 中都有一個與之一一對應的 Angular 元件。

當在瀏覽器中開啟 SAP Commerce Cloud UI 時，SAP Spartacus 會發起一個 API 呼叫，向 Commerce Cloud 後臺索取該頁面的 CMS 資訊。下圖展示了 homepage 在 CMS 中的建模資訊，透過 API 呼叫的方式返回給 SAP Spartacus：

![](https://img-blog.csdnimg.cn/img_convert/13dee2c5fba555d7929e99c70613f710.png)

其中 Section1 這個 Content Slot 裡包含的兩個 Components 名稱，正是我之前在 Commerce Cloud CMS 裡維護的兩個 Component：

![](https://img-blog.csdnimg.cn/img_convert/f3cbe85f7ec10ce8a794d19be1fc0326.png)

SAP Spartacus 接收到這些 API 響應後，解析出 CMS Component 的名稱以及與其一一對應的 Angular Component 的名稱，將後者動態渲染出來。

下圖是 SAP Commerce Cloud 預設的主頁：

![](https://img-blog.csdnimg.cn/img_convert/c44770d725a7812bebf06bb2ecbfbe2f.png)

如何才能知道其中哪個區域，代表我前文提到的內容插槽 Section1，及放置在其中的兩個元件呢？

我在 SAP Spartacus 渲染 Content Slots 中放置的元件程式碼位置處，加上了一些除錯資訊，列印出了 Slot ID 和 Component ID，便於大家理解：
![](https://img-blog.csdnimg.cn/img_convert/56d3eebedbad401ddfa433cac31ec160.png)

重新整理 SAP Commerce Cloud 頁面：

![](https://img-blog.csdnimg.cn/img_convert/fcc0e426f30670207264dd77964de687.png)

根據頁面上列印的除錯資訊，一目瞭然，下圖黃色高亮部分，代表 ID 為 Section1 這個內容插槽在頁面上的起始位置。綠色高亮為 Section1 包含的兩個元件的 ID，而紅色及藍色矩形框，代表的是這兩個元件被 Angular 渲染後的最終顯示效果：

![](https://img-blog.csdnimg.cn/img_convert/96447c39a236a1538160b51957eb5930.png)

# 總結

本文概述了 SAP CRM，SAP S/4HANA，SAP Cloud for Customer 和 SAP Commerce Cloud 這四個產品中前端 UI 開發中使用到的元件理念。雖然具體實現技術不同，但這四個產品前端的元件，都體現了對各自完成功能的封裝，以及作為應用程式前端介面構建塊的用途。

由於篇幅所限，本文沒有辦法針對每個產品逐一展開深入介紹，大家可以使用我這篇文章 如何高效搜尋汪子熙公眾號發表的文章 介紹的搜尋功能，搜尋本公眾號之前釋出的文章，以對這些產品的 UI 開發技術進行深入瞭解。

感謝閱讀。

SAP Spartacus SimpleResponsiveBannerComponent url 的資料來源

相關文章