这是 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 的原创文章，尽在：” 汪子熙 ”: