這是 Jerry 2021 年的第 74 篇文章，也是汪子熙公眾號總共第 351 篇原創文章。

本來想寫一篇 SAP UI5 應用和 SAP 電商云 UI 開發的語言決定機制的，由于文章篇幅原因，最后決定分成兩篇文章來寫。本文是 SAP 軟件決定機制的概要介紹，下一篇文章再介紹這種決定機制，在 SAP UI5 中的應用。

SAP 軟件中的決定機制，往往容易被忽視，不是因為這種機制不重要，而是因為它廣泛應用于 SAP 各種軟件的前臺和后臺實現中，可以說是無處不在。這就好比我們都知道空氣對于人類的重要性，但很少有人專門去留意空氣的存在一樣。

所謂決定機制，就是基于一個輸入集合，經過分析和處理，產生一個輸出集合。換言之，決定機制包含三部分內容：

(1) 輸入集合。這個輸入集合的數據，可能直接來自終端用戶輸入，也可能來自決定機制的上游業務邏輯的輸出。在運行了 SAP 軟件的客戶系統上，輸入集合的排列組合，理論上可能有無窮多種。

(2) 分析處理引擎。針對幾乎無限多種排列組合的輸入集合，分析處理引擎需要能健壯且高效地進行處理，以不變應萬變。

(3) 輸出集合。分析處理引擎根據輸入集合處理產生的結果。這些結果數據有可能直接返回給終端用戶，也可能作為輸入數據，繼續傳入下游業務的處理邏輯中去。

不難看出，決定機制模塊實現的核心和難點就是其分析處理引擎。

如何實現一個決定機制模塊？

不少朋友在大學第一次學習某門編程語言時，想必都寫過如下風格的代碼。至少我寫過。

IF 條件1.DO 邏輯1.RETURN 結果1. ELSEIF 條件2.DO 邏輯2.RETURN 結果2. ELSEIF 條件3.DO 邏輯3.RETURN 結果3. ELSEIF ... ENDIF.

以上可看作一個簡易的決定機制模塊實現，因為它具備了輸入，處理和輸出三大部分。但它也是一個很蹩腳的實現，因為前文提到，決定機制的輸入集合可能有無限多種可能。如果每次決定機制的需求發生變化，要求支持新的輸入，那么通過新增一個 IF 分支來應對這種需求變化，顯然不現實，根本達不到“以不變應萬變”的效果。

來看看 SAP 怎么做的。

Jerry 工作后遇到的第一個決定機制的例子，是 SAP Business ByDesign 的 Form Template 決定機制。

客戶在 SAP BYD 創建銷售訂單之后，當流程走到 SCM 模塊 的發貨流程時，客戶維護在系統里的電子郵箱，會收到一封 BYD 系統發送的交貨單(Delivery Note)，格式為 PDF.

上圖這個 PDF 在 SAP BYD 系統里通過 Adobe Document Service 生成，調用這個 Web Service 時需要兩個輸入，Form 模板和業務數據。

Form 模板通過 Adobe Form Designer 開發而成，業務數據來自 SAP BYD 系統后臺對應的 Business Objects.

可不要小看這些看似簡單的 Form 模板，為了實現 SAP 產品標準之一的 Internalization，各個不同的國家和地區，因為語言差異和閱讀習慣的不同，包含同樣業務數據的一張交貨單，其 Form 模板布局卻存在差異。比如中文地址的排列順序習慣從大到小，而英文地址的默認順序為從小到大排列。又比如某些國家和地區的閱讀習慣是從右到左(參看 Jerry 的文章：SAP ABAP 業務開關和 SAP 電商云的 Feature Level)，因此 Form 模板布局要能應對所有這些差異。

所以，SAP BYD 的客戶，即使對于同一張交貨單模板，往往也在系統中維護了多個不同版本的模板變體(variants)，這些變體通過國家和語言區分，如下圖所示。

那么問題來了，運行時，負責生成 PDF 的 Form Processor 模塊，如何知道它應該選擇哪個具體的 Form Template Variant 呢？這就得用到 Form Template 決定機制了。

由于 SAP BYD 的后臺 ABAP 源代碼對客戶和合作伙伴是不可見的，因此 Jerry 也無法在文章中截圖發布出來。這里將其邏輯大幅度簡化之后，用文字給大家描述原理。

SAP 決定機制實現的指導方針，用一句話概括就是：盡量把變化的內容放到配置里，而把不變的內容用編碼實現。

更精簡地說：Configuration Over Code - 配置優于編碼。

在基于 ABAP 技術棧的 SAP 產品里，最常見的做法是使用數據庫表里的一條條記錄存儲配置信息。比如 SAP Business Suite，SAP Cloud for Customer，SAP Business ByDesign，SAP S/4HANA 等等。這一條條記錄叫做 Condition Record(條件記錄)，存放這些記錄的表叫做 Condition Table(條件表)。

條件記錄存放了輸入和輸出的映射關系，或者說定義了從一條輸入數據決定出一條輸出數據的規則。

SAP 產品通常會提供專門的 UI 給客戶，作為維護條件記錄的入口，常見的配置界面有基于 SAPGUI 的 SPRO Customizing 和基于瀏覽器的 Business Configuration.

回到 SAP BYD 的 Form Template 決定機制實現。精簡過后的條件記錄集合如下圖所示。注意，下圖的數據只是 Jerry 為了闡述原理而準備的測試數據，和實際業務無關。

國家和語言兩列代表輸入集合，模板變體名稱代表輸出集合。

圖中第二行記錄代表當發貨單的接收方對應的 Business Partner BO 的國家和語言字段為 US 和 EN 組合時，生成 PDF 發貨單使用的模板 ID 為 DELIVERY-NOTE-V1.

以此類推，第三行代表 CN 和 ZH 的組合，使用模板 DELIVERY-NOTE-V2.

第四行中 * 的含義是通配符，如果國家字段有值，但是不為 US 和 CN，并且語言字段有值，但是不為 EN 和 ZH，這種情況下使用模板 DELIVERY-NOTE-VA.

第五行中符號 - 的含義是該字段并未維護值。這行的含義是，如果國家字段為 US,并且語言字段未維護,此時使用 DELIVERY-NOTE-VB.

第六行代表只維護了國家字段，且值不為 US，然后語言字段未維護，此時使用 DELIVERY-NOTE-VC.

最后一行意思是，如果國家和語言字段均未維護，作為最后一道防線，使用模板 DELIVERY-NOTE-VZ.

這樣一來，我們成功將可能出現幾乎無限多種國家和語言的排列組合的 IF 條件，從編碼中移到了配置中。客戶只需要修改配置記錄，就能自行增加對新的國家和語言排列組合的支持。

條件表中的條件記錄，按照優先級從高到低的順序進行存儲。條件信息描述越具體的記錄(比如上圖最前兩行記錄，國家和語言都維護了對應值)，優先級越高。包含了通配符的記錄次之，那些字段沒有維護值的條件記錄，優先級最低。

優先級最低的條件記錄，相當于 IF ELSE 語句里最后一個分支，作為 Fall Back 機制。

決定機制引擎要做的事情，就是根據輸入，到條件表中查詢對應的條件記錄，從匹配的記錄中解析輸出值。

SAP 客戶關系管理解決方案比如 SAP CRM，創建銷售訂單輸入 Sold-To Party 字段后，訂單其余的相關 Business Partners 和 Sales Organization 信息都能夠自動被填充上對應的值(即 SAP 顧問通常所說的“自動帶出來”)：

這種自動填充的行為，通過 SAP CRM Business Partner Determination 和 Organization Unit Determination 機制完成。

SAP S/4HANA 的產品計價決定邏輯也是另一個大名鼎鼎的決定機制實現。在 S/4HANA 訂單行項目里維護產品 ID 和數量，能根據訂單信息，自動決定出該行項目的價格信息。

光數一數下圖每一行條件記錄的字段數就令人咂舌了，可想而知計價場景背后的業務邏輯有多么復雜。

Jerry 2017年的時候有幸去 SAP 德國總部工作三個月，參與 SAP CRM One Order 模型的重構項目(詳情參考我的文章：Jerry的2017, 編程與游泳)。當時我跟著 SAP CRM 首席架構師 Carsten 去和 S/4HANA Pricing 的一位專家開會。Carsten 向我介紹這位專家：他在 Pricing 領域已經工作了二十多年，熟知各種業務場景下的 Pricing 設計和實現，堪稱一部 Pricing Walking Dictionary.

我端詳著眼前這位德國同事，他略顯瘦削，面容清癯，正微笑著注視著我。不算濃密的頭發已經全白，戴一副黑框眼鏡，鏡片后的目光炯炯有神。聽著 Carsten 的介紹，我不由得肅然起敬，他在 Pricing 領域的耕耘時間比我整個職業生涯都還要長。

如果僅靠一維的條件記錄，不足以滿足決定場景的業務需要，那么可以使用一些更加專業的業務規則決定引擎。

在 SAP ABAP On-Premises 產品工作過的 ABAP 開發人員，可能都接觸或者聽說過 Business Rule Framework Plus(簡稱 BRF+)這個框架。

SAP BRF+ 主要包含實現存儲功能的規則倉庫(Rules Repository)，以及根據用戶輸入，分析并執行規則，返回給用戶處理結果的規則處理器(Rules Processor)兩部分。同前文介紹的 SAP 條件表技術相比，SAP BRF+ 支持種類更加多樣的條件數據結構，比如決策表，決策樹和公式等規則建模方式。

在 SAP 電商云里，我們選擇的是支持 Java Rules Engine API 標準的開源業務規則引擎和企業框架 Drools，來作為產品推薦和促銷規則管理引擎。

在 SAP Business Technology Platform 上，我們還可以利用云端的 Business Rules 服務，維護好業務決定規則之后，通過 Restful API 調用的方式，觸發業務規則決定機制的執行。

關于更多 SAP BTP Business Rules 服務的介紹，參考 Jerry 之前的文章：SAP 業務技術平臺(BTP) 上的 Business Rules Service 使用介紹。

如果對傳統的決定機制這種需要事先人工維護條件記錄的方式不滿意，可以嘗試更加智能的決定機制，比如 SAP Cloud for Customer 里借助機器學習實現的 Service Ticket Intelligence.

Service Ticket Intelligence 通過對傳入的客戶 Service Tickets 進行分類(Classify)并在機器學習功能的幫助下，提供推薦(Recommend)和情緒分析，從而避免傳統的服務座席決定機制里繁瑣的座席分配規則的維護，幫助客戶自動化其服務流程并提供更快的解決方案。

總結

本文首先概述了 SAP 決定機制實現的思路，接著用 SAP Business ByDesign Form 模板決定機制作為例子，簡單介紹了其實現原理。最后列舉了 SAP BRF+ 和 SAP BTP Business Rules Service 這些 SAP 自研的業務規則決定引擎，以及開源的 Drools 引擎在 SAP 電商云產品推薦和促銷管理場景中的應用。希望對大家理解決定機制在解決企業復雜業務流程中所起的作用有一個基礎的理解，感謝閱讀。

有了本文的鋪墊，將來的文章，我會分享 SAP UI5 的語言決定機制，敬請期待。

更多閱讀

• 淺談 SAP CRM 和 Hybris Commerce里的價格架構折扣

• 如何在Web應用里消費SAP Leonardo的機器學習API

• 如何對SAP Leonardo上的機器學習模型進行重新訓練

• SAP Leonardo圖片處理相關的機器學習服務在SAP智能服務場景中的應用

• 使用Java程序消費SAP Leonardo的機器學習API

• 機器學習在SAP Cloud for Customer中的應用

• SAP 業務技術平臺(BTP) 上的 Business Rules Service 使用介紹

• SAP 業務技術平臺(BTP) Workflow(工作流)功能介紹

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的SAP 软件的精髓之一：各种各样的决定机制 - Determination Logic的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。