Datapayasadas

diciembre 11, 2012

Workflow Foundation 4.0

Filed under: .Net, C#, Desarrollo, WF4 — Etiquetas: , , , — pabloide86 @ 11:57 pm

Buenasss amigosss! Hacía muchísimo que no escribía por acá!

El pasado Jueves 22 de Noviembre fui invitado por la cátedra de .NET de la UTN para disertar en las Mini Charlas Tecnológicas!

El tema que elegí fue Procesos de Negocios con Workflow Foundation 4.0. Me topé con esta tecnología a mediados del 2010 como parte del desarrollo de un proyecto en el que estaba trabajando. En ese proyecto estaban usando BizTalk 2000 y se estaba haciendo una migración hacia .NET, entonces WF4 surgió como un reemplazo natural a esta tecnología.

A continuación, un breve resumen de la charla.

¿Que es Workflow Foundation 4.0?

Workflow Foundation 4.0 es un framework de Microsoft para desarrollar flujos de trabajo que está integrado dentro de .NET. Esto quiere decir que no necesitamos de un producto como BizTalk para poder usarlo.

La ventaja que tiene WF es que permite construir flujos de trabajo de manera visual lo cual permite ver el proceso, además de proveernos una infraestructura para ejecutar, persistir y trackear la ejecución de estos flujos de trabajo.

La primer ventaja que surge de esto es que el proceso queda prácticamente documentado en el mismo workflow. Es muy intuitivo explicarle a alguien como funciona con solo verlo. Esto es muy practico cuando tenemos lógica de negocios muy compleja o con gran cantidad de bifurcaciones.

Muchas veces me dijeron “uhh loco esto esta buenísimo! pero no se me ocurre donde usarlo..”. Y acá la palabra clave es proceso. Hay que entender el proceso de negocio para saber cuando y donde usar WF!!

La segunda ventaja que surge es que el entorno de ejecución valida que el proceso se ejecute en el orden que fue diseñado (ver el apartado del Runtime).

Visual Studio 2010 nos provee un ambiente de desarrollo con muchísimas herramientas que nos van a facilitar la tarea de construir y debuggear workflows.

Evolución de WF

WF4 fue una reingeniería completa y simplificó muchos conceptos y componentes para que sea más sencillo de usar.

image

Una de las novedades que trae WF4 es la posibilidad de publicar un workflow como un Web Service WCF.

¿Dónde estamos?

image

¿Qué es un workflow?

Podríamos considerar a un workflow como un árbol de actividades, donde el workflow propiamente dicho seria la actividad raíz que contiene otras actividades. Cada actividad además puede estar compuesta por otras actividades, y así hasta llegar a las actividades hoja.

image

Las actividades hojas son las que realizan las operaciones concretas como validar un dato, leer un registro de la base de datos, enviar un mail, etc.

¿Qué es una actividad?

Una actividad es una entidad que tiene datos y realiza un trabajo. Los datos se almacenan en variables de ejecución y se transmiten a través de InArguments y OutArguments. Esto es así debido a que el runtime es quien tiene la responsabilidad de coordinar la ejecución de todas las actividades.

Hay dos formas de programar actividades: de forma Declarativa (Designer, XAML, Code) o de forma Imperativa (Code Activities).

En el caso de las Code Activities, el trabajo se ejecuta dentro del método Execute.

image

Clases base

Cualquier actividad hereda directa o indirectamente de alguna de las siguientes clases:

image

Cuando se ejecuta una actividad, existe un contexto de ejecución que contiene toda la información necesaria para ejecutar dichas actividades. Según la complejidad de la actividad que se esta desarrollando hay diferentes niveles de acceso a este contexto de ejecución.

  • CodeActivity: son actividades simples, por lo cual el acceso al contexto de ejecución es mas acotado.
  • AsyncCodeActivity: lo mismo que CodeActivity pero es asincrónica.
  • NativeActivity: son actividades más complejas, por lo cual el acceso al contexto de ejecución es mas avanzado. Permite schedulear la ejecución de otras actividades por ejemplo.
  • CodeActivity<TResult>, AsyncCodeActivity<TResult>, NativeActivity<TResult>: son iguales que las anteriores con la diferencia de que tienen un OutArgument<TResult> llamado Result y se utilizan cuando la actividad debe devolver un resultado.

La elección de cuál de estas heredar va a depender de la actividad que estamos queriendo programar. Por ejemplo, si es una validación simple que debe devolver un valor booleano usamos CodeActivity<Boolean>, en cambio si estamos queriendo hacer una actividad de Retry donde tiene actividades hijas y nosotros debemos controlar la ejecución de esas actividades usamos NativeActivity.

Designer Activity

Son actividades hechas con el Designer. Por lo general son actividades compuestas por otras actividades sencillas (Code Activities) y se pueden reutilizar.

imageimage

Para estas actividades, Visual Studio nos provee de una paleta de actividades out-of-the-box que podemos usar, como son las actividades para controlar el flujo (if, for, foreach, switch, etc.), actividades para WCF, etc.

En este editor además podemos definir Variables de ejecución, las cuales poseen un scope definido. Esto permite optimizar la cantidad de memoria que utiliza cada instancia ya que no almacena variables que ya no son utilizadas (es una mejora con respecto a la versión 3.5):

image

La pestaña Imports permite agregar Namespaces de proyectos referenciados. Esto es importante para poder utilizar las actividades creadas en otros proyectos referenciados.

Para elegir el tipo de variable tenemos una ventana muy piola con un buscador de tipos:

image

Cabe mencionar también que las expresiones utilizadas para asignar variables son todas expresiones en lenguaje Visual Basic. A partir de la versión 4.5 agregaron soporte para expresiones C#.

Al ver el panel de propiedades de una actividad vemos todos sus InArguments y OutArguments:

image

La propiedad CanCreateInstance de una actividad es sumamente importante ya que establece si la actividad puede producir o no una nueva instancia de workflow.

Code activity

Estas son las actividades que realizan un trabajo concreto, como leer o guardar un registro en la base de datos, enviar un mail, validar si un valor se encuentra adentro de un determinado rango, etc.

La idea es que las actividades sean lo más atómicas posibles, permitiendo una mejor reutilización de las mismas. Pero también se pueden utilizar para invocar métodos de la capa de negocios en caso de que queramos reutilizar métodos que ya existen en esa capa y que son utilizados fuera del workflow (como puede ser la validación de un número de CUIT por ejemplo). En este ultimo caso, las CodeActivity solo serían un pasamanos entre el workflow y la lógica de negocios.

image

Tipos de Workflow

Existen tres tipos de workflow:

  • State Machine

image

  • Sequence

image

  • Flowchart

image

Quiero hacer hincapié en la composición. Es decir, podemos usar un StateMachine dentro de un Flowchart dentro de una Sequence.

Arquitectura

image

En este caso en particular, WorkflowServiceHost permite hostear los workflow services (con extensión xamlx). Pero existen otros tipos de host que permiten hostear workflows como un servicio de Windows, aplicación de consola o incluso invocar workflows dentro de nuestro mismo programa.

Runtime

Es el arbitro, fuerza las “reglas del juego”. Sólo ve activities, activities, activities (no Sequence, Parallel, Recurrence).

image

Es el encargado de ejecutar todas las actividades dentro del workflow y de coordinar y llevar el rastro de qué es lo que falta ejecutar.

El runtime analiza todas las actividades que va a ejecutar y sabe cuales son sus InArguments, OutArgumens, execution variables, etc. Todo esto lo hace dinámicamente por Reflection. Esto puede tener un costo de performance para workflows con grandes volúmenes de ejecución. Para solucionar este problema existe un método llamado CacheMetadata que se puede sobrescribir y describir en forma explícita todas las variables y argumentos utilizados por la actividad.

Persistencia

Es uno de los mecanismos mas importantes que provee WF4. Este permite pausar la ejecución de un workflow, persistir su estado (en base de datos por ejemplo) y descargar la instancia de workflow de memoria. Esto permite optimizar muchísimo los recursos. Luego, cuando llegue alguna acción que “despierte” al workflow, el runtime se encarga de “rehidratar” la instancia a partir de los datos persistidos. Cabe destacar que este mecanismo es extensible y se configura mediante el web.config del workflow.

Estas acciones de “despertar” se implementan mediante bookmarks. Cuando un workflow es persistido en la base, se almacena un listado de bookmarks habilitados para que se pueda seguir ejecutando. Una vez mas, el runtime nos alivia el trabajo de tener que validar que el bookmark que queremos resumir es válido. Es decir, si el workflow está esperando resumir desde el bookmark AprobarPedido y nosotros queremos resumir el bookmark EnviarPagoAProveedor es el runtime quien nos va a decir “No querido, mi estado no permite que hagas esa operación”. Esta validación es otras de las características poderosas de WF.

Si bien la persistencia en base de datos es imprescindible para workflows con grandes volúmenes de peticiones, trae aparejado un gran problema: el versionado. Seguramente hable en alguna otra entrega sobre este tópico (pueden revisar el blog de Ron Jacobs también), pero básicamente no se puede modificar la definición de un workflow que esté persistido. Esto se debe a que el runtime no serializa la definición del workflow junto con su estado y es responsabilidad de quien hostea el workflow de mantener las diferentes versiones del mismo.

Según sea el caso, este “defecto” es deseable o no. Por ejemplo, si un workflow representa un contrato y los contratos en curso no se pueden modificar, tiene sentido que no se pueda modificar la definición de los workflows que ya estén iniciados. Si en cambio, existe un bug en la definición del workflow que impida la ejecución, entonces ahí estaremos en problemas.

Algunas de estas cuestiones fueron resueltas en la versión 4.5.

La estrategia que yo utilicé es usar WCF Routing Service para direccionar los mensajes WCF a la versión de workflow que corresponda. En este caso, si hay un bug en el workflow no se puede hacer nada y hay que empezar de nuevo.

Tracking

Al igual que la persistencia, el tracking de ejecución es otra de las herramientas poderosas de workflow. Permite llevar el rastro de la ejecución de todas las actividades del workflow y después nos va a permitir diagnosticar con mayor precisión a la hora de resolver problemas. También es un mecanismo extensible y se puede configurar mediante el web.config del workflow.

Designer Re-hosting

Otra de las características de WF4 es la posibilidad de usar el designer de workflow dentro de una aplicación WPF lo cual permitiría incluir el proceso de creación de workflows dentro de nuestra misma aplicación!

En el editor se puede incluir un conjunto de actividades predefinidas (tanto las out-of-the-box como las propias). De esta forma se podría crear una herramienta para que los analistas funcionales o incluso los mismos usuarios avanzados de la aplicación creen sus propios workflows!

Un ejemplo de esto es la herramienta Active Build & Deployment

Conclusiones

Workflow Foundation 4 es una herramienta muuuuy poderosa! Las posibilidades que provee son infinitas y la forma de desarrollo es bastante intuitiva. Hasta donde pude ver, Visual C# Express no incluye el editor de Workflow Foundation.

Si bien tiene su curva de aprendizaje (sobre todo a la hora de definir la arquitectura de la solución) existe bastante documentación y foros de ayuda.

¿En donde aplicarlo? Siempre que tengamos un proceso, generalmente de larga duración, con interacción humana. Puede ser un proceso de registración de usuarios a una web, aprobaciones de documentos, vacaciones, prestamos, gestión de pólizas de seguros, procesos productivos, etc. Todo lo que sea un proceso se puede modelar!

Referencias

Algunos links para profundizar:

http://blogs.msdn.com/b/rjacobs/ (blog de un program manager de WF/AppFabric. Tiene videos con ejemplos y algunos temas interesantes)

http://msmvps.com/blogs/theproblemsolver/archive/tags/WF4/default.aspx

http://channel9.msdn.com/Shows/Endpoint

http://channel9.msdn.com/shows/Endpoint/endpointtv-Workflow-and-Custom-Activities-Best-Practices-Part-1/ (Serie de capítulos con best practices a la hora de desarrollar actividades! Véanlos que se aprende mucho)

http://msdn.microsoft.com/en-us/library/vstudio/dd489441(v=vs.100).aspx

http://msdn.microsoft.com/en-us/library/dd456788(v=vs.100).aspx

Espero que les haya gustado y que les sirva!!! Intentaré subir algún ejemplo para que puedan verlo en acción.

Hasta la próxima!!

Anuncios

Dejar un comentario »

Aún no hay comentarios.

RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Crea un blog o un sitio web gratuitos con WordPress.com.

A %d blogueros les gusta esto: