一. 映射关系原理

中间表: (存放于集成平台)

CRM对象数据ID	第三方对象数据ID
CRMID1	ThirdID1
CRMID2	ThirdID2
CRMID3	ThirdID3

中间表新增映射关系的情况:

1. CRM中新建某对象数据A，触发了集成流，集成平台根据集成流中配置的字段映射关系新建了一个第三方对象数据a，于是中间表中便新建ID映射关系: A的ID <——> a的ID
2. 第三方系统新建某对象数据A，推送/轮询触发了集成流，集成平台根据第三方系统推送过来的数据新建了一个第三方对象数据a，集成平台根据集成流中配置的字段映射关系新建了一个CRM对象A，于是中间表中便新建ID映射关系: A的ID<——>a的ID

二. 数据同步(流转)原理以及对集成平台的思考

数据同步(流转)原理

本质: 一切数据流转都是走的WEB API

1. CRM -> 第三方系统: 走的是第三方系统WEB API

2. 第三方系统 -> CRM: 走的是纷享的WEB API

对集成平台的思考

既然本质都是走的WEB API，那么为什么不采用如下方式:

1. CRM -> 第三方系统: 直接工作流 + 自定义APL代码(调用第三方系统公网接口推送数据)
2. 第三方系统 -> CRM:
   1. 轮询方式:
      1. 计划任务定时调用APL代码(调用第三方系统公网接口查询数据，将返回结果与CRM里的对象进行比对)
      2. 如果有不一样的数据，则同一套APL代码里直接对CRM对象进行字段更新即可
   2. 推送方式:
      1. 第三方系统直接调用纷享的WEB API来对对象数据进行CRUD

我认为上述方案完全可实现集成平台数据同步的功能，那么为什么需要集成平台呢?

有最关键的两点:

1. 配置、编码简易化
2. 数据同步可视化

再者如果对接的第三方系统是常见的金蝶K3Cloud、SAP、用友U8等，便可以直接利用现成的连接器来实现数据同步，降低了实现数据同步的配置与编码成本。

如果对接的第三方系统是自研系统，那么需要自己在通用连接器中进行对象配置、对象字段配置、对象API配置，还是有一定的配置与编码成本的。任何一个涉及第三方系统数据的接口都得利用自定义函数实现。

三. 在实际对接案例中学习

思考了一下，把自研系统放在前面写更好，毕竟对接自研系统是从0到1，更能加深对集成平台理解

自研系统: 迈维自研(不具有现成连接器)

CRM -> 自研系统

以项目券使用评论对象为例:

自研系统 -> CRM

以子项目对象为例:

第三方系统: 金蝶K3Cloud(具有现成连接器)

CRM ->K3Cloud

以销售合同对象为例:

K3Cloud -> CRM

以样品BOM对象为例