SAP 软件的精髓之一：各种各样的决定机制 - Determination Logic
这是 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 的语言决定机制，敬请期待。
更多阅读