Outlook加载项撰写模式：修改+发送方案

Question

我们正在解决的问题

许多个月以来，我们一直使用makeEwsRequestAsync从外接程序上下文中更新和发送草稿。这种方法面临Outlook缓存模式的局限性，迫使我们在完成过程之前重试EWS请求未知的时间。 考虑到实际客户抱怨处理时间，我们已更改流程并将草稿处理移至后端。

以下是我们要执行的操作的示意图-draft message processing flow

出了什么问题？

将此更改交付生产后，我们遇到了两个主要问题，我们正在尝试调查和解决这些问题。 这里是一些上下文：

• 我们已经将Microsoft Graph访问令牌存储在我们的一侧以访问API
• 我们将在45分钟内重试12次，直到将错误电子邮件发送给客户
• 错误率约为5％

问题

1。在API中找不到草稿

有许多草稿从未在后端保留：failed draft searches over retries。 从6次重试开始，NotFounds数量的增加表明，处理作业能够获得一段时间的电子邮件，但它是由客户手动发送的。

2。草稿正文中没有sync_id

一年前，我们曾尝试在后端使用EWS在后端处理电子邮件，但由于发送的某些电子邮件与客户的期望不符，我们不得不还原电子邮件：电子邮件正文中的随机部分丢失了。假设API同步可能需要一些时间，我们开始使用office-js的{​​{1}}向电子邮件正文插入空链接。看起来像这样：body.prependAsync。通过这样做，我们能够验证通过API收到的草稿已同步到用户按下命令按钮的位置。不幸的是，我们的45分钟重试时间似乎还不够同步。 failed sync_id check attempts

我们想要了解并获得一些帮助的东西：

1. 是否有更好的方法来知道后端的电子邮件处于正确状态？
2. Microsoft Graph API和Outlook REST API是否同时同步，这是真的吗？换句话说-使用这两个API有什么价值？
3. 是否有Windows Outlook Desktop设置可以帮助更快地同步草稿？ （除了关闭缓存模式）
4. 在我们可以在后端获得草案之前，预计最差的情况是什么？
5. 对此有任何其他评论/想法