SAP產品增強技術回顧

Jerry最近的工作和SAP某雲產品的擴充套件性設計相關，因此借這個機會，把我過去工作中積累的SAP產品擴充套件技術相關的知識做一個梳理和回顧。

文章目錄

SAP產品標準

SAP Field Extensibility簡述

SAP Side-by-Side Extensibility簡述

SAP In-App Extensibility介紹

SAP Business Addin增強概念在多種SAP產品中的應用

ABAP類面向切片程式設計方式(Aspect Oriented Programming)

SAP Commerce擴充套件方式簡述

SAP Fiori UI擴充套件方式簡述

展望未來

下面是文章正文。

SAP產品在釋出到市場上之前，都必須經歷一系列嚴格的產品標準(Product Standards)相關測試。

這些產品標準包含但不侷限於：

• 功能正確性(Functional Correctness)
• 效能(Performance)
• 安全性(Security)
• 全球化(Globalization)
• 業務配置性(Business Configuration)
• 可擴充套件性(Extensibility)
• 生命週期管理(Software Lifecyle)
• 可訪問性設計(Accessibility)

其中SAP產品的可擴充套件性(Extensibility), 又可細分為欄位級別的可擴充套件性(Field Extensibility)和流程級別(Process Extensibility)的可擴充套件性。當然二者有時也沒有明確的區分界限，比如客戶實際應用場景中，一旦建立了新的擴充套件欄位後，通常也期望該欄位參與到業務流程中去，即所謂端到端的擴充套件場景(End-to-End Extension Scenario).

Jerry之前寫過一篇文章介紹了SAP產品欄位級別可擴充套件性(Field Extensibility)的設計原理： SAP產品的Field Extensibility，本文則介紹SAP產品流程級別的可擴充套件性。

SAP產品的兩種擴充套件方式：In-App和Side-by-Side Extensibility

以Jerry工作的SAP C/4HANA套件為例，在 SAP幫助文件裡，我們可以首先選擇以In-App Extensibility還是以Side-by-Side的方式來擴充套件:

選定擴充套件型別後，再從下拉選單裡選擇具體的產品名稱，即得到該產品針對選定的擴充套件型別，SAP所推薦的擴充套件方式。

所謂In-App Extensibility，指透過SAP擴充套件工具建立出的Enhancement(增強)，同被增強的SAP標準產品執行在同一伺服器上。更準確地說，增強實現同被增強的SAP應用執行於同一會話(Session)內。

與之相對的是Side-by-Side Extensibility，增強實現同被增強的SAP應用通常執行在不同的伺服器上。以Jerry之前文章  基於SAP Kyma的訂單編排增強介紹 裡提及的場景為例，SAP Commerce將Order.Created事件註冊到SAP Cloud Platform Extension Factory(Kyma)上，二次開發人員在SAP雲平臺上建立Lambda Function，訂閱這個事件，實現傳送郵件的邏輯。執行時每當SAP Commerce有訂單建立，Order.Created事件釋出到SAP雲平臺上，Lambda Function被觸發，自動傳送郵件。

透過Side-by-Side Extensibility，可以實現諮詢公司Gartner早在2014年就提出的雙模IT(Bimodel)概念，即一方面透過SAP S/4HANA作為數字化核心，以支撐企業穩定可靠運作；另一方面，透過SAP雲平臺所架構的數字化創新平臺，藉助包括人工智慧、區塊鏈、大資料分析等前沿科技，對S/4HANA進行Side-by-Side擴充套件，幫助客戶實現快速的產品/服務乃至商業模式的創新。

關於Side-by-Side Extensibility，Jerry之前的文章曾做過簡單介紹：

還在用ABAP進行SAP產品的二次開發？來了解下這種全新的二次開發理念吧

本文餘下部分著重回顧SAP In-App這種擴充套件方式。

在討論SAP產品擴充套件時，我們有必要區分這組概念的差異：Enhancement(增強)和Modification(修改). 後者是直接對SAP產品的原始碼進行修改，在SAP產品升級或者Patch匯入系統時，這些本地修改會被覆蓋，故SAP不推薦透過Modification的方式進行二次開發。而SAP增強技術則不會存在當產品升級時被覆蓋的問題，因此將SAP增強技術描述為一種具備Upgrade Safe或者Modification Free特性的技術.

SAP Business Addin增強概念在多種SAP產品中的應用

以ABAP作為技術棧的On-Premises產品，其增強技術源遠流長。儘管具體技術實現有差異，但思路都一致：SAP事先在標準程式裡預留一些Hook，二次開發人員可以實現這些Hook，將自己的業務邏輯程式碼編寫在裡面。 這些Hook所在SAP標準程式裡的位置，稱之為增強點(Enhancement Point). 當標準程式執行到這些Hook時，系統如果檢測到有Partners實現了這些Hook，就呼叫之，從而實現了業務流程的擴充套件。

這些增強方式技術上沒有太多噱頭，但卻體現了德國製造一貫的作風：嚴謹實用，低調高效。可以說SAP早期基於ABAP技術棧的產品能在全世界取得成功，稱霸ERP軟體領域，這些增強技術功不可沒。

從時間線來說，國內很多SAP中文部落格將ABAP增強技術劃分為三代：User Exit，Function Enhancement和Business Addin. 前兩種方式廣泛用於早期的SAP產品中，現在已很少提及。Business Addin(有時簡稱BAdI)，從誕生至今一直是SAP ABAP On-Premises產品增強技術的主力軍，並且在ABAP Cloud產品如SAP Cloud for Customer和S/4HANA Cloud中也能看到其身影。

Business Addin技術又分為使用CL_EXITHANDLER進行增強管理和呼叫的傳統方式(Classical BAdI)和使用ABAP關鍵字GET BADI和CALL BADI實現這兩種方式。二者區別在於前者是在ABAP應用層面管理和呼叫增強，而後者兩個關鍵字的實現位於ABAP Kernel中，效能優於傳統方式。

換言之，在傳統BAdI增強方式裡，對於SAP預留的增強點裡，執行時到底包含哪些有效增強實現的邏輯，是編寫在ABAP層的CL_EXITHANDLER裡，所有ABAP開發人員都能除錯這些ABAP程式碼：

而GET BADI和CALL BADI實現在ABAP Kernel層，只有SAP內部人員才能看到這些關鍵字的C語言實現程式碼。

GET BADI關鍵字執行完畢後，滿足Filter條件且狀態為Active的增強實現例項被ABAP Kernel填充到內表IMPS裡：

正因為ABAP新式增強其強大的擴充套件功能，在基於ABAP的Cloud產品裡也出現了它的身影。

在SAP Cloud for Customer裡，二次開發人員無法直接用SAPGUI編寫ABAP增強程式碼，卻仍舊能用SAP Cloud Application Studio建立增強：

下圖下拉選單顯示的就是CustomerQuote這個BO預留的增強點：

在Studio裡用ABAP指令碼語言編寫增強實現，儲存啟用後，會在ABAP後臺自動生成BAdI增強體和根據ABAP指令碼語言編譯成的ABAP原生程式碼。

到了S/4HANA Cloud，SAP仍然不想放棄給二次開發人員提供編寫ABAP BAdI增強實現的功能，只不過編寫工具從SAPGUI和SAP Cloud Application Studio遷移到了瀏覽器中。

客戶在S/4HANA Cloud的Fiori Launchpad裡，進入Custom Logic這個tile：

新建一個Enhancement Implementation：

選定Business Context後，同樣能從Enhancement Option即可用增強點列表裡，選擇合適的增強點建立增強實現：

同SAP Cloud for Customer編寫的ABAP指令碼不同，在SAP S/4HANA Cloud Custom Logic裡，編寫的是原生的ABAP程式碼：

關於瀏覽器裡如何實現上圖所示的ABAP語法高亮，請參考Jerry的文章： ABAP開發環境語法高亮的那些事兒。

ABAP類面向切片程式設計方式(Aspect Oriented Programming)

相對Java程式設計人員，ABAP開發人員平時可能不會接觸到面向切片程式設計(Aspect Oriented Programming，簡稱AOP)這個概念。

面向切片程式設計可以看成對物件導向程式設計思維的一種補充，廣泛應用在基於Spring框架的Java應用中，比如SAP Commerce.

利用AOP，可以對組成業務邏輯的各部分進行隔離，降低各部分間的耦合度，以及避免非業務邏輯程式碼侵入到業務邏輯程式碼裡。

由於ABAP語言特性和Java的差異，SAP官方從未提及ABAP對AOP的支援，所以Jerry本文目錄裡也採用“類AOP”的字眼來描述。

在ABAP裡如果想要統計一個方法的執行時間，最常用的辦法是在方法實現體的頭部開啟一個計時器，在實現體末尾關閉計時器。虛擬碼如下：

下圖是SAP Gateway處理OData請求的框架程式碼。在處理開始之前開啟計時器：

請求處理完畢後關閉定時器：

這樣的寫法，開關計時器這些基礎設施性質的程式碼就侵入到了OData請求處理的業務程式碼裡。

除了效能統計外，許可權檢查，日誌記錄，事務處理等任務也幾乎是任何應用必須編碼實現的非業務邏輯模組程式碼。

藉助AOP理念，可以優雅地避免非業務邏輯程式碼對業務邏輯程式碼的侵入(有時也稱汙染)。

使用AOP程式設計正規化，業務模組的編寫只關注業務邏輯本身，僅此而已。許可權檢查，日誌記錄，效能檢測這些基礎設施級別的關注點，透過不同的AOP實現技術，在不修改業務模組原始碼的前提下，像切面(Aspect)一樣編織(Weave)到業務模組裡。

ABAP缺少Java那樣對AOP的完善支援，ABAP平臺提供的Pre/Post/Overwrite Exit，可以在一定程度上實現類似Java AOP的效果，即某ABAP方法的Pre-Exit增強，能夠自動在該方法呼叫之前被呼叫；Post-Exit增強，自動在該方法呼叫之後被呼叫。Pre和Post-Exit增強的儲存和生命週期管理，均獨立於被增強方法本身。

限於文章篇幅，ABAP這種類AOP技術和Java AOP的比較，有機會Jerry單獨寫一篇文章介紹。

在SAP Business by Design和SAP Cloud for Customer的Cloud Application Studio裡，以標準Business Object節點作為粒度，為二次開發人員暴露了很多增強點，比如在某BO節點發生修改之後，儲存之前，從資料庫載入到應用之後，執行某Action之前，都能編寫自定義邏輯。

本來ABAP Pre-Exit和Post-Exit是實現這些自定義邏輯的最佳載體，但是在Jerry工作的2010年的時候，這些Exit無法實現多租戶隔離(Multi-tenant isolation)，即租戶A上建立的Exit，在其他所有租戶上也都可見，因此無法用在諸如SAP Business by Design，SAP Cloud for Customer這些需要支援多租戶隔離特性的SAP雲產品上。

關於SAP Cloud for Customer Extensibility設計的更多細節，請參考我的同事Xu Boris的文章： SAP Cloud for Customer Extensibility的設計與實現。

SAP Commerce擴充套件方式簡述

SAP Commerce的服務層是根正苗紅的基於Spring的實現，因此可以充分發揮Java Spring AOP帶來的高可擴充套件性。

關於Spring AOP在SAP Commerce中的應用，請參考 SAP幫助文件.

除了Spring AOP之外，SAP Commerce的高可擴充套件性還體現在其以Extension為基礎的模組化架構上。

Jerry第一次學習SAP Commerce時，曾經被其Extension這個單詞的字面意思所迷惑。其實在SAP Commerce上下文裡，Extension和ABAP裡的Extension含義有所不同——後者多指二次開發人員基於SAP標準程式做的增強，而前者是Commerce裡一個更加寬泛的概念：

An extension is an encapsulated piece of software that extends SAP Commerce functionality by either modifying existing features, or introduction new features.

SAP Commerce的業務層，平臺層和基礎設施層的很多標準功能，均透過Extension作為載體來實現。一個Extension就是SAP Commerce裡一個最小粒度的功能模組，從開發角度上看就是一個匯入到IDE後的Java工程資料夾：

按照 SAP幫助文件上的步驟，二次開發人員可以建立新的Extension，實現了自己的自定義業務邏輯後，再按照嚮導將其合併到SAP Commerce中去，從而實現功能擴充套件需求。

在SAP Commerce config資料夾下的localextensions.xml, 宣告瞭執行時會載入的Extension列表。由此看出，SAP Commerce裡無論標準Extension還是二次開發人員自建的Extension，在載入時都處於同等地位，這是我覺得SAP Commerce在Extensibility上不同於ABAP產品的一個有趣之處。

SAP Fiori UI擴充套件方式簡述

本文描述的SAP Fiori UI，僅限於基於SAP UI5框架實現的前臺頁面。採用React，Vue，Angular等技術實現的Fiori UI不在本文討論範圍內，您可以透過Jerry這些文章瞭解更多細節：

• SAP Fiori + Vue = ？
• Fiori Fundamentals和SAP UI5 Web Components
• 用React開發SAP Fiori應用

基於SAP UI5框架實現的Fiori UI，從實現方式又可以分為前端開發人員手動編寫的UI，以及透過框架比如SAP Fiori Elements自動生成的UI兩種。

前者的典型例子是SAP CRM Fiori的標準應用，Jerry之前工作過的SAP成都研究院CRM開發團隊曾經負責過這幾個Fiori應用的開發和維護：

這些Fiori標準應用的XML檢視和Controller的JavaScript程式碼均是我們人工編寫的，我們在XML檢視裡，預留了Partners能夠插入自定義UI元素的Extension Point：

二次開發人員透過下圖所示的UI5 View Extension，將自定義UI元素插入Fiori UI的SAP標準XML檢視預留的Extension Point裡：

而JavaScript實現的SAP Fiori UI標準控制器裡，我們也為二次開發人員預留了進行流程邏輯增強的所謂Extension Hook：如下圖第933行所示：

上圖的Hook在Partners的UI控制器裡實現程式碼如下：

我當時擔任SAP CRM Fiori客戶專案Dev Angel時，曾經建議專案的二次開發人員，用這種方式完成了很多端到端級別的增強開發，我把其中一些案例寫在了SAP社群的 部落格系列裡.

無論XML檢視裡的Extension Point，還是JavaScript控制器裡的Extension Hook，設計理念同前文介紹的ABAP Business Addin如出一轍。

這種理念也延續到了基於SAP Fiori Elements自動生成的UI裡：

關於如何使用Extension Point對SAP Fiori Elements UI進行擴充套件，請參考 SAP幫助文件.

展望未來

隨著SAP Cloud Platform Extension Factory的問世，越來越多的客戶選擇將自定義邏輯實現在基於Serverless架構的Lambda Function裡，透過Side-by-Side的方式對SAP雲產品進行擴充套件。而微服務架構下的SAP雲產品，如何對這些基於Lambda Function實現的客戶增強進行統一管理和呼叫，是一個令人浮想聯翩的話題，Jerry將來有機會的話會繼續介紹。

感謝閱讀。

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":