天天看點
傳回

SAP産品增強技術回顧文章目錄SAP産品的兩種擴充方式：In-App和Side-by-Side ExtensibilitySAP Business Addin增強概念在多種SAP産品中的應用ABAP類面向切片程式設計方式(Aspect Oriented Programming)SAP Commerce擴充方式簡述SAP Fiori UI擴充方式簡述展望未來

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特性的技術.

以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開發環境文法高亮的那些事兒

。

相對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的服務層是根正苗紅的基于Spring的實作，是以可以充分發揮Java Spring AOP帶來的高可擴充性。

關于Spring AOP在SAP Commerce中的應用，請參考

.

除了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工程檔案夾：

按照

上的步驟，二次開發人員可以建立新的Extension，實作了自己的自定義業務邏輯後，再按照向導将其合并到SAP Commerce中去，進而實作功能擴充需求。

在SAP Commerce config檔案夾下的localextensions.xml, 聲明了運作時會加載的Extension清單。由此看出，SAP Commerce裡無論标準Extension還是二次開發人員自建的Extension，在加載時都處于同等地位，這是我覺得SAP Commerce在Extensibility上不同于ABAP産品的一個有趣之處。

本文描述的SAP Fiori UI，僅限于基于SAP UI5架構實作的前台頁面。采用React，Vue，Angular等技術實作的Fiori UI不在本文讨論範圍内，您可以通過Jerry這些文章了解更多細節：

基于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 Cloud Platform Extension Factory的問世，越來越多的客戶選擇将自定義邏輯實作在基于Serverless架構的Lambda Function裡，通過Side-by-Side的方式對SAP雲産品進行擴充。而微服務架構下的SAP雲産品，如何對這些基于Lambda Function實作的客戶增強進行統一管理和調用，是一個令人浮想聯翩的話題，Jerry将來有機會的話會繼續介紹。

感謝閱讀。

本文來自雲栖社群合作夥伴“汪子熙”，了解相關資訊可以關注微信公衆号"汪子熙"。

更多閱讀

ABAP專題

xml 監控 前端開發 javascript java 區塊鍊 c語言 資料格式 c++ spring java調用c c++ java多線程同步代碼塊 java調用c++ javascript資料可視化程式設計 java調用c
上一篇: 畢馬威聯合阿裡雲釋出《2020消費品生态全鍊路數智化轉型白皮書》
下一篇: CDN加速OSS以及相關問題背景資訊架構優勢常見問題

繼續閱讀