SAP SuccessFactors利用元数据框架（MDF）对象和业务规则做很多事情。业务规则适用于许多不同的情况，并且有大量关于如何使用它们的文档。不幸的是，这里明显缺乏定制解决方案的指南。
如果一个企业必须使用几个相连的业务规则，他们如何从这些规则中实现他们期望的行为？
可悲的是，业务规则并没有得到非常明确的解释，这让那些想要实施定制解决方案的企业感到他们必须通过实验来找出事情的真相。我们将介绍企业在构建使用MDF对象的业务规则的定制解决方案时需要了解的一些基本知识。
将场景上下文切换为“基于 MDF 的对象的规则”
基本场景不是为使用基于 MDF 的对象而设计的，因此场景“基于 MDF 的对象的规则”更适合我们正在尝试做的事情。它为企业提供了很多好处，其中包括：
- 完全内置于扩展中心
- 仅涵盖适合特定用途的功能
- 允许从业务规则导航到调用它的事件
每当企业打算使用 MDF 对象时，建议他们使用这些“基于 MDF 的对象的规则”，因为该场景对用户友好且可靠。
创建新规则
创建新的自定义规则会显示需要编辑以完成规则设置的字段。
规则 ID
仅在未选择对象时可编辑。ID 至关重要，因为它是我们导入和导出业务规则及其对对象定义的分配的方式。规则名称应包含有关规则的固定事实，例如：
- 实施项目的简称
- 基础对象代码
- 规则的目的
- 保存业务规则的代码类型
因此，例如，有效的规则 ID 可能类似于 COMPANY_Position_externalCode_Evaluate。
规则名称
规则名称可以随时更改。规则名称和规则 ID 在配置工具中表示时始终可见。因为规则名称在系统内的 UI 中是可见且可修改的，所以它是存储有关规则的可变数据的理想场所。项目如：
- 诸如“被删除”或“被替换”之类的操作。
- 任何调用规则的事件
- 规则的执行顺序
- 前一个规则 ID（如果有此规则的前任规则）
- 可变的 IF 条件以及要更改哪些字段等。
分配事件顺序
在任何事件中，添加到事件中的业务规则都按照添加的顺序执行。通常，如果规则是独立的，这不会引起任何问题。但是，某些规则需要先前规则的结果。在这些情况下，执行顺序对于确保没有中断至关重要。将规则链接在一起并不少见，但某些配置往往比其他配置发生得更多。配置这些链时，OnLoad- 和 Initialize-Purposed 规则可能很复杂。供应商-消费者链应避免实施这样的链。Evaluate-Purposed 规则经常出现在消费者-供应商链中，并适用于 OnChange 和 Save 事件。
不幸的是，工作流专用规则不尊重对象定义中的分配顺序。他们在事件中具有固定的位置。在 Sve 事件上，首先执行工作流专用规则。在删除事件上，工作流专用规则在其他所有内容之后运行。
测序事件
事件根据对象上发生的操作进行排序。
编写业务规则的提示
那么，企业在制定自定义业务规则时应该注意什么？
- 业务规则应尽可能简单（KISS 原则）
- 如果存在复杂的条件（IF 语句），则应尽可能简化它们
- 应避免对大量参数使用逻辑组合（AND 语句）
- 首先应说明最可能的情况
- 任何使用重复计算或“魔术”数字的东西都应该用变量代替
- 业务规则永远不应替代关联和字段标准。
乍一看，构建自定义业务规则可能看起来很复杂。但是，一旦一个人了解了后端是如何完成的，就更容易掌握如何编写成功的规则。他们应该有一个深思熟虑的名称和 ID，以便任何使用它的人一目了然地描述规则。他们还应该尽可能地简单，但不要简单到一事无成。在制定这些规则时要找到平衡点需要一些实践，但值得拥有一个更精简的系统来处理可能影响业务效率和生产的复杂条件。