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裡名叫P E R S 的 L a y e r 中 。 運 行 時 ， 包 含 了 P e r s o n a n i z a t i o n 的 U I 頁 面 準 備 渲 染 時 ， C 4 C 前 端 框 架 才 會 臨 時 把 這 些 位 于 PERS的Layer中。運作時，包含了Personanization的UI頁面準備渲染時，C4C前端架構才會臨時把這些位于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 L o a d 讀 取 U I 源 代 碼 ， 從 下 圖 中 我 們 看 到 Load讀取UI源代碼，從下圖中我們看到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的參數進入調試模式。
這個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。