系统整合 · 影片导读
用 Graph 变更追踪影片，设计可对帐的同步流程
变更追踪展示应引出复原问题，而不是被视为完整整合的证明。
观看来源视频
Microsoft 365 Developer · Demo — Microsoft Graph track changes (delta query)Demo — Microsoft Graph track changes (delta query) 前往原网站观看 ↗
点击播放后才会加载 YouTube 视频。
从公开课程介绍开始
Microsoft 365 Developer 在 2021 年 9 月发布 delta query 示范，公开说明介绍如何追踪资料变动。目前文件则区分主动取回变更与接收推送通知。本文根据影片介绍及文件作导读，不表示已完整观看。实施团队接下来应问：同步中断之後，如何知道哪些纪录已处理、哪些仍未接上？
定义哪边是准确纪录
假设公司把客户目录同步到内部请求应用，先决定每个栏位由原目录还是应用负责。同步检查点与业务完成状态要分开保存；看到变更，不等於所有相关纪录都已安全更新。若来源权责不清，整合可能在下次同步时静默覆盖员工有效修改，让资料看起来一直在更新，实际却越来越不可靠。
流程一览
演练漏收与重复变更
测试重复事件、删除纪录、分页读取失败与长时间中断。建立能比较来源及本地识别码的对帐程序，也不要假设通知抵达次序就是业务发生次序。演练要找出本地应用必须保证的事情，而不是从影片顺畅的展示推定平台已有某种保证。每个差异都应能交给负责人查看和处理。
核实支援范围再承诺
承诺同步能力之前，先核实目前 API 对哪些资源与环境提供支援。保留人工对帐渠道，并让员工看见本地资料最後更新时间。旧的官方影片是良好的学习起点，但正式实施仍须以目前参考文件与端到端测试为准。若用户无法辨认资料已经过时，整合再快也可能引导他们作错决定。
可以立即进行的练习
演练修改、删除及中断，让操作人员不用通知数量猜测，而是逐项对帐。记录识别码和检查点，把未写下的复原知识加入指引後，才批准整合。首次连线成功不代表可营运。也应在来源暂时不可用时，观察介面如何显示过时资料；若使用者仍以为内容最新，就要先改状态提示，而不是只增加後台重试，让他们在未知情况下作出决定。
来源与延伸阅读
- Demo — Microsoft Graph track changes (delta query)Demo — Microsoft Graph track changes (delta query)Microsoft 365 Developer · Video source ·
- Use delta query to track changes in Microsoft Graph dataUse delta query to track changes in Microsoft Graph dataMicrosoft Learn · 官方文件 ·
编辑原则
本系列以 AI 辅助原创撰写，并对照连结的公开来源。实作建议与假设情境属编辑分析，并非客户实绩。来源发布日期及产品细节可能与本系列整理日期不同。