谈谈 SAP 产品 UI 开发中的组件概念
這是 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
前文已經介紹過,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 公開課第四單元:開發環境搭建
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 類型各異, 由不同的組件所實現。
打開任意一個 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
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 開發技術進行深入了解。
感謝閱讀。
更多Jerry的原創文章,盡在:“汪子熙”:
總結
以上是生活随笔為你收集整理的谈谈 SAP 产品 UI 开发中的组件概念的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 剑网3指尖江湖叶芷青连招技巧是什么 叶芷
- 下一篇: 乐高(LEGO)在线购物店面剖析