Exchange server 检测Office365 REST mail API中的日历事件邮件项目

我正在通过REST请求和ADAL库成功地从Exchange Online服务器检索用户电子邮件。我们一直在检索和处理日历事件电子邮件及其相关日历事件，这些事件由Outlook、GMail/Google日历、iPad、iPhone和Android设备生成

我们一直在查找meeting.request或meeting.cancelled的ClassName属性，但这些值在一周前被删除，尚未返回。我们现在一直在寻找非Null MeetingMessageType属性MeetingRequest或MeetingCancelled，但截至今天，这些属性也已被删除。这是非常有价值的互操作数据，但我不知道下一步该去哪里查找

如何将从用户邮箱或共享邮箱检索到的json邮件对象与Exchange关联。。。关联日历事件？我们可以使用消息项处理会议创建、邀请、接受等，然后清除这些消息项；然而，查询日历中的新事件和更新事件要密集得多，因为我们当然不能在处理日历事件时将其从日历中清除

我可以在日历中查询相关的邮件ID吗？我无法想象这能为每一条信息做到

谢谢

编辑：@Venkat谢谢。与紧急日历事件标准相比，邮件项目具有无限的可处理性。作为一名Exchange开发人员，我必须问—您是否真的需要一个示例，说明如何更好地将邮件绑定事件作为邮件项而不是日历事件项来处理？好的，很酷，这里有一个：

我们正在做的一件事是将邮件/mtg请求抄送/密件抄送到特定邮箱进行处理，或者使用客户端和服务器规则来完成同样的事情。然后，我们可以轮询单个邮箱、共享邮箱和/或邮箱集合是否自动响应。。。是否移动到特定日历，是否重定向到特定用户，是否在路由过程中更改标题信息以进一步分类，甚至是否替换收件人/与会者等。如果对REST日历请求执行相同操作，我们将失去所有服务器规则自动化，所有客户端规则自动化、过程自动响应、所有标题操作、数据插入/提取等。我们只是尝试使用共享邮箱将事件推送到云应用程序，这些邮箱重定向到特定的守护程序帐户，这些帐户为我们的用户/客户端的特定子集保存日历

和其他人一样，我们正在尝试与云应用集成。因此，我们需要对邮件和日历项进行过程分析、数据处理和推送。因此，首先，我们拥有服务器邮件处理规则、客户端/用户邮件规则、邮件标题修改、轻松的项目数据修改、邮件自动响应控制和盲收件人等巨大优势。日历事件没有得到任何这些东西。第二件事，我们有一个比日历分类法更健壮的邮件文件夹分类法，日历分类法几乎不存在。第三，日历事件邮件项目是特定于用户的，其持久值低于共享日历事件。最后，如果我们以任何方式处理邮件，为什么不至少为事件设置一个eventId？为什么要删除所有互操作信息？拥有eventId完全不需要对返回多个项目的日历端点进行查询，也不需要对邮件端点添加其他查询

Google附带了一个ics。即使从API邮件项中删除了事件项附件，我也不明白为什么必须删除eventId。通过邮件处理日历事件并不是什么新鲜事，但要做到这一点，我们必须在两个对象之间建立数据绑定。仅此而已

我的Exchange Server仍然知道邮件项目何时是日历事件。如果我在休息时再问它，它就不会告诉我了。因此，作为一项粗野的工作，我可以设置一个邮件规则，为所有类型为Meeting Request的传入邮件添加一个api_calendarEvent类别。然后，在对邮件项目进行REST调用之后，我可以解析类别以手动重新填充类属性。但是为什么要从邮件中删除附件、类名、MeetingMessageType和EventId呢？即使我制定了服务器规则，将某些邮箱中的某些邮件项目重新分类为日历事件，并且能够知道何时轮询日历以获取事件详细信息，我是否总是知道轮询哪个日历以查找该事件？为了避免跨多个日历进行盲目轮询，我们需要做的就是保留EventId和/或类名。然后，我们还将再次实现日历处理的大规模自动化，目前已从API中删除

---

谢谢

感谢您对我评论的详细回复！我们希望支持您的方案。作为模式清理的一部分，我们从messag中删除了事件ID和会议消息类型 e、 因为它被包含在每条消息中。对于日历邀请和响应，我们计划添加2个属性： 1.指向相关事件的导航链接，以便您可以单击该事件，并在具有日历权限的情况下对其执行操作。 2.日历响应类型，例如会议已接受、会议已拒绝等，以便您知道收到的页面类型

我们目前正在进行设计，我们没有确切的时间表来分享。但是，一旦有了这个API，我们就会更新我们的文档

[更新]我们现在将日历事件邀请和响应作为EventMessage返回，EventMessage是Message的一个子类。此实体包括名为MeetingMessageType的属性和指向用户日历上相应事件的导航链接。请参见下面的示例：

{
  @odata.context: "https://outlook.office365.com/api/v1.0/$metadata#Users('<snipped>')/Messages/$entity",
  @odata.type: "#Microsoft.OutlookServices.EventMessage",
  @odata.id: "https://outlook.office365.com/api/v1.0/Users('<snipped>')/Messages('<snipped>')",
  @odata.etag: "<snipped>",
  Id: "<snipped>",
  ChangeKey: "<snipped>",
  Categories: [ ],
  DateTimeCreated: "2015-04-08T14:37:55Z",
  DateTimeLastModified: "2015-04-08T14:37:55Z",
  Subject: "<snipped>",
  BodyPreview: "",
  Body: {
    ContentType: "HTML",
    Content: "<snipped>"
  },
  Importance: "Normal",
  HasAttachments: false,
  ParentFolderId: "<snipped>",
  From: {
    EmailAddress: {
      Address: "<snipped>",
      Name: "<snipped>"
    }
  },
  Sender: {
    EmailAddress: {
      Address: "<snipped>",
      Name: "<snipped>"
    }
  },
  ToRecipients: [{
    EmailAddress: {
      Address: "<snipped>",
      Name: "<snipped>"
    }
  }],
  CcRecipients: [ ],
  BccRecipients: [ ],
  ReplyTo: [ ],       
  ConversationId: "<snipped>",
  DateTimeReceived: "2015-04-08T14:37:55Z",
  DateTimeSent: "2015-04-08T14:37:48Z",
  IsDeliveryReceiptRequested: null,
  IsReadReceiptRequested: false,
  IsDraft: false,
  IsRead: false,
  WebLink: "<snipped>",
  MeetingMessageType: "MeetingRequest",
  Event@odata.navigationLink: "https://outlook.office365.com/api/v1.0/Users('<snipped>')/Events('<snipped>')"
}

如果您有任何问题或需要更多信息，请让我知道我们建议的更改是否符合您的要求

谢谢

---

Venkat

嗨，Valleyspirit，你能再解释一下你根据邀请和会议回复邮件所做的处理吗？您是否为每个用户保留任何状态？您说过查询新事件和更新事件的日历要密集得多。你能详细说明一下吗？了解这些信息将有助于我推荐使用Office 365 REST API的正确方法。谢谢。@VenkatAyyadevara MSFT-我已经为你编辑了我的问题。谢谢。嗨，Valleyspirit，我回答了，但还有一个问题。如果您能够通过Me/MeetingMessages集合（与Me/messages集合分开）获取所有会议邀请和响应消息，这是否满足您的场景要求？或者，与会议相关的邮件与所有其他邮件一起出现在“我/文件夹/收件箱/邮件”提要中，这对您的场景是否很重要？如果我的问题不清楚或者你需要更多的背景，请告诉我。谢谢，谢谢！是的，太棒了。这将返回几乎所有项目范围的功能。我的主要问题是，ipad/iphone/android平板电脑/android手机/gmail calendar/MS Outlook的所有日历电子邮件，无论是创建/更新/删除，都可以使用以下消息属性进行处理：ClassName、EventId和MeetingMessageType。当这三个都被移除后，我们的项目就陷入了休眠状态。你将要放回的任何互操作数据，都将是非常棒的。我每天都在关注改进文档，请传递这些需求。谢谢回复：a/Me/MeetingMessages集合：是的，这也是完全合理的，前提是这些消息包含一些类似于日历响应类型和导航链接的数据。谢谢，终点不是太关键，我忘了回复。嗨，valleyspirit，谢谢你的反馈！很抱歉延迟回复。我们正在努力以某种形式公开这些信息，您可以使用这些信息。请继续关注…更新信息和事件消息支持。谢谢