背景
这几年经历的项目，大量的需求都是和第三方系统集成，SAP ECC是名副其实的主数据系统。
一旦涉及集成，都离不开主数据同步的问题，SAP有MDM系统（自己也没用过，从一些资料上来看还是要一定的二次开发），上MDM公司的好像也不多。既然数据就在ECC，使用ABAP来完成ETL，并搭建一个分发的框架。
以物料主数据为例，手头的这个系统，至少要同步OA、BPM、WMS、MES、CMS、SRM六套系统！维护代码就是一个萝卜一个坑，同步方式差别也比较大。
数据接口主要考虑的问题
所有的开发都是在应用程序服务器层面，ECC屏蔽了底层数据库细节，无法应用数据库机制，比如触发器，数据库日志等。
要考虑的问题很多，归纳了主要的三类：
1. 接口方向
就SAP而言，就PUSH和PULL两种模式：
-
PULL模式 第三方系统调用SAP接口
常见场景SAP 提供RFC接口 或者 Webservice，新一点的平台可以提供Odata服务。 -
PUSH模式
-
直接调用第三方接口
webservice和http的接口比较常见,SAP内部还有idoc，也有一些比较偏门的需要调用控件（必须基于SAP GUI）。 -
输出到"中间载体"
-
文件
配合目录监控，FTP服务等，有时也手工导入导出文件。 -
中间表
第三方系统直接访问中间表，这个表可以是SAP系统的自定义表，也可以不是。 -
运行脚本
ABAP有时候限制很多，不妨考虑SAP输出一个脚本文件，比如python，再调用这个脚本文件，同理的windows下还有bat脚本。
如果SAP GUI的话，还可以调用js，vbs！思路是GUI调用
windows的MSHTA命令。
-
-
-
混合模式
SAP通过增强或者后台程序，写入中间表，并提供接口供第三方系统从中间表取值。
2. 时效性要求
-
高
允许一定的时间差，比如1H，轮询PULL或者实时PUSH均可，要求实时同步就是实时PUSH模式。
-
中低
推荐第三方系统轮询SAP接口
实时方式与其他方式的对比
实时一般就是SAP PUSH模式，直接调用第三方接口
简单的对比：
| 实时PUSH模式 | 其他PULL模式 | |
|---|---|---|
| 实时性 | 好 | 一般 |
| 查找增强 | 是 | 否 |
| 额外推送接口 | 是 | 否 |
| 监控及预警 | 是 | 否 |
| 数据包顺序控制 | 增量时需要 | 不需要 |
总而言之，实时模式对业务来说最理想，对开发而言需要的开发工作量可能是RFC接口模式的2~3倍，甚至更多。
-
第三方系统差异很大，调用难易程度不等，有些系统调用先要通过认证，然后才能调用，这部分系统一般没有abap的包，登录认证公钥加密私钥解密，特定格式的数据包等等都要从零开始开发。
-
要想实时模式运行顺畅，额外的监控程序是必不可少的。
-
在增量数据同步时，还要考虑数据包顺序发送，以及上个数据包是否发送成功，实际项目中有限的人天，挑战比较大。
3. 数据组织方式
全量
整张表的所有数据直接覆盖。简单粗暴，实现难度低。
适合数据量不大，抽取时间代价明显小于增量算法的代价。同步过程即使存在失败也没问题，只要最新一次同步ok就行，不需要额外的纠错机制。
第三方系统在处理时，还有一定的操作空间，比如发现数据库已有就忽略，仅关注新增，不考虑删除。
适合基础数据的同步，比如公司代码，科目表之类。
对于变化频率极低的表，不妨直接考虑手动+全量同步。
增量
增量同步似乎更容易让人接受，仅更新变化的部分。抽取的代价和更新的代价都比较小，难度都集中在增量算法上。增量算法太复杂，可能就是个无底洞。
定义几种常见的增量级别：
-
业务对象级别(伪增量) Business Object
这个业务对象，任意属性有变更，更新整个业务对象的所有数据。在业务对象的级别，就是全量，只不过相较于全表更新的模式算是增量。好处就是相对简单，不需要考虑变化过程。
-
组件级别 Component Of Business Object
简单的说，就是业务对象有几张表，仅关注发生更改的表，把具体的更改记录（整行数据）一起同步。 这种比较常见，难点还是在增量算法，并且考虑实际业务场景中是否关注删除操作。
-
字段级别 Field Of Component
相当于数据库更新操作日志，哪张表具体哪个字段，发生了变更。SAP的话利用标准的Change Document 技术。
增量算法
不考虑DB层面，都是基于AS层面考虑。
-
基于时间戳
如果是目标数据表上本身的时间戳，删除操作是无能为力的。 -
全表对比
可以在SAP实现，也可以在第三方实现。
SAP有个非常有用的函数
CTVB_COMPARE_TABLES；第三方系统中的话，考虑基于MD5值得校验。
- 自定义变更日志表
-
基于增强
按标准增强中产生增量数据，写入变更日志表。
-
基于后台任务
后台任务大多也是基于时间戳，提取变更数据，然后生成变更日志。
-
4. 综述
涉及数据同步时，分析步骤如下：
-
按照业务场景，确定接口方向
-
确定数据包格式（增量 or 全量）
-
确认数据包生成机制
-
考虑监控及纠错机制
个人认为，简单稳定优先，开发交付快的优先，牺牲点性能其实也能接受。
数据同步允许一定的差异，允许垃圾数据存在，有时能大大简化方案，比如删除数据不需要同步。
网友评论