使用SSIS迁移Dynamics CRM邮件及附件遇错误，求指导

核心实体依赖关系说明 #

先明确你提到的几个实体的作用，避免混淆：

• EmailBase：本地CRM的邮件主数据，对应云端的email实体，是邮件的核心记录
• ActivityPartyBase：存储邮件的参与方（发件人、收件人、抄送、密送），每条记录关联Email的ActivityId（即Email的GUID）
• ActivityMimeAttachmentBase：邮件的附件记录，关联Email的ActivityId；Attachment/FileAttachmentBase属于旧版或非邮件类附件，迁移邮件附件只需关注这个表

错误原因拆解 #

• 'create'方法不支持'activitypointer'类型的实体：ActivityPointer是所有活动的基类，不能直接创建该实体，必须创建具体的email实体，不要选择ActivityPointer作为目标实体
• 用户提供的Entity:'emails'负载中存在错误：通常是邮件必填字段缺失（比如subject、ownerid），或者ActivityParty的partyid未映射到云端存在的用户/联系人GUID，也可能是参与方的participationtypemask（参与类型：发件人=1，收件人=2等）设置错误
• ID为空的'email'实体不存在：附件或ActivityParty先于Email创建，导致关联的Email GUID不存在，迁移顺序完全错误

正确迁移步骤（SSIS+Kingswaysoft） #

步骤1：预处理并迁移Email主数据 #

1. 从本地EmailBase复制数据到临时表，更新关键字段：
   • 将OwnerId替换为云端对应用户的GUID
   • 保留ActivityId（Email的唯一GUID），在Kingswaysoft的CRM Destination组件中勾选「Use Existing Record Id」，确保云端Email使用该ID，方便后续关联
   • 检查必填字段：subject、ownerid等，确保非空
2. 通过CRM Destination组件将预处理后的Email数据同步到云端email实体，这一步必须最先完成

步骤2：迁移ActivityParty（邮件参与方） #

1. 从本地ActivityPartyBase筛选出ActivityId属于已迁移Email的记录（关联临时表的Email数据）
2. 更新字段：
   • PartyId：如果是用户，替换为云端用户GUID；如果是联系人，替换为云端联系人GUID；未知实体可考虑跳过或标记
   • 保留ActivityId（对应已迁移的Email GUID），ParticipationTypeMask（参与类型代码）保持原数值不变
3. 通过CRM Destination组件同步到云端activityparty实体，确保activityid对应已存在的Email GUID

步骤3：迁移ActivityMimeAttachment（邮件附件） #

1. 从本地ActivityMimeAttachmentBase筛选出ObjectId属于已迁移Email的记录（ObjectId对应Email的ActivityId）
2. 更新字段：
   • ObjectId替换为云端Email的GUID（即原ActivityId）
   • OwnerId替换为云端对应用户GUID
   • 确保Body（附件二进制内容）、FileName、MimeType等字段完整
3. 通过CRM Destination组件同步到云端activitymimeattachment实体，注意objecttypecode要设置为email（对应实体代码通常为4202）

关键注意事项 #

• 所有关联实体的GUID必须保持一致：本地Email的ActivityId要作为云端Email的ID使用，这样后续的ActivityParty和附件才能直接关联，避免匹配错误
• 不要尝试直接操作activitypointer实体，所有邮件操作都针对email实体
• 迁移前先在云端测试单条邮件+参与方+附件的创建，确认字段映射正确后再批量迁移

内容的提问来源于stack exchange，提问作者Steve Pearson