近期业务中台、aPaaS、低代码如火如荼,类似的概念其实在私有化软件产品时代并不新鲜。以SAP为代表的to大企业的软件的大杀器有:
- 功能多,配置多。
- 稳定,不停机。
- 扩展性,可以定制和集成。
稀缺性由低到高,但这些是在产品基本价值之上的锦上添花。
相对而言,这些是可以容忍的:贵、丑、慢。
SAP定义了多种层次的定制级别:
- Customizing: 配置。全公司修改,无代码。
- Personalizaiton: 个性化。用户修改,无代码。
- Modification:修改。改代码,不兼容升级。
- Enhancement:增强。改代码,兼容升级。
- Customer Development:改代码,兼容升级,可发布为产品。
以下重点介绍下最有特点的SAP增强与配置,以为其它软件产品设计做参考。主要材料来源于SAP培训BC_425及其它公开材料。
SAP增强
表增强
可以自定义字段、表。也可以将多个自定义字段组合为可重用的结构体,减少重复维护。
Customer Exit可增强对象
Exit是SAP中对扩展程序的专有名词。SAP代码都是开源的,Function Module是类似于数据库存储过程的过程语言。Function Group里包含Data、Function Module、Subroutine、events等。
Business Transaction Event
BTE是Customer Exit的升级版,可以更好的与外部系统交互,也支持打包为产品。
BTE分为两种,下图左侧的订阅接口可以同时被多个外部系统订阅,所以可以同时触发多个增强实现。右侧的就是传统的流程增强。
Business Add-In
BADI是基于ABAP OO面向对象的开发模式的,这种开发模式与其它的面向对象语言一样,有类、方法等。BADI可以同步改程序、界面、菜单,是一种更高级的增强方式。
以下是上面几种增强方式的对比,最新的BADI肯定是最强的,但这些扩展框架都需要SAP标准产品支持,所以实际应用中最早出现的Customer Exits是应用最广泛的。
修改(源代码)
除了增强外,SAP也支持直接修改源代码。但修改源代码会带来升级兼容的问题,所以SAP提供了以下几种手段来规避或解决升级兼容的问题。
- 尽量复制到客户名称空间
- 通过Transport发布到各个环境。下图即展示了一个典型的Transport环境。
- 对SAP预置对象的修改在升级时会被检测要求兼容。下图即展示了自动检测出的插入、替换、删除的代码块。
SAP配置
SAP配置框架包含几层:
- IMG - Implementation Guide:最基本的配置菜单目录。
- BCSet - Business Configuration Set:可以一键激活以自动配置相关的多个配置项。
- Switch Framework:可以以业务领域,激活相关的多个BCSet以及程序。
详见
https://help.sap.com/doc/7acaf0ba728810148a4b1a83b0e91070/1511%20001/en-US/frameset.htm?4dae4a3aa1352145e10000000a42189e.html
以下就是一个典型的SAP配置界面:
总体上是和维护表字段类似的,这也是为什么可以用BCSet这种表格数据的技术实现的原因。
SAP最佳实践/快速部署解决方案
SAP Best Practices / Rapid Deployment Solutions是SAP为了进一步减少实施时间和成本,开发的配置产品。为什么做配置也需要一个单独的产品?以SAP近年的旗舰产品S/4 HANA为例,功能非常多,有10个领域的近50个大的功能模块。
以Sales - Order and Contract Management功能模块为例,有41个scenario场景。
以Sell from Stock为例,又有好几步配置和业务流程。
所以总共会有上万个配置需要做,每个配置的时间从几分钟到几天不等。这也是为什么SAP实施需要动辄几个月的原因。
所以SAP BP/RDS产品提供了以下的能力:
- eCATT:类似RPA的自动化(测试)工具
- BCSet:可以Transport的配置表的值。
- Document:Configuration Guide / Business Process Documentation
- Solution Builder:包含以上的工具。
- 流程:Scoping -> Master Data -> Activation
通过该产品在系统中激活,即可缩短30%以上的实施时间。
就目前笔者所见,因为绝大多数产品都没有将配置做得这么全,功能也没有这么多,所以SAP BP/RDS产品还是很特别的。