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 多個客戶故障。

目前作為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中的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包含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的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼:

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24475491/viewspace-2169022/，如需轉載，請註明出處，否則將追究法律責任。