Microsoft Azure Websites: Lanzar acciones a WebJobs mediante queues o blobs

Estos días estoy trabajando en un proyecto que necesita lanzar ciertas tareas, las cuales se pueden ejecutar perfectamente en segundo plano. Estoy utilizando Microsoft Azure Web sites por lo que puedo hacer uso de Web Jobs. Hace unos días comentaba cómo era posible crear una aplicación de consola y publicarla en Azure como Web Job. Sin embargo, en esta ocasión no quiero una tarea programada, sino que el proceso se lance a través una acción. Gracias a WebJobs SDK puedo crear un proceso en segundo plano que se mantenga a la escucha de ciertas acciones. El SDK todavía está en pre release.

Para poder probarlo, creamos un proyecto de tipo Microsoft Azure WebJob:

Microsoft Azure WebJob

Instalamos el SDK de WebJobs a través de Nuget:

PM> Install-Package Microsoft.Azure.Jobs -Pre

using Microsoft.Azure.WebJobs;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace WebJob
{
    // To learn more about Microsoft Azure WebJobs, please see http://go.microsoft.com/fwlink/?LinkID=401557
    class Program
    {
        static void Main()
        {
            var host = new JobHost();

            host.RunAndBlock();

        }

        public static void CheckingBlobs([BlobTrigger("input/{name}")] TextReader input, [Blob("output/{name}")] out string output)
        {
            output = input.ReadToEnd();
        }

        public static void TestingQueuesTriggers([QueueTrigger("queuejobs")]string message)
        {
            Console.WriteLine("TestingQueuesTriggers launched: {0}", message);
        }
    }
}

En el código anterior, lo primero que hacemos es crear un objeto de tipo JobHost que mantiene el proceso ejecutándose y a la espera de alguno de los triggers. Además, tenemos dos métodos que nos permiten capturar dos acciones: nuevos mensajes en una queue llamada queuejobs y la subida de nuevos blobs en un container llamado input. En el caso de los blobs, para que el evento sea lanzado, se comprueba que la fecha del archivo ubicado en input sea mayor que la fecha del posible archivo en el container output, si es que lo hubiera.

Antes de realizar la subida a Azure, podemos comprobar que el Job funciona correctamente, ejecutándolo en local:

WebJobs SDK local

Los WebJobs hacen uso de dos cadenas de conexión: AzureWebJobsDashboard y AzureWebJobsStorage. La primera de ellas se utiliza para almacenar las trazas relacionadas con el diagnóstico del job y la segunda será la cuenta de Azure Storage sobre la que el servicio estará a la escucha.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>
  <connectionStrings>
    <add name="AzureWebJobsDashboard" connectionString="DefaultEndpointsProtocol=https;AccountName=[YOUR_ACCOUNT_NAME];AccountKey=[YOUR_ACCOUNT_KEY]"/>
  <add name="AzureWebJobsStorage" connectionString="DefaultEndpointsProtocol=https;AccountName=[YOUR_ACCOUNT_NAME];AccountKey=[YOUR_ACCOUNT_KEY]"/>
  </connectionStrings>
</configuration>

También es posible especificar la cuenta de Storage en el WebJob, cuando creamos la instancia del JobHost:

            var storage = "DefaultEndpointsProtocol=https;AccountName=[YOUR_ACCOUNT_NAME];AccountKey=[YOUR_KEY]";
            var host = new JobHost(new JobHostConfiguration
            {
                StorageConnectionString = storage,
                DashboardConnectionString = storage
            });

            host.RunAndBlock();

Para añadir nuevos blobs y mensajes en la cola he utilizado Azure Storage Explorer.

Subiendo el WebJob a Microsoft Azure

A través de la acción Publish as WebJob estamos listos para subir el proyecto al web site:

Publis as Azure WebJob

En este caso es necesario que la configuración del WebJob sea Run Continuously:

Run Continuously

Seleccionamos el sitio web sobre el cual queremos desplegar el WebJob y publicamos el servicio. Si no se hubiera indicado ninguna cuenta de Microsoft Azure Storage, donde estará la queue asociada al trigger del código y el container donde almacenaremos los blobs, el servicio buscará por defecto las dos cadenas en las connection strings del web site:

WebJobs connection strings

Por otro lado, tenemos una página donde podemos ver el estado del WebJob una vez que está en Azure: https://[YOUR_SITE].scm.azurewebsites.net/azurejobs/#/jobs/continuous/WebJob. El enlace puede verse en la sección de WebJobs del sitio web:

WebJobs Logs

En esta página podemos ver todas las veces que se ha ejecutado un método y el output del WebJob:

WebJob output
El proceso de las queues es mucho más rápido que el de los blob. El servicio comprueba el container cada 10-20 minutos.

Espero que sea de utilidad.

¡Saludos!