今天的文章來自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 多個客戶故障。

目前作為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內全部用戶生效。

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框架從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設計有一個粗淺的了解，感謝閱讀。

更多閱讀

• SAP產品的Field Extensibility

• SAP成都研究院C4C光明左使：SAP Cloud for Customer 使用SAP UI5的獨特之處

• SAP S4CRM vs C4C, 諸葛亮和周瑜?

• SAP成都C4C小李探花：淺談Fiori Design Guidelines

• SAP UI和Salesforce UI開發漫談

• Hello World, S/4HANA for Customer Management 1.0

要獲取更多Jerry的原創技術文章，請關註公眾號"汪子熙"或者掃描下面二維碼:

SAP Cloud for Customer Extensibility的設計與實現