2014年5月30日,星期五

谈到Office 365 API和“modern” 的SharePoint dev techniques 在 the 的SharePoint Evolutions 2014 Roadshow

 Speaker_web_banner I’我一直处于低头模式,最近准备了两个新的演讲,我’我期待着即将到来的 的 SharePoint演进路演 这里 in the UK. It’将会是一件大事– pretty sure it’s the first time I’ve heard of a “roadshow” conference, but it’s a great idea! As usual for the 的SharePoint Evolutions event, 那里 ’出色的演讲者阵容 来自英国,欧洲,美国和其他地方。该路演总共访问了12个英国地点 – I’我在伦敦和剑桥演讲,但是许多其他演讲者(包括美国佬)都在很多地方做演讲!即使这样,也不会有两个地点的发言者/内容完全相同,因此,超过一天的想法也是可行的。

I’ll be 请讲 on:

 

Office 365的新开发人员API简介–伦敦,6月10日,下午3:45

[这是与 韦斯·哈克特(Wes Hackett) ]

Microsoft已声明,他们将从SharePoint,Exchange和Lync API转向通用Office 365 API。首批API的预览版已于2014年3月发布,涵盖了用户协作的几个核心构件-包括邮件,OneDrive文件,日历条目和联系人。需要了解Office 365 /混合方案的开发人员可以期望将来会有更多此类API。我们’将演示核心REST API,最近发布的.NET客户端API(有助于简化身份验证等),甚至演示如何从“多设备混合应用”(aka Cordova)使用适用于Office 365的新JavaScript API。

尽早上车-来了解API和新的权限模型("共同同意框架")。

Modern 的SharePoint Development - techniques for moving code off 的SharePoint servers –剑桥,6月11日,下午1点

那些实施Office 365的人知道自定义代码无法在SharePoint服务器上运行,因此必须使用远程代码替代方法。但是,采用相同的方法可能很有价值"cloud-friendly"开发技术,甚至适用于本地实施。除了提高平台稳定性之外,这还使您能够为部署增加灵活性,从而无需进行重大重新设计就为将来可能迁移到Office 365敞开了大门。通过几个以代码为中心的演示,本次会议探讨了切换到"off-box"代码-包括远程事件接收器,PowerShell和CSOM脚本,以及对基于JavaScript的方法的致谢。我们’我还将深入了解Microsoft’Office App模型样本(AMS)以及为什么要关心它们。

It’还不算太晚-说服您的老板您需要参加一天的活动!

由于路演是基于一系列一日活动的想法,因此’从办公室和客户那里获得一些关键知识(比之为3天的会议)要少得多。当你’d期望,成本也更低(£每天125个)和组织者( 综合知识 )甚至提供了“注册1,免费获得1”在活动结束时限时提供! 

有关更多信息,请访问:

//www.sharepointevolutionconference.com

2014年5月1日,星期四

Office 365混合和搜索– presenting results from both on-premises and 的SharePoint Online sites

在我以前的有关Office 365和本地SharePoint混合部署的文章中,我们讨论了一个想法,尽管在很多情况下它可能是正确的解决方案,但混合部署并不简单,实际上仅包含搜索,BCS和Duet(对于SAP)集成。与文档管理,站点/导航,元数据,自定义以及您可能要提及的其他任何事物有关的其他方面都不会以任何方式同步或合并。提醒一下,这些文章的结构如下:

  1. Office 365 的SharePoint hybrid – what you DO and DON’T get
  2. Office 365混合和搜索–展示双方的结果[本文]

即使在搜索(混合动力的基石之一)中,您获得的也不是’re hoping for – results from the “remote”环境将显示在单独的结果块或升级结果中。这里’提醒您(更强大的)结果块方法:

的SharePoint混合搜索结果-结果块

显然这不是’最佳的用户体验。替代方案“促进结果”更多地是关于定义 个人 结果显示在给定搜索的顶部(即最佳匹配)– so that’对于单个结果非常有用,但对整个结果却不是。

上次,我讨论了当前经验可能引起的一些问题:

  • 第1页上应显示多少个结果(来自每个来源)?
    • 暗示– you’无论如何,最多只允许10个结果块:)
  • 那分页呢?当我转到第2页时会怎样?
  • 如何从这两个来源轻松看到更多结果?
  • How do I determine which results are more relevant, from the local or 远程 environment?
  • 是否有任何其他选项可以更全面地查看结果?
有关此主题的重要新闻(2014年4月)
在最近的2014年SharePoint大会上,Microsoft表示他们正在研究此问题(混合部署中搜索结果脱节),并希望在今年晚些时候找到解决方案。因此,希望整个问题能在某个时候消失。无论如何,我认为’仍然值得讨论当前的情况以及解决该问题的可能的临时技术。

 

调查中–可以使用代码合并结果吗?

因此,考虑到当前开箱即用的用户体验的局限性,我很想看看是否还有其他选择。确实,在某些方面,我们正在为我当前的客户提供服务,这一要求非常高“只需搜索所有内容,然后向我展示最相关的内容即可!” I think 那里 ’希望以此作为用户体验并没有错。因此,作为开发人员,我想知道直接进入搜索API是否会提供其他选择–也许标准搜索页面是以某种方式构建的,但是API具有更大的灵活性。一世’d之前还注意到API中的一个非常有趣的属性,所以我从那里开始:

调查中1 - using the 启用交错 property on the Query class

的SharePoint搜索API有一个有趣的选项,可在为SharePoint搜索编写自定义代码时使用。 API中的属性名称为“EnableInterleaving”在KeywordQuery对象上–从可能成为合并结果集的本机方式来看,这听起来很有希望。 Microsoft文档(当前)对设置的作用尚不十分清楚,至少对我而言还是这样:

“一个布尔值,它指定是否 结果表 中的对象 结果表 Collection 通过运行此查询产生的结果应该是交错的。” (从 http://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.client.search.query.query.enableinterleaving.aspx )。

为了开始测试,我在开发环境中配置了混合搜索– I used the 出站混合 模型,其中搜索中心网站是本地存在的,但可以访问Office 365 / SharePoint Online从那里引入结果。 (TechNet文档位于 Configure hybrid search for 的SharePoint Server 2013,或下周在SharePoint会议上举行的众多会议)。此时,开箱即用的搜索结果页面为我提供了本文开头图像中所示的体验,并带有单独的结果框(以红色/蓝色框突出显示)。

然后,我编写了一些自定义代码,使我可以测试此配置选项– effectively I have a custom web part with some CSOM (JSOM) code which runs a search query using the API. I have some URL parameters which enable me to specify the query text and whether 启用交错 is enabled or not. Unfortunately, 启用交错 does NOT interleave results between Office 365 and on-premises 的SharePoint. 主要发现是仍然会返回多个结果集(例如,对于Office 365和本地),并且结果不会以任何方式组合在一起。我确实观察到的一个区别是,针对个性化结果返回了另一组结果(一个ResultTable)(“个人收藏结果”), but it’对我来说是空的(很可能是因为这是一个非生产环境,在该环境中分析并没有’t in use. I’确保SharePoint确实在实际使用情况下填充/保留了此内容–它存储用户先前为此搜索单击的结果)。

Conclusion: - the 启用交错 property does NOT help us combine search results across Office 365 and on-premises 的SharePoint.

调查2–手动将结果合并到自定义代码中

任何对SharePoint搜索非常熟悉的人都会知道,对于任何给定的查询(例如,查询查询文本“SharePoint”),搜索引擎可以返回不同“tables” of results –也许认为这些是“flavors”结果。他们是:

  • 相关结果( “RelevantResults”)
  • 最佳投注结果(“SpecialTermResults”)
  • 个人最喜欢的结果(“个人收藏结果”)

通常是’s the “relevant results”我们最关心的–该表具有查询的核心结果集。如果我们的目标是将Office 365和本地SharePoint的结果结合起来,那么实际上我们只需要一个“relevant results”包含两个位置的项目的表格。但是,当我们’在混合模式下,默认情况下我们实际得到的是两个单独的“relevant results” 桌子 –下图显示了呈现这些表的我的自定义代码,您可以看到此表与开箱即用的搜索结果页(显示Office 365结果的单独结果块)之间的相似之处:

Hybrid search - 启用交错 on 2

因此,如果我们要显示合并的结果(而不是分开的结果),我们可以*编写一些代码以将结果表合并在一起(例如在内存中)。但是,我们将使用什么逻辑?结果应如何排序?好吧,结果表中返回的列之一是“Rank” – this is the “relevancy score”结果与使用的查询相比(所有搜索引擎都有这样的计算– like Google’的PageRank)。所以问题是– can we use 秩 to compare results from different search indexes? Is it valid to merge the two result sets together, and then sort the full list by rank? After all, this can definitely be achieved with custom code – here’是我的自定义Web部件,该部件直接进入搜索API来执行此操作:

混合搜索-自定义交错2

我有一种感觉’这样做是有效的。因此,我向包括Microsoft,其他MVP等在内的一些人征求意见,证实了我的怀疑– 威克多 最好的总结如下:

“来自两个不同索引的结果交织会产生非常奇怪的结果。由于排名基于分析,因此您基本上需要"normalize"两个(或多个)不同索引之间的排名和分析数据。假设用户在不同环境中的行为有所不同(这并不罕见-一种环境可能是协作,而另一种是其他工作负载,例如BI)。”

So in effect, you can mash up the results, but not in a way which gives you the most 相关结果 first (across both environments) –按等级排序是人为的,不应’不要被信任。但是,值得考虑的是,如果 ’*关心相关性/排名,那么这种自定义方法就可以了。例如,如果要求显示按上次修改日期(或按其他内容,例如作者,网站URL或其他内容)排序的结果,那么快乐的日子!在这些情况下,您可以使用此自定义代码方法合并Office 365和本地站点的结果。

编码

如果你’对这种方法感兴趣,在这里’是执行此操作的代码。我使用JSOM代码执行搜索,但是REST应该是另一个选择。当我有两个结果表时,将迭代每个结果表并添加到组合的集合中。最后,在Underscore.js的帮助下,我对结果进行了排序。所有这些JavaScript均由一个自定义Web部件引用,我将其部署到本地站点并添加到该页面中。只要正确配置了混合,我的代码就可以到达关联的Office 365环境并从那里获取搜索结果。

这是执行搜索的初始代码– 这里要注意的主要事情是,代码中不需要“use hybrid mode” or “enable hybrid”或任何东西。如果配置了基础架构,结果将自动从两个来源返回。 You might notice I pick up some URL parameters for the query text and 启用交错 properties –您需要适当地将此与您的UI集成:

在成功处理程序中,这里需要一些不同的代码*。由于返回了2个结果表,因此我们在此处进行了一些处理,以将结果合并到一个新的JavaScript数组中,并实现任何排序。下面的代码提供了不同的排序选项–按等级(即使我们’re saying it’在混合模式下无效),以及最后修改日期:

..和这里’包含我所有的辅助函数等的完整JavaScript代码。(注意:’我仍然把它留给读者作为练习在某处实现的练习–我使用了两个引用此JavaScript的自定义Web部件,因此可以根据需要提供所需的确切实现):


概要

目前,在混合模式下进行搜索的用户体验尚不理想’不一定会达到我们想要的最佳状态,因为结果是分别针对Office 365网站和本地SharePoint网站显示的。在某些情况下,用户只想“搜索所有内容”不在乎结果在哪里。

但是,在某些情况下,您可能可以使用自定义代码来“join-up”结果。具体来说,如果您希望显示按排名以外的*类别*排序的结果,则此方法应该会很好–可能是上次修改日期,作者姓名或其他一些元数据。在两个SharePoint环境中按等级排序无效,因为出于某种原因,等级使用SharePoint’的分析框架,该框架仅在单个环境的范围内运行(即’不要为混合部署做任何神奇的事情)。

将来,Microsoft有望提供解决此问题的功能“natively”,无需自定义代码。然后,可以在Office 365网站和本地SharePoint网站之间一起显示结果。在此之前,这里提供的解决方案可能是您的选择。