Bueno, en la primera parte hemos visto en que consiste el motor de flujos de trabajo, poco a poco nos iremos introduciendo en los detalles, también hemos visto que un flujo de trabajo esta compuesto de actividades. Cuando ejecutamos un flujo de trabajo dentro del motor, la representación del mismo (SequentialWorkflowActivity ó  StateMachineWorkflowActivity) en ejecución es un WorkflowInstance.

Esta instancia, se crea desde el motor, Runtime.CreateWorkflow(typeof()) y como vimos existen distintas formas de cargar los flujos de trabajo dentro del mismo, (más adelante veremos como hacerlo de otras maneras).

Tenía que impartir un curso de Workflow Foundation que finalmente no voy a dar, ya que estoy muy liado con otros temas. Ayer por la noche pensé que era una pena desaprovechar todo este trabajo, más aún porque estaba deseando montar un curso distinto, me explico:

El curso iba a consistir de 10 clases de una hora y media de duración (usease 15 horas) que no es mucho. De modo que tenía pensado lo siguiente. Una introducción de 45 minutos explicando cosas y mostrando un ejemplo práctico, ejemplo que previamente habría diseñado para la ocasión. Los 45 minutos restantes iban a ser para (30 min) que la gente trabajara con el código del ejemplo y lo enredara (mientras yo les explicaba el código). Por último, entre todos (siguiendo unas directrices 15min) iríamos añadiéndole funcionalidad al código, para ir viendo cada cosa en profundidad en la siguiente clase.

Ayer tuvimos en la Universidad Pública de Navarra,  un evento de 5 horas sobre  AJAX, XNA, WF, WCF y WPF

A pesar de que el tiempo no nos acompaño,  el guru bilbaíno, le hecho un par de pelotix y se vino a Pamplona.  La asistencia no le hecho tantas pelotix así que de los 150 nos quedamos en 90, no está nada mal.

Lo pasamos de miedo y nos reímos un montón. Hubo buen feeling con la gente. Lo mejor es que grabamos las 5 horas en DVD así que en breve puede que las pongamos on-line.

Mark Schmidt’s a puesto una última versión del WFPad, para Windows Workflow Foundation. Lo acabo de bajar para jugar un poquito, para los que aún no lo sepan, este ejemplo es el mejor ejemplo que hay sobre como integrar el Diseñador de flujos de trabajo dentro de nuestras aplicaciones.

Justito lo he compilado y añadido mi propia biblioteca de actividades (sin ir más lejos la que he creado hoy en el evento de la UPNA, mañana pondré fotos). Podéis ver FritoDeGamba y Visor de eventos.

Una de las coas que más me cuesta explicar cuando hablo de Windows Workflow Foundation, es el dichoso AutoResetEvent.

El AutoResetEvent, es una variable que nos ayudará en la sincronización de los distintos hilos de proceso (threads), no es más que un simple mutex (exclusión mutua), ó semáforo, que nos va a permitir es proteger ciertos datos compartidos cuando se llevan a cabo escrituras, previniendo las condiciones de carrera.

Para entender bien este concepto, revisemos como son programadas las distintas instancias de los flujos de trabajo en el runtime. El runtime de Workflow Foundation, tiene un servicio de temporización (scheduler) que nos va a permitir ejecutar las distintas instancias que se lleven a cabo de manera Asíncrona (por defecto) ó Síncrona (utilizando el servicio manual).

En la corta vida de NavarraDotNet vamos a por nuestro segundo Evento, donde veremos lo más representativo del Framework 3.0, aquí os dejo el cartel (a mi juicio impresionante) que Sergio Jimenez a preparado así como el link de registro y la agenda del evento.

09:30 – 10:30 ASP.NET AJAX Web Development Repasaremos la evolución en la interfaz web asíncrona desde el MSXML XMLHttpRequest hasta el momento actual y los problemas que se planteaban en el desarrollo. Veremos los nuevos controles existentes en ASP.NET y como facilitan al desarrollador mejorar la experiencia de navegación del usuario.

Well, today the first day of 2007,I Want to thank all the people who read this blog for this stats. Also today I received my MVP award renewal.
Gracias a todos los que me leéis, seguiré dando la lata

También mis felicitaciones para Miguel Jimenez, Rodrigo Corral, Marco Amoedo, Haaron Gonzalez

Este será casi con seguridad mi último post del 2006, pero eso no lo puedo asegurar ya que cuando me pica la curiosidad, siento esa irresistible necesidad de saciarla. Y eso es lo que me ha ocurrido esta mañana. Como había comentado antes no había usado punteros en c# y este hecho me ha picado, de modo que he tratado ver como son manejados por el CLR.

Bien, todo era normal hasta que he visto este código IL en donde no entendía el misterioso conv.u, el código que estaba usando es el siguiente:

Para añadir una nueva actividad a nuestro SPD, lo primero que debemos hacer es comenzar un proyecto de Workflow, en concreto un Workflow Activity Library (Biblioteca de actividades para el flujo de trabajo).

A partir de ese punto crearíamos nuestra actividad, para este ejemplo voy a crear una actividad que consiste en enviar un texto al visor de eventos.

public partial class LogEventViewer : Activity
{
   
    public static DependencyProperty TextLogProperty =
        DependencyProperty.Register(“TextLog”, typeof(string), typeof(LogEventViewer));
 
    public LogEventViewer()
    {
        InitializeComponent();
    }
 
    /// <summary>
    /// Valor que figurará en el visor de eventos
    /// </summary>
    /// <value>Texto</value>
    [Description("Texto que saldrá en el visor de eventos")]
    [Category("User")]
    [Browsable(true)]
    [DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
    public string TextLog
    {
        get { return (string) GetValue(TextLogProperty); }
        set { SetValue(TextLogProperty, value); }
    }
 
    /// <summary>
    /// Ejecución de la actividad
    /// </summary>
    /// <param name=”provider”>Contexto de ejecución de la actividad</param>
    /// <returns></returns>
    protected override ActivityExecutionStatus Execute(ActivityExecutionContext provider)
    {
        EventLog eventLog = new EventLog(“Workflow”);
 
        eventLog.Source = “SharePoint Workflow”;
 
        try
        {
            eventLog.WriteEntry(TextLog, EventLogEntryType.Information);
        }
        finally
        {
            eventLog.Dispose();
        }
 
        return ActivityExecutionStatus.Closed;
    }
}

Lo primero que hacemos es declarar una propiedad dependiente del flujo de trabajo llamada TextLogProperty, a través de la cual pasaremos el texto que deseamos visualizar en el visor de eventos.

Sin duda una de las mejores cosas de MOSS 2007 es el nuevo SPD, y dentro de este, el diseñador de flujos de trabajo, que nos permite de forma ágil y sencilla diseñar nuestros flujos de trabajo.

Aunque como he comentado en otras ocasiones, si deseamos realizar flujos de trabajo más complejos, o máquinas de estados debemos usar Visual Studio.

SPD, solo nos permite realizar workflows secuenciales con las actividades que vienen predeterminadas. Sin embargo existe la posibilidad de ampliar las actividades básicas que nos encontramos dentro de SPD, con lo cual podemos extender la funcionalidad de nuestros workflows sin llegar a realizarlos completamente en Visual Studio.