RSS

Monthly Archives: 一月 2012

托管元数据(2)——托管元数据和搜索中的精简面板

精简面板(Refinement Panel,SharePoint也有些地方把Refinement翻译成“优化”)是SharePoint 2010搜索中新增加的一个非常好的功能,可以通过搜索结果中的文件类型、作者、修改时间、网站等属性,对搜索结果进行二次过滤,方便用户快速找到自己想要的功能。

2010搜索结果页面中的精简面板是一个Web部件,而且是允许用户进行自定义的,管理员可以随意增加需要在这里进行“过滤”的属性。关于如何在精简面板Web部件中添加自己需要的属性,玉树临风的kaneboy童鞋在这篇博客(点我点我)中已经解释得非常清楚了。这篇博客主要介绍一下托管元数据这种特殊类型的属性在SharePoint搜索结果精简面板中的表现。

如果我们使用默认的Web部件设置,通过点击Web部件属性,在“优化”属性分组中,我们可以看到SharePoint默认使用的优化参数设置。在默认设置的这一段Xml里面,除了文件类型、网站、作者、修改时间之外,我们会看到最后包含两个属性:

1、Title(标题)为“Managed Metadata Columns”、Type(类型)为“Microsoft.Office.Server.Search.WebControls.TaxonomyFilterGenerator”、MappedProperty(映射属性)为“ows_MetadataFactedInfo”

2、Title为“标记”(在英文版中是“Tags”)、Type与第一个相同,MappedProperty为“ows_MetadataFacetInfo, popularsocialtags”

这两个就是SharePoint默认设置中针对托管元数据的处理。它和其它的属性过滤的方式非常不同,而且这种区别不仅仅表现在Type的不同上。

“Managed Metadata Columns”是针对所有已经被配置为可以在搜索结果中进行优化过滤的托管元数据映射属性,只要配置“一切正常”的话,SharePoint会自动从搜索结果中找到这些托管元数据的属性,并且按照不同的来源字段,呈现出多种不同的属性过滤。它的MappedProperty必须设置为“ows_MetadataFacetInfo”,这样SharePoint才能够按照托管元数据的方式对其进行处理(后面会说明SharePoint针对托管元数据属性的处理和对文本类型属性的处理的不同之处);其次,这个看似奇怪的Title是不能随意修改的,只有把它设置为“Managed Metadata Columns”,SharePoint才会去寻找搜索结果中的所有已配置为可优化的托管元数据字段类型,如果我们只需要针对某个字段进行过滤,可以把Title设置成这个字段的名称(显示名称),而任何其他的设置,都会导致这个配置无效。

“标记”(Tags)是针对所有未在上一个节点中出现的其他托管元数据类型的数据的过滤(包括企业关键字、用户标签)。它的MappedProperty设置同样是不可修改的,而且Title也是不可修改的。

 

BUT!

有些时候,虽然是一个托管元数据类型的字段,它并不会按照字段的名称出现在精简面板中,而是一律出现在“标记”这个面板中,如下图所示:

p5

在我进行配置过的几个环境中,只有在我自己的开发虚机中自动根据字段的名称出现了正常的样式(而且这个虚机的多个托管元数据类型的字段,只有一个会出现),如下图所示:

p1

后来经过多次试验(期间改过多种配置,重新进行过多次完全爬网……),后来发现了一个可能的问题:

当我们进行完全爬网的时候,貌似SharePoint会针对每个托管元数据字段自动创建一个映射属性,这些映射属性的名称都是以owstaxId开头的,后面跟着这个字段的名称(应该是内部名称),下面这张图是我开发虚机里面的映射属性的一个截图:

p6

如果仔细看一下的话,就知道为什么只有“知识分类”这个托管元数据字段会“正常”地出现在搜索结果的精简面板中了,它的第三个设置是“是”,其他所有托管元数据字段的设置都是“否”,而这个设置,就是是否允许此映射属性在精简面板中进行过滤,具体的属性设置如下图所示(红框圈起来的那个):

image

在我的另一个项目虚机里面,当我把这个owstaxIdxxxxx的这个设置开启之后,它在精简面板中就可以正常显示了(不过我在做试验的时候,还修改过其他配置,比如爬网账号、托管元数据的各级管理员、甚至手动给这个字段添加了一个映射属性,我不是100%地确定这些设置是否和这个问题有关系,但是只有当我把这个taxId的属性修改了之后,才一切正常)。

如果在你的环境里面,托管元数据类型的字段不能正常出现在搜索结果精简面板中的话,可以按照本文介绍的内容来配置一下。

 

最后,介绍一下SharePoint对托管元数据的“过滤”处理,和一个普通的文本类型属性的过滤处理有何不同。

我们可以尝试按照kaneboy那篇博客中的方法,把一个托管元数据的字段,添加一个“文本”类型的映射属性,并且修改默认的精简面板,添加这个属性(注意Type使用ManagedPropertyFilterGenerator,而不是TaxonomyFilterGenerator)。这种配置方法,在某些情况下,确实是可以按照我们的预期进行工作的,但是它主要的区别在于如下两个方面:

1、对于多值的处理。即使我们在创建映射属性的时候,选择了“具有多个值”,在精简面板中也不会真正地进行多值处理,只会把所有值拼合在一起,作为一个值进行过滤(比如在精简面板中会变成“分类1; 分类2;”,而不是“分类1”和“分类2”两个过滤条件)。

2、对于层级结构的处理。如果是按照本文前面的部分配置的托管元数据类型的过滤器,会按照托管元数据的层级结构进行过滤。举个例子来说,如果我们的搜索结果中某个字段的值有如下几种:猫、波斯猫、孟买猫(其中“猫”是后两者的父级),那么这三个值都会出现在精简面板中,如果我们在精简面板中选择了“猫”的时候,搜索结果中所有标记为“猫”的,以及所有标记为“猫”的所有后代节点的结果,都会被过滤出来。而如果我们是作为一个文本类型的字段进行处理的时候,选择“猫”时,就只会过滤出被标记为“猫”的那些结果,而不会出现被标记为“波斯猫”、“孟买猫”的那些结果了……

其实这两个区别背后的原因,应该是针对不同的字段进行的设置,一个是表面的字段(就是我们存放托管元数据那个类型的字段),一个是背后的字段(注意看上面那张截图中,映射的实际字段是“ows_taxId_KBCatalog”,而不是“ows_KBCatalog”)。

我折腾这个问题的时候,google了很多文章,不过似乎没有谁提到过这个背后的“taxId”字段的那个精简设置的属性。

参考链接:

1、精简面板的设置参考(来自MSDN)

2、在列表定义中创建托管元数据类型字段时需要的一些额外设置(里面提到了一些精简面板的问题,看了这篇blog我才注意到一个托管元数据字段的背后居然有这么多个辅助字段)

btw,春节快乐!

 

Posted by on 2012 年 01 月 22 日 in SharePoint

Leave a comment

Tags:

托管元数据(1)——隐藏列表以及一些相关问题

托管元数据服务(Managed Metadata Service)是SharePoint 2010新加入的一个服务(其实我们在2007上自己做过一个类似的自定义字段),关于这个服务的介绍应该就不用再多说了,关于编程访问托管元数据、托管元数据字段的方法也有很多博客都介绍过了(包括中文的),也不再废话了。

这篇Blog主要是介绍一下托管元数据背后的隐藏列表,以及因为这个隐藏列表所带来的一些问题。

如果我们去看一下托管元数据字段类型(TaxonomyField)的继承关系,我们会发现TaxonomyField是继承LookupField的,换句话说,托管元数据在本质上是个查阅项,它查阅的是网站集根网站上,一个名字叫TaxonomyHiddenList的隐藏列表(没错,查阅项是可以跨网站查阅的,从2007的时候就可以,只不过微软没有开放设置界面而已,用代码可以创建出来跨网站的查阅项)。

这个隐藏列表保存了所有在网站集中正在使用以及使用过的所有托管元数据的值(包括企业关键字,这也是个托管元数据类型的字段),当我们在托管元数据字段中选择了某个值并保存之后,SharePoint会判断这个隐藏列表中是否包含这个值,如果不包含的话,会自动把这个值加到列表里。此外,SharePoint在后台有一个TimerJob去把托管元数据服务中的数据同步到这个隐藏列表中(比如改了名字、换了路径、删除之类的)。

自然,这样的设计提供了托管元数据在网站集中的缓存,本意上是在一定程度上提高了性能。但是因为这个背后隐藏列表的存在,以及这种随用随加的机制,导致了一些问题。目前遇到的有如下三个可能存在的问题或不方便之处:

1、权限问题

这种问题出现的可能性不大,不过确实在实际的客户那里遇到过。

TaxonomyHiddenList是不继承网站权限的,他默认的权限设置是所有用户有读取权限(如果你是Windows认证的网站的话,这里的所有用户是Authenticated Users这个AD组),系统账号拥有完全控制权限,如果网站开启了匿名的话,匿名用户拥有查看项目的权限。这样的设置即保证了用户能够正常读取到其中的值,也能够防止其他用户修改列表中的内容(针对这个列表的所有修改都是通过托管元数据服务以及后台的TimerJob来完成的)。

但是上次在客户现场遇到过一个问题,这个Authenticated Users的权限不知道因为什么原因被去掉了,于是就造成了如下的诡异现象:

(1)用户可以在托管元数据导航的地方看到完整的元数据信息,但是点击进行筛选的时候报错(除非系统账号之前点过)

(2)用户在视图、查看页面上看不到任何托管元数据的值,但是在编辑页面和新建页面都能够正常看到。

这个很明显就是用了查阅项、而且查阅的那个列表上没有权限的现象;而新建、编辑、托管元数据导航之所以正常,因为这些数据都是直接来自托管元数据服务的。系统账号点过之后就可以用,估计是因为有缓存神马的。

2、视图筛选

如果你想在一个托管元数据字段上设置视图的筛选条件,那么你就只能使用“等于”和“不等于”这两种运算符,而且这两种运算符都会把托管元数据字段退化成一个“单行文本”行为的字段,换句话说,只能筛选到特定的那一个值,而不包含其中的子项的值。

举个例子来说,如果有下面一个托管元数据字段的设置:

动物;动物/猫;动物/猫/波斯猫;动物/猫/孟买猫;动物/狗;动物/狗/哈士奇;动物/狗/雪纳瑞

如果你想筛选这个字段的值 = 波斯猫的,那么ok,因为波斯猫是处于叶子结点的位置;但是如果你想通过视图去筛选所有的猫,这个是实现不了的。

你会说,如果我用API或者PowerShell设置视图的Query属性,把所有可能的值都包含进去(2010在CAML查询中新提供了一个In的运算符,行为就和SQL里面的In是一样的)呢?

如果你用文本的话,如果管理员修改了某个元数据的值,那查询条件就不对了;如果你用查阅项ID,那么因为背后那个隐藏列表有着随用随加的机制,如果你在设置视图的时候,某些值还从来没有使用过,当这些值被使用的时候,你的视图就查不到这些值了。而且不管你用哪一种方式,当管理员在后台更改了托管元数据的结构或者增加了新的节点的时候,这个视图条件都不再正确了。

一种变通的方式,是使用托管元数据导航,选中你需要的节点,然后把Url记下来,以后使用这个Url作为你这个视图的入口(SharePoint会在后台动态生成一个使用In运算符,包含所有子节点的CAML查询)。但是如果你要想在一个页面上放置多个视图,那就彻底没辙了。同样,对于“内容查询Web部件”来说,针对托管元数据的查询也会因为类似的原因而无能为力。

只能自己写代码做Web部件了(如果你有其他更好的方式,欢迎告诉我erucy9[_at_]gmail[_dot_]com)

3、API不正常的By Design行为

托管元数据提供了一套完整的API,这里面有一个方法需要特别说明,那就是GetTerms。

在TaxonomySession、TermStore、TermSet上都提供了这个方法,这个方法可以通过托管元数据的字符串值(Label)获取到特定名称的那一个(或多个)Term。

BUT……

当我们通过TaxonomySession和TermStore去使用这个方法的时候,只能获取到那些已经存在于TaxonomyHiddenList中的值(也就是网站中曾经使用过的值);只有当通过TermSet去使用GetTerms的时候,才能够获取到所有的值……

 

预告:

下一篇的内容是介绍托管元数据在SharePoint搜索结果页面中的“精简面板”(Refinement Panel)中的设置。

 

Posted by on 2012 年 01 月 20 日 in SharePoint

Leave a comment

Tags: