SAP 软件的精髓之一：各种各样的决定机制 – Determination Logic

SAP 软件中的决定机制，往往容易被忽视，不是因为这种机制不重要，而是因为它广泛应用于 SAP 各种软件的前台和后台实现中，可以说是无处不在。这就好比我们都知道空气对于人类的重要性，但很少有人专门去留意空气的存在一样。

所谓决定机制，就是基于一个输入集合，经过分析和处理，产生一个输出集合。换言之，决定机制包含三部分内容：

(1) 输入集合。这个输入集合的数据，可能直接来自终端用户输入，也可能来自决定机制的上游业务逻辑的输出。在运行了 SAP 软件的客户系统上，输入集合的排列组合，理论上可能有无穷多种。

(2) 分析处理引擎。针对几乎无限多种排列组合的输入集合，分析处理引擎需要能健壮且高效地进行处理，以不变应万变。

(3) 输出集合。分析处理引擎根据输入集合处理产生的结果。这些结果数据有可能直接返回给终端用户，也可能作为输入数据，继续传入下游业务的处理逻辑中去。

不难看出，决定机制模块实现的核心和难点就是其分析处理引擎。

如何实现一个决定机制模块p>

不少朋友在大学第一次学习某门编程语言时，想必都写过如下风格的代码。至少我写过。

以上可看作一个简易的决定机制模块实现，因为它具备了输入，处理和输出三大部分。但它也是一个很蹩脚的实现，因为前文提到，决定机制的输入集合可能有无限多种可能。如果每次决定机制的需求发生变化，要求支持新的输入，那么通过新增一个 IF 分支来应对这种需求变化，显然不现实，根本达不到“以不变应万变”的效果。

来看看 SAP 怎么做的。

Jerry 工作后遇到的第一个决定机制的例子，是 SAP Business ByDesign 的 Form Template 决定机制。

客户在 SAP BYD 创建销售订单之后，当流程走到 SCM 模块 的发货流程时，客户维护在系统里的电子邮箱，会收到一封 BYD 系统发送的交货单(Delivery Note)，格式为 PDF.

那么问题来了，运行时，负责生成 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 为了阐述原理而准备的测试数据，和实际业务无关。

Jerry 2017年的时候有幸去 SAP 德国总部工作三个月，参与 SAP CRM One Order 模型的重构项目(详情参考我的文章：Jerry的2017, 编程与游泳)。当时我跟着 SAP CRM 首席架构师 Carsten 去和 S/4HANA Pricing 的一位专家开会。Carsten 向我介绍这位专家：他在 Pricing 领域已经工作了二十多年，熟知各种业务场景下的 Pricing 设计和实现，堪称一部 Pricing Walking Dictionary.

如果仅靠一维的条件记录，不足以满足决定场景的业务需要，那么可以使用一些更加专业的业务规则决定引擎。

在 SAP ABAP On-Premises 产品工作过的 ABAP 开发人员，可能都接触或者听说过 Business Rule Framework Plus(简称 BRF+)这个框架。

在 SAP 电商云里，我们选择的是支持 Java Rules Engine API 标准的开源业务规则引擎和企业框架 Drools，来作为产品推荐和促销规则管理引擎。

在 SAP Business Technology Platform 上，我们还可以利用云端的 Business Rules 服务，维护好业务决定规则之后，通过 Restful API 调用的方式，触发业务规则决定机制的执行。

Service Ticket Intelligence 通过对传入的客户 Service Tickets 进行分类(Classify)并在机器学习功能的帮助下，提供推荐(Recommend)和情绪分析，从而避免传统的服务座席决定机制里繁琐的座席分配规则的维护，帮助客户自动化其服务流程并提供更快的解决方案。