无modifiedon/versionnumber字段时，Dynamics 365 CRM增量同步至SQL Server方案咨询

1. 启用Dynamics 365变更追踪（Change Tracking） #

这是最推荐的官方原生方案，无需自定义字段即可实现增量同步：

• 启用步骤：在Dynamics 365解决方案中找到目标实体（如gitorganization），开启「变更追踪」选项（需系统管理员权限）。
• SSIS实现方式：
  • 使用Dynamics 365官方数据源组件，或通过Script Component调用Web API。
  • 首次同步时获取初始变更令牌（changetoken），后续同步通过RetrieveEntityChanges消息或Web API的$filter=__nextchangetoken eq '<上次令牌>'参数，仅拉取上次同步后新增、更新、删除的记录。
  • 同步完成后更新存储的变更令牌，用于下次增量拉取。
• 优缺点：无需自定义开发，原生支持增删改的增量捕获；但要求Dynamics 365版本为2016及以上，且变更追踪有默认90天的数据保留期（可配置）。

2. 自定义变更标记字段 #

若无法启用变更追踪，可通过添加自定义字段实现增量：

• 操作步骤：
  • 在Dynamics 365中给目标实体新增LastModifiedSync（日期时间类型）字段，默认值设为当前时间。
  • 创建Dynamics 365插件或工作流，当实体记录新增、更新时，自动将LastModifiedSync更新为当前时间。
• SSIS同步逻辑：
  • 每次同步前，读取SQL Server配置表中存储的上次同步最大时间戳。
  • 从Dynamics 365拉取LastModifiedSync > 上次时间戳的记录，完成新增/更新操作。
  • 针对删除记录，可每周执行一次全量比对（删除操作不会触发插件更新时间戳），日常同步仅处理增改。
• 优缺点：实现简单、可控性强；但需自定义开发插件/工作流，且无法直接捕获删除操作，需额外处理。

3. 基于哈希值的增量优化 #

针对现有全量方案做效率提升，减少数据传输量：

• 优化逻辑：
  • 首次同步时，将主表记录的主键和所有字段的哈希值（如HASHBYTES('SHA2_256', CONCAT(gitorganizationname))）存储到SQL Server的哈希对照表中。
  • 后续同步时，先从Dynamics 365拉取所有记录的主键和对应哈希值到临时表。
  • 对比临时表与哈希对照表的哈希值，找出新增、哈希值变化（更新）、主表存在但临时表不存在（删除）的记录。
  • 仅针对差异记录，从Dynamics 365拉取完整字段数据同步，并更新哈希对照表。
• SSIS实现：用Lookup组件对比哈希值，通过Conditional Split区分增删改操作。
• 优缺点：无需修改Dynamics 365配置，大幅减少全量同步的数据量；但仍需拉取主键+哈希值的全量数据，极端大数据集下有一定开销。

4. 利用Dynamics 365审计日志 #

若实体已开启审计功能，可通过审计日志捕获变更：

• 操作步骤：
  • 确保目标实体已开启审计（在实体设置中启用「审计」选项）。
  • 在SSIS中查询Dynamics 365的Audit实体，过滤ObjectTypeCode为目标实体的类型代码，以及Action为创建（1）、更新（2）、删除（3）的记录。
  • 通过审计日志中的ObjectId关联原实体记录，更新操作需解析Detail字段的XML内容获取变更后的值。
• 优缺点：可捕获所有变更操作（包括删除）；但审计日志存储有上限，且解析更新字段的XML较为繁琐，适合对变更溯源有要求的场景。

内容的提问来源于stack exchange，提问作者Mahin Sojitra