6

手头的问题

我们的 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 将一些评论与搜索文件夹和受限视图联系起来，但我不确定这些是否适用于我们的情况。

将视图应用于文件夹的操作会在存储中创建搜索文件夹。创建搜索文件夹时，会对其进行缓存以供以后使用。如果用户尝试创建已经存在的搜索文件夹，则使用缓存的搜索文件夹。这使得未来的观看变得相当快。默认情况下，Exchange 不会无限期地缓存所有搜索文件夹。

特别是关于 EWS：

同样重要的是要知道第一次发出 Exchange 存储搜索查询时，它会运行得非常缓慢并且可能会超时，而在以后的运行中它会毫无问题地响应。这是由执行存储搜索时在 Exchange 服务器上发生的后端进程引起的。

他们建议为不变的、非动态的查询创建搜索文件夹，这在我们的案例中似乎不合适，因为每个约会的查询都不同。

如果应用程序需要具有一组固定不变参数的特定查询，您可以使用搜索文件夹。[...] 搜索文件夹仅对不变的、非动态的查询有用。

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

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

4

4 回答 4

6

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

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

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

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

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

无论如何，我并不声称自己是 EWS/Exchange 的所有方面的专家，所以也许有比这更好的方法。带上一粒盐。

于 2013-11-16T01:03:39.663 回答
3

没有办法为您的财产启用索引。我不熟悉哪些属性在 Exchange 2007 中被索引。由于您的应用程序似乎正在使用约会，也许您可​​以重新利用其他非约会属性之一来存储您的唯一值。也许通过扩展属性使用 AssistantName 属性（以解决 EWS 架构和服务施加的限制）。这样，大多数客户端将不会将该属性用于日历项目。

根据此主题，http ://technet.microsoft.com/en-us/library/jj983804(v=exchg.150).aspx ，该属性已编入索引（2013 年）。该属性已存在很长时间，因此它可能会在 2007 年被编入索引。

嘿，这是一个长镜头，无论如何都不是最佳选择，但也许它可能适用于您的场景。

于 2013-11-14T02:01:56.203 回答
1

再阅读此线程后，我发现您不是在寻找具有扩展属性的所有项目，而是特定项目。抱歉，我在第一次回复中没有注意到这一点。我同意单独的搜索文件夹对您不起作用，因为您每次搜索项目时都需要更新过滤器。这显然会非常昂贵（可能比您当前的方法更糟）。我的一个想法是创建一个按您的扩展属性排序的视图。我可能是错的，但我相信您可以将此视图应用到上面的搜索文件夹（请注意，我说的是显式创建搜索文件夹和视图并将它们存储在邮箱中，它们可以隐藏或暴露给 OL UI在搜索文件夹树下）。搜索文件夹将仅过滤具有您的扩展属性的约会。然后视图将按属性值对文件夹进行排序。在我对 ESE 内部进行的一些阅读中，我看到一些评论表明按属性排序将导致 Exchange 在 ESE 上创建索引（希望我现在能找到它）。ESE B-Tree Indexes 部分似乎证实了这一点：http://books.google.com/books?id=12VMxwe3OMwC&pg=PA73&lpg=PA73&dq=how+to+create+exchange+ese+indexes&source=bl&ots=D5hJyJIEo5&sig=ppZ6RFJh3PnrzeePRWHFJOwXgeU&hl=en&sa=X&ei=QQ7HUtgggvTbBdjcgfAP&vedone=0CFQQQ=QQ7HUtgggvTbBdjcgfAP&vedone=0CFQQ如何%20to%20create%20exchange%20ese%20indexes&f=false

然后，您必须使用上面在搜索文件夹中使用的相同方法来查找与您的条件匹配的特定项目。一个挑战当然是 Exchange 丢弃您的索引的问题（这可能是您当前方法中正在发生的事情）。也许您可以定期以编程方式触摸搜索文件夹以确保不会发生这种情况？此链接还有助于了解创建搜索文件夹/视图的性能影响：http ://technet.microsoft.com/en-us/library/cc535025%28EXCHG.80%29.aspx

如果您找到了一个好的解决方案（或者这个解决方案有效），我很想知道它（我相信很多其他人也是）。哦，交流发展的乐趣:-)

于 2014-01-03T20:16:29.963 回答
0

使用您的扩展属性创建一个搜索文件夹作为标准是要走的路。您将在最初构建搜索文件夹时付出代价，但在创建索引后，只要该文件夹存在并且正在运行，它就会由 Exchange 自动更新。我们使用这种技术非常成功地找到了众所周知的“大海捞针”。

http://msdn.microsoft.com/EN-US/library/dd633687(v=exchg.80).aspx

于 2013-11-15T17:10:13.897 回答