Como usar Regras de consulta, Tipos de resultado e Modelos de exibição para um Relatório de vendas de pesquisa personalizada no SharePoint 2013
Artigo original publicado em 24 de julho de 2012, terça-feira
(Aviso de isenção padrão: o formato de blog é muito ruim. Faça um favor aos seus olhos e baixe o anexo, que é a versão em documento do Word desta postagem.)
Certo, é um título comprido para o tópico de hoje, mas vamos abordar uma variedade de bons materiais. O SharePoint 2013 tem vários recursos excelentes que permitem que você use e personalize de verdade os resultados de pesquisa como nunca o fez antes. Não vou testar nem oferecer uma visão geral abrangente de todos eles, nem mesmo detalhes significantes sobre os componentes que estamos usando nesta postagem porque eles são abordados de forma competente em outros lugares. Porém, vou oferecer a vocês um conjunto inicial de resultados de pesquisa, uma breve visão geral de cada um desses recursos e depois passar pelo processo usando os recursos para criar um resultado de pesquisa muito bom e personalizado que demonstra como todas as peças trabalham juntas.
Primeiro, vamos começar com uma exibição da aparência dos resultados de pesquisa quando executamos uma consulta por "relatórios de vendas" no farm (OBSERVAÇÃO: essa é uma versão beta 2; a versão final pode parecer diferente):
Essa é a experiência especial com resultados de pesquisa e parece boa. Porém, adicionamos esses recursos para ajudá-lo a aprimorar de verdade a experiência de pesquisa do usuário final no SharePoint 2013, então vamos adicionar um pouco mais ao nosso cenário aqui. Temos várias divisões em nossa companhia, sendo que muitas delas são responsáveis pelo gerenciamento de vendas dentro da sua divisão. Cada divisão usa um modelo de Excel padrão para relatar suas atividades de vendas com o passar do tempo. Além disso, cada divisão tem uma pessoa responsável pelo gerenciamento dos relacionamentos com o cliente e por relatar suas informações de vendas. Sendo assim, como podemos usar esses recursos no SharePoint para ajudar a padronizar e a revelar informações importantes sobre a divisão e seus clientes? Vamos usar uma abordagem de vários pontos para solucionar isso.
Tipo de conteúdo personalizado
Para começar, vamos criar um tipo de conteúdo personalizado para todos que carregam relatórios de vendas no SharePoint. Começamos criando as colunas de site que vamos usar, que são campos que desejamos que apareçam no relatório de vendas. Para nosso cenário, defini que vamos usar as colunas de site a seguir:
Nome da coluna de site |
Tipo |
Gerente de conta |
Linha única de texto |
Funcionários subordinados |
Número |
Região de vendas |
Opção: América do Norte, EMEA, Ásia |
Contas principais |
Linha única de texto |
Total de contas |
Número |
Depois, criamos um tipo de conteúdo que inclui todos essas colunas de site. Criamos esse tipo de conteúdo no site do hub de publicação associado ao Serviço de Metadados Gerenciado de forma que seja vinculado a todos os sites associados no farm, que, nesse caso, são todos os sites em todos os aplicativos da Web.
A próxima etapa, que, nesse caso, foi manual, foi adicionar esse tipo de conteúdo à lista de tipos de conteúdo disponíveis para cada conjunto de sites da divisão na biblioteca de documentos em que são armazenados os relatórios de vendas (além de outras coisas). Obviamente, há outras maneiras de automatizar isso, mas para ser mais rápido, fizemos manualmente. Então, a primeira etapa foi concluída: temos um tipo de conteúdo personalizado que está implementado e, como os relatórios de vendas foram adicionados a essas bibliotecas de documentos, os Gerentes de contas podem identificar um relatório de vendas quando eles o carregam e preenchem os metadados.
Propriedades gerenciadas
Agora que temos esses relatórios de vendas preenchendo nossos sites, precisamos criar propriedades gerenciadas a partir das colunas de site dos relatórios de vendas personalizados. Não há nada realmente novo no SharePoint 2013 comparado ao SharePoint 2010 para os propósitos desse cenário: é preciso fazer um rastreamento completo para criar as propriedades rastreadas, depois criar propriedades gerenciadas que são mapeadas a essas propriedades rastreadas e fazer um novo rastreamento completo. Não há nada diferente nesse cenário porque estamos implementando uma solução em todo o farm. Contudo, o SharePoint 2013 possui um recurso fabuloso que permite que o os administradores do conjunto de site marcam seu conjunto de sites, ou o site ou mesmo uma lista para um rastreamento completo. Isso salva você de ter que fazer um rastreamento completo da empresa quando quiser fazer isso a um nível de escopo mais restrito, o que é muito bom. Vou testar e abordar esse recurso em outra postagem, só quis mostrar que ele existe e que não é aplicável nesse caso porque nosso escopo da solução é para o farm inteiro.
Regras de consulta
Nesse ponto, temos relatórios de vendas que estão usando um tipo de conteúdo personalizado e gerenciamos propriedades preenchidas com os valores de metadados desses relatórios de vendas. A próxima coisa que faremos é certificarmo-nos que esses itens sejam "notados" quando alguém estiver pesquisando algo que devesse incluir um desses relatórios de vendas. O SharePoint 2013 possui o recurso perfeito para isso, chamado Regras de consulta. As Regras de consulta possuem três componentes principais:
- Condições – As condições para um regra de consulta determinam quando uma regra será ativada. Há um número de variações diferentes que você pode ter com essas regras. Isso é só uma leitura, mas as possibilidades de uso delas são ENORMES e, na verdade, você verá que várias delas já estão prontas para o uso. Outro ponto interessante: se você quer que uma regra de consulta seja ativada em TODOS os resultados de pesquisa, então você não tem nenhuma condição. Você pode fazer o contrário e ter várias condições também. Provavelmente, você pode ver bem rápido como pode se perder com o escopo de possibilidades aqui. As condições que você pode usar para uma regra de consulta incluem:
- uma consulta que começa ou termina com uma palavra ou uma frase específica
- uma consulta que contém uma palavra de ação (palavras que você define e que geralmente são verbos, como "baixar", etc.)
- uma consulta contém uma palavra que está em um conjunto gerenciado de termos de metadados (algumas coisas muito LEGAIS qeu se pode fazer com isso)
- uma consulta que é comum em outra fonte de resultado, como resultados de vídeo, resultados de documentos, etc. e que pode ser qualquer coisa, já que você define e cria fontes de resultados
- os resultados contêm um tipo de resultado frequentemente clicado, como discussões, planilhas de Excel, etc.
- regras avançadas, onde você pode enlouquecer com expressões comuns, dividir a consulta entre termos de ação e termos objeto (o que sobra depois dos termos de ação é removido), etc.
- Ações – São o que iremos fazer quando as condições para sua consulta forem satisfeitas. Você tem três escolhas diferentes aqui também, podendo:
- Adicionar resultados promovidos – É semelhante a como o Melhores Opções trabalhava no SharePoint 2010 e como o Melhores Opções Visuais trabalhava com o FAST Search para SharePoint 2010. Você pode adicionar um novo link que será exibido na parte superior de todos os resultado de pesquisa. Você pode optar por ter o link renderizado como um hyperlink ou como uma figura, por isso a analogia a uma Melhor Opção Visual.
- Adicionar bloco de resultado – Um bloco de resultado é onde você executa uma consulta adicional e retorna e renderiza os resultados juntamente com os resultados da pesquisa original. É chamado de bloco porque os resultados são renderizados todos juntos, em um bloco. Você pode optar entre o bloco ser exibido no topo de todos os resultados de pesquisa ou misturado com os outros resultados de pesquisa, com base na classificação. É importante observar que isso NÃO SIGNIFICA que é feito uma classificação de relevância entre as duas consultas. Quer dizer apenas que o bloco como um todo terá uma classificação juntamente com todos os outros resultados de pesquisa local. Ao clicar em qualquer item do bloco de resultado, essa ação de clicar é gravada localmente, e o bloco como um todo se torna mais relevante. Assim, se os itens no bloco forem clicados várias vezes, com o passar do tempo, o bloco começará a subir posições nos resultados, pois terá uma relevância maior que os resultados individuais que não são selecionados frequentemente. Há, na verdade, uma TONELADA de coisas que você pode fazer para configura seu bloco de resultado, mas, como eu disse anteriormente, não vamos nos aprofundar nisso aqui e nesse momento.
- Alterar resultados de classificação alterando a consulta – Essa opção detalhada faz o que se propõe a fazer. Você pode entrar e mudar a consulta solicitada da maneira que você quiser. É possível adicionar outros critérios, remover termos, usar o XRANK para modificar a classificação, enfim, as opções são bastante numerosas.
- Publicação – É o que permite que você controle se e quando uma regra de consulta é usada. Por exemplo, você pode querer criar um conjunto de regras que deseja ativar no dia seguinte à venda de Ação de Graças. Porém, você não quer que elas acabem antes que esse dia chegue. Então, você pode criar as regras, mas pode configurar a publicação de forma que essa regra fique inativa. Ou você pode tornar a regra ativa, mas configurá-la para que não inicie até uma data específica e para que termine em uma data posterior.
Esse foi o "breve" resumo sobre o que são regras de consulta. Então, como vamos usar as regras aqui? Bom, acontece que há uma regra de consulta imediata e especial que vai cuidar disso para nós. Na verdade, tornamos a regra inativa quando tiramos a captura de tela acima para que você entendesse melhor seu impacto. No nosso caso, queremos regras nas quais alguém pode querer visualizar um relatório de vendas ser exibido com pop up. Portanto, vá até seu Conjunto de sites de pesquisa, Configurações do site, e clique no link Regras de consulta. No menu suspenso Selecionar uma fonte, clique nele e selecione Relatórios locais e Resultados de dados que você verá uma regra de consulta chamada Relatórios e Dados. Clique nela e selecione Exibir no menu suspenso para ver como a regra é construída. Funciona assim:
- Condição – A condição para a regra é que a consulta contenha uma dessas palavras no início ou no fim da consulta: analysis;cube;dashboard;dashboards;data;database;report;reports;sales. Note que você vê os relatórios e as vendas ali. Assim, se alguém fizer a consulta por "relatórios de vendas", essa regra será executada. Parece perfeito: se alguém pesquisar por "relatórios de vendas", então queremos MESMO que vejam os relatórios de vendas da nossa divisão. Como parte dessa regra, é atribuída a correspondência a esses termos de ação, e tudo mais é atribuído aos termos objeto. Nesse caso, "relatórios" é atribuído ao termo de ação. e "vendas" ao termos objeto.
- Ação – A ação para essa regra é executar outra consulta com base APENAS nos termos objeto. Assim, com base na condição acima, será executada uma consulta separada apenas para "vendas". E será adicionado um bloco que é sempre retornado no topo de todos os outros resultados. MAS…será pesquisado por vendas SOMENTE nos Relatórios locais e Resultados de dados. Essa é uma fonte de resultado também pronta para uso e especial e que, efetivamente, apenas retorna documentos do Excel (a extensão do arquivo termina com .XLSX, XLS, etc.). Ótimo! Então a consulta a ser feita é "vendas" e apenas em documentos do Excel.
- Publicação – A regra é ativada sem restrições de data de início ou de fim, então está sempre ativa.
Essa regra de consulta foi reativada, então agora esta é a aparência dos resultados quando fazemos uma consulta para relatórios de vendas:
Está melhorando: a regra de consulta está contribuindo e agora estamos obtendo nossos documentos com base em nosso tipo de conteúdo de relatórios de vendas personalizados aparecendo no topo dos resultados, e isso é ótimo! Porém, ainda não estamos mostrando nenhum dos metadados sobre os documentos, que é o que realmente junta tudo isso.
Modelos de exibição
No SharePoint 2010, se você quisesse renderizar um item específico de modo diferente, seria um processo muito árduo ter que entrar e modificar uma GRANDE parte de XSLT nos resultados principais da Web part. Você deve praticar suas incríveis habilidades de XSLT e testar e encontrar o local certo daquele enorme documento onde inserir seu código personalizado. No fim, não foi uma experiência tão prazerosa.
No SharePoint 2013 – consulte a música – exibimos os modelos e como eles são uma melhoria. Você não precisa mais carregar o Zen do XSLT sobre você, agora você pode criar seu código de exibição personalizado como um HTML em sequência direta. Na verdade, nesta postagem, usamos o Adobe’s Dreamweaver CS6 para criar o "código" para o modelo de exibição personalizado. Então, como os modelos de exibição funcionam?
Com um modelo de exibição, você possui algumas coisas diferentes para acompanhar:
- Propriedades gerenciadas – Você precisa saber quais propriedades gerenciadas você precisa que sejam retomadas no momento da consulta. Essas propriedades podem ser usadas no seu HTML, usando um método que será descrito a seguir.
- JS e CSS externos – Se você possui arquivos javascript ou CSS que queira usar no seu modelo de exibição, você pode exteriorizá-los e adicioná-los ao seu modelo de exibição.
- JS embutido – Você também pode usar o JS embutido no seu modelo de exibição. Para isso, só é preciso certificar-se que ele fique abaixo do primeiro <div> no modelo. Também falaremos mais sobre isso em breve.
- HTML – É onde você cria o HTML de verdade para seu modelo de exibição e que renderizará os resultados.
Para nosso modelo de exibição, vamos juntar os atributos do tipo de conteúdo do relatório de vendas personalizado que criamos para que ele seja exibido nos resultados de pesquisa desta forma:
Vamos começar. Basicamente, você sempre deve começar com um modelo de exibição existente quando for criar um novo. Se você acessar seu conjunto de sites do centro de pesquisa, Configurações de Site, clique no link Páginas mestras e layouts de página. Ao entrar na biblioteca, clique na pasta Modelos de Exibição, depois clique na pasta Pesquisa. Ali você encontrará todos os modelos de exibição prontos para uso. Provavelmente você verá um número de arquivos com o mesmo nome, mas que terão o sufixo .html ou .js. Você só tem que se preocupar com os arquivos .html (os arquivos .js são gerados automaticamente quando você carrega um arquivo .html). Nesse caso, como o modelo de exibição é para arquivos Excel, começamos com o arquivo Item_Excel.htm. Baixamos uma cópia local, renomeamos como SalesReport.html e a abrimos no Dreamweaver.
Depois, adicionamos as propriedades gerenciadas. Há uma marca chamada mso:ManagedPropertyMapping, na qual pomo as propriedades gerenciadas que seu modelo de exibição precisa. Adicionamos a nossa ao final da lista, usando o mesmo formato que o restante das propriedades gerenciadas. A aparência fica assim:
<mso:ManagedPropertyMapping msdt:dt="string">'Title':'Title', 'Author':'Author', 'Size':'Size', 'Path':'Path', 'Description':'Description', 'LastModifiedTime':'LastModifiedTime', 'CollapsingStatus':'CollapsingStatus', 'DocId':'DocId', 'HitHighlightedSummary':'HitHighlightedSummary', 'HitHighlightedProperties':'HitHighlightedProperties', 'FileExtension':'FileExtension', 'ViewsLifeTime':'ViewsLifeTime', 'ParentLink':'ParentLink', 'ViewsRecent':'ViewsRecent', 'FileType':'FileType', 'IsContainer':'IsContainer', 'ServerRedirectedURL':'ServerRedirectedURL', 'ServerRedirectedEmbedURL':'ServerRedirectedEmbedURL', 'ServerRedirectedPreviewURL':'ServerRedirectedPreviewURL', 'AccountManager':'AccountManager', 'SalesRegion':'SalesRegion', 'TotalAccounts':'TotalAccounts', 'TopAccounts':'TopAccounts', 'DirectReports':'DirectReports', 'ContentType':'ContentType'</mso:ManagedPropertyMapping>
Como você pode ver, foram adicionadas AccountManager, SalesRegion, etc., todas as propriedades que foram criadas para o tipo de conteúdo personalizado. Depois, rolamos a barra até onde diz:
<div id="_#= $htmlEncode(itemId) =#_" name="Item" data-displaytemplate="ExcelItem" class="ms-srch-item" onmouseover="_#= ctx.CurrentItem.csr_ShowHoverPanelCallback =#_" onmouseout="_#= ctx.CurrentItem.csr_HideHoverPanelCallback =#_">
_#=ctx.RenderBody(ctx)=#_
<div id="_#= $htmlEncode(hoverId) =#_" class="ms-srch-hover-outerContainer"></div>
</div>
E excluí tudo entre as marcas DIV externas (destacadas em vermelho acima). Agora podemos dar toda nossa atenção à criação do HTML . Antes de fazer isso, tem algumas coisas que precisamos saber:
- Provavelmente você achará mais fácil manter a marca <style> na seção <head> do seu modelo de exibição. Por razões que não falaremos agora, essas marcas de estilo serão descartadas quando o modelo de exibição for renderizado, então, no fim, você precisa copiar suas marcas de estilo e pô-las em um arquivo CSS separado. Contudo, enquanto você estiver criando seu HTML, você pode usar e modificar suas marcas de estilo para ter certeza de que elas reflitam a aparência que você quer que seu modelo de exibição tenha.
- Como mencionado acima, você pode adicionar o que chamamos de javascript embutido, o que significa que você pode adicionar o código javascript, desde que ele esteja no local correto. O local correto para um modelo de exibição quer dizer que ele tem que estar após a primeira marca DIV do seu modelo. Além disso, deve estar entre uma marca de abertura e uma de fechamento que se parecem com isso: <!--#_ e _#-->. Explicarei melhor as marcas personalizadas a seguir, mas basta dizer que se você não colocar o javascript entre essas marcas, ele não será executado. Uma coisa é que é MUITO legal sobre isso é que você pode usar variáveis que você define no seu javascript embutido ao criar um HTML que será saída. Isso será mais bem explicado no próximo item.
- Para emitir uma propriedade gerenciada ou uma variável a partir de qualquer javascript embutido que você tenha criado, eles precisam estar dentro de um conjunto de marcas de abertura e de fechamento como essas: _#= e =#_. As propriedades gerenciadas estão todas disponíveis em um objeto chamado ctx.CurrentItem. Por exemplo, para emitir a propriedade gerenciada AccountManager, as marcas seriam: _#= ctx.CurrentItem.AccountManager =#_. Se tivéssemos um javascript que se parecesse com isso: var foo = “The current Account Manager is “ + ctx.CurrentItem.AccountManager + “.”;, para emitir "foo", as marcas seriam: _#= foo =#_. Isso dá flexibilidade total para adicionar ou processar dados para trabalhar no seu modelo de exibição.
Agora que você entende os mecanismos para criar o HTML, a seguir temos o que foi usado para criar o modelo de exibição mostrado acima. Na marca head, adicionamos os atributos de estilo a seguir:
<style>
.ReportDiv
{
float:left;
}
.ReportText
{
font-family: Verdana, Geneva, sans-serif;
font-size: 12px;
}
.ReportHeading
{
font-weight: bold;
}
.LogoImg
{
margin-top: 15px;
width: 118px;
height: 101px;
}
.MasterDiv
{
float:left;
height: 215px;
width: 342px;
background-repeat: no-repeat;
background-image: url(https://sps/sites/search/PublishingImages/SalesReportBackground.PNG);
padding: 15px;
}
.DetailsContainer
{
background-color:#CCC;
}
</style>
O que merece ser notado aqui é que a imagem usada para o fundo nos detalhes do gerenciador de conta é um que já foi carregado para o site, e todo o restante deve ser autoexplicativo. Novamente, por ter essa marca de estilo na seção <head> é possível ver exatamente como o layout se parecerá ao projetá-lo no Dreamweaver.
Agora vamos observar o HTML que é usado para criar o modelo de exibição:
<div>
<div class="ReportDiv">
<img class="LogoImg" src="https://sps/sites/search/PublishingImages/SalesReportLogo.PNG" />
</div>
<div class="MasterDiv">
<!-- Title and link to item -->
<a href="_#= ctx.CurrentItem.Path =#_" class="ReportText">_#= ctx.CurrentItem.Title =#_</a>
<br/><br/>
<!-- Account Manager -->
<span class="ReportHeading ReportText">
Account Manager:
</span>
<span class="ReportText">
_#= ctx.CurrentItem.AccountManager =#_
</span><br/>
<!-- Sales Region -->
<span class="ReportHeading ReportText">
Sales Region:
</span>
<span class="ReportText">
_#= ctx.CurrentItem.SalesRegion =#_
</span><br/>
<!-- Total Accounts -->
<span class="ReportHeading ReportText">
Total Accounts:
</span>
<span class="ReportText">
_#= ctx.CurrentItem.TotalAccounts =#_
</span><br/>
<!-- Top Accounts -->
<span class="ReportHeading ReportText">
Top Accounts:
</span>
<span class="ReportText">
_#= ctx.CurrentItem.TopAccounts =#_
</span><br/>
<!-- Direct Reports -->
<span class="ReportHeading ReportText">
Direct Reports:
</span>
<span class="ReportText">
_#= ctx.CurrentItem.DirectReports =#_
</span><br/>
<!-- Hit Highlighted Text -->
<br/>
<span class="ReportHeading ReportText">
Details:
</span>
<br/>
<span class="DetailsContainer ReportText">
_#= Srch.U.processHHXML(ctx.CurrentItem.HitHighlightedSummary) =#_
</span>
</div>
</div>
Vamos pular a parte dos recursos de formatação desse conteúdo e focar apenas nos dados. É possível ver todos os locais em que incluímos as propriedades gerenciadas usando as marcas _#= e =#_. Você verá que é puramente uma substituição de token, assim podemos usá-lo diretamente no atributo <a> href acima (como o contrário de fazer isso com XSLT, que está bem mais envolvido). Os outros campos são incluídos na marca DIV ou SPAN adequada para formatação. O único caso "especial" exibido aqui é para o HitHighlightedSummary, que está usando um componente de processamento interno que surge com a pesquisa. Nesse momento, não possuímos uma lista completa dos componentes e métodos e do que eles fazem, mas adicionei esse só porque, caso não seja usado, o resumo não será destacado. Então, certifique-se de que usará esse método para esse fim.
Agora que tudo está funcionando, tem mais uma coisa que precisamos fazer na nossa marcação. Copiamos tudo entre as marcas <style> e pomos em um novo documento CSS chamado SalesReport.css. Na galeria da página mestra, na pasta /Modelos de exibição/Pesquisa, criamos outra pasta chamada Estilos. Carregamos o arquivo SalesReport.css nesse diretório. Para usá-lo no meu modelo de exibição, precisamos adicionar uma nova marca de script. Ela deve estar abaixo da marca <body>, e acima da primeira marca <div>. Uso uma função javascript do SharePoint chamada $includeCSS para que o arquivo CSS seja ativado no modelo de exibição. A marcação de abertura fica assim:
<body>
<script>
$includeCSS(this.url, "./styles/SalesReport.css");
</script>
<div id="Item_SalesReport">
Os códigos estão completos, mas como usamos o modelo de exibição personalizado?
Tipos de resultado
Tipos de resultado são a forma na qual você obtém os modelos de exibição invocados, com base em um conjunto de regras. As regras são bem fáceis de serem usadas: elas podem ser ativadas para um tipo de conteúdo específico e pré-definido, como um e-mail, um PDF, um documento Word, um SharePoint Wiki, etc. Além disso, você também pode usá-los apenas quando uma consulta for para uma fonte de resultado específica. Por fim, também é possível escolher uma propriedade gerenciada como critério para a regra, com qualquer comparação comum. Por exemplo, poderia existir uma regra de tipo de resultado que seria ativada somente quando o campo AccountManager contém "Vice-presidente" se você quisesse ter um tipo de exibição diferente usado para seus VPs. No nosso caso, queremos que nosso tipo de resultado seja ativado quando o tipo de conteúdo for igual a "Relatórios de venda". Então, adicionamos uma condição para o tipo de resultado que diz quando o ContentType é igual a "Relatórios de vendas".
Como você pode ver, poderíamos até mesmo adicionar vários valores para que correspondessem. Também podemos adicionar várias propriedades, que juntam os E's. Para o cenário ContentType, é tudo que precisamos. Uma vez definidas as condições, podemos configurar a Ação para a regra. Para um tipo de resultado, a Ação é apenas um menu suspenso com todos os modelos de exibição disponíveis. Tudo que precisamos fazer é escolher o modelo de exibição do Relatório de Vendas do menu suspenso e clicar no botão Salvar para criar o tipo de resultado. Mais uma vez, se você não tem certeza de como criar tipos de resultado, dê uma olhada em todos os tipos de resultados prontos no SharePoint. Você pode tirar muitas boas ideias para novos tipos de resultados ao fazer isso.
Juntando tudo
Agora temos todas as partes montadas: um tipo de conteúdo personalizado que capta os metadados que queremos, algumas propriedades para extraí-los e pô-los no índice, uma regra de consulta que garanta que o conteúdo do relatório de vendas seja exibido como um pop up no topo da lista quando alguém pesquisa por "relatórios de vendas", um modelo de exibição personalizado que exibe os metadados que captamos em um formato realmente único e útil que não parece remotamente próximo a um resultado de pesquisa típico e um tipo de resultado que assegura que nosso modelo de exibição seja usado quando nosso tipo de conteúdo é retornado aos resultados de pesquisa. Os resultados finais recém produzidos têm a seguinte aparência:
Isso conclui essa introdução para alguns dos ótimos recursos do SharePoint 2013 para a apresentação de resultados de pesquisa. Felizmente, você entende o poder desses recursos e pode encontrar várias formas interessantes de usá-los.
Esta é uma publicação localizada. O artigo original está em Using Query Rules, Result Types and Display Templates for a Custom Search Sales Report in SharePoint 2013