c# - 在 Exchange 上使用扩展属性缓慢搜索项目

Question

手头的问题

我们的 C# Windows 应用程序使用 EWS Managed API 2.0 在用户的日历中创建约会。每个约会都有一个具有唯一值的扩展属性。它稍后使用 FindItems 定位约会和一个 ItemView .

第一次执行此搜索时，用户会遇到明显的延迟。随后的响应时间是完全可以接受的。

(“第一次”在这里有点含糊，因为用户可能会在当天晚些时候再次遇到延迟)

// locate ID of appointment where extended property value equals 1234:
var filter = new Ews.SearchFilter.IsEqualTo(extendedPropertyDefinition, 1234);
var view = new ItemView(1, 0);
view.PropertySet = BasePropertySet.IdOnly;
var folder = new FolderId(WellKnownFolderName.Calendar, new Mailbox("..."));
var result = service.FindItems(folder, filter, view);

远程服务器是 Exchange Server 2007 SP1。

研究

MSDN ties some comments to search folders and restricted views ，但是我不确定这些是否适用于我们的情况。

The act of applying a view to a folder creates search folders in the store. When a search folder is created, it is cached for later use. If a user tries to create a search folder which already exists, the cached search folder is used. This allows future viewings to be fairly quick. By default, Exchange does not cache all search folders indefinitely.

特别是with regard to EWS :

It is also important to be aware of the fact that the first time an Exchange store search query is issued, it will run very slowly and possibly time out, whereas on future runs it will respond without issue. This is caused by back-end processes that occur on the Exchange server when a store search is performed.

他们建议为不变的、非动态的查询创建搜索文件夹，这似乎不适合我们的情况，因为每次约会的查询都是不同的。

If an application requires a specific query that has a fixed set of nonchanging parameters, you can use search folders. [...] search folders are useful only for nonchanging, nondynamic queries.

本质上，我们需要的是在该属性上创建一个“索引”(用数据库术语来说)，确保对该特定属性的所有搜索都是快速的，无论时间或频率如何。

是否可以“索引”此属性？可以在客户端或服务器端配置任何东西来消除这个初始延迟吗？

Answer 1

我在一个集成项目中遇到了同样的问题。我希望有一个好的解决方案...

您不能为 Exchange 尚未编制索引的属性创建索引。如果约会数量增长到足够高，则为每个人创建一个搜索文件夹是不可行的。单个文件夹中的搜索文件夹太多会导致更多问题，因为在将新项目添加到文件夹时，它们都需要更新。至少这是我的理解。此外，Exchange 2007 限制为每个父文件夹有 11 个动态搜索文件夹，因此根据约会的数量和访问频率，它可能更不可行。使用现有的索引属性可能不可行，因为用户可能会在应用程序之外更改这些属性。如果您有某种方法可以确保只能从您的应用程序访问或更改您创建的约会，那就另当别论了。

数据库表是一个很好的方法，但是有一个潜在的障碍，有些人直到为时已晚才看到。 ItemId 是链接到扩展属性的明显选择，但 ItemId 不是常量。它是基于其他几个计算得出的属性。如果将项目移动到另一个文件夹，它可能会发生变化，并且它也可能随着服务包的安装或经过足够的时间而发生变化，或者我听说过。我至少可以确认第一个。 ItemId 对于长期存储是不可行的，至少在没有额外检查的情况下是这样。您可能会存储 ItemId 和您的扩展属性。如果使用 ItemId 的绑定(bind)失败，则回退到扩展属性搜索。如果绑定(bind)成功，则根据数据库中的扩展属性检查它以确保它匹配。如果项目不匹配，请在获得项目后更新 ItemId。您是否需要处理 Appointment 对象之外的任何内容，即 session 响应、转发通知等，或者这只与日历有关？

虽然不漂亮，但应该是一个比较合理的妥协。您可能仍然偶尔会进行搜索，但只要用户不决定将约会移动到不同的文件夹或提前计划一些约会，它们就应该很少见，即使这样同步也应该有助于缓解这种情况.如果 Exchange 升级，请准备好重新填充该表。

当然，如果 Microsoft 已经添加了索引其他属性的功能，或者甚至为此目的在 Exchange 搜索中的索引中添加了一两个空白字符串字段，我们就不会遇到这个问题。哎呀，约会和关联对象的 GlobalObjectId 属性的索引会有所帮助，但唉......没有。我不喜欢重新利用现有的索引字段。并非所有这些都适用于约会，而那些往往是用户需要或可编辑的。除非您确切地知道自己在做什么，否则重新调整这些领域的用途可能会在未来产生不可预见的后果。

无论如何，我并不声称自己是 EWS/Exchange 所有事务的专家，所以也许有比这更好的方法。对此持保留态度。