Búsquedas a través del modelo cliente de SharePoint 2013: KeywordQuery I

Dentro de las novedades de búsqueda de SharePoint 2013, nos encontramos con la capacidad de utilizar la mayoría de la funcionalidad del modelo de objetos de Query. A través de este modelo (CSOM) vamos a poder realizar búsquedas desde aplicaciones que se ejecuten en máquinas donde no está SharePoint 2013 instalado y obtener los resultados como si las realizáramos en la propia plataforma.

El modelo CSOM de búsqueda incluye un Framework de .NET y un modelo de JavaScript para poder atacar desde cliente y realizar las búsquedas. En este post vamos a ver cómo realizar una búsqueda básica utilizando el Framework de .NET desde una aplicación de consola.

Para ello vamos a utilizar una instancia del ClientContext para abrir un contexto de cliente contra nuestra plataforma, y a través del modelo de Microsoft.SharePoint.Client.Search.Query vamos a realizar la búsqueda utilizando la clase KeywordQuery, que nos devolverá los resultados en una ResultTable como veremos ahora.

Esta clase KeywordQuery va a representar una query de búqueda que usa la sintaxis de SharePoint 2013, con la que podremos construir consultas tanto en lenguaje Keyword Query Language (KQL) o FAST Query Language (FQL).

Lo primero de todo, va a ser en nuestro proyecto, incluir las librerías DLL necesarias para usar el modelo cliente de SharePoint 2013 y las búsquedas de SharePoint 2013. Podemos encontrarlas por defecto en la ruta C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI

Microsoft.SharePoint.Client.dll

Microsoft.SharePoint.Client.Runtime.dll

Microsoft.SharePoint.Client.Search.dll

image

Una vez agregadas, vamos a utilizar la clase KeywordQuery dentro de un contexto de cliente para realizar una búsqueda básica y ver qué nos devuelve, y cómo nos lo devuelve.

ClientResult<ResultTableCollection> results = null;

using (ClientContext ctx = new ClientContext("http://localhost:41414"))
{
KeywordQuery query = new KeywordQuery(ctx);
query.QueryText = "Item";

SearchExecutor executor = new SearchExecutor(ctx);
results = executor.ExecuteQuery(query);
ctx.ExecuteQuery();
}

if (results.Value.FirstOrDefault() != null)
{
Console.WriteLine("Results: " + results.Value.FirstOrDefault().ResultRows.Count());
foreach (var resultRow in results.Value.FirstOrDefault().ResultRows)
{
Console.WriteLine("\tTitle: {0}", resultRow["Title"]);
}
}

 


En esta Query buscamos la palabra Item (que hemos metido en varios elementos de una lista para que devuelva resultados). Si lanzamos el programa, nos devuelve lo siguiente:


image


Y si lanzamos la misma búsqueda desde el portal, veremos que nos devuelve exactamente los mismos elementos:


image


Y al igual que los resultados que nos devuelve el propio portal, desde nuestra aplicación de cliente podemos acceder a las propiedades que nos devuelve la búsqueda, de modo que podemos listarlas y ver que por ejemplo nuestro primer resultado tiene las siguientes propiedades:


image


Son las mismas propiedades que está utilizando la página de resultados de búsqueda de SharePoint 2013 para pintar en pantalla los resultados.


En otros post veremos como seguir utilizando este modelo de Search.

Desplegar Solución de forma no global

Cuando preparamos paquetes de solución para nuestras aplicaciones de SharePoint, la forma natural en la que Visual Studio nos prepara dichos paquetes, es para hacer un despliegue Global. ¿Qué quiere decir un despliegue global? Quiere decir que el paquete se va a desplegar para estar disponible en todas las Web Applications que están en la granja.

Desde el punto de vista de soluciones de SharePoint, esta es la forma normal, para poder reutilizar soluciones y para poder usar características entre Web Applications. Pero no siempre queremos que sea así, y hay veces que tenemos la necesidad de desplegar una solución de forma única para una determinada Web Application en concreto.

Vamos con un ejemplo. Si montamos un Timer Job para que se despliegue de forma global, basta con generar la clase del Job, una Feature con la activación del mismo, y un paquete de solución por defecto que incluya dicha feature:

image

image

Y desplegamos desde Visual Studio:

image

Y ahora si comprobamos desde la Administración Central cómo ha quedado desplegado nuestro paquete, podremos ver que se ha desplegado de forma Global:

image

Ahora vamos a generar un paquete diferente para que se despliegue a la que nosotros queremos.

Para ello hay que modificar desde Visual Studio el paquete, teniendo que prescindir del Wizard y haciendo la edición manual mediante XML. Básicamente se trata de añadir una entrada de Safe Control a la DLL que se genera en nuestro proyecto de SharePoint. Si tuvieramos más componentes propios y / o de terceros, esos se quedarían como están. Sólo hay que añadir el Safe Control al Assembly del proyecto de SharePoint.

Para ello, lo primero de todo, localizamos el paquete, y desde la pestaña de Manifest, hacemos clic en la parte inferior en Edit Options, donde podemos decir que queremos abrir el diseñador en modo XML:

image

image

Una vez confirmada la advertencia, editamos en el modo XML:

image

Y veremos algo similar a esto:

image

Hay que añadir por lo tanto una etiqueta de Safe Control al Assembly del proyecto, de forma que quedaría algo como la siguiente:

image

Ahora si desplegamos nuestro paquete, y revisamos desde la Administración Central el estado de nuestra solución, veremos que ya está desplegada para una Web Application en concreto:

image

SharePoint Between Racks © 2012
. Con la tecnología de Blogger.

¡Compártelo!


Estoy en LinkedIn!


Ve mi perfil en LinkedIn!