Pesquisa do SharePoint: bugs, limitações e soluções

A pesquisa do SharePoint oferece muitas possibilidades. Neste artigo vamos discutir algumas das limitações que poderão encontrar quando fazem programaticamente uma query ao serviço de pesquisa do SharePoint.

Páginas de boas-vindas como "STS_Web"

A página de boas-vindas de um publishing site é a primeira página que um visitante vê quando acede a um sub site (normalmente default.aspx).

A parte estranha é esta: o serviço de pesquisa do SharePoint trata estes resultados com a classe de conteúdo "STS_Web", separando-os das restantes páginas.

O que é que isto significa? Significa que, por exemplo, se quiserem criar um scope que inclui todas as páginas de um site (e.g. incluindo apenas os itens com a classe de conteúdo "STS_ListItem_850"), as páginas de boas-vindas não irão aparecer a não ser que também incluam a classe "STS_Web".

Claro, isto não é tudo. Traz todo o tipo de inconvenências. Vamos dizer que querem ir buscar todos os resultados com o content type "Project". Agora imaginem que têm vários sub sites e que alguns deles têm uma página de boas-vindas do tipo "Project".

Basta fazer uma query ao serviço de pesquisa e dizer que querem todos os resultados do content type "Project", certo? Errado! Como as páginas de boas-vindas são tratadas de forma diferente, simplesmente não irá resultar. Desde que sejam páginas de boas-vindas, irão ser tratadas com a classe "STS_Web", impedindo-as de serem filtradas pelas suas managed properties, não existindo uma solução rápida para este problema.

Solução para as páginas de boas-vindas

Uma solução que podem aplicar é a seguinte: criar uma página de redirect usando o page layout RedirectPageLayout.aspx. Configurem o redireccionamento para a página que querem que seja de facto a homepage do publishing site. Agora definam a página de boas-vindas como sendo a página de redirect.

O serviço de pesquisa irá agora tratar a página de redirect como a página de boas-vindas (aplicando-lhe a classe "STS_Web"), mas tratará todas as restantes páginas de forma normal. Os utilizadores não irão reparar no redirect, porque acontece “atrás das cortinas”.

Tenham em atenção que também poderão querer ajustar a navegação do site para esconder a verdadeira homepage.

Incapacidade de pesquisar resultados com valores nulos

Por design, valores nulos não são guardados nas propriedades de um item na base de dados do SharePoint.

Isto significa que se usarem uma condição "OU" com várias propriedades, apenas serão encontrados itens com valores para todas as propriedades. Por exemplo, vamos dizer que estão à procura de todos os itens do tipo "Project" que pertencem a uma determinada indústria ou têm um estatuto específico. Se existirem projectos que não tenham um valor para uma destas propriedades, a pesquisa não os irá devolver.

Outra implicação é que não é possível encontrar itens que tenham uma propriedade a null. Por exemplo, estão à procura de todos os itens que não tenham um valor para uma propriedade em particular - não podem. Ou vão buscar todos os itens e depois retiram programaticamente os que não têm nenhum valor na propriedade ou procuram por todos os itens que tenham um valor.

Infelizmente, esta é uma grande limitação para a qual desconheço uma solução.

Ir buscar o content type de um item

Há uma managed property chamada "ContentType" que permite filtrar os resultados pelo tipo de conteúdo. No entanto, se quiserem ler o valor do tipo de conteúdo, não o podem fazer através desta propriedade.

Isto acontece porque a managed property "ContentType" está mapeada a duas crawled properties: "Basic:5" e "ows_ContentType". Apesar de funcionar para filtrar (i.e. numa cláusula WHERE), se tentarem ler o seu valor, irão receber o valor da crawled property "Basic:5".

Se quiserem mostrar o tipo de conteúdo dos vossos resultados (e.g. para mostrar num filtro ao utilizador), têm de criar uma managed property (e.g. "ItemContentType") e mapeá-la à crawled property "ows_ContentType".

HTML é removido das propriedades (ou porque é que PublishingPageImage não funciona na pesquisa)

Vamos imaginar que têm notícias no vosso site. Como parte do conteúdo das notícias, usam o campo "Page Image" (que tem como nome interno "PublishingPageImage") para guardar a imagem principal de cada notícia.

Na vossa pesquisa de notícias querem poder mostrar as imagens ao lado dos sumários. Criam uma managed property e fazem o mapeamento à crawled property "ows_PublishingPageImage". Agora tentam usar essa propriedade nos resultados da pesquisa, mas reparam que a propriedade está sempre vazia. Como é que pode ser?

Isto acontece porque por design o SharePoint não faz crawl a compound controls. É uma forma simpática de dizer que o SharePoint nos detesta e remove todo o markup HTML dos valores das propriedades quando faz o seu crawl. Como a propriedade "PublishingPageImage" é guardada inteiramente como HTML (i.e. <img ...), nada irá aparecer na pesquisa.

Solução para a propriedade PublishingPageImage

Existe uma solução "simples" para isto. Se quiserem usar a propriedade "PublishingPageImage" nos vossos resultados de pesquisa, primeiro têm de criar uma nova propriedade. Esta propriedade irá guardar apenas o caminho para a imagem.

Segundo, têm de criar um event handler. No handler têm de definir o evento "ItemUpdated", para que sempre que um item é actualizado guardar o URL da imagem na nova propriedade.

Depois disto, apenas têm de criar uma nova managed property mapeando-a para a nova site column que criaram e usando-a nos vossos resultados.

Conclusão

Neste artigo falamos de algumas coisas triviais que se podem tornar numa dor de cabeça quando trabalhamos com a pesquisa do SharePoint que, sendo poderosa, também tem várias limitações.

Recursos

Nuno Freitas
Publicado por Nuno Freitas em 18 novembro, 2013

Artigos relacionados