SharePoint. Consulta a múltiples listas con búsqueda

En el último artículo de Adrian Diaz sobre cómo realizar consultas en múltiples listas en SharePoint, nos enseñaba una de las diversas formas para conseguir resolver el más que común problema de SharePoint para consultar listas o bibliotecas de documentos que se encuentren distribuidos en diferentes sitios.

Abramos un pequeño debate de cómo y cuál es la mejor forma de realizar consultas en SharePoint sobre múltiples listas, ya que la opción propuesta por Adrián no siempre es la más adecuada o la más eficiente, y me encuentro con ganas de discutir un poco sobre tecnología J.

Como comenta Adrian en su artículo, cuando trabajamos con SharePoint tenemos que tener en cuenta que NO es un SQL Server aunque con las consultas CAML podamos hacer JOIN, UNION o cosas similares. Cuando tratamos con una Gestión Documental, los documentos se distribuyen en diferentes repositorios, cada uno en su departamento o sitio de referencia, en función de la seguridad, los tipos de documentos o por funcionalidad. Además, cada documento se suele clasificar en un Tipo de Contenido, o lo que es lo mismo, un tipo de documento con sus metadatos y procesos.

Pero, ¿Qué pasa cuando necesitamos consultar, por ejemplo, todos los tipos de documentos Ofertas que tenemos en nuestra intranet? Dependiendo de su distribución en sitios, lo habitual sería realizar una consulta en la biblioteca de documentos Comercial, dentro de los sitios de los Departamentos, esto que en seudocódigo traducimos como:

  1. Recorro la lista de sitios de Departamentos
  2. Por cada departamento, hago una consulta en la biblioteca para obtener todos los documentos que sean del tipo Oferta
  3. Cuando recorro todos los sitios, unifico la lista y la devuelvo

Esto es lo que Adrián soluciona de una forma muy eficiente en su artículo usando SPSiteDataQuery, pero ¿Por qué no hacerlo con búsqueda?

El servicio de búsqueda de SharePoint expone un API que nos permite realizar consultas de todo el contenido que tenga indexado y cuando hablo de índice, en SharePoint significa un fichero de texto con la clasificación de la información lista para buscar y devolver resultados de la base de datos de contenido.

SharePoint 2013 nos ofrece esta API tanto en el modelo de objetos de servidor (SSOM) como en el modelo de objetos de cliente (CSOM) o en la interfaz REST, y es aquí donde encontramos la primera ventaja con respecto al SPSiteDataQuery que no es posible su uso en el cliente. Veamos algún ejemplo:

SSOM

KeywordQuery keywordQuery = new KeywordQuery(web);

 

keywordQuery.QueryText = “ContentTypeId:0x0101*”;

keywordQuery.TrimDuplicates = false;

 

SearchExecutor searchExecutor = new SearchExecutor();

ResultTableCollection resultTableCollection = searchExecutor.ExecuteQuery(keywordQuery);

var results = resultTableCollection.Filter(“TableType”, KnownTableTypes.RelevantResults);

 

var dt = results.FirstOrDefault().Table;

 

REST

http://host/site/_api/search/query?querytext=’ContentTypeId:0x0101*’&trimduplicates=false

Hay que tener en cuenta que el servicio de búsqueda tiene un lenguaje de consultas específico, distinto a CAML Query, llamado Keyword Query Language (KQL).

Al tratarse de un índice de búsqueda, el rendimiento de la consulta es superior al SPSiteDataQuery y, como todos sabemos, esto en SharePoint siempre importa. Hemos realizado las siguientes pruebas:

Nº de Elementos

Ámbito

Tiempo Search (ms.)

Tiempo SPSiteDataQuery (ms.)

100

Sitio

4712

4261

100

Colección de Sitio

4965

7240

100

Toda la Granja

4965

N/A

* Las pruebas se han realizado en un servidor de desarrollo que no ofrece el mismo rendimiento que un entorno de producción.

Otra de las ventajas de usar búsqueda es que podemos realizar la consulta sobre toda la granja, mientras que el SPSiteDataQuery nos limita al ámbito de Colección de sitios. Con el servicio de búsqueda podemos traernos contenido de cualquier colección de sitios de la granja de SharePoint. Esto aunque parezca trivial, cuando hablamos de portales de miles de usuarios con un uso intensivo de la gestión documental puede ser fundamental y un punto de éxito dentro de la arquitectura de la solución. Por ejemplo, si dividimos los departamentos en múltiples colecciones de sitios podemos almacenar la información en diferentes bases de datos de contenido y garantizar la escalabilidad y el futuro de la intranet.

Por su puesto, el servicio de búsqueda tiene paginado y esto es algo que el SPSiteDataQuery no se puede permitir por cuestiones de arquitectura de SharePoint, pero que es algo muy común en las interfaces de usuario actuales y que debemos buscar siempre la forma más eficiente de realizarla.

Sí, no me queda otra, tengo que hablar de alguna ‘posible’ desventaja y darle algún punto a la solución de Adrian.

Para que las búsquedas funcionen, tenemos que tener todo el contenido indexado y esto implica que el servicio de rastreo de SharePoint ha tenido que pasar por cada elemento que queremos consultar. Hasta SharePoint 2010, lo normal era tener programado un rastreo incremental cada 15 minutos y un rastreo completo diario, lo que nos impide consultar un nuevo documento hasta que no se haya rastreo y lo habitual es que nuestros usuarios crean que el contenido se ha perdido o eliminado por error.

En SharePoint 2013 existe la posibilidad de activar un nuevo tipo de rastreo continuo, o lo que es lo mismo, cada cierto tiempo, se activa un rastreador que se encarga de indexar el contenido existente, con la ventaja de este proceso de rastreo no bloquea la siguiente ejecución y es posible que tengamos 5 o 6 rastreadores que disminuyen la posibilidad de que no aparezca un documento recién creado en nuestra intranet. Vale Adrian J, esto requiere que tengamos más máquina porque los rastreadores son los monstruos de las galletas de los procesadores, pero ¿te has planteado que con una buena arquitectura de SharePoint pensada para búsqueda esto no debería de ser un problema?

Resumiendo…

 

Búsqueda

SPSiteDataQuery

Consultas Cross-Site

Si, toda la granja

Si, sólo en la colección de sitios

API Cliente

Si

No

Velocidad

Más rápido con un ámbito más amplio

Pierde velocidad si se amplía el ámbito de búsqueda

Paginado

Si

No

 

Le paso el guante a Adrian, a ver si es capaz de mejorar estos resultados sin hacer uso de búsqueda.