使用内容搜索Web部件（并了解SP2013搜索）

本系列文章：

• 使用内容搜索Web部件（并了解SP2013搜索）[本文]
• 在SharePoint 2013的内容搜索Web部件中显示正确的数据
• 使用自定义显示模板配置Content Search Web部件

使用SharePoint满足客户要求通常涉及以某种方式聚合项目–通常我们想展示诸如“所有财务地点的所有逾期任务”, 要么 “导航到该区域所有子站点的链接” 要么 “相关项目（例如带有相同字词的标签）”等等。在SharePoint 2010中，有两种主要的实现方法：

• 内容查询Web部件
• 基于SPSiteDataQuery（网站集范围），SPQuery（列表范围）或搜索API构建的自定义解决方案

在较小程度上，也可以选择将搜索Web部件用作自定义解决方案的一部分。无论如何，通常需要自定义代码来满足此类要求。也许我们需要在结果中添加分页，或者我们需要使用一些通过代码动态获得的值（例如，从当前站点/当前页面/当前用户/其他地方）–从这个差距中产生了几个Codeplex解决方案，并且 很多 的代码行被编写。

SharePoint 2013将内容搜索Web部件显示为新选项– it’的功能意味着仅使用Web部件（通过一些前端工作即可满足外观需求）将满足许多需求， 没有 使用自定义代码。如果你’作为开发人员，以下屏幕截图应为您提供一个有关为何赢得代码的线索’不需要太多（突出显示我最喜欢的选项之一）：

It’非常强大，并且’s a good idea to understand 什么 it can 做.

了解基于搜索的解决方案

顾名思义，内容搜索Web部件由SharePoint提供支持’的搜索功能。因此，有以下注意事项：

• 可以将CSWP配置为“see” items 任何地方 在SharePoint中 （潜在优势）
  • 相反，CQWP和相关的SPSiteDataQuery只能搜索 在当前网站集中 -网站集“boundary” is a factor
• 显示的结果不能保证是100％最新（潜在的不利条件）  
  • 由于必须先运行搜索爬网，才能在搜索结果中显示任何内容更改（请记住，其中可能包括页面/文档的标题，摘要，图像等），如果用户创建/编辑项目，则不会立即显示。这可能是一个关键点。
  • 此外，根据FAST工程师的理解，在SharePoint 2013中 不再有任何直接将文档推入搜索索引的方法 –在以前的FAST版本中，包括用于SharePoint 2010的FAST，有一些选项，例如 做cpush.exe 对于“proactively” add an item to the index, rather than waiting 对于the next 搜索 crawl.
  • 也就是说，应该可以通过以下方式在SharePoint 2013中获得更低的索引编制延迟：“Continuous Crawl'”能力。在大多数部署中，我的猜测是更改将在几分钟内反映出来 最多 如果启用了此功能（以前，您可能已经安排了每15、30或60分钟对SharePoint网站内容源进行一次增量爬网。

总结-如果您要创建的功能需要完全最新的结果（例如，用户创建/编辑了某些内容，并且需要*立即*在网站中反映出来），则您可能需要坚持使用原始方法（即一个 询问基于而不是 搜索的解决方案）。

术语–SharePoint 2013搜索中的新概念

所以如果我们’要构建基于SP2013搜索的解决方案，我们需要对一些概念有基本的了解– we’一次又一次地遇到这些：

概念	我的快速定义
结果来源	喜欢搜寻‘scope’ in SP2007/SP2010, but on steroids. Rules are specified to say 什么 the 范围 consists of –例如我的TEAM SITES区域中的文档（在此示例中，内容类型和路径受到限制）。 集中创建或在Web级别创建。结果源几乎可以用于任何与搜索相关的功能，包括“内容搜索” Web部件。
查询规则	像一个‘best bet’在类固醇上。能够在结果列表顶部执行特殊格式的结果（例如 提升结果) 对于highly-recommended content. In addition to 提升结果, we can also 做 a 结果块 (example 可以 be a block of 5 image results within 主要 list of text links). 另一种选择是 Change the 秩ed Results –即在顶部放一些东西， 促进 要么 降级 1-10（以前称为‘boost’ in FAST)  灵活地匹配用户’的查询，包括托管元数据存储中的正则表达式和匹配项。
显示模板	显示模板是用于控制格式的JavaScript模板（类似于jQuery模板）–对于CSWP，这实际上替代了XSL在外观上的使用。有一个单独的模板可用于个人的整体控制和格式化 项目。 模板的.js文件存储在‘Content Web Parts’母版页画廊的子文件夹。  边注 –在搜索结果页面（而不是CSWP）的上下文中，显示模板与结果类型（例如Word 做c，wiki页面，PowerPoint文件等）相关联，因此我们可以精确控制每个显示方式（以及何时显示） ）。太酷了。

因此，搜索基础结构具有很大的灵活性。让我们在“内容搜索” Web部件的上下文中查看其中的一些内容。

Configuring the 内容搜寻 web part

有 two 主要 aspects to this:

• 显示正确的项目（搜索条件）
• 外观（显示模板）

就搜索标准而言，CSWP和基础搜索功能的功能具有“巨大”的灵活性。一方面，它’可以直接在此Web部件实例的属性中直接完全配置查询（例如，向我显示所有符合条件X的文档），和/或从预先存在的结果源开始进行某些过滤。结合这些方法将是相当普遍的–一个例子可能是“仅在Wiki页面上搜索”（一个OOTB结果源），但仅显示标记有X的项目（此项目直接在CSWP属性中定义）。

有趣的是，在页面上配置集中的“结果源”和“内容搜索” Web部件非常相似，即使看起来有些类似。“reusable 范围 ”和Web部件在SharePoint中是完全不同的。之所以会出现重叠，是因为在两者之下都有一个搜索查询，它可以隔离期望的结果-实际上，正如我们稍后会看到的一样“Query Builder”用户界面在两个地方都使用（有一些细微差别）。所以，如果你’我已经学会了如何配置CSWP’我基本上还学会了如何创造 自定义结果源。

配置Web部件

首先要了解的是，内容搜索Web部件以不同的外观出现在Web部件库中。的‘main’ web part is in the ‘Content Rollup’ category:

但是也有很多 预配置 可用的版本，每个版本都可以找到特定类型的内容。这对于不这样做的最终用户非常有用’t necessarily 认为 在需要一个方面‘Content Search’ web part: 

为了证明这一点，上面的Web部件与Web部件库中的以下.webpart定义文件相对应：

将Web部件添加到页面后，即可对其进行配置’的工具窗格。主要配置项目是要使用的查询，可以通过单击‘Change 询问’ button:

 
这将打开"’Build Your Query” dialog – this has tabs labeled 基本, REFINERS, SORTING, SETTINGS and TEST. This thing is known (unsurprisingly) as the 查询生成器 – 什么 you might not realize, is that it’在SharePoint 2013中的多个位置使用：

• 配置内容搜索Web部件（显然）
• 创建结果源（特别是在“查询转换”部分中）
• 配置搜索结果Web部件

有 一些 差异–例如，在配置“搜索结果” Web部件时，没有“排序”选项卡，因为它将在“结果源”或查询中进行处理。 I’m going to talk about things from the perspective of the 内容搜寻 web part, but will call out any 差异for the other usages –因此希望通过学习CSWP，您还可以学习75％的搜索基础架构。

基本 tab – 快速模式

虽然第一个标签被标记为‘BASICS’, I’d say it’实际上是最复杂的-这是配置查询本身的地方，并且有一个‘Quick Mode’ and ‘Advanced Mode’. You’我也会注意到这一点-让我只说我’d个人愿意为此功能提供产品经理极大的帮助-’s a “live” results preview pane, permanently visible on the right-hand side of the 查询生成器. This shows 前10个结果 通过针对当前索引运行当前配置的搜索将显示 没有 每次更改后需要保存Web部件：

请注意，如果您创建自己的查询，则只有在“测试”选项卡上时，此预览窗格才能显示结果。和我们’我会在最后谈到。

让’现在，在这里完成各个配置步骤。

选择一个查询

In 快速模式, the dropdown contains the 结果来源s (see my definition above 如果 you’我们已经忘记了:)），随SharePoint 2013一起提供–其中之一可能为您所需的内容提供良好的基础：

 
从下拉菜单中选择结果源时，其他选项可能会在下拉菜单中变为可用。因此，如果我想查找与特定内容类型匹配的项目，则会得到以下信息：

 
In fact, this option to restrict by content type appears 对于许多 预定义的结果源，而不仅仅是“符合内容类型的项目” –这是有道理的，因为它’包含为过滤器是很常见的事情。同样，“Items matching a tag” 和其他几个查询 give this interface 对于selecting a tag to filter on:

而且，快乐的日子里，如果我通过输入一个来指定标签，则会自动完成以帮助我选择该术语–这是一个完整的“托管元数据”输入字段。因此那里’还可以完全验证您键入的字词（尽管这需要花费几秒钟的时间），因此如果作者不小心输入了不正确的内容’一个已知的术语，他/她应该立即发现错误：

还请考虑使用与当前页面相关联的导航术语的中间选项是 究竟 什么’需要构建多种类型的‘related items’ functionality –同样，现在不需要任何代码。

按应用限制结果

In the next section, I can restrict the 范围 of the results to a particular location (e.g. the current site). This enables me to get 一些thing like the 内容查询Web部件 behavior of 只要 根据需要在当前网站集中进行搜索–因为尽管我们现在拥有力量，但它赢得了’遍历整个农场总是有意义的:)

添加其他过滤器

在下一节中，我可以使用任何有效的查询文本来补充查询，例如属性过滤器。在这个例子中，我’m添加过滤条件以仅显示那些 被创造 由当前用户：

排序结果

当我们将查询范围限定到预定义的“结果源”时（如我们在CSWP中的此处所示）‘Quick Mode’），那么排序通常是在该级别预先定义的。 CSWP确实为我们提供了基于某些受欢迎度排名模型（围绕观看次数最多/点击次数最多）进行覆盖的机会，–希望在RTM版本的此下拉列表中会显示正确的措词，但您会明白： 

 
那么，如果到目前为止您没有想要的选项，那么会发生什么呢？例如，可能要使用现有的结果源（例如‘wiki pages’），但按降序对“上次修改时间”进行排序。显然，上面的下拉列表不允许这样做。我们 可以 创建一个自定义结果源并在那里执行查询/排序，但这只有在我们希望它可以在多个地方重复使用的情况下才有意义。

In these cases, we can click into 高级模式 (still on the 基本 tab).

基本 tab – 高级模式

In 高级模式 you basically get to specify the full 询问 text yourself. In my mind, this is like building a solution with the 搜索 API in SP2007/SP2010 –我看到了许多自定义解决方案（并自己构建了一些解决方案） FullTextSqlQuery 要么 关键字查询 类以查找正确的项目。 SharePoint 2013使拥有完全控制的权限变得更加容易，同时仍然可以使用现成的Web部件–意味着更少的工作和更高的生产率。

When switching to the 高级模式, a couple of things become available:

• 排序标签（稍后详细说明）
• 用于帮助您构建查询的控件（’d以前在早期版本中基本上是手工完成的）， ‘Keyword filter’ and ‘Property filter’选项。可以根据需要将它们组合在一起，结果查询文本将显示在底部的文本框中：

 

通过使用令牌来避免自定义代码

有许多 代币 以这种方式构建查询时可以使用–通常，您可能希望将某些内容传递给查询，例如URL（querystring）参数，页面上特定字段中的值，等等。能够做到这一点解锁了 巨大 各种解决方案的可能性。这是本文第一张图片的来源– here’s a reminder:

 

In summary, when using the 高级模式 of the 询问 builder you should be able to target just about any content in your SharePoint environment.

排序标签（仅高级模式）

在SharePoint 2010企业搜索中，您只能按相关性/等级（常规搜索引擎方法）或日期进行排序。 SharePoint 2010的FAST具有更多选项（您可以按托管属性排序）。坦率地说，在SharePoint 2013中，仅排序选项就足以引起您的注意：)  如果你 做n’不需要任何有关排序的特定信息，则可以跳过此位，但是如果这样做，则可以选择以下方法：

首先，您可以通过排序的方式不仅仅是排名和日期：

有一件事要注意– I’我不清楚它是什么‘Sort by’列表，什么没有。它’据我所知，它不是托管属性，因此尽管列表很长，但许多选项可能并不是很有用。仍然比以前更好。

有用的是，您现在可以进行多级排序（按此排序，然后按该排序）。的‘Add sort level’上图中的链接添加了另一行，使我可以执行诸如按URL深度排序的操作（因此，在网站层次结构中较高的项显示在顶部），以及 然后 按等级（这很有意义，因为那里’在相同的URL深度处会有很多项目，因此我确实需要两个级别的排序）：

注意，有效地我’我在这里正在建立某种自定义排名模型。如果我需要一些非常具体的排序方法，则此方法非常有用，但请注意，SharePoint 2013附带了几种排名模型–下一节让我从中选择 如果 I’ve left the ‘Sort by’ dropdown on ‘Rank’，与上图不同。这是因为所有这些选项都有效 不同形式 等级–大多数都围绕着人物搜索或人气：

And 对于those occasions when the client is telling you that his/her strategic 做cument 真 必须在结果的第1页上（但不是推荐结果/最佳选择），‘Dynamic 要么dering’ –您可以提高/降低结果，包括提升到顶部的选项：

精炼标签

在搜索方面，精炼商是 通常 搜索引擎上的链接’的结果页面（通常在左侧导航栏中），该页面允许用户进一步过滤结果。所以如果我搜索“meeting minutes”并获得很多结果，最好能够过滤，例如：

• 日期范围
• SharePoint网站（因为几分钟可能存储在各个项目网站中）
• 作者
• ..等等

但是，在Content Search Web部件的上下文中，精简程序实际上允许您在初始查询的过程中执行此筛选。 “精简”选项卡实际上是为您（配置Web部件的人员）带来的便利–发生的情况是在编辑模式下执行搜索，并且所有相关的优化程序（例如托管属性）都显示为可用的优化程序。可以选择这些并将其移至右侧列表：

The effect of this is that a further filter is added to my 询问. In the example above, this may be easier than using a Property Filter on the 基本 tab –由于那里几乎没有支持，所以我只选择属性并输入值：

在“细化工具”选项卡中，SharePoint正在为我搜索（因为它’到目前为止已配置），并且仅返回值 在返回的结果中找到的.

设置标签

The 设置标签 controls 一些 high-level options 对于running the 搜索:

查询规则

由于这些可以在父站点上定义 要么 搜索服务，那么您的CSWP可能会受到其中一种的影响。正如单选按钮显示的那样，可以将其覆盖，但是请考虑某些类型的查询规则可能仍然没有作用-作为提醒（从开头的表开始），查询规则可以：

• 添加提升的结果
• 添加结果块
• 以某种方式更改排名结果（通过修改查询）

在这3项操作中，有1.5项可能会影响‘default’CSWP。可以总结为：

查询规则动作	会影响CSWP结果吗？
添加提升的结果	Not by 默认. 在SharePoint中运行搜索时，将返回多个结果集（例如‘main results’, ‘best bet results’依此类推-在SP2013中，这些的真实名称是‘RelevantResults’, ‘SpecialTermResults’, ‘个人收藏结果’ and ‘RefinementResults’）。尽管可以将CSWP配置为显示任何表，但是默认值为‘RelevantResults’ –并将提升的结果添加到‘SpecialTermResults’.
添加结果块	是，如果结果块配置为显示‘在核心结果中排名’ (the 默认), rather than ‘如上核心结果所示’.
更改排名结果	是.

为了完整起见，这里’是CSWP中您选择要使用的搜索结果集的位置（例如，如果要从默认值‘RelevantResults’:

结果表下拉菜单中的选项（显示在左侧）：

URL重写

这个很简单–如果结果是从正在使用的目录返回的“friendly”URL，然后CSWP可以覆盖它以使用原始URL。在目录页面之外的聚合中使用重写的URL可能并不总是有意义，特别是如果您’在那里执行了任何时髦的操作。

加载行为

这很有用–指定CSWP Web部件实例是应在主页加载后加载（默认）还是在主页完成后以AJAX方式加载。考虑到CSWP可能是着陆页的核心，或者仅仅是某些页脚导航，’能够以这种方式确定优先级很好。

优先

同样，我们实际上可以为我们使用的每个CSWP实例指定高，中或低优先级–非常适合我们的不同用法，尽管按照说明，请注意，这仅在搜索服务超载时才有效。

测试标签

TEST标签非常有用–它为您提供以下功能：

• 要查看已生成的基础查询文本（使用关键字查询语言[KQL]）（尽管必须在其他选项卡中对其进行编辑）
• 自己定义查询时查看预览（在这种情况下，预览窗格在其他选项卡上将为空）

哪个都很棒，但是乍一看’很容易错过一些额外的功能– 如果‘Show more’ link is clicked，其他信息将变得可见，包括有关已应用的所有优化程序和查询规则的详细信息。因此，在下面我可以看到确实使用了我创建的自定义查询规则，因此’（例如）某项商品实际上是否在促销中，您无需做任何猜测：

旁注-使用Content Search Web部件列出一个站点/列表/库中的项目

值得一提的是-如果您需要做的只是汇总一个列表/库中的内容，那么您可以*使用CSWP来做到这一点– in the 询问, simply restrict the 搜索 using PATH:[URL to 做cument library]. The 查询生成器 UI helps you 做 this by providing the ‘Restrict by app’ area: 

N.B.请注意，这里的一个潜在陷阱可能是您需要‘HTTP’如果您的网站是在HTTPS上浏览但在HTTP上爬网（例如我的案例）。

如果你 做 要按站点/列表/库进行过滤，当然要考虑到’内容查询Web部件在这里可以正常工作，*和*您’随着内容的更改，将立即获得更改。你赢了什么’内容搜索Web部件’自动在查询中使用令牌的能力（例如，当前导航类别的值，当前用户的值’s profile etc.)

概要

内容搜索Web部件是SharePoint顾问中的出色工具’的把戏。在某些情况下，配置可能非常简单，但同时也具有极大的灵活性，因此具有一定程度的复杂性。可以利用SP2013搜索功能的许多高级方案（例如结果源，查询规则，升级结果等）–了解细节将帮助您确定CSWP是否可以解决特定问题。

在这篇文章中，我们简单地看了看“显示正确的项目”即搜索查询方面。在其他帖子中，我’ll talk about:

• 显示项目
  • 在“内容搜索” Web部件中显示正确的数据