Eventos del Runtime en Workflow Foundation

by Misael Monterroca 29. January 2008 22:25

 

En este articulo profundizaremos un poco más acerca del Runtime Engine, los diferentes eventos del Runtime, su sintaxis y su uso en Workflow Foundation.

Runtime Engine

La arquitectura de Windows Workflow Foundation consta de seis partes principales, el Runtime Engine es una de ellas. El Runtime Engine es una librería que ejecuta flujos de trabajo. El Runtime Engine también provee otros servicios, como mecanismos para comunicarse con software fuera del flujo de trabajo. Todos los flujos de trabajos dependen del Windows Workflow Foundation Runtime Engine. Este motor ejecuta cada flujo de trabajo y maneja su estado a lo largo de su tiempo de vida. El Windows Workflow Foundation Runtime es una librería; por lo tanto, debe ser ejecutado en algún proceso host. En vez de proveer un host requerido, Windows Workflow Foundation le permite al Runtime (y a cualquier flujo de trabajo que ejecute) ser alojado en cualquier proceso Windows, desde una simple aplicación de consola de Windows o una aplicación de formulario, hasta un servidor complejo diseñado teniendo en cuenta el ambiente de flujo de trabajo.

Windows Workflow Foundation cuenta con un conjunto de servicios que le permiten al Runtime ejecutarse dentro de ASP.NET, aunque los vendedores independientes de software y los usuarios finales son libres de crear sus propias aplicaciones contenedoras de flujo de trabajos para aplicaciones existentes.

Al ser Windows Workflow Foundation un Framework para flujos de trabajo en vez de un producto independiente, y al soportar este tipo de diversidades, se convierte en una meta explícita para sus creadores. A pesar de que cada host usa el mismo Runtime Engine, cada uno debe proveer un conjunto de servicios Runtime. Estos servicios brindan soporte para persistir el estado de un flujo de trabajo, rastrear su ejecución, usar transacciones, etc.

Un flujo de trabajo puede ser de larga duración, ya que podría ejecutarse durante horas, días o semanas, y el Runtime de Windows Workflow Foundation podría apagarse durante un flujo de trabajo, y persistentemente almacenaría su estado si hubiera estado inactivo por un período de tiempo.

La decisión de descargar el flujo de trabajo se puede lanzar porque éste se encuentra bloqueado esperando un evento externo; esta decisión es tomada típicamente por el Runtime. Para escribir estados del flujo de trabajo en el disco, el Runtime depende del servicio de persistencia proporcionado por su proceso host.

Los eventos del flujo de trabajo son procesados por el Runtime a través de los delegados de manejo de eventos.

WWF_Eventos_1

¿Por qué son importantes los Runtime Events?

Porque proporcionan un mecanismo para hacer un seguimiento del ciclo de vida del flujo de trabajo, por ejemplo cuando se crea un flujo de trabajo, cuando finaliza el mismo flujo, etc. Otro beneficio de manejar eventos del Runtime es que proporcionan un mecanismo para dar seguimiento a todas las instancias del flujo de trabajo. De esta forma podemos determinar cuántos fueron los flujos de trabajo fueron creados, abortados, terminados, etc. Entre los eventos que se ejecutan del lado del workflowRuntime a los que se puede suscribir son:

Del tipo:

  • EventHandler<WorkflowRuntimeEventArgs>
  • EventHandler<WorkflowEventArgs>

Del motor:

  • Started
  • Stopped

De las instancias:

  • WorkflowCreated/Started/Stopped
  • WorkflowAborted/Terminated/Completed
  • WorkflowIdled/Loaded/Persisted/Unloaded

Eventos de Flujo de Trabajo

Los eventos del flujo de trabajo son procesados por el Runtime a través de los delegados de manejo de eventos. Estos eventos son generados/levantados por el Runtime del flujo de trabajo y no por la instancia del flujo de trabajo. Asimismo, tampoco son modelados como parte de la definición de flujo de trabajo. Los eventos enviados por el Runtime del flujo de trabajo contiene el identificador de la instancia del flujo de trabajo que generó el evento. La Tabla 1 nos muestra los diferentes eventos de flujo de trabajo existentes:

Eventos de flujo de trabajo

Descripción

ServicesExceptionNotHandled

Generado cuando la instancia del flujo de trabajo no puede manejar la excepción interna

Started

Generado cuando se inicia el runtime

Stopped

Generado cuando se detiene el runtime

WorkflowAborted

Generado cuando se aborta la instancia del flujo de trabajo

WorkflowCompleted

Generado cuando se completa la instancia del flujo de trabajo

WorkflowCreated

Generado cuando se crea la instancia del flujo de trabajo

WorkflowIdled

Generado cuando la instancia del flujo de trabajo está inactiva(por ejemplo: Delay o EventSink)

WorkflowLoaded

Generado cuando la instancia del flujo de trabajo se carga en memoria (por ejemplo: re-hydrated)

WorkflowPersisted

Generado cuando la instancia del flujo de trabajo tiene persistencia

WorkflowResumed

Generado cuando la instancia del flujo de trabajo se reanuda después de ser suspendida

WorkflowStarted

Generado cuando se inicia la instancia del flujo de trabajo

WorkflowSuspended

Generado cuando el runtime suspende la instancia del flujo de trabajo

WorkflowTerminated

Generado cuando el runtime o internamente se termina la instancia del flujo de trabajo

WorkflowUnloaded

Generado cuando la instancia del flujo de trabajo se descarga de memoria (por ejemplo: Hydrated)

Tabla 1. Eventos de Flujo de Trabajo

 

En el siguiente ejemplo podemos ver la implementación del evento WorkflowCompleted del WorkFlowRuntime:

private void ApplicationInitMethod() 
 
{ 
 
WorkflowRuntime workflowRuntime = new WorkflowRuntime(); 
 
workflowRuntime.WorkflowCompleted += new EventHandler<WorkflowCompletedEventArgs>( 
 
workflowRuntime_WorkflowCompleted); 
 
} 
 
 
 
void workflowRuntime_WorkflowCompleted(object sender, WorkflowCompletedEventArgs e) 
 
{ 
 
MessageBox.Show("Se completó el flujo de trabajo"); 
 
} 

 

En el siguiente ejemplo podemos ver la implementación del evento WorkflowCreated del WorkFlowRuntime:

private void ApplicationInitMethod() 
 
{ 
 
WorkflowRuntime workflowRuntime = new WorkflowRuntime(); 
 
workflowRuntime.WorkflowCreated += new EventHandler<WorkflowCompletedEventArgs>( 
 
workflowRuntime_WorkflowCreated); 
 
} 
 
 
 
void workflowRuntime_WorkflowCreated(object sender, WorkflowCompletedEventArgs e) 
 
{ 
 
MessageBox.Show("Se creó el flujo de trabajo"); 
 
} 

Tags: , ,

Comunidades | Articulos | WWF

Distintos tipos de Actividades Predefinidas

by Misael Monterroca 29. January 2008 00:47

Distintos tipos de Actividades Predefinidas

Workflow Foundation incluye una gran variedad de actividades predefinidas que podemos utilizar al crear nuestros propios flujos de trabajo. En este articulo veremos algunas de las actividades más destacables incluidas en esta plataforma.

Code

Clase: System.Workflow.Activities.CodeActivity

La actividad Code es una de las actividades más usadas en Workflow Foundation, ya que nos permite ejecutar cualquier tipo de código escrito dentro de un método. Su propiedad más importante es ExecuteCode la cual establece el nombre del método que queremos que se ejecute. En algunos capítulos hemos visto incluso el uso de esta actividad y su importancia que tiene al desarrollar flujos de trabajo. La siguiente figura muestra el resultado de un flujo de trabajo que utiliza esta actividad la cual ejecutará el método MetodoAEjecutar(), siendo el código de ese método el siguiente:

private void MetodoAEjecutar(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine("Hola Workflow Foundation"); 
 
} 
 

Sequence

Clase: System.Workflow.Activities.SecuenceActivity

La actividad Sequence nos permite ejecutar otras actividades en un orden específico, ya que asimismo esta actividad es un contenedor de otras actividades. Un buen ejemplo de una actividad Sequence son los flujos de trabajo de tipo Sequential Workflow, en donde podemos definir diversas actividades para que se ejecuten de manera ordenada o secuencial.

Los flujos de trabajo de tipo Sequential Workflow son instancias de la clase System.Workflow.Activities.SequentialWorkflowActivity, la cual a su vez hereda de la clase System.Workflow.Activities.SequenceActivity.

La siguiente figura muestra el diseñador de Workflow Foundation con una actividad Sequence con tres actividades de tipo Code. El código de esas actividades es el siguiente:

private void Metodo1(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine("Code 1"); 
 
} 
 
 
 
private void Metodo2(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine("Code 2"); 
 
} 
 
 
 
private void Metodo3(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine("Code 3"); 
 
} 
 

 

Por otro lado, al ejecutar el flujo de trabajo de la figura anterior obtenemos el resultado de la siguiente figura. Nótese como efectivamente el código es ejecutado en el orden establecido.

WWF_Actividades_b

Parallel

Clase: System.Workflow.Activities.ParallelActivity

La actividad Parallel como su nombre lo indica permite a un flujo de trabajo ejecutar paralelamente dos o más actividades. Parallel hace uso de la actividad Sequence para definir la serie de actividades que requieren ejecutarse en cada ramificación que definamos. La siguiente figura muestra un flujo de trabajo que implementa esta actividad con cuatro ramificaciones que incluyen cuatro actividades de tipo Code (codeActivity1, codeActivity2, codeActivity3, codeActivity4). El código de los métodos relacionados con esas actividades es el siguiente:

WWF_Actividades_2

 

 

El resultado de la ejecución de este flujo de trabajo será el siguiente:

WWF_Actividades_3 

Es importante aclarar que si bien la actividad Parallel define actividades que se ejecutarán de manera paralela no significa que se ejecutarán al mismo tiempo. Esto obedece a que Workflow Foundation asigna un solo hilo de ejecución para cada instancia de un flujo de trabajo. Esto es por diseño.

 

Delay

Clase: System.Workflow.Activities.DelayActivity

Esta actividad permite definir un retraso de tiempo. Su propiedad más importante es TimeoutDuration la cual especifica la duración en tiempo de ese retraso. La siguiente figura muestra el resultado de agregar esta actividad a la segunda rama del ejemplo de la actividad Parallel, con un retraso de 10 segundos. Podemos observar como efectivamente el retraso de tiempo provoca que el mensaje de codeActivity2 sea desplegado hasta el último lugar.

WWF_Actividades_4

 

While

Clase: System.Workflow.Activities.WhileActivity

La actividad While nos permite ejecutar una serie de actividades de manera cíclica, usando un método que funcione como expresión condicional. Su propiedad más importante es Condition con la cual precisamente definimos el tipo de condición a utilizar (Code Condition o Declarative Rule Condition). En el caso de seleccionar Code Condition necesitamos definir el nombre del método relacionado que fungirá como condicionante para que la actividad While continúe ejecutando iterativamente. El método relacionado con esta actividad debe tener la siguiente signatura:

void NombreDelMetodo(object, ConditionalEventArgs) 

ConditionalEventArgs tiene la propiedad Result de tipo bool. Esta propiedad le indica al runtime de Workflow Foundation si la condición es verdadera o falsa. En este caso para la actividad While si Result es true significa que debe continuar su ejecución de manera cíclica. Si Result es false el ciclo de While es finalizado y continúa la ejecución de la siguiente actividad definida después de While. Veamos un ejemplo de esta actividad.

La siguiente figura muestra el diseñador de Workflow Foundation con una actividad While, la cual contiene una actividad Code. El código relacionado con la actividad Code es el siguiente:

int contador = 1; 
 
 
 
private void Metodo1(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine(contador); 
 
contador++; 
 
} 
 

WWF_Actividades_5

Es necesario hacer notar que hemos definido una variable a nivel de clase llamada int contador. Esta variable nos servirá para desplegar su valor en la consola por cada ejecución iterativa de la actividad Code dentro de While. Para la actividad While hemos establecido que Condition es de tipo Code Condition, y hemos definido el método ChecaCondicion() el cual se encargará de evaluar si la condición ha sido alcanzada. El código de ChecaCondicion() es el siguiente:

private void ChecaCondicion(object sender, ConditionalEventArgs e) 
 
{ 
 
e.Result = contador<=20?true:false; 
 
} 

Si analizamos el código del método ChecaCondicion() podemos observar que estamos evaluando que la actividad While seguirá iterando siempre y cuando la variable llamada contador sea igual o menor que 20. Ya que la variable contador se inicializa con el valor de 1, tal y como esperamos, la consola desplegará los números del 1 al 20 ya que al llegar al 20 la condición evalúa a falsa y While alcanza su fin. Esto lo podemos corroborar en la siguiente figura:

WWF_Actividades_6

Throw

Clase: System.Workflow.ComponentModel.ThrowActivity

La actividad Throw nos permite lanzar excepciones dentro de un flujo de trabajo en Workflow Foundation. Esta actividad nos será de mucha utilidad cuando detectemos que el comportamiento o valores dentro de nuestro flujo de trabajo han alcanzado un estado inconsistente y por ello necesitemos parar la ejecución del flujo. Su propiedad más importante es FaultType, la cual indica qué tipo de excepción es la que arrojará esa actividad.

Para poder demostrar el uso de la actividad Throw, usaremos el mismo flujo de trabajo usado para la actividad While, sin embargo después (abajo) de la actividad While arrastraremos la actividad Throw de la caja de herramientas y la colocaremos en el diseñador. La siguiente figura muestra la caja de diálogo "Browse and Select a .NET Type", en donde podemos buscar y definir el tipo de excepción que la actividad Throw arrojará. Para este ejemplo usaremos la excepción de tipo System.ApplicationException la cual está implementada en mscorlib.

WWF_Actividades_7

La segunda propiedad importante para esta actividad es Fault, la cual nos permite definir una propiedad o campo para ligar la excepción. La siguiente figura muestra la caja de diálogo "Bind 'Fault' to an activity's property". En esta caja de diálogo podemos seleccionar un miembro existente o crear un nuevo miembro. En nuestro caso en este ejemplo crearemos un nuevo miembro ya que no hemos escrito código hasta el momento. Podemos seleccionar que la excepción se ligue a una variable o a una propiedad, en nuestro caso usaremos un campo llamado workflow_exception.

WWF_Actividades_8

Una vez definida y configurada la actividad Throw, veamos en la siguiente figura cuál es el resultado de la ejecución de este flujo de trabajo.

WWF_Actividades_9

Como podemos observar, después de desplegar los valores del contador la consola nuestra el mensaje de error relacionado con esa excepción. Ahora bien, podemos darnos cuenta que la ejecución del flujo de trabajo es suspendida gracias a que se está arrojando una excepción de tipo ApplicationException. En la siguiente parte veremos la actividad FaultHandler la cual nos permite capturar cualquier tipo de excepción y manejarla apropiadamente.

FaultHandler

Clase: System.Workflow.ComponentModel.FaultHandlerActivity

La actividad FaultHandler nos permite manejar apropiadamente las excepciones que sean arrojadas por las actividades Throw dentro de nuestros flujos de trabajo en Workflow Foundation. Para demostrar su uso continuaremos usando el proyecto de flujo de trabajo usado en la demostración de la actividad Throw. En un flujo de trabajo podemos definir uno o más actividades de tipo FaultHandler para definir las actividades que deben ser ejecutadas al estar capturando la excepción. Para realizar esto necesitamos cambiar la vista de nuestro diseñador para desplegar la lista de FaultHandlers. Esto lo logramos haciendo clic en la lista desplegable que se muestra al acercar el cursor a la fecha verde de inicio de nuestro flujo de trabajo, tal y como lo muestra la siguiente figura:

WWF_Actividades_10

Al cambiarnos de vista podemos observar que el diseñador de Workflow Foundation crea una actividad FaultHandlersActivity (nótese el nombre en plural), la cual es un contenedor de actividades de tipo FaultHandlerActivity. En esta actividad podemos arrastrar y colocar una o más actividades de tipo FaultHandler para así definir en cada una la serie de actividades que deseamos que se ejecuten al estar manejando la excepción. La actividad FaultHandler tiene la propiedad FaultType, la cual nos sirve para definir el tipo de excepción que esta actividad puede capturar. La siguiente figura muestra el diseñador con una actividad de tipo FaultHandler a la que se le ha definido la propiedad FaultType como System.ApplicationException (para efectivamente capturar la excepción que arroja Throw) y dentro de esta actividad se ha colocado una actividad de tipo Code con el siguiente código relacionado:

private void ErrorManejado(object sender, EventArgs e) 
 
{ 
 
Console.WriteLine("Error manejado!"); 
 
} 

WWF_Actividades_11

Como podemos deducir, al ejecutar el flujo de trabajo la actividad FaultHandler captura la excepción arrojada por la actividad Throw y despliega efectivamente el mensaje "Error manejado!" en la consola, en vez de desplegar el mensaje por defecto de la excepción. Vale la pena mencionar que cada actividad FaultHandler podría tener una o más actividades relacionadas. El resultado de la ejecución de este flujo de trabajo es mostrado en la siguiente figura:

WWF_Actividades_12

Articulo Publicado en http://desarrollador.redusers.com/

Tags: , , ,

Comunidades | .Net | Articulos | WWF

MVP