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

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.

Azure Logic Apps III: Creando conectores personalizados. Las API Apps

Hola a todos de nuevo,

En anteriores entradas, inicié una serie sobre las Logic Apps de Azure y lo que se podía hacer con ellas. Vimos alguno de los conectores que había disponibles por defecto y como usarlos, como configurarlos y las opciones para trabajar con arrays de datos y condiciones.

Azure Logic Apps I: Primeros Pasos

Azure Logic Apps II: ¿Qué más puedo hacer?

En la entrada de hoy, quiero seguir avanzando en conocer las opciones que nos ofrecen las Logic Apps como herramienta para crear nuestras lógicas de negocio y que nos permitan, de una forma sencilla, implementar las mismas conectando todos los servicios que utilicemos. Hoy os quiero mostrar, como podemos crear nuestros propios conectores, para ampliar la funcionalidad y posibilidades de las Logic Apps.

Para ello, vamos a introducir un nuevo servicio de los disponibles en Azure, las API Apps.

¿Qué son las API Apps?

Según la propia documentación de Azure, las API Apps ofrecen una plataforma y un ecosistema enriquecido para la compilación, el hospedaje, el uso y la distribución de las API, tanto en la nube como de forma local. Las API Apps proporcionan capacidades para desarrollar, implementar, publicar, consumir y administrar las API web de RESTful.

Éstas API Apps forman parte del Servicio de aplicaciones de Azure, que también incluye aplicaciones web, móviles y lógicas.

appservicesuite

Os dejo un enlace a la documentación de Azure de donde he extraído esta información para que podáis ampliarla si queréis

https://azure.microsoft.com/es-es/documentation/articles/app-service-api-apps-why-best-platform/

Usando las API Apps para extender los conectores de una Logic App

Las API Apps que acabamos de contar se integran de forma nativa con las Logic App, ya que que podremos usarlas como conectores. Vamos a ver como crear una Api App que podamos usar en nuestra lógica de negocio.

Creando la API App en Visual Studio 2013

Lo primero que tenemos que hacer es crear el proyecto en Visual Studio 2013. Para ello creamos un proyecto de tipo ASP.NET Web Application.

newproject1

De las opciones que nos muestran disponibles, seleccionamos la opción Azure API app (Preview).

newProject2

Esto nos crea un proyecto de tipo Web API con la siguiente estructura.

estructura

Vamos a destacar aquí el fichero apiapp.json que contiene la información de definición de nuestra API App en Azure, que podremos modificar si lo deseamos. El contenido es el siguiente:

{
"$schema": "http://json-schema.org/schemas/2014-11-01/apiapp.json#&quot;,
"id": "ExampleAPIApp",
"namespace": "microsoft.com",
"gateway": "2015-01-14",
"version": "1.0.0",
"title": "ExampleAPIApp",
"summary": "",
"author": "",
"endpoints": {
"apiDefinition": "/swagger/docs/v1",
"status": null
}
}

Para el ejemplo he creado un modelo y un controlador muy sencillos. El modelo implementa una petición y el controlador, parte de una lista de peticiones y a través del método FilterRequest, y permite filtrar esa lista de peticiones en función de la cantidad, que se recibe como parámetro. El código que he usado es el siguiente.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace ExampleAPIApp.Models
{
    public class Request
    {
        public int id { get; set; }
        public string title { get; set; }
        public int quantity { get; set; }
    }
}
using ExampleAPIApp.Models;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Web.Http;

namespace ExampleAPIApp.Controllers
{
    public class RequestController : ApiController
    {
        private readonly Request[] _requests = {
                    new Request { id = 0, quantity = 6, title = "Example1" },
                    new Request { id = 1, quantity = 4, title = "Example2"},
                    new Request { id = 2, quantity = 7, title = "Example3"}
                };

        [HttpGet]
        public IEnumerable<Request> FilterRequest(int quantity)
        {
            List<Request> response = _requests.Where<Request>(r => r.quantity > quantity).ToList<Request>();

            return response;
        }
    }
}

Antes de publicar la API App que hemos creado podemos probarla de una forma muy sencilla. La integración automática de las API Apps de Azure con Swagger, un marco para la documentación interactiva y la detección de una API de RESTful que se usa de forma predeterminada en las aplicaciones de API, nos permite hacerlo a través de una interfaz gráfica. Para ello, previamente, debemos acceder al fichero de configuración de Swagger en la carpeta App_Start de nuestro proyecto y descomentar las siguiente líneas de código.

})
    .EnableSwaggerUi(c =>
{

Una vez hecho esto, si depuramos nuestra aplicación, podremos acceder a la siguiente URL que nos permite probar nuestra API App.

http://localhost:%5Bpuerto%5D/swagger

swagger

Os dejo también un enlace a la página de Swagger donde podréis encontrar más información de esta herramienta.

http://swagger.io/

Una vez comprobado el correcto funcionamiento de la API que hemos creado podemos proceder a su publicación.

Publicando la API App en Azure

Para publicar nuestra API App, hacemos click derecho sobre la solución y pulsamos en Publish. Esto nos muestra una ventana como la que se ve a continuación y que nos pide seleccionar el tipo de publicación que queremos hacer.

publish1

A continuación, tendremos que indicar la cuenta de Azure donde queremos publicar la API App. Una vez logueados, indicaremos que queremos crear una nueva API APP.

publish2

El siguiente paso, es indicar todos los parámetros para crear una API App: Plan de servicio, grupo de recursos, nivel de acceso y la región de publicación.

publish3

publish4

Tras esto, hacemos click en OK, lo que provisionará la API App. Una vez que se ha provisionado, tendremos que volver a ejecutar la opción de publicación para desplegar el código en la nueva API App que se acaba de crear.

publish5

Una vez terminado el proceso y publicada correctamente la API App, nos aparece una pantalla como la siguiente.

publish6

Ya tenemos nuestra API App creada y desplegada en Azure, a continuación vamos a crear una Logic App que la use como conector.

Creando la Logic App

La creación de la Logic App ya la hemos tratado en entradas anteriores. Por tanto seguiremos el proceso habitual para provisionar y crear la Logic App, con la única premisa que tenemos que crearla dentro del mismo plan de servicios y grupo de recursos que la API App que hemos creado anteriormente.

Captura de pantalla 2015-10-24 a las 20.10.11

Una vez que entremos al diseñador de Logic App, vemos que en el panel de conectores, aparece la API App que creamos en la sección anterior.

Captura de pantalla 2015-10-24 a las 20.11.32

Vamos a añadir dos pasos, el primero nuestra API App y luego un conector a SharePoint OnLine. Cuando añadimos el conector correspondiente a nuestra Api App, vemos que nos pide como parámetro de entrada la cantidad. Luego añadiremos el conector de SharePoint OnLine con el objetivo de añadir un elemento en una lista por cada Request devuelta por la API App.

Lo configuramos de la siguiente manera:

Captura de pantalla 2015-10-24 a las 20.17.14

Lo guardamos y ya tenemos la Logic App lista para ser ejecutada. En este caso, además hemos marcado la opción de poder ejecutar la Logic App manualmente para poder hacer las pruebas.

Probando nuestro conector

En la pantalla principal de la Logic App hacemos click en Run. Esto lanza nuestro proceso de negocio. Cuando termina, podemos acceder a los resultados y ver algo como esto, que nos indica que todo se ha hecho correctamente.

Captura de pantalla 2015-10-24 a las 20.18.41

Si accedemos a SharePoint OnLine, vemos que se han añadido dos elementos a la lista.

executed

Y esto es todo por hoy, hemos creado un conector personalizado, que aunque muy sencillo, nos permite ver la forma de extender la funcionalidad de las Logic Apps por medio de nuevos conectores. Con esto, junto a las anteriores entradas, os podréis hacer una idea de lo que podemos hacer con estos servicios de Azure.

Probablemente, las Logic Apps aún no estén listas para ser usadas en procesos de negocio críticos, están aún en modo preview y siguen cambiando y todavía tienen bugs que corregir. No obstante, como ya os comenté en la primera entrada sobre Logic Apps, es una herramienta a tener en cuenta y puede resultar interesante, por el hecho de tener a nuestra disposición una capa de nivel superior que nos permita implementar la lógica de negocio que conecte distintos servicios en uso. Veremos a ver la evolución que lleva este interesante servicio de Azure.

Espero que os haya resultado interesante.

Hasta la próxima

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.

Primeros Pasos con el Service Bus de Azure: Las colas

Muy buenas a todos,

Después de unas semanas sin poder publicar porque he estado ocupado preparando un examen de inglés, vuelvo con una entrada de la que llevaba tiempo detrás. Dentro de mis objetivos del año, además de profundizar en cómo usar las APIs de SharePoint y de Office 365 (de lo que ya he publicado bastantes entradas en el blog), está el empezar a aprender de Azure. Recientemente os expliqué cómo hacer tareas programadas con Azure por medio de los webjobs, aplicados en el caso del post a SharePoint.

Timer Jobs para SharePoint OnLine

Hoy os quiero hablar de otro de los servicios que nos ofrece Azure y que cuando he indagado sobre él, me ha resultado muy interesante, el Service Bus. Este servicio nos proporciona métodos para comunicar nuestras aplicaciones. Estos métodos pueden ser muy diversos, desde una simple cola FIFO, sistema de colas basado en subscripciones o situaciones en las que no se necesitan colas, solo un mecanismo para comunicarse. Todos estos escenarios los proporcionar el Service Bus de Azure. Os dejo algunos enlaces para que indaguéis y leáis más sobre este servicio que tenemos disponible.

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

https://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-queues/

En este post, vamos a centrarnos fundamentalmente en las colas FIFO, en las que un productor va a ir colocando mensajes y un consumidor los irá leyendo por estricto orden de llegada.

Untitled

Vamos a ver un ejemplo en el que podremos comprobar como funcionan las colas en Azure Service Bus. El ejemplo constará de dos aplicaciones de consola, una que actuará como productor y otra como consumidor. Vamos a ver también los pasos para poner en marcha este servicio en Azure y cómo usarlo desde nuestras aplicaciones.

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 nuestro caso, como solo vamos a usar en este ejemplo una cola FIFO, seleccionamos la opción mensajería de tipo 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

A continuación os dejo el código del productor que he creado a modo de ejemplo:

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

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

                        QueueHelper.CreateQueue("TestQueue");
                        break;
                    case 2:

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

                        i += 1;

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

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

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

            return value;
        }
    }

El código del productor implementa un sencillo menú por consola con dos opciones: por un lado crear la cola que vamos a usar (para la primera vez que usamos la aplicación), y por otro lado envía un mensaje a la misma.

Los mensajes se envían usando la clase BrokeredMessage. Esta clase en el constructor, nos permite establecer el cuerpo del mensaje y usando las propiedades de la misma, pasar otros parámetros de interés del mensaje.

Cómo podéis ver, el productor hace uso de un helper que implementa la funcionalidad de interacción con el service bus. Os dejo también a continuación las funciones que se usan.

public static void CreateQueue(string queueName)
        {
            // Configure queue settings
            QueueDescription qd = new QueueDescription(queueName);
            qd.MaxSizeInMegabytes = 5120;
            qd.DefaultMessageTimeToLive = new TimeSpan(0, 1, 0);

            // Create a new queue with custom settings
            string connectionString =
                CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");

            var namespaceManager =
                NamespaceManager.CreateFromConnectionString(connectionString);

            if (!namespaceManager.QueueExists(queueName))
            {
                namespaceManager.CreateQueue(qd);
            }
        }

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

            QueueClient Client =
                QueueClient.CreateFromConnectionString(connectionString, queueName);

            Client.Send(message);
        }

La función que crea la cola es muy sencilla. En primer lugar establece las propiedades de la cola que vamos a crear, en este caso, tamaño de la misma y el tiempo de vida del mensaje. A continuación obtiene del app.config la cadena de conexión y se conecta con el Service Bus. Por último, comprueba si existe la cola y en caso negativo, la crea.

La función que envía un mensaje es aún más sencilla. Simplemente establece la conexión con la cola del Service Bus donde queramos publicar el mensaje y lo envía.

El consumidor de mensajes

El código del consumidor es el que véis a continuación:

class Program
    {
        static void Main(string[] args)
        {
            while(true)
            {
                BrokeredMessage message = QueueHelper.ReceiveMessage("TestQueue");

                Console.WriteLine("Body: " + message.GetBody<string>());
                Console.WriteLine("MessageID: " + message.MessageId);
                Console.WriteLine("Test Property: " +
                message.Properties["Counter"]);

            }
        }
    }

Este código es muy sencillo. Está continuamente a la escucha de que en la cola haya algún mensaje y en caso de que sea así lo recibe y lo imprime por pantalla.

Al igual que el productor, usa un helper para la conexión con el Service Bus. El código de la función ReceiveMessage es el siguiente:

public static BrokeredMessage ReceiveMessage(string queueName)
        {
            string connectionString =
  CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");
            QueueClient Client =
              QueueClient.CreateFromConnectionString(connectionString, queueName);

            BrokeredMessage message = null;

            try
            {
                message = Client.Receive();

                message.Complete();
            }
            catch(Exception ex)
            {
                message.Abandon();
            }

            return message;
        }

La función que recibe un mensaje de la cola funciona de la siguiente manera. En primer lugar se conecta con la cola correspondiente del Service Bus. Tras esto espera a que haya un mensaje en la cola para leer, si se recibe correctamente usa la función Complete() para eliminar el mensaje recibido de la cola. En caso de que haya algún error, usa la función Abandon() para liberarlo de nuevo en la cola.

Cómo funciona el ejemplo

Vamos a ver en una captura como funciona el ejemplo que hemos desarrollado:

Untitled2

Cada vez que se ejecuta la opción enviar mensaje, el productor envía un mensaje y el receptor lo recibe y muestra en pantalla, ya que como vimos en el código, éste está siempre esperando nuevos mensajes para procesarlos.

Y hasta aquí todo lo que os quería enseñar. ¿Cuáles son los siguientes pasos?, pues en próximos post os contaré como funcionan las subscripciones o topics y más adelante mezclaré todo esto con SharePoint OnLine, para como siempre, avanzar en las opciones que tenemos disponibles en Azure y ver cómo las podemos usar con SharePoint, se pueden plantear, como veremos, ejemplos muy interesantes.

Un saludo a todos y hasta la próxima

La nueva API de Office 365 Unificada

Buenas tardes a todos,

Esta semana desde Microsoft se lanzó la noticia de la aparición de una nueva API de Office 365 unificada, que busca facilitar y estandarizar todas las operaciones que se pueden realizar contra los servicios de Office 365 a través de su API, además de añadir nuevas opciones y servicios a la misma. Ayer tuve la oportunidad de echar un vistazo a esta API unificada y me pareció que mejora mucho la versión anterior y particularmente me gusta más esta línea que la que llevaba hasta ahora.

Hoy os voy a contar en qué consisten todas estas mejoras y enseñaros un ejemplo de cómo trabajar con ella que podréis comparar con un ejemplo que publiqué hace un tiempo sobre el uso de la API de Office 365 que hasta ahora teníamos vigente. Esta versión de API unificada está aún en Preview, por lo que aún pueden haber mejoras o modificaciones, no obstante lo que veremos hoy es la filosofía de la misma.

Antes de entrar de lleno os voy a dejar una recopilación de enlaces que creo que son fundamentales para entender la nueva API Unificada.

http://dev.office.com/unifiedAPIs

https://msdn.microsoft.com/office/office365/HowTo/office-365-unified-api-overview#msg_how_learn_unified_api

https://msdn.microsoft.com/en-us/office/office365/howto/get-started-with-office-365-unified-api

https://msdn.microsoft.com/en-us/office/office365/howto/office-365-unified-api-reference

http://www.vrdmn.com/2015/05/using-office-365-unified-api-in-aspnet.html

¿En qué consiste esta API de Office 365 Unificada?

La nueva API de Office 365 Unificada pretende seguir ofreciendo a los desarrolladores la oportunidad de utilizar los servicios de la suite de productividad de Office 365, pero de forma unificada y a través de una API REST, que nos permite hacer todas las operaciones de una forma mucho más sencilla y alineada con el “standard” de las API de servicios web hoy en día.

Además añaden acceso a nuevos servicios dentro de Office 365, quedando ahora el mapa de entidades de la siguiente forma:

O365_unified_API_entities

Con la API tradicional para usar algunas de las entidades disponibles teníamos siempre que realizar las siguientes acciones:

  • Usar el servicio discovery para encontrar los endpoints
  • Determinar la URL de los servicios a los que la app se quería conectar
  • Obtener y manejar el token de cada servicio y hacer la petición a cada uno de ellos directamente

Desde ahora, por medio de esta nueva API unificada, evitaremos estas operaciones para sustituirlas por una simple API REST. Además no es necesario descubrir y navegar a cada uno de los diferentes endpoints para cada servicio ya que todos comparten uno mismo, con lo que comparten también el sistema de autenticación y autorización. Estos nos permite además fácilmente consumir desde cualquier herramienta o lenguaje de programación esta API.

¿Cómo podemos usar la API?

Vamos a ver ahora algunas de las URLs que tenemos disponible en la API REST unificada para acceder a las distintas entidades de Office 365.

La Url de referencia al servicio la tenemos en la siguiente dirección https://graph.microsoft.com/{version}. A partir de aquí, voy a dejar distintos ejemplo de cómo podemos usar esta referencia para acceder a las distintas entidades.

Acceder a One Drive
https://graph.microsoft.com/{version}/me/files
Accediendo al servicio de Exchange OnLine
https://graph.microsoft.com/{version}/me/Messages
Accediendo a los usuarios de mi tenant
https://graph.microsoft.com/{version}/{myOrganization}/users
Accediendo a los grupos de Office 365
https://graph.microsoft.com/{version}/{myOrganization}/groups
Aplicaciones registradas en Azure AD
https://graph.microsoft.com/{version}/{myOrganization}/applications

Obviamente estas son solo algunas de las URLs principales de los servicios. En el enlace a la referencia de la API podemos ver todas las opciones y todas las oportunidades que tenemos disponibles y os animo a que naveguéis por ahí para ver todo lo que se puede hacer, que como veréis es mucho.

Ejemplo de uso de la nueva API de Office 365 Unificada

Para terminar con el artículo, vamos a ver un ejemplo de código de cómo podemos usar en una aplicación MVC esta nueva API REST.

Para poder usar la API REST unificada de Office 365, tenemos en primer lugar que registrar nuestra App en Azure Active Directory tal y como se comentaba en la entrada que os enlazo a continuación:

Registrando una aplicación en Azure Active Directory

Lo único que tenemos que hacer diferente a cuando íbamos a usar la versión anterior es a la hora de establecer los permisos para la app que estamos registrando. En esta ocasión deberemos añadir los permisos para la nueva API unificada, como se ve en la imagen siguiente, tenemos esta opción disponible.

unifiedAPI

Una vez que ya hemos registrado adecuadamente nuestra app, podemos pasar al código de la aplicación. En la demo que vamos a ver, voy a leer los archivos y directorios de mi One Drive, tal y como hice en el ejemplo con la API anterior. He creado una aplicación MVC y todo el código por simplicidad en el ejemplo, lo he puesto en la misma acción del controlador, aunque si accedéis al último enlace de los que indiqué arriba, podréis ver como se podría organizar el código a través de varias acciones en una aplicación MVC. Vamos a ver el código y luego lo explicaré destacando los puntos más importantes del mismo:

public async Task<ActionResult> Files(string  code)
{
       string authCode = Request.Params["code"];

       // The url in our app that Azure should redirect to after successful signin
       string redirectUri = Url.Action("Files", "Home", null, Request.Url.Scheme);

       var authContext = new AuthenticationContext("https://login.microsoftonline.com/common");

       if(authCode == null)
       {

           // Generate the parameterized URL for Azure signin
           Uri authUri = authContext.GetAuthorizationRequestURL("https://graph.microsoft.com/", ConfigurationManager.AppSettings["ida:ClientID"],
               new Uri(redirectUri), UserIdentifier.AnyUser, null);

           // Redirect the browser to the Azure signin page
           return Redirect(authUri.ToString());
       }

       ClientCredential creds = new ClientCredential(
           ConfigurationManager.AppSettings["ida:ClientID"],
           ConfigurationManager.AppSettings["ida:Password"]);

       // Get the token
       var authResult = await authContext.AcquireTokenByAuthorizationCodeAsync(
           authCode, new Uri(redirectUri), creds, "https://graph.microsoft.com/");

       // Save the token
       string accesstoken = authResult.AccessToken;

       // Make request
       using (var client = new HttpClient())
       {
           string endpointUri, resourceId;

           using (var request = new HttpRequestMessage(HttpMethod.Get,
             "https://graph.microsoft.com/beta/me/files"))
           {
               request.Headers.Add("Authorization", "Bearer " + accesstoken);

               using (var response = await client.SendAsync(request))
               {
                   List<OneDriveFile> modelList = new List<OneDriveFile>();

                   var content = await response.Content.ReadAsStringAsync();
                   foreach (var item in JObject.Parse(content)["value"])
                   {
                       OneDriveFile newFile = new OneDriveFile
                       {
                          Name = item["name"].ToString(),
                          Size = double.Parse(item["size"].ToString())
                       };

                       modelList.Add(newFile);
                   }

                   ViewBag.files = modelList;

                }
            }
       }

       return View();
}

Vamos a destacar tres aspectos fundamentales de este código:

  • Lo primero que haremos en nuestro código es comprobar si nos hemos autenticado contra Azure Directory, tal y como hacíamos con la API tradicional, y en el caso de que no lo esté nos redirigirá a la página correspondiente para autenticarnos, para todo el proceso de autenticación y autorización se va a usar como hacíamos anteriormente la librería ADAL que tenemos en Nuget. (Líneas 10 a 19)
  • El siguiente paso, es capturar el token de acceso para obtener autorización al hacer las peticiones REST. (Líneas 26 a 30)
  • En el último paso usaremos un cliente Http que nos proporciona C# para hacer llamadas a la API y procesar las respuestas. (Líneas 33 a 62)

Las diferencias con respecto al uso de la versión anterior de la API para Office 365 basada en el servicio discovery la podemos ver con la entrada que publiqué sobre este tema. Nos obstante son obvias, por la facilidad con la que ahora podemos acceder a la API de Office, sin tener que hacer todos los pasos para simplemente acceder al servicio que eran necesarios. Esta es la entrada que os comentaba.

Usando la API de Office 365

Y nada más por hoy, como siempre espero que os resulte interesante, a mi esta nueva versión unificada me ha gustado mucho. Os recomiendo echar un vistazo por todos los enlaces que os he comentado, y ver las oportunidades que nos ofrece esta API, como dije al principio me parecen muy interesantes.

Un saludo a todos.

Métodos de extensión en C#. Usándolos en desarrollo para SharePoint

Muy buenas a todos,

Hoy lo que os traigo es más una recopilación de información que una entrada de mi cosecha propiamente, aunque creo que es muy interesante. No pasan días sin que aprendas cosas nuevas. Todo viene de una entrada en el blog de desarrollo de Encamina, el cual os recomiendo que sigáis porque se suelen hacer entradas muy interesantes. En esta semana se ha estado haciendo un recorrido por buenas prácticas a la hora de desarrollar sobre SharePoint y entonces es cuando me topé con los “Métodos de extensión en C#”. Os dejo la entrada en cuestión.

http://blogs.encamina.com/desarrollandosobresharepoint/2015/05/05/como-aprovechar-la-potencia-de-c-en-nuestros-desarrollos/

Me ha llamado la atención el uso de los métodos de extensión de C#. Yo venía desde hace un tiempo usando algunas clases para facilitar determinadas acciones cuando desarrollo sobre SharePoint. Pero me ha resultado muy interesante ver que podemos, por medio de los métodos de extensión, asociarlos al objeto que afectan, de manera que el intellisense de VS lo detecta y además los puedes llamar como si fueran métodos del objeto propiamente dicho, sin tener que crear una clase derivada, ni heredar ni hacer nada con el objeto original. Os pongo un ejemplo de código con algo sencillo:

public static class Helper
{
   public static string MetodoExtensionEjemplo(this string s, string ejemplo)
   {
      //To do something
   }
}

Este método lo podríamos usar ahora de la siguiente forma

string s = "Hello Extension Methods";
s = s.MetodoExtensionEjemplo("hola");

La verdad es que resulta muy cómodo usarlo de esta forma. Como véis la sintaxis para definir este tipo de métodos es muy sencilla y lo vemos en el primer código.

  • La clase a la que pertenezca el método tiene que ser estática, así como el método propiamente dicho
  • El primer parámetro del método es del tipo al que queremos asociarle el método y lleva delante la palabra reservada this.

En mi caso usar esta opción que nos brinda C#, me da como resultado un código más limpio e intuitivo, así que por mi parte, merece la pena tenerlo en cuenta.

Y bueno, como me gusta compartir con la comunidad todo lo que puedo o creo que puede ser interesante, he subido a GitHub las dos clases que estoy usando como Helpers y en las que estoy usando los métodos de extensión. Por si os interesa, veréis que he creado dos clases, una que tiene las acciones “atómicas” (la clase Helpers) y otra que tiene acciones necesarias pero que son un poco “más complejas” (la clase Utility).

https://github.com/jcroav/SPHelpers

Sentíos libres de cogerlas, modificarlas, mejorarlas, proponer cambios, todo lo que suponga mejorar bienvenido sea. Por otro lado, si conocéis otros trabajos similares que se puedan utilizar y estén en fases más avanzadas, estaré encantado de saberlo. Yo de momento he creado los métodos que necesito para mi último proyecto y a medida que vaya necesitando modificar los mismos para añadir funcionalidad o mejoras o añadir nuevos los iré publicando en el repositorio.

Os dejo también el enlace de la MSDN sobre el tema de los métodos de extensión:

https://msdn.microsoft.com/es-es/library/bb383977.aspx