Indexando contenido en el Servicio Azure Search

Muy buenas a todos.

En anteriores post, comenzamos a trabajar con el servicio de Azure Search. Concretamente, vimos como crear índices en una instancia del servicio creada en Azure.

Primeros pasos con Azure Search: Los índices

A continuación, ¿Cuál es el siguiente paso?, una vez que hemos creado el índice, tenemos que indexar documentos en ese índice y eso es lo que vamos a hacer en esta entrada.

La indexación de contenidos, una vez que tenemos creado el índice es muy sencilla. En primer lugar, vamos a crear una aplicación de consola y vamos ejecutar desde la consola de Nuget el siguiente  comando para añadir las referencias a la SDK de Azure:

Install-Package Microsoft.Azure.Search -Pre

Esta aplicación va a tener el siguiente código de ejemplo


class Program
{
static void Main(string[] args)
{
int option;

do
{
option = menu();
switch (option)
{
case 1:
PopulateIndexUsingSDK();

break;
default:
break;
}
}
while (option != 0);
}

private static void PopulateIndexUsingSDK()
{
SearchIndexClient indexClient = GetSearchIndexClient();

UploadDocuments(indexClient);
}

private static SearchIndexClient GetSearchIndexClient()
{
string serviceName = ConfigurationManager.AppSettings["SearchServiceName"];
string apiKey = ConfigurationManager.AppSettings["ApiKey"];

SearchIndexClient indexClient = new SearchIndexClient(serviceName,"files", new SearchCredentials(apiKey));

return indexClient;
}

private static void UploadDocuments(SearchIndexClient indexClient)
{

try
{
var files = new files[]{
new files(){
DocumentId = "1",
Name = "Example Document Title 1",
Url = "http://www.example.com/mydocument1",
CreatedDate = "2012-02-01"
},
new files(){
DocumentId = "2",
Name = "Example Document Title 2",
Url = "http://www.example.com/mydocument2",
CreatedDate = "2012-02-01"
},
new files(){
DocumentId = "3",
Name = "Example Document Title 3",
Url = "http://www.example.com/mydocument3",
CreatedDate = "2012-02-01"
}
};
var batch = IndexBatch.Upload(files);
indexClient.Documents.Index(batch);
}
catch (IndexBatchException e)
{

Console.WriteLine(
"Failed to index some of the documents: {0}",
String.Join(", ", e.IndexingResults.Where(r => !r.Succeeded).Select(r => r.Key)));
}

// Wait a while for indexing to complete.
Thread.Sleep(2000);
}

private static int menu()
{
int value = 0;

Console.WriteLine("-----------------------------------");
Console.WriteLine("1.- Populate index using .NET SDK");
Console.WriteLine("0.- Exit");
Console.WriteLine("-----------------------------------");

do
{
Console.WriteLine("Enter a valid option: ");
value = Int16.Parse(Console.ReadLine());
}
while (value < 0 && value > 1);

return value;
}
}

Vamos a ver los elementos clave de este código. Obviamente, los métodos más importantes de nuestra aplicación de consola son 2.

SearchIndexClient()

Este método crea un nuevo objeto del tipo SearchIndexClient que nos va a permitir operar con el índice en cuestión. Para ello, obtiene del App.Config los datos relacionados con el servicio de búsqueda (api-key y servicename) y a continuación en el constructor de la clase ServiceIndexClient indica: el nombre del servicio de búsqueda, el nombre del índice y las credenciales para acceder al servicio.

UploadDocuments()

Este método se encarga de hacer la subida de documentos propiamente dicha. Para ello crea un array de objetos de tipo files, que tienen la siguiente definición:


class files
{
public string DocumentId { get; set; }
public string Name { get; set; }
public string Url { get; set; }
public string CreatedDate { get; set; }
}

Una vez ya se ha generado el array,  lo primero que se hace es crear un batch con la petición que se quiere hacer por medio de método IndexBatch.Upload(files).

A continuación por medio de la función indexClient.Documents.Index(batch) se hace la subida de los documentos al servicio Azure.

Se usa, para esperar y darle tiempo a que la indexación de documentos finalice correctamente Thread.Sleep(2000)

Ahora, podemos ejecutar la aplicación y ver los resultados. Si accedemos después al servicio de búsqueda de Azure, podemos ver que los elementos se han añadido correctamente la índice.

Captura de pantalla 2016-02-02 a las 22.24.17

Captura de pantalla 2016-02-02 a las 22.24.35

Os voy a dejar algunos enlaces que he usado para la entrada de hoy:

https://azure.microsoft.com/en-us/documentation/articles/search-howto-dotnet-sdk/

https://msdn.microsoft.com/en-us/library/azure/dn951165.aspx

Y esto es todo por hoy, en próximas entradas, veremos como usamos esto que hemos aprendido hoy y lo que vimos en la entrada anterior.

Autenticación app-only para usar la API Microsoft Graph en webjobs de Azure

para indexar contenido de Office 365 en este servicio Azure Search

Espero que os haya resultado interesante.

 

Anuncios

Autenticación app-only para usar la API Microsoft Graph en webjobs de Azure

Muy buenas a todos

En entradas anteriores, hemos visto cómo empezar a trabajar con el servicio de búsqueda de Azure, creando los índices. Dentro de mi objetivo a la hora de trabajar con este servicio, estaba el de indexar contenido de Office 365 usando la API Microsoft Graph por medio de webjobs. Y es aquí donde entra lo que os quiero contar hoy.

El flujo habitual de autenticación para usar la API Microsoft Graph en nuestras aplicaciones está basado en el protocolo OAuth2. Este protocolo parte de un token que hace una delegación de una serie de permisos específicos para un usuario concreto. Para obtener este token, es necesario que el usuario se identifique en Office 365 al menos una vez, por lo que tiene que introducir sus credenciales en una pantalla de autenticación que se muestra en pantalla.

Sin embargo, hay una serie de aplicaciones en las que este flujo de autenticación no es posible, aplicaciones que ejecutan tareas en background y en las que no hay un usuario como pueden ser los webjobs. Para este tipo de aplicaciones, el protocolo OAuth2 proporcionar un flujo adicional de autenticación y es el que vamos a usar para acceder a la API de Microsoft Graph en una aplicación que se va a ejecutar en un webjob de Azure. Podemos usar este flujo de autenticación, de momento, para obtener acceso a las API de contactos, mail y calendario. He estado probando y para OneDrive aún no está soportado.

Antes de nada, os voy a dejar los enlaces donde he encontrado toda la información y el tutorial para poder configurar la aplicación y todo lo que hay que hacer en Azure para que funcione correctamente.

http://www.eliostruyf.com/building-daemon-or-service-app-with-the-microsoft-graph-api/

http://blogs.msdn.com/b/exchangedev/archive/2015/01/21/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx

Creando los permisos para la aplicación en AAD

El primer paso que tenemos daremos será configurar los permisos de nuestra aplicación en Azure Active Directory.

1.- Accedemos a Azure, el portal clásico y vamos a la sección de Azure Active Directory. Una vez ahí nos vamos al apartado de aplicaciones, donde añadiremos una nueva aplicación.

Captura de pantalla 2016-01-24 a las 16.28.51

2.- Seleccionamos la opción de “Agregar una aplicación que mi organización está desarrollando” y de tipo “Aplicación Web y/o API Web” ya que la otra opción no soporta el tipo de autenticación app-only que vamos a configurar.

Captura de pantalla 2016-01-24 a las 16.29.04

Captura de pantalla 2016-01-24 a las 16.29.28

3.- Indicamos la URL de inicio de sesión y la URI de la aplicación. El primero de los dos valores, no es importante, en este caso hemos añadido la url donde el webjob estará alojado.

Captura de pantalla 2016-01-24 a las 16.30.49

4.- Vamos a la nueva aplicación que hemos añadido y en la pestaña “Configuración”, vamos a la parte final, de permisos, ahí añadimos permisos para Microsoft Graph.

Captura de pantalla 2016-01-24 a las 16.31.30

Captura de pantalla 2016-01-24 a las 16.31.42

5.- Una vez añadidos, tenemos que indicar en el desplegable de “Permisos de la Aplicación” (ya que los permisos los vamos a conceder directamente a la aplicación), los servicios para los que tendrá permisos.

Captura de pantalla 2016-01-24 a las 16.31.57

6.- Una vez terminado pulsamos Guardar.

Creando y configurando los certificados

A continuación necesitamos generar los certificados y configurarlos en nuestra aplicación web (que también tendremos que crear) y en la aplicación que acabamos de crear en nuestro AAD.

1.- En primer lugar, abrimos la consola de comandos y creamos el certificado, sustituyendo Tenant y AppName por los valores que correspondan

makecert -r -pe -n “CN=Tenant AppName Cert” -b 11/25/2015 -e 11/25/2017 -ss my -len 2048

2.- A continuación, vamos a exportar dicho certificado como PFX y CER. Para ello primero abrimos el Microsoft Management Console (mmc.exe).

3.- Una vez aquí, vamos a archivo->Agregar o quitar complemento y ahí añadimos la opción certificados.

cer1

4.- A continuación, buscamos el certificado que acabamos de crear y hacemos click sobre el botón derecho del mismo y seleccionamos Todas las tareas->exportar

cer3

Tenemos dos opciones de exportación, “Exportar la clave privada” y “No exportar la clave privada”, ejecutaremos la exportación dos veces y completaremos el asistente para cada una de éstas opciones, generando los dos certificados.

5.- Ahora, volvemos nuevamente a la aplicación que hemos creado en Azure Active Directory para configurar el certificado en la misma. Esto no se puede hacer a través de una interfaz gráfica, por lo que habrá que hacerlo modificando el manifest. Para ello, lo primero que debemos hacer es recuperar las claves del certificado CER que hemos obtenido, esto lo podemos hacer por medio del siguiente script de powershell:


$certPath = Read-Host "Enter certificate path (.cer)"
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$cert.Import($certPath)
$rawCert = $cert.GetRawCertData()
$base64Cert = [System.Convert]::ToBase64String($rawCert)
$rawCertHash = $cert.GetCertHash()
$base64CertHash = [System.Convert]::ToBase64String($rawCertHash)
$KeyId = [System.Guid]::NewGuid().ToString()
Write-Host "base64Cert:" $base64Cert
Write-Host "base64CertHash:" $base64CertHash
Write-Host "KeyId:" $KeyId

Este script nos devuelve las tres claves que nos hacen falta.

6.- Ahora, descargamos el manifest de la aplicación:

Captura de pantalla 2016-01-24 a las 17.46.09

Captura de pantalla 2016-01-24 a las 17.46.25

7.- Y sustituimos la siguiente cadena:


"keyCredentials": []

por


"keyCredentials": [
 {
 "customKeyIdentifier": "base64CertHash",
 "keyId": "KeyId",
 "type": "AsymmetricX509Cert",
 "usage": "Verify",
 "value": "base64Cert"
 }
],

Sustituyendo los valores “base64CertHash”, “KeyId” y “base64Cert”, por la cadena correspondiente obtenida de la ejecución del script powershell anterior.

8.- Ahora tenemos que volver a cargar el manifest modificado en la aplicación con lo que habremos terminado de configurar los permisos de nuestra app en Azure Active Directory.

9.- A continuación, creamos una aplicación web de Azure y cargamos el certificado PFX en la misma.

Captura de pantalla 2016-01-24 a las 17.57.36

Es necesario escalar la aplicación web a nivel básico

Captura de pantalla 2016-01-24 a las 17.58.28

En la pestaña configuración de la aplicación web, hacemos click en Cargar un certificado

Captura de pantalla 2016-01-24 a las 17.59.15

Captura de pantalla 2016-01-24 a las 18.01.35

En la sección de configuración de aplicación, añadimos el valor WEBSITE_LOAD_CERTIFICATES con la huella digital que hemos obtenido al cargar el certificado.

Captura de pantalla 2016-01-24 a las 18.07.42

Y por fin, habremos configurado los certificados en Azure. Ahora no solo nos queda publicar y probar el WebJobs.

Creando y publicando el webjob en Azure 

Vamos a crear una nueva aplicación de consola con el código del WebJob que vamos a publicar.

Para esta aplicación hay que añadir las siguientes referencias:

  • System.Configuration

Y Añadir a través de Nuget la librería ADAL y RestSharp.

Además en el app.config, debemos añadir las siguientes propiedades:


 <appSettings>;
 <add key="GraphUrl" value="https://graph.microsoft.com"/>;
 <add key="ClientId" value="clientidaad"/>;
 <add key="Thumbprint" value="thumbprint"/>;
 <add key="Authority" value="https://login.windows.net/tenant.onmicrosoft.com/"/>;
 </appSettings>;

Debemos de sustituir el clientidaad por el ClientId de la aplicación que hemos creado en el Azure Active Directory, el valor de thumbprint por la huella obtenida al cargar el certificado en la aplicación web y por último sustituir el valor tenant por el nombre de nuestra organización.

Lo que nos queda ahora, es el código de la aplicación de consola de ejemplo, que es el siguiente:


class Program
 {
 private static readonly string GraphUrl = ConfigurationManager.AppSettings["GraphUrl"];
 private static readonly string ClientId = ConfigurationManager.AppSettings["ClientId"];
 private static readonly string Authority = ConfigurationManager.AppSettings["Authority"];
 private static readonly string Thumbprint = ConfigurationManager.AppSettings["Thumbprint"];

static void Main(string[] args)
 {
 //&nbsp;Recuperar el certificado
 var certificate = GetCertificate();

//&nbsp;Recuperar el token de acceso
 var token = GetAccessToken(certificate);

//&nbsp;Obtener los contactos
 var client = new RestClient(GraphUrl);
 var request = new RestRequest("/v1.0/users/&lt;userid&gt;/contacts", Method.GET);
 request.AddHeader("Authorization", "Bearer " + token.Result);
 request.AddHeader("Content-Type", "application/json");
 request.AddHeader("Accept", "application/json");

var response = client.Execute(request);
 var content = response.Content;

Console.WriteLine(content);

}

private static X509Certificate2 GetCertificate()
 {
 X509Certificate2 certificate = null;
 var certStore = new X509Store(StoreName.My, StoreLocation.CurrentUser);
 certStore.Open(OpenFlags.ReadOnly);
 var certCollection = certStore.Certificates.Find(X509FindType.FindByThumbprint, Thumbprint, false);

 if (certCollection.Count &gt; 0)
 {
 certificate = certCollection[0];
 }
 certStore.Close();
 return certificate;
 }

private static async Task&lt;string&gt; GetAccessToken(X509Certificate2 certificate)
 {
 var authenticationContext = new AuthenticationContext(Authority, false);
 var cac = new ClientAssertionCertificate(ClientId, certificate);
 var authenticationResult = await authenticationContext.AcquireTokenAsync(GraphUrl, cac);
 return authenticationResult.AccessToken;
 }
 }

El último paso es publicar la aplicación como un WebJob de Azure. Para ello, haciendo click en botón derecho sobre el proyecto de consola, seleccionaremos la opción Publish as Azure WebJob

public1

A continuación, indicamos la planificación del WebJob:

public2

Seleccionamos la aplicación web a la que queremos asociar el WebJob:

public3

Por último publicamos el WebJob.

public4

Y esto es todo, podemos probarlo ejecutando una vez el WebJob en Azure y ver que al final, se devuelven los contactos del usuario que le hemos indicado.

Captura de pantalla 2016-01-24 a las 19.05.09

Hasta aquí el post de hoy. Con lo que hemos visto en este post, podemos consumir información de Office 365 desde aplicaciones en background que no nos permiten usar el flujo habitual de autenticación del protocolo OAuth2.

Espero que os haya resultado interesante, en futuros post usaremos todo lo que hemos visto hoy para indexar contenido de Office 365 en Azure Search a través de un WebJob como el que hemos creado hoy.

Hasta la próxima

 

 

Primeros pasos con Azure Search: Los índices

Muy buenas a todos.

Hoy, quiero empezar a hablar sobre un servicio al que tenía muchas ganas de dedicarle un tiempo, el servicio Azure Search. A lo largo de los próximos días haremos un overview completo sobre este servicio y veremos cómo funciona y qué podemos hacer con él.

El servicio Azure Search permite añadir una robusta experiencia de búsqueda a nuestras aplicaciones usando una API REST o una SDK .NET sin gestionar la infraestructura de búsqueda o llegar a ser un experto en búsqueda.

En el siguiente enlace, podréis ver una descripción más profunda sobre este servicio:

https://azure.microsoft.com/en-us/documentation/articles/search-what-is-azure-search/

En el post de hoy, vamos a  ver cómo configurar el servicio de búsqueda y el primer paso a la hora de poder comenzar a trabajar con el mismo, los índices.

Configurando el servicio de búsqueda en Azure

Lo primero que debemos hacer es aprovisionar el servicio de búsqueda. Para ello, en el nuevo portal de Azure, iremos a Nuevo->Datos y almacenamiento->Búsqueda de Azure, como se ve en la siguiente imagen.

Captura de pantalla 2016-01-16 a las 16.08.41

A continuación, tenemos que indicar los datos básicos de configuración del servicio: el nombre del servicio, el grupo de recursos al que pertenece, la ubicación y el nivel de precios.

Captura de pantalla 2016-01-16 a las 16.11.14

Para este servicio disponemos de dos niveles de precios, con diferentes características que harán que en función de la finalidad del uso del servicio, elijamos uno u otro.

Captura de pantalla 2016-01-18 a las 23.27.48

Una vez configurados todos los parámetros, pulsamos sobre crear y el servicio se aprovisionará, con lo que ya lo tendremos listo para usar.

Los índices en Azure Search

Un índice es el medio principal para organizar y buscar documentos en el servicio de búsqueda de Azure, similar a cómo se organizan los registros en una tabla de una base de datos. Cada índice tiene una colección de documentos que cumplen el esquema de índice (nombres de campo, tipos de datos y propiedades), pero los índices también especifican construcciones adicionales (proveedores de sugerencias, perfiles de puntuación y configuración de CORS) que definen otros comportamientos de la búsqueda.

Por tanto es necesario, como paso previo a subir documentos al servicio de búsqueda, definir un índice y su estructura, que no es más que una estructura de tablas que acepta datos y consultas. Los índices en el servicio de búsqueda de Azure, se pueden crear de tres formas, o desde el propio portal de Azure o por medio de código usando una SDK de .NET o una API REST.

A continuación, vamos a ver como crear un índice por medio de la SDK y la API REST en un solución de consola de Visual Studio.

Creando índices en Azure Search

Para ello, vamos a crear una aplicación de consola en Visual Studio. Una vez creada, tenemos que añadir las referencias a la SDK de Azure Search. Esto lo conseguiremos ejecutando en la consola de Nuget el siguiente comando:

Install-Package Microsoft.Azure.Search -Pre

Nos instalará todas las referencias necesarias para poder trabajar con la SDK correspondientes. Además, para el resto del ejemplo necesitaremos añadir otras dos referencias:

System.Configuration (Con la que tendremos la posibilidad de hacer referencia al App.Config de nuestra aplicación)

System.Net (Necesaria para poder llamadas REST desde la aplicación de consola).

Una vez añadidas todas las referencias, podemos pasar a ver el código. Para la aplicación de consola hemos creado un sencillo menú que nos permite elegir entre las dos opciones que tiene nuestra aplicación, crear un índice usando la SDK, o crear un índice por medio de API REST. Este es el código que implementa el menú:


class Program
 {
 static void Main(string[] args)
 {
 int option;

do
 {
 option = menu();
 switch (option)
 {
 case 1:

SearchServiceClient serviceClient = GetSearchServiceClient();

DeleteIndexIfExists(serviceClient,"files");
 CreateIndexUsingNetSDK(serviceClient,"files");

Console.WriteLine("Index successfully created");

break;
 case 2:

SearchServiceClient serviceClient2 = GetSearchServiceClient();

DeleteIndexIfExists(serviceClient2,"files");

CreateIndexUsingRESTAPI("files");

break;
 default:
 break;
 }
 }
 while (option != 0);
 }

private static int menu()

 {
 int value = 0;

Console.WriteLine("-----------------------------------");
 Console.WriteLine("1.- Create an index using .NET SDK");
 Console.WriteLine("2.- Create an index using REST API");
 Console.WriteLine("0.- Exit");
 Console.WriteLine("-----------------------------------");

do
 {
 Console.WriteLine("Enter an valid option: ");
 value = Int16.Parse(Console.ReadLine());
 }
 while (value &lt; 0 &amp;&amp; value &gt; 2);

return value;
 }

}

Como veréis, este código hace referencia a cuatro funciones, que son la clave de este post y que son en las que nos vamos a centrar para describir a continuación.

GetSearchServiceClient: Esta función nos va a devolver un objeto de tipo SearchServiceClient que es el que nos permite interaccionar con el servicio de búsqueda.

private static SearchServiceClient GetSearchServiceClient()
{
string serviceName = ConfigurationManager.AppSettings["SearchServiceName"];
string apiKey = ConfigurationManager.AppSettings["ApiKey"];

SearchServiceClient serviceClient = new SearchServiceClient(serviceName, new SearchCredentials(apiKey));

return serviceClient;
}

Este método solo se encarga de crear un nuevo objeto de tipo SearchServiceClient. El constructor de esta clase, recibe dos parámetros: el nombre del servicio que podemos obtener de la URL del servicio (https://%5Bnombreservicio%5D.search.windows.net) y la api-key para la autenticación del servicio. Ambos parámetros, para el ejemplo, los he almacenado en el App.Config de la aplicación de consola.

DeleteIndexIfExists: Una buena práctica, es comprobar si el índice existe previamente antes de crearlo y si es así, eliminarlo. De esto se encarga la función que vamos a ver a continuación:

private static void DeleteIndexIfExists(SearchServiceClient serviceClient, string indexName)
{
if (serviceClient.Indexes.Exists(indexName))
serviceClient.Indexes.Delete(indexName);
}

CreateIndexUsingNetSDK: Este método, crea un índice usando la SDK .NET de Azure Search.

private static void CreateIndexUsingNetSDK(SearchServiceClient serviceClient, string indexName)
{
var index = new Index()
{
Name = indexName,
Fields = new[]{
new Field("DocumentId",DataType.String) { IsKey = true, IsRetrievable = true, IsFilterable = true},
new Field("Name", DataType.String) { IsRetrievable = true, IsSearchable = true, IsFilterable = true},
new Field("Url", DataType.String) { IsRetrievable = true, IsSearchable = true, IsFilterable = true},
new Field("CreatedDate", DataType.String) { IsRetrievable = true, IsSearchable = true, IsFilterable = true}
}
};

serviceClient.Indexes.Create(index);
}

El método recibe como parámetros el objeto que hace referencia al servicio de búsqueda y el nombre del índice que vamos a crear. A continuación crea un objeto de tipo Index y le indica el nombre y los campos que va a tener dicho índice.

Cada campo se crea por medio de un objeto de tipo Field. El constructor de dicho objeto tiene dos parámetros, el nombre del campo y el tipo del mismo. Luego, podremos indicar otras propiedades de cada campo, como se ve en el ejemplo.

Por último, se crea el índice propiamente dicho con la llamada serviceClient.Indexes.Create(index) que vemos al final de la función.

CreateIndexUsingRESTAPI: La última función, crea un índice por medio de una llamada API REST.:

private static void CreateIndexUsingRESTAPI(string indexName)
{
string serviceName = ConfigurationManager.AppSettings["SearchServiceName"];
string apiKey = ConfigurationManager.AppSettings["ApiKey"];

string body = @"{
'name': '" + indexName + @"',
'fields': [
{'name': 'DocumentId', 'type': 'Edm.String', 'key': true, 'searchable': true},
{'name': 'Name', 'type': 'Edm.String'},
{'name': 'Url', 'type': 'Edm.String'},
{'name': 'CreatedDate', 'type': 'Edm.String'}
]
}";

using(var client = new HttpClient())
{
client.BaseAddress = new Uri("https://" + serviceName + ".search.windows.net");

client.DefaultRequestHeaders.Add("api-key", apiKey);
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

var response = client.PostAsync("/indexes?api-version=2015-02-28", new StringContent(body,Encoding.UTF8, "application/json")).Result;

if(response.IsSuccessStatusCode)
{
Console.WriteLine("Index successfully created");
}
else
{
Console.WriteLine("HTTP Status: " + response.StatusCode.ToString() + " - Reason: " + response.ReasonPhrase);
}
}
}

Esta función en primer lugar, crea una cadena de texto con la estructura JSON del índice, y la almacena en la variable body. A continuación, establece la URL base del servicio REST de Azure Search (https://%5Bnombreservicio%5D.search.windows.net).

Tras esto, hace la llamada haciendo uso de la clase HttpClient. A esta llamada, de tipo POST y con la URL (/indexes?api-version=2015-02-28), hay que añadirle en las cabeceras la api-key del servicio.

Una vez que se recibe la respuesta, podremos comprobar si hemos recibido un estado correcto, en cuyo caso el índice se habrá creado correctamente, o no.

Probando el ejemplo
Una vez terminado el código, si depuramos el ejemplo nos aparece una pantalla como la siguiente:

test

Pulsando sobre cualquier de las dos opciones, veremos que se ejecuta correctamente, y si accedemos posteriormente al portal de Azure, al servicio de búsqueda, veremos que el índice se ha creado.

Captura de pantalla 2016-01-18 a las 20.44.17
Os voy a dejar algunos enlaces en los que me he basado y que os pueden resultar de interés.

https://azure.microsoft.com/en-us/services/search/

https://azure.microsoft.com/en-us/documentation/articles/search-get-started/

https://azure.microsoft.com/en-us/documentation/articles/search-howto-dotnet-sdk/

https://azure.microsoft.com/en-us/documentation/articles/search-create-service-portal/

Y esto es todo hasta aquí, en este post, hemos configurado y puesto en marcha el servicio de búsqueda creando los índices. En próximos posts, comenzaremos a indexar contenido y veremos cómo podemos hacerlo y consumiremos el servicio de búsqueda con todas las opciones de que disponemos para trabajar con el mismo.

Espero, como siempre, que os haya resultado interesante.

Hasta la próxima.

[Evento] Potencia tus desarrollos de SharePoint con Azure

Muy buenas a todos, y antes de nada Feliz Navidad a todos los que habitualmente entran a “El blog del programador”.

Hoy os quiero hablar del próximo evento que se va a celebrar, organizado por la comunidad de usuarios de SharePoint de Madrid, MadPoint, y que tendrá lugar el próximo 15 de Enero en Wayra en la calla Gran Via, 28.

En dicho evento, tendremos la oportunidad de profundizar en las oportunidades que nos ofrece Azure para usarla en nuestros desarrollos de SharePoint, tanto OnLine como OnPremise. Os dejo el enlace de la página de madpoint donde encontraréis toda la información sobre el evento

http://www.madpoint.net/2015/12/23/evento-potencia-tus-desarrollos-de-sharepoint-con-azure/

La agenda del evento, en donde tendré la oportunidad de aportar mi granito de arena, es la siguiente:

  • 16.00 – 16.15: Bienvenida e introducción
  • 16.15-16.50: Diseña tu propio Office 365 con Azure IaaS y PaaS
    • En esta sesión teórica, Miguel Tabera (MVP de Office Servers and Services) nos enseñará, desde el punto de vista de arquitectura, cómo es posible utilizar máquinas virtuales y servicios como las web apps, Azure Search, Media Services y Application Insights para diseñar nuestro propio servicio similar a Office 365 en el que proporcionemos SharePoint, Exchange, Office Vídeo, etc.
  • 17.00-17.50: Logic apps o el futuro de los flujos de trabajo
    • ¿Qué son las logic apps? ¿Cómo las podemos utilizar? ¿Se convertirá en el motor para desarrollar nuestras lógicas de negocio y flujos de trabajo en el futuro? En esta sesión, Jose Carlos Rodríguez Avilés, nos enseñará qué podemos hacer con este servicio de Azure y cómo podemos usarlo para implementar lógicas de negocio interconectando entre si la amplia gama de herramientas que usamos hoy en día.
  • 18.00-18.50: Timerjobs y eventos en SharePoint Online usando Hangfire
    • Cristian Ruiz nos mostrará un ejemplo práctico de cómo crear timerjobs y eventos remotos (evitando los límites de tiempo de SharePoint online) utilizando el motor de tareas programadas.

Como podéis ver, las ponencias son muy interesantes, os animo a seguir de cerca la información del evento, y a que participéis en el mismo. Poco a poco, desde MadPoint iréis recibiendo más información, desde twitter, linkedin y la página de web, para todos aquellos que podáis estar interesado.

Un saludo, y por si acaso que tengáis una muy buena entrada del año 2016.

 

El service Bus de Azure: Los temas

Muy buenas a todos,

Hace unos días, escribí un post en el que os contaba los primeros pasos para usar la funcionalidad más básica del Service Bus de Azure, las cosas FIFO.

Primeros pasos con el Service Bus de Azure: las colas

Hoy quiero profundizar más en el Service Bus y las opciones que nos permite, concretamente, quiero hablaros sobre una funcionalidad que me ha resultado interesantísima, los temas. Vamos a ver el esquema de esta funcionalidad antes de entrar en el detalle de la misma.

sb-topics-01

Esta funcionalidad, como podemos ver en la imagen, nos va a permitir crear un tema y asociado a éste distintas subscripciones. Los mensajes se enviarán al tema y las aplicaciones consumidoras leerán dichos mensajes de la subscripción a la que estén subscritos. Y ¿Cómo se copían los mensajes en las distintas subscripciones?, pues como veremos más adelante, se hace mediante filtros SQL a las distintas propiedades del mensaje, lo que nos permite trabajar de una forma muy sencilla y familiar. Os dejo algunos enlaces que os pueden ser de interés.

https://azure.microsoft.com/en-us/documentation/articles/fundamentals-service-bus-hybrid-solutions/

https://azure.microsoft.com/es-es/documentation/articles/service-bus-dotnet-how-to-use-topics-subscriptions/

Esta funcionalidad es muy útil por ejemplo en sistemas de gestión de incidencias, en donde podemos clasificar las incidencias en función de la importancia de las mismas, y consumirlas por distintos clientes en función de esto. A continuación os voy a enseñar en un ejemplo cómo se pueden usar los temas del Service Bus de Azure.

Creando el servicio en Azure

Lo primero que tenemos que hacer es entrar en el portal de administración de Azure para crear un nuevo Service Bus.

Captura de pantalla 2015-07-01 a las 20.01.02

Una vez ahí, en el apartado de Service Bus, hacemos click en crear y completamos el formulario

Captura de pantalla 2015-07-01 a las 20.01.19

Seleccionamos el centro de datos que queremos y en el caso de querer usar los temas, tenemos que indicar el modo standard en lugar del modo basic.

Esta es la pantalla de opciones de un service bus una vez creado.

Captura de pantalla 2015-07-01 a las 20.07.44

Cómo usarlo desde nuestra aplicación

Vamos a crear una nueva solución con un proyecto de tipo aplicación de consola en Visual Studio 2013. Para poder usar el Service Bus, tendremos en primer lugar, que añadir desde Nuget el paquete Microsoft Azure Service Bus.

Tras este tendremos que añadir la cadena de conexión al app.config de la aplicación de consola. La cadena de conexión la podemos obtener en el portal de azure. Una vez dentro del Service Bus creado, en la parte inferior de la pantalla, hacemos click en Información de conexión. (Como podemos ver en la imagen inmediatamente anterior).

De ahí copiamos la cadena de conexión y la añadimos en la el app.config de la siguiente forma:

<appSettings>
        <!-- Service Bus specific app setings for messaging connections -->
        <add key="Microsoft.ServiceBus.ConnectionString" value="[connectionstringhere]"/>
    </appSettings>

El productor de mensajes

Vamos a empezar por ver el código del productor de mensajes.

class Program
    {
        static void Main(string[] args)
        {
            bool exit = false;
            int i = 1;

            do
            {
                switch (menu())
                {
                    case 1:

                        TopicHelper.CreateTopic("TestTopic");
                        break;
                    case 2:

                        Console.Write("Write name to this subscription: ");
                        string subscriptionName = Console.ReadLine();

                        Console.Write("Write filter: ");
                        string sqlFilter = Console.ReadLine();

                        SqlFilter filter = new SqlFilter(sqlFilter);

                        TopicHelper.CreateSubscription("TestTopic",subscriptionName,filter);
                        
                        break;

                    case 3:

                        Console.Write("Set message priority: ");
                        string priority = Console.ReadLine();

                        BrokeredMessage message = new BrokeredMessage("Example Service Bus Message");
                        message.Properties["Counter"] = i;
                        message.Properties["Priority"] = priority;

                        i += 1;

                        TopicHelper.SendMessage("TestTopic", message);
                        break;
                    default:
                        exit = true;
                        break;
                }
            }
            while (!exit);
        }

        static int menu()
        {
            Console.WriteLine("--- Option Menu ---");
            Console.WriteLine("0.- Exit");
            Console.WriteLine("1.- Create Topic");
            Console.WriteLine("2.- Create Subscription");
            Console.WriteLine("3.- Send Message");
            Console.Write("-->");

            int value = int.Parse(Console.ReadLine());

            return value;
        }
    }

En este caso, el productor nos ofrece un menú con 3 opciones: Crear el tema, crear una subscripción y enviar un mensaje.

    • La creación del tema es muy similar a las colas. Las diferencias comienzan a la hora de crear subscripciones.
    • En este caso, en primer lugar indicamos el nombre de la subscripción y a continuación el filtro que queremos aplicar para la misma. Las subscripciones, como ya se comentó anteriormente, utilizan filtros sql sobre las propiedades de los mensajes para copiar los mensajes que se envían al tema. Algunos ejemplos de estos filtros SQL podrían ser de la siguiente forma:
Priority = 'medium'
Priority = 'high'
Counter >= 3
  • El envío de mensajes, al igual que la creación de los temas, es muy similar a lo visto en el post anterior

En el caso del ejemplo que se ha realizado he creado dos subscripciones, una donde se copiarán los mensajes que lleven el valor de su propiedad Priority a ‘medium’ y otra para cuando tenga el valor ‘high’. Antes de ver el código de los helpers que hacen la conexión del Service Bus, vamos a ver la secuencia de acciones que hemos lanzado en el ejemplo para configurar el tema.

creation

Como se ha podido observar, para la comunicación con el Service Bus se usa una clase TopicHelper, que tiene los siguientes métodos interesantes:

public class TopicHelper
    {
        public static void CreateTopic(string topicName)
        {
            string connectionString =
                CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");

            var namespaceManager =
                NamespaceManager.CreateFromConnectionString(connectionString);

            if (!namespaceManager.TopicExists(topicName))
            {
                namespaceManager.CreateTopic(topicName);
            }
        }

        public static void SendMessage(string topicName, BrokeredMessage message)
        {
            string connectionString =
                CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");

            TopicClient Client =
                TopicClient.CreateFromConnectionString(connectionString, topicName);

            Client.Send(message);
        }

        public static void CreateSubscription(string topicName, string subscriptionName, SqlFilter filter)
        {
            string connectionString =
                CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");

            var namespaceManager =
                NamespaceManager.CreateFromConnectionString(connectionString);

            if (!namespaceManager.SubscriptionExists(topicName, subscriptionName))
            {
                namespaceManager.CreateSubscription(topicName, subscriptionName, filter);
            }
        }
    }

Vamos a destacar aquí, por la novedad con respecto a la entrada en la que hablaba del uso de las colas, el método CreateSubscription. Este es el método que se usa para añadir una subscripción a un tema. Este método, además del nombre del tema, recibe el nombre de la subscrición y un parámetro de tipo SqlFilter, donde vamos a definir el filtro que usará esa subscripción para recibir los mensajes del tema.

El método básicamente, comprueba si existe una subscripción creada con ese nombre en el tema y en caso negativo la crea.

El consumidor de los mensajes

El código del consumidor de mensajes, es el que vemos a continuación.

class Program
    {
        private static string topicName = "TestTopic";
        private static string mediumSubscription = "Medium";
        private static string highSubscription = "High";

        public static void ThreadProcSubscriptionMedium()
        {
            Console.WriteLine("Entering to Medium Subscription Consumer");

            while(true)
            {
                BrokeredMessage message = TopicHelper.ReceiveMessage(topicName, mediumSubscription);

                Console.WriteLine("Read From Medium Priority Subscription");
                Console.WriteLine("Body: " + message.GetBody<string>());
                Console.WriteLine("MessageID: " + message.MessageId);
                Console.WriteLine("Test Property: " +
                message.Properties["Counter"]);
            }
        }

        public static void ThreadProcSubscriptionHigh()
        {
            Console.WriteLine("Entering to High Subscription Consumer");

            while(true)
            {
                BrokeredMessage message = TopicHelper.ReceiveMessage(topicName, highSubscription);

                Console.WriteLine("Read From Medium Priority Subscription");
                Console.WriteLine("Body: " + message.GetBody<string>());
                Console.WriteLine("MessageID: " + message.MessageId);
                Console.WriteLine("Test Property: " +
                message.Properties["Counter"]);
            }
        }

        static void Main(string[] args)
        {
            Thread thread1 = new Thread(new ThreadStart(ThreadProcSubscriptionMedium));
            Thread thread2 = new Thread(new ThreadStart(ThreadProcSubscriptionHigh));

            thread1.Start();
            thread2.Start();

            thread1.Join();
            thread2.Join();
        }
    }

Este código, crea dos hilos de ejecución, para poder leer simultáneamente de las dos subscripciones que hemos creado desde el productor, cuando recibe un mensaje de una subscripción u otra, lo imprime en pantalla indicando de la subscripción que lo ha hecho. Para la recepción de mensajes se utiliza la siguiente función de nuestra clase TopicHelper.

public static BrokeredMessage ReceiveMessage(string topicName, string nameSubscription)
        {
            string connectionString =
                CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");

            SubscriptionClient Client =
                SubscriptionClient.CreateFromConnectionString
                        (connectionString, topicName, nameSubscription);

            BrokeredMessage message = null;

            try
            {
                message = Client.Receive();
                message.Complete();
            }
            catch(Exception ex)
            {
                message.Abandon();
            }

            return message;

        }

Esta función se conecta con el tema del Service Bus y una subscripción indicadas como parámetro. Cuando recibe el mensaje y lo hace correctamente, usa el método Complete() para eliminar el mensaje de la subscripción. En caso de error, usar el método Abandon() para devolverlo a la subscripción.

Cómo funciona el ejemplo

Vamos a ver una captura en la que se ve como funciona de forma simultánea el ejemplo cuando se ejecutan, tanto el productor como el consumidor.

topicIII

Y esto es todo por hoy, espero que os haya resultado interesante y que os sirva para comprender mejor todas las oportunidades que nos ofrece el Service Bus. En la próxima entrada veremos como combinar este con SharePoint Online en un ejemplo.

Un saludo a todos.

Modificando el Web.config al desplegar una solución en SharePoint

Hola a todos,

Últimamente estoy intentando trabajar en la mejora de los desarrollos y de cómo enfocar las soluciones de SharePoint que después se desplegarán en la granja. Un aspecto de los que me quedaba por trabajar tenía que ver con el web.config de una aplicación web. En ocasiones, por diferentes motivos, algunas soluciones requieren de algunos parámetros de configuración para su funcionamiento, como es evidente, el lugar de esos parámetros es en el web.config (en el apartado de appSettings por ejemplo) de la aplicación web, que se encuentra en el caso de SharePoint en la ruta “C://inetpub/wwwroot/wss/VirtualDirectories”. Pero, imaginemos que tenemos una granja con varios servidores, ¿Es necesario ir a cada servidor de nuestra granja, acceder a su web.config y establecer esos parámetros de configuración manualmente?, es evidente que no, y que eso se trata de una mala práctica (Lo digo con conocimiento de causa XD). Para modificar el web.config de una aplicación web y añadirle parámetros de configuración que necesite nuestra solución, SharePoint nos proporciona los mecanismos necesarios.

Una buena solución puede ser utilizar el evento de activación y desactivación de una característica en una solución de SharePoint, para crear o borrar esos parámetros de configuración del web.config correspondiente. Para hacer esto disponemos de la clase SPWebConfigModification.

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx

Esta clase nos permitirá establecer las modificaciones que queremos hacer al web.config. Además, también haremos uso de la clase SPWebApplication para añadir los cambios que hayamos definido previamente.

Definiendo las modificaciones del web.config

Como ya he comentado, para definir estas modificaciones, se usa la clase SPWebConfigModification, para la que habrá que definir en cada caso, una serie de propiedades que voy a describir a continuación:

  • Name: Esta propiedad no es un nombre interno dado a la modificación. Se debe indicar la etiqueta del XML que se quiere modificar, además de todos los parámetros que se desean establecer del mismo. Esta propiedad posibilita a SharePoint el borrado posteriormente
  • Path: Indica el padre del nodo que se está intentando añadir o establecer
  • Owner: Esta propiedad es muy importante a la hora eliminar las modificaciones del web.config. Lo que hace es establecer un nombre único para los cambios que se han realizado.
  • Type: En la mayoría de las ocasiones se utilizará el valor EnsureChildNode
  • Value: La etiqueta XML que se quiere añadir en el web.config

Vamos a ver ahora un ejemplo de la definición de una modificación del web.config usando esta clase y sus propiedades.

SPWebConfigModification entry = new SPWebConfigModification();
entry.Name = @&quot;add[@key='KeyExample'][@value='ValueExample']&quot;;
entry.Path = &quot;configuration/appSettings&quot;;
entry.Sequence = 0;
entry.Owner = &quot;Owner&quot;;
entry.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
entry.Value = @&quot;&lt;add key='KeyExample' value='ValueExample' /&gt;&quot;;

Añadiendo las modificaciones al web.config

Una vez que ya hemos creado la modificación que queremos hacer, la añadiremos utilizando la clase SPWebApplication de la siguiente manera.

SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;

webApp.WebConfigModifications.Add(entry);

/*Call Update and ApplyWebConfigModifications to save changes*/
webApp.Update();
webApp.Farm.Services.GetValue&lt;SPWebService&gt;().ApplyWebConfigModifications();

La parte más reseñable de este código es la última línea, donde se llama a la función ApplyWebConfigModifications, os dejo el enlace a la MSDN donde se explica lo que hace esta función, lo cual me ha resultado interesante.

http://msdn.microsoft.com/es-es/library/microsoft.sharepoint.administration.spwebservice.applywebconfigmodifications.aspx

Eliminando las modificaciones del web.config

Para eliminar las modificaciones que hemos insertado anteriormente, por ejemplo, en el evento de desactivación de la característica correspondiente, usaremos, como ya mencionamos anteriormente la propiedad Owner de la clase SPWebConfigModification. Lo que haremos será obtener todas las modificaciones del SPWebApplication, comprobar aquellas cuyo Owner se corresponde con el de las modificaciones que queremos borrar, y en caso de que coincidan las borramos. Vamos a ver el código de cómo tendríamos que hacerlos.

private void removeConfigModification(SPWebApplication webApp)
{
     SPWebConfigModification entry = null;

     if (webApp.WebConfigModifications.Count &gt; 0)
     {
          for (int i = webApp.WebConfigModifications.Count - 1; i &gt;= 0; i--)
          {
              if (webApp.WebConfigModifications[i].Owner == &quot;Owner&quot;)
              {
                  entry = webApp.WebConfigModifications[i];
                  webApp.WebConfigModifications.Remove(entry);
              }
          }

          webApp.Update();
          webApp.Farm.Services.GetValue&lt;SPWebService&gt;().ApplyWebConfigModifications();
     }
}

Dejo por último algunos enlaces que me han servido de utilidad relacionados con este tema y donde es posible que haya más información sobre cómo se puede utilizar la modificación del web.config en SharePoint.

http://blogs.perficient.com/microsoft/2013/02/how-to-make-web-config-changes-with-a-feature-and-why-you-should/

http://blog.crsw.com/2007/09/20/how-to-modify-the-web-config-file-in-sharepoint-using-spwebconfigmodification/

http://smindreau.wordpress.com/2013/06/12/finally-the-way-to-add-web-config-modifications-to-sharepoint/

Y esto es todo, espero que os pueda ser de utilidad, a mi me ha venido muy bien en mi trabajo para mejorar la organización y estructuración de los proyectos de SharePoint.

Un saludo a todos

Consultas CAML para filtrar listas de SharePoint

Muy buenas a todos.

Hace bastante tiempo, cuando empecé con el blog, que coincidió además con mis inicios en SharePoint, escribí un artículo en el que hablaba sobre consultas con CAML. Con el tiempo, he visto que esta entrada es la que más visitas del blog recibe, y creo que en el fondo es muy escasa para conocer, siquiera por encima, lo que se puede hacer con CAML. Aprovechando también que ya conozco mucho más sobre esto, quiero escribir una entrada, con un contenido mucho más extenso sobre este tema.

Esta es la entrada del blog sobre CAML que escribí:

Consultas sobre CAML en Sharepoint 2010

Vamos a empezar por ver la estructura completa de una consulta en CAML y que partes la componen

<View>
 <Query>
      <OrderBy>
          ...
      </OrderBy>
      <Where>
         ...
      </Where>
 </Query>
 <ViewFields>
      <FieldRef Name='Title'/>
      <FieldRef Name='ID'/>
 </ViewFields>
 <RowLimit>10</RowLimit>
</View>

En una consulta CAML, tenemos las siguientes secciones:

  • Query: Que contiene los apartados OrderBy y Where de la consulta.
  • ViewFields: Es similar a la parte de Select de una consulta SQL. Nos permite indicar que campos queremos devolver en la consulta que vamos a realizar.
  • RowLimit: Indica el máximo número de columnas que puede devolver la consulta

¿Como podemos usar la clausula Where?

Voy a hacer un resumen ahora de algunas de las situaciones más comunes que se pueden dar cuando hacemos consultas CAML y queremos filtrar los elementos de una lista determinada.

Filtrando por un campo de la lista
<Where>
    <Eq>
        <FieldRef Name='Title' />
        <Value Type='Text'>ejemplo</Value>
    </Eq>
</Where>
<Where>
    <BeginsWith >
        <FieldRef Name='Title' />
        <Value Type='Text'>ejemplo</Value>
    </BeginsWith>
</Where>
<Where>
    <Contains>
        <FieldRef Name='Title' />
        <Value Type='Text'>ejemplo</Value>
    </Contains>
</Where>
Filtrando por campos de tipo Búsqueda
<Where>
    <Eq>
        <FieldRef Name='LookupField1' LookupId='TRUE'/>
        <Value Type='Lookup'>3</Value>
    </Eq>
</Where>
Filtrar un campo de tipo User
Filtrar usando la ID de un usuario cualquiera:

<Where>
  <Eq>
    <FieldRef Name="User1" LookupId="True" />
    <Value Type="User">123</Value>
  </Eq>
</Where>

Filtrar por el usuario actual:

<Where>
  <Eq>
    <FieldRef Name="User1" />
    <Value Type="Integer">
      <UserID />
    </Value>
  </Eq>
</Where>
Concatenando varios filtros
<Where>
    <And>
        <Eq>
            <FieldRef Name='LookupField1' LookupId='TRUE'/>
            <Value Type='Lookup'>3</Value>
        </Eq>
        <Eq>
            <FieldRef Name='TextField1'/>
            <Value Type='Text'>ejemplo</Value>
        </Eq>
    </And>
</Where>
<Where>
    <Or>
    <Eq>
        <FieldRef Name="User1" />
        <Value Type="Integer">
            <UserID />
        </Value>    
    </Eq>
    <And>
        <Eq>
            <FieldRef Name='LookupField1' LookupId='TRUE'/>
            <Value Type='Lookup'>3</Value>
        </Eq>
        <Eq>
            <FieldRef Name='TextField1'/>
            <Value Type='Text'>ejemplo</Value>
        </Eq>
    </And>
    </Or>
</Where>

Usando la clausula OrderBy

Esta clausula va dentro de Query al igual que Where y su uso es muy sencillo.

Ordenando de forma ascendente por un campo concreto
<OrderBy>
    <FieldRef Name='ID' />
</OrderBy>
Ordenando de forma descendente por un campo concreto
<OrderBy>
    <FieldRef Name='ID' Ascending='FALSE' />
</OrderBy>
Ordenando por varios campos una consulta
<OrderBy>
    <FieldRef Name='Field1' Ascending='False' />
    <FieldRef Name='Field2' />
</OrderBy>

Usando CAML dentro del modelo de objetos

El modelo de objetos nos proporciona una clase para hacer consultas CAML en nuestro código. Esta clase es la clase SPQuery. Vamos a ver como deberíamos usar en nuestro código esta clase

SPQuery consulta = new SPQuery();
consulta.Query="<Where><Eq><FieldRef Name="Field1" /><Value Type="Text">ejemplo</Value></Eq></Where>"

SPListItemCollection resultadoConsulta = lista.GetItems(consulta);

De esta forma podremos hacer un filtrado de la lista en cuestión que habremos cargado en la variable lista definida previamente. Algunas consideraciones sobre esta clase.

  • Si queremos añadir la clausula OrderBy, podemos hacerlo a través de la propiedad Query de la clase, junto con el Where
  • No incluir las etiquetas Query dentro de la propiedad Query de la clase, esto provocará que el resultado no sea el esperado
  • Si queremos limitar el número de resultados que nos devuelva la consulta, podemos hacerlo con la propiedad RowLimit de la clase. Además es una buena práctica limitar el número de resultados de la consulta, para tenerlo controlado en todo momento. Si no lo indicamos, por defecto (podéis comprobarlo con el depurador), el valor que se establece es muy grande y esto puede provocar problemas de rendimiento.
  • Podéis establecer una cadena con la estructura completa de una consulta CAML a través del campo ViewXml

Y esto es todo amigos, espero que os sea útil y sirva también para completar el artículo inicial sobre esta temática que escribí hace un tiempo.

Un saludo y buen fin de semana a todos