SAP 産品 UI 裡的容器元件的概念和開發概述

Jerry 之前的文章，談談 SAP 産品 UI 開發中的元件概念，曾經提到，無論基于何等開發技術的 SAP 産品 UI，其呈現在最終使用者面前的視覺效果，都是通過若幹邏輯意義上的元件(Component)實作的。這些邏輯意義上的元件，代表了 SAP 産品提供給最終使用者互動功能的細粒度的封裝，比如查詢訂單的界面，和建立訂單的界面，開發時通常放置于兩個不同的元件内實作。

這些 UI 元件通常都包含模型層，視圖層和控制器層，通過開源或者 SAP 自研的 UI 架構彼此互動，協同工作。

不少 SAP 産品的 UI 開發，元件的定義和邊界非常清晰，比如 SAP UI5 裡的 Component.js, SAP ABAP Webdynpro 和 WebClient UI 的 Component，SAP Commerce Cloud Accelerator UI 裡的 JSP Component 和 Spartacus UI 裡的 Angular Component.這些産品的 UI 開發工作，主要就是進行這些 Component 的代碼編寫。

下圖所示的 SAP Cloud for Customer UI Designer 裡這些類型各異的 UI 模型，如 OWL，QAF, FS 等等，更是典型的 UI 元件的例子。

另外一些早期的 SAP 産品，比如運作在 SAPGUI 裡的 SAP ERP，其界面采用 ABAP Dynpro 實作，後者沒有明确提出 UI 元件的概念。但 ABAP Dynpro Screen 和 PAI/PBO 邏輯組合在一起，從設計和功能角度來說，也形成了一個邏輯意義上的 UI 元件。

本文通過一系列 SAP 産品 UI 為例，介紹 SAP 産品 UI 開發領域裡另一種重要的元件類型，我稱其為容器元件。

同前文描述的包含了具體界面和業務功能的 UI 元件相比，容器元件自身并不存在呈現給最終使用者的界面，而是單純地充當容器的角色，它們是容納其他 UI 元件的元件。部分容器元件可能支援一些簡單的控制邏輯編寫，運作時能夠根據開發人員指定的條件，動态地決定應該顯示其包含的哪些 UI 元件。

下面通過 Jerry 參與過的一些 SAP 産品 UI 開發工作中的具體例子，來介紹 SAP UI 容器元件的概念和作用。

SAP WebClient UI

下圖是基于 SAP WebClient UI 開發的 SAP CRM 産品明細頁面。紅色區域代表一個個普通的 UI 元件，綠色區域是一個容器元件，後者決定運作時，到底應該顯示其容納的哪些 UI 元件。

SAP Cloud for Customer / SAP Business ByDesign

SAP Cloud for Customer 同 SAP CRM 一樣，都借助了工作中心(Work Center)和工作中心視圖(Work Center View)的概念來實作權限管控。使用者隻能看到配置設定給其的工作中心視圖包含的具體界面。對開發人員來說，SAP CRM 的工作中心隻是配置表裡的一些條目，而 SAP Cloud for Customer 裡的工作中心和工作中心視圖，成為開發工具裡能實實在在看到和編輯的 UI 模型。一個工作中心包含若幹個工作中心視圖，下圖是一個例子：

點開上圖所示的 Sales Order 工作中心視圖，可以看到該工作中心視圖包含了一個 OWL Component

OWL 是 Object Work List 的縮寫，即下圖所示的給最終使用者提供搜尋界面的 UI 元件。這展現了 SAP 産品關于 Transaction 處理的一貫思路：客戶一般都是從 SAP 産品 UI 提供的事務資料搜尋頁面開始，從搜尋結果裡選中一條，浏覽明細頁面。SAP Cloud for Customer 和 SAP Business ByDesign 的搜尋頁面，就是由類型為 OWL 的 UI 元件實作的，而這些 OWL 元件，又被放置到工作中心視圖這個容器元件内。

SAP Cloud for Customer 還存在另一類使用廣泛，功能強大的容器元件 EC Component，即 Embedded Component，嵌入式元件。EC Component 作為容器控件，本身能夠容納其他的 UI 元件，同時其本身能夠以緊耦合和松耦合的方式，嵌入到另一個父元件中，通過多種方式使其内部容納的 UI Component 同嵌入的父元件之間進行資料傳遞和通信。

借助 SAP C4C 的 Mashup 技術，EC Component 無論是在 SAP C4C 标準開發，還是合作夥伴二次開發領域，都有着廣泛的用途。比如下圖所示 SAP C4C 的地圖內建功能：

以及我之前的文章 如何在SAP Cloud for Customer頁面嵌入自定義UI 介紹的場景，比如我們可以把第三方網站或者自開發的部署在 SAP BTP 平台上的頁面，通過 EC Component 嵌入到 SAP C4C 标準 UI 上去。

SAP 電商雲 Spartacus UI

作為基于無頭電商(Headless Commerce)架構解決方案的代表之一，SAP Commerce Cloud Spartacus UI 頁面的展示，采取純 CMS 驅動的思路來完成。

CMS(Content Management System)管理者，在 SAP Commerce Cloud Backoffice 裡定義電商雲前台需要顯示的頁面内容。這些頁面内容定義，通過暴露成 OCC(Omni Commerce Connect) API 的方式，提供給 SAP Spartacus UI 消費。後者拿到需要顯示的頁面内容之後，負責具體的視覺效果(Visual Effect)渲染。

以 SAP 電商雲的首頁 homepage 為例，CMS 管理者在 homepage 裡，維護該頁面容納的 Content Slots(内容插槽)。 一個頁面可以容納多個内容插槽，每個頁面插槽對應螢幕一個區域。

這些内容插槽，按照顯示内容，把 homepage 劃分成若幹個區域，比如 HeaderSlot,FooterSlot,SiteLogoSlot, Section1Slot,Section2Slot 等等。

每個内容插槽裡能夠放置一到多個 CMS Component，這裡的 CMS Component 起的是占位符的作用—— CMS 管理者不關心每個 CMS Component 具體顯示的視覺效果，甚至不關心這些 CMS Component，到底是由 JSP 還是用 Angular 來實作。

下圖展示的是 Section1Slot 這個内容插槽，放置的兩個 CMS Component 的名稱。SAP 電商雲 Accelerator UI 和 Spartacus UI，會分别使用 JSP Component 和 Angular Component 技術實作這些 CMS Component. 大家可以把下圖 Backoffice 所示的放置在内容插槽中的 CMS Component，與其和在 Accelerator UI 和 Spartacus UI 中的 Component 之間的關系，類比成面向對象程式設計中接口和其具體實作類的關系。

Spartacus 解析上圖 API 響應結果，拿到 name 屬性為 Electronics Homepage Splash Banner Component 的元件，得知其 typeCode 為 SimpleResponsiveBannerComponent，然後在其維護的映射表裡，查找到該 CMS Component 對應的 Angular Component 名稱為 BannerComponent，于是就會渲染 BannerComponent 對應的模闆檔案。

雖然從最終使用者的視角出發，覺察不到容器元件的存在，但對于 Spartacus UI 的标準開發人員和需要進行二次開發的合作夥伴來說，Spartacus UI 的容器元件是一個比較重要的概念。

SAP Spartacus UI 的入口頁面，實作代碼位于 storefront.component.html 模闆檔案。不到30行的代碼，把這個基于 Angular 的 UI 界面，劃分成了 header,main 和 footer 三大區域。

上圖是了解 SAP 電商雲 Spartacus UI 運作時渲染原理的關鍵所在，展示了 SAP Spartacus 兩個重要的容器元件。

标注2 顯示的 cx-page-layout, 以及其若幹個子節點 cx-page-slot, 分别對應了 SAP Spartacus 兩大容器元件 PageLayoutComponent 和 PageSlotComponent 的選擇器。

從 PageLayoutComponent 容器元件的模闆檔案實作能夠看出，每個 PageLayoutComponent 的執行個體，實際就是 CMS 管理者在 Backoffice 裡維護的一個 Page 在 Angular 端的具體呈現形式。

當最終使用者通路 SAP 電商雲 Spartacus UI 時，後者調用 OCC API，将對應 Page 在 Backoffice CMS 中的模型資料取回來，該 Page 配置設定的内容插槽資訊，存儲在上圖第 16 行的 slots$ 變量裡。PageLayoutComponent 使用 Angular 結構型指令 *ngFor, 周遊這個 slots$ 變量，将每條内容插槽記錄的資料，傳遞給另一個容器元件 PageSlotComponent，其選擇器為第 15 行所示的 cx-page-slot.

PageSlotComponent 根據 PageLayoutComponent 傳入的内容插槽資訊，解析出該插槽配置設定的 CMS Components 資訊。因為單個内容插槽可以配置設定多個 CMS Components，是以在第 10 行同樣使用結構型指令 *ngFor, 周遊該内容插槽需要顯示的每一個 CMS 元件資訊，将該資訊傳遞給第 19 行我們團隊自定義的 Angular 指令 cxComponentWrapper.

這個帶有我們部門名稱字首 cx - Customer Experience 的自定義指令，會根據傳入的 CMS Component 類型，解析出對應的 Angular Component 中繼資料，然後調用 Angular Component creation API，動态建立 Component 執行個體并觸發渲染流程。

采取這種 CMS 驅動的設計思路，通過 PayLayoutComponent 和 PageSlotComponent 兩大容器元件的配合，無論 CMS 管理者在 Backoffice 對一個 Page 待顯示的内容進行何種修改，Spartacus UI 端的代碼均能夠自動應對這些修改，做到以不變應萬變。

本文概述了 SAP WebClient UI，SAP Cloud for Customer 和 SAP Commerce Cloud Spartacus UI 中容器元件的設計和運作原理。個人認為，學習 SAP 某個産品的 UI 開發，隻要掌握了其普通 UI 元件(參考我的文章：談談 SAP 産品 UI 開發中的元件概念)和容器元件的概念和開發方式，就足以勝任大多數場合下的工作需求了。

Jerry 後續将帶來更多關于 SAP UI 開發技術的分享，敬請期待。

更多閱讀

SAP UI和Salesforce UI開發漫談

SAP 産品一脈相承的 UI 增強思路，在 SAP Commerce Cloud(電商雲) UI 增強實作中的展現

響應式程式設計在 SAP 标準産品 UI 開發中的一個實踐

談談 SAP 産品 UI 開發中的元件概念

關于 SAP 産品 UI 的搜尋引擎優化 SEO - Search Engine Optimization

聊聊 SAP 産品 UI 上的消息顯示機制