企業級應用增強技術概述

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將來有機會的話會繼續介紹。

ABAP ERP JavaScript

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。