SAP Cloud for 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多個客戶故障。
目前作為SAPC4C在中國標準開發團隊的一員，很高興能在這裡分享我關於C4C Extensibility的一些心得。
Jerry前一篇文章SAP產品的Field Extensibility已經介紹過Enhancement和Modification這兩個概念的區別。C4C用戶通過Key User Tool這個工具（類似CRM的Application Enhancement Tool，AET）對C4C標準UI和客戶定製開發的UI進行增強。增強類型分為Personalization和Adaptation，分別針對同一tenant內單個用戶生效和同一tenant內全部用戶生效。
Key User Tool非常容易使用。如果想通過Adaptation的方式增強UI，登錄C4C ,在頂部菜單欄選擇Adapt -> Edit Master Layout（相應的，如果選擇Personalization方式，則通過下圖Adapt旁邊的Personalize菜單項開始）。
現在將游標懸浮在頁面任意位置，如果頁面被C4C後台設置為「可以增強」，那麼能看到一個彈出的工具欄，點擊裡面的加號圖標，就能從下拉菜單中選擇「Add Fields」來進行欄位的增強了。
填寫欄位描述，類型等信息之後保存即可。
大家把上圖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框架從XREPLayer $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設計有一個粗淺的了解，感謝閱讀。
更多閱讀
TAG:汪子熙 |