SAP Cloud for Customer Extensibility的設計與實現

時間 2019-11-19

標籤 sap cloud customer extensibility 設計實現欄目雲服務简体版

原文原文鏈接

今天的文章來自Jerry的同事，SAP成都研究院C4C開發團隊的開發人員徐歡(Xu Boris)。徐歡就坐我左手邊的位置，所以我工做中但凡遇到C4C的技術問題，一扭頭就能夠請教他了，很是方便。下圖是他辦公室的桌面。前端

Jerry前一篇文章 SAP產品的Field Extensibility 以SAP CRM和SAP S/4HANA爲例，介紹了SAP產品Field Extensibility的設計原理與實現。如今由徐歡繼續Extensibility這個話題，向您介紹SAP Cloud for Customer的Extensibility設計與實現。前端框架

SAP C4C和SAP S/4HANA的Extensibility有很深的淵源，後者的設計之前者爲基礎而又有所創新。從時間線上說，我認識的不少德國同事前後都參與了C4C和S/4HANA Extensibility的框架開發。這兩個框架開發團隊的不少關鍵角色，好比架構師和產品經理，甚至都是同一批人。架構

下面是他的正文。框架

你們好，我是Boris，中文名徐歡。2015年元旦以前一直從事ERP客戶項目開發與諮詢，大約有6年的時間。在這以前也從事過幾年與SAP產品無關的開發工做。因爲在加入SAP以前參與ERP實施項目，我曾經花費大量的時間研究ERP核心模塊的基本業務流程，曾經參與多個項目從立項到客戶上線的實施工做。2015年，懷着對SAP開發團隊的憧憬之心加入SAP BYD/C4C應用開發項目，參與了多個應用模塊和行業解決方案的開發，並在2年的時間裏以技術支持的角色在C4C HTML5 UI框架這個領域內處理了1000 多個客戶故障。ide

目前做爲SAP C4C在中國標準開發團隊的一員，很高興能在這裏分享我關於C4C Extensibility的一些心得。工具

Jerry前一篇文章 SAP產品的Field Extensibility 已經介紹過Enhancement和Modification這兩個概念的區別。C4C用戶經過Key User Tool這個工具（相似CRM的Application Enhancement Tool，AET）對C4C標準UI和客戶定製開發的UI進行加強。加強類型分爲Personalization和Adaptation，分別針對同一tenant內單個用戶生效和同一tenant內所有用戶生效。flex

Key User Tool很是容易使用。若是想經過Adaptation的方式加強UI，登陸C4C ,在頂部菜單欄選擇Adapt -> Edit Master Layout（相應的，若是選擇Personalization方式，則經過下圖Adapt旁邊的Personalize菜單項開始）。ui

如今將光標懸浮在頁面任意位置，若是頁面被C4C後臺設置爲「能夠加強」，那麼能看到一個彈出的工具欄，點擊裏面的加號圖標，就能從下拉菜單中選擇「Add Fields」來進行字段的加強了。url

填寫字段描述，類型等信息以後保存便可。debug

你們把上圖C4C擴展字段建立頁面和下圖出如今Jerry前一篇文章的S/4HANA擴展字段建立頁面作對比，是否是很是相像？

對客戶而言，整個過程簡單易懂，僅僅幾分鐘便完成所有操做。背後的支撐是SAP C4C提供的Extensibility框架, 這正是我要給你們介紹的。首先咱們從基本概念提及。

Personalization

用戶經過這種方式對UI進行的調整，只對當前進行Personalization的用戶生效，對其餘用戶不可見。

C4C後臺有一個叫XREP的存儲系統，設計思路和理念同Jerry介紹S/4HANA Extensibility時提到的LREP一致，只不過在C4C裏換了一個名字而已，這裏的X表明Cross。儘管C4C的客戶和Partner沒法像S/4HANA那樣，登陸後臺查看XREP的所有內容，但仍舊能夠經過UI Designer裏的Configuration Explorer，查看XREP裏的部份內容。以下圖右邊區域所示，XREP實質上就是一個用ABAP實現的分層的文件系統。

從技術上講，每一個Personalization施加的UI修改，都會生成一個文件，這些文件的C4C官方叫法是Change Transaction，下文簡稱CT。Personalization產生的CT存儲在C4C後臺XREP里名叫$PERS的Layer中。運行時，包含了Personanization的UI頁面準備渲染時，C4C前端框架纔會臨時把這些位於$PERS中的CT合併到對應的C4C標準UI上。

Adaptation

技術上講，Adaptation產生的CT文件會存儲在該用戶所歸屬的Layer裏。例如客戶作的UI修改，會存儲到名爲$Cust的Layer中去。而Partner作的修改，存儲到Partner對應的Solution獨有的Layer下面。Partner Solution是C4C一個特有的概念，以下圖Cloud Application Studio中的一個例子。你們能夠把Partner Solution類比成ABAP Package的一個封裝，一個Partner Solution裏能存放Cloud Application Studio支持的各類資源，好比UI，BO，Web Service，OData開發等等。每一個Partner Solution在XREP裏都有對應的Layer。

個人同事Yang Joey曾經在他的文章SAP成都研究院C4C光明左使：SAP Cloud for Customer 使用SAP UI5的獨特之處提到過，C4C的UI界面的源代碼，是以XML格式存儲在ABAP Netweaver後臺的XREP裏的。XREP提供了許多訪問這些XML文件的API，好比讀取，解析，激活等等。同S/4HANA LREP同樣，C4C XREP有不一樣的Layer，分別存儲SAP標準UI，Partner建立的UI，以及用戶所建立的資源。經過Layer實現了資源的區分隔離，使得操做者對UI的更改不須要修改最底層SAP標準的UI文件。運行時，上層的更改覆蓋對應的底層文件的表現。關於不一樣層之間合併(Merge)的更多細節，請參考Jerry文章SAP產品的Field Extensibility裏S/4HANA章節裏對LREP的介紹。

運行時，C4C框架從XREP Layer $Load讀取UI源代碼，從下圖中咱們看到$Load包含SAP標準UI，以及Partner和客戶進行UI更改產生的CT。在Adaptation模式下產生的CT會被當即合併到對應的UI去，CT合併以後$Load中的UI文件會被從新生成，以便在下次加載時前臺框架老是基於最新合併後的UI源代碼進行渲染。

咱們如今以Adaptation的方式修改一個標準字段的屬性，而後觀察伴隨着這個修改動做，自動生成的CT究竟是什麼樣子的。咱們將Employee UI上Manager這個標準字段的Mandatory屬性打上勾，意思是若是該字段未維護，則對Employee作的修改沒法成功保存。

由於用戶和Partner沒法登錄C4C後臺，因此咱們須要用另外一種方式查看生成的CT明細。在地址欄的url裏增長debugMode=true的參數進入調試模式。

而後從新加載該頁面，按住Ctrl + 鼠標左鍵點擊「Manager」字段，出現一個彈出窗口。下圖紅色下劃線標註的就是這個CT在XREP中的存儲路徑。路徑裏有個片斷"AddCondition", 提示了這個CT的類型。點擊超連接"Get CTs"查看CT明細。

這個CT的XML內容以下：

裏面包含的一些重要信息：

UsedAnchor：這個屬性是C4C Extensibility設計區分於SAP CRM和S/4HANA的最重要標誌之一，立刻詳細介紹。上圖的UsedAnchor類型爲SectionGroupAnchor，xrepPath爲該Anchor在XREP中的路徑。
TargetFile：說明這個CT會被合併到哪一個C4C UI上。上圖例子裏的值爲COD_Employee.TI, 指的是Employee的明細頁面，即Employee明細頁面上發生了UI Adaptation操做。
AddCondition：說明這個UI修改的具體類型。上圖例子指修改的屬性名稱爲"Mandatory", 默認值爲true。

如今來細說UsedAnchor。Jerry的文章SAP產品的Field Extensibility 曾經提到，在SAP CRM和S/4HANA的後臺，都有一個統一的Extensibility註冊表。每一個應用的開發人員，若是但願本身應用的UI可以支持Extensibility，那麼須要將框架須要的信息註冊進去。一樣，C4C Extensibility也須要這種註冊表的邏輯，經過上面例子裏提到的Anchor實現。

Anchor的中文意思是「錨點」，這個字用在C4C Extensibility註冊這個上下文很是合適。每一個Anchor指向了一個能夠經過C4C Key User Tool進行加強的UI區域。咱們用UI Designer中打開剛纔修改了Manager字段Mandatory屬性的Employee明細頁面，發現Manager字段位於一個Section Group中。選中該Group，從頁面右邊的Extensibility屬性中能發現維護有一個Anchor。該Anchor即咱們以前研究的CT的XML內容裏UsedAnchor字段的值。

若是一個Section Group的Extensibility屬性處維護有Anchor，意思是SAP C4C聲明該Section Group能夠被Key User Tool加強。反之，不可加強。在Adaptation模式下將鼠標放至這些不可加強的UI上，只會被高亮，但沒有任何工具欄顯示。

除了Key User Tool外，C4C的Partner還有另一個途徑對UI作加強，即便用Cloud Application Studio的Extensibility Explorer。選中一個UI Section Group，若是該Group的Extensibility字段維護了Anchor，那麼能夠看到下圖紅色高亮的操做選項，按照嚮導便可對該UI作加強。

最後，這些自動建立的CT，究竟是在什麼時候何處，由誰建立的？

**CT **建立

CT建立的觸發是在UI端JavaScript代碼中完成，而後投遞到C4C後臺的。在C4C UI端JavaScript的目錄sap/client/flex/changes文件夾下，存放着不一樣類型的UI修改對應的處理器(Handler)。好比AddConditionHandler.js這個文件，負責響應用戶在Key User Tool裏對UI字段的屬性作了修改的事件。

而ChangeRegistry.js, 做爲響應用戶在Key User Tool裏操做的入口，將不一樣類型的UI修改分發給對應的處理器進行處理。

下圖顯示的是當"PropertyChange"這個類型的UI修改發生時，該修改被ChangeRegistry.js投遞給處理器PropertyChange.js。

PropertyChange.js會根據傳入的事件參數進行解析，判斷出當前發生更改的字段的Property是mandatory，因而進入_mandatoryChanged進行處理，建立CT記錄這個修改。

但願這篇文章能讓你們對C4C的Extensibility設計有一個粗淺的瞭解，感謝閱讀。

更多閱讀