這是 Jerry 2021 年的第 54 篇文章，也是汪子熙公衆号總共第 331 篇原創文章。
任何企業級軟體的前端開發，都離不開元件(Component)這個概念。撇開具體的 UI 開發技術不談，所謂元件，就是界面的組成部分(UI Building Blocks). 元件在視覺或者業務功能上，能夠被視為單一進制素。
元件可能被構成應用程式的其他元件重用，也可能包含其他元件。理想情況下，一個設計良好的元件，其同其他元件或者外部服務的依賴關系，可以被恰當地隔離，進而能夠單獨對元件進行單元測試甚至自動化測試。
近些年随着微服務架構浪潮而興起的微前端設計理念，甚至支援同一應用内不同的 UI 元件，采取不同的前端技術進行開發，這些異構的 UI 元件，可以獨立地進行開發，測試，部署和傳遞，通過統一的微前端容器進行管理，并構成最終由使用者使用的前端程式。
Luigi 就是 SAP 推動的一個微前端架構。
微前端架構的使用已經超出了本文讨論的範疇。本文就 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 開發漫談。
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 元件時會再次提及。
前文已經介紹過，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.
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 應用為例：
和其他所有基于 Fiori Elements 開發的應用一樣，Sales Management Overview 應用工程内僅包含一個 Component.js, 該檔案内聲明了對 manifest.json 檔案的引用。其餘在 Freestyle SAP UI5 開發模式下需要應用開發人員編寫的 Controller，View 等資源檔案，在 Fiori Elements 應用裡均被 SAP UI5 架構提供的模闆版本所取代。
在 manifest.json 檔案裡，我們能得到下列這些資訊：
該 Fiori 應用消費的 OData 服務名稱，SD_OVP_SM
該 Fiori 應用消費的 OData 服務基于的 CDS view 名稱：C_PROFITMARGINBYMONTHQUERY_CDS
Fiori 應用 ID：F2601
有了 F2601 這個 Fiori ID 之後，從 Jerry 文章 SAP Fiori應用索引大全 裡介紹的網站上，根據該 ID，即可查詢到該 Fiori 應用的設計詳情：
關于 SAP Fiori Elements 應用 manifest.json 更多的細節介紹，請參考 Jerry 之前的文章：
在沒有任何前端開發經驗的基礎上, 建立第一個 SAP Fiori Elements 應用
答網友提問：使用 SAP Fiori Tools 建立的 Fiori Elements 應用，如何進行二次開發？
關于 SAP Fiori Elements 開發的更多介紹，可以參考 Jerry 翻譯的 OpenSAP 上的公開課。由于工作繁忙，目前隻完成了前四期視訊的翻譯工作：
OpenSAP Fiori Elements 公開課第一單元：總體介紹
OpenSAP Fiori Elements 公開課第二單元：架構介紹
OpenSAP Fiori Elements 公開課第三單元：OData 服務和注解介紹
OpenSAP Fiori Elements 公開課第四單元：開發環境搭建
同 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 類型各異, 由不同的元件所實作。
打開任意一個 UI 元件，發現其仍然分為 MVC 三層。其中視圖層，開發人員可以在 Toolbox 面闆中拖拽合适的 UI 控件，以所見即所得的方式設計視圖;
在模型層，選擇 C4C 标準的 BO 或者 Partners 二次開發的 BO, 可以完成視圖控件字段同 BO 字段的資料綁定;
在控制器層面，可以采用非編碼的聲明方式，指定該視圖響應使用者操作之後，應該執行何種業務邏輯。
由于曆史原因，SAP C4C 使用者通路入口，并不是像 S/4HANA 那樣采用了 Fiori Launchpad，而是同 SAP CRM 一樣，選擇工作中心(Work Center)作為入口。
使用者被配置設定的業務角色(Business Role)決定了其能夠通路的工作中心。C4C 的 UI 元件被添加到工作中心視圖中，後者再被添加到工作中心内，進而被使用者通路。
因為并未通過 Fiori Launchpad, 進行管理，是以 C4C 元件也就不存在 Component.js. 每個 C4C UI 元件本質上是一個 XML 檔案，該檔案存儲在 C4C 背景一個叫做 X-Repository 的基礎設施上。
運作時當所屬的工作中心視圖被通路時，UI 元件的源代碼從 C4C 背景加載到浏覽器，被 SAP UI5 架構解析。後者按照 C4C 特有的視圖格式，根據元件源代碼裡包含的控件定義内容，建立對應的 UI5 控件執行個體。這些控件執行個體再使用對應的渲染器，按照文章 深入學習SAP UI5架構代碼系列之二：UI5 控件的渲染器 裡介紹的邏輯，生成最終的原生 HTML 源代碼。
傳統的 SAP UI5 應用裡，UI5 架構基于 JavaScript 或者 XML 視圖檔案，建立對應的 SAP UI5 控件執行個體。而 C4C 則是基于元件視圖檔案，進行控件執行個體化，這算是 C4C 元件使用 SAP UI5 的獨特之處。
關于 C4C 元件設計的更多細節和其與 SAP UI5 架構互動的深入分析，請參考我的同僚 Yang Joey 的文章: SAP Cloud for Customer 使用 SAP UI5 的獨特之處。
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 面闆，定義該頁面由哪些内容插槽組成：
下圖展示了 homepage 由内容插槽 Section1, Section2A，Section2B，Section2C 等區域組成。
一個 Content Slot 可以容納多個元件，下圖展示了 Section1 這個 Content Slot，容納 Electronics Homepage Splash Banner Component 和 Electronics Homepage Splash Discount Component 這兩個元件。
大家可以類比前文介紹的 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：
其中 Section1 這個 Content Slot 裡包含的兩個 Components 名稱，正是我之前在 Commerce Cloud CMS 裡維護的兩個 Component：
SAP Spartacus 接收到這些 API 響應後，解析出 CMS Component 的名稱以及與其一一對應的 Angular Component 的名稱，将後者動态渲染出來。
下圖是 SAP Commerce Cloud 預設的首頁：
如何才能知道其中哪個區域，代表我前文提到的内容插槽 Section1，及放置在其中的兩個元件呢？
我在 SAP Spartacus 渲染 Content Slots 中放置的元件代碼位置處，加上了一些調試資訊，列印出了 Slot ID 和 Component ID，便于大家了解：
重新整理 SAP Commerce Cloud 頁面：
根據頁面上列印的調試資訊，一目了然，下圖黃色高亮部分，代表 ID 為 Section1 這個内容插槽在頁面上的起始位置。綠色高亮為 Section1 包含的兩個元件的 ID，而紅色及藍色矩形框，代表的是這兩個元件被 Angular 渲染後的最終顯示效果：
總結
本文概述了 SAP CRM，SAP S/4HANA，SAP Cloud for Customer 和 SAP Commerce Cloud 這四個産品中前端 UI 開發中使用到的元件理念。雖然具體實作技術不同，但這四個産品前端的元件，都展現了對各自完成功能的封裝，以及作為應用程式前端界面建構塊的用途。
由于篇幅所限，本文沒有辦法針對每個産品逐一展開深入介紹，大家可以使用我這篇文章 如何高效搜尋汪子熙公衆号發表的文章 介紹的搜尋功能，搜尋本公衆号之前釋出的文章，以對這些産品的 UI 開發技術進行深入了解。
感謝閱讀。