Los Webjobs de Azure, si recordáis lo que ya comentamos, son procesos de background y aunque hablamos que valía cualquier tipo de «cosa» ejecutable, también os paunté hacia el SDK y quedamos en que ya veríamos los Bindings que nos proporciona el JobHost.

No vamos a repasar todas las opciones que nos proporciona, podéis verlas en una chuleta de referencia de Microsoft, pero veremos un ejemplo para que todo se entienda bien.

El caso es que JobHost entre otras cosas, lo que hace es inyectar dependencias a los métodos que queremos ejecutar, de tal modo que simplemente declarando parámetros de un tipo concreto, el JobHost se encargará de que se invoque el método con los valores adecuados. También se encarga de disparar a los métodos de los Webjobs continuos cuando hay nueva información, pero vayamos por pasos.

Un caso muy básico es por ejemplo el del TextWriter, es un binding que nos da acceso al log de los Webjobs, son los mensajes que podemos ver en el portal de Kudu en https://tuWebApp.scm.azurewebsites.net/azurejobs/. Por tanto si en el método que queramos correr ponemos un parámetro de tipo TextWriter, el JobHost se encargará de que tenga el objeto adecuado para que las cadenas que se le pasen al método WriteLine queden registradas en el log y por tanto se puedan leer en el portal.

 Lo de los disparadores, a lo mejor es un poco más complejo de entender, pero vamos a intentar plantearlo de un modo fácil. Hay un disparador que se llama QueueTrigger al que se le pasa como parámetro el nombre de la cola que queremos «escuchar». Hay que ponerlo como atributo de uno de los Bindings que soporta, por ejemplo CloudQueueMessage, y JobHost se encargará de llamar una vez a nuestro método por cada mensaje que aparezca en la cola, e introducirá dicho mensaje en el parámetro correspondiente. Veamoslo todo con un ejemplo:

// Main class of the Webjob
class Program
{
	static void Main()
	{
		var host = new JobHost();
		host.RunAndBlock();
	}
}

//Entity stored in the queue 'queuename'
public class QueuedEntity{
	public string Field1;
	public int Field2;
}

//Functions executed by the continuous Webjob
public class Functions
{
	public static void ProcessQueueMessage(
		[QueueTrigger("queuename")] QueuedEntity message,
		CloudStorageAccount account,
		TextWriter log)
	{
		TextWriterTraceListener logListener = new TextWriterTraceListener(log);
		Trace.Listeners.Add(logListener);
		Trace.TraceInformation(
			"ProcessQueueMessage-> account:{0}, field 1:{1}, field 2:{2}",
			account.Credentials.AccountName,
			message.Field1,
			message.Field2);

		//... process the message...

	}
}

Como os habréis dado cuenta, en el código de ejemplo no se escribe directamente en el logListener, si no que se añade a los listener de Diagnostics que se usa de manera habitual, de este modo se podrá usar sin necesidad de estar pasándolo a todas las clases y librerías.

A no ser que indiquemos en el settings.job que un Webjob continuo es singleton, el SDK se encargará de paralerizar las llamadas a nuestro método en función del trigger usado. Por ejemplo en nuestro caso, si metemos 100 objetos de tipo QueuedEntity en la cola ‘queuename‘, la teoría dice que el sistema lanzará 100 hilos llamando al método ProcessQueueMessage. La práctica es que en realidad por cada máquina levanta 16 hilos y a medida que van acabando va levantando otros, que es algo más lógico.

Con esto, sinceramente, no se si he conseguido aclarar como funciona. La verdad que es algo que parece muy complejo, pero que en realidad cuando te pones a usarlo ves que es de una simplicidad pasmosa, así que lo mejor que podéis hacer es poneros manos a la obra y soltar las preguntas aquí abajo.

Post By Javi López (27 Posts)

Arquitecto/desarrollador, creativo, buscador de nuevas soluciones y modelos de negocio, crítico constructivo y ex muchas cosas

Website: → JaviLopezG

Connect

SDK, Webjobs