Windows WorkFlow Foundation – Part III

Windows Workflow Persistence Services

Muchos procesos de negocios demoran largos períodos de tiempo en completarse. Mantener el Workflow en memoria no sólo es poco práctico (por limitaciones de memoria), sino que también evita el escalamiento, porque una instancia debe ser procesada en un solo servidor.

Muchos de estos workflows de larga duración no están actualmente ejecutando un flujo o una lógica de procesos y son efectivamente lentos, esperando un ingreso por parte de un usuario u otro sistema. Al descargar una instancia lenta, la aplicación host puede ahorrar memoria y permitir la escalabilidad entre servidores que están procesando.

Cuando ciertas condiciones ocurren mientras un workflow se está ejecutando, el motor del runtime de workflow usa un servicio de persistencia, si uno es cargado en el runtime, para persistir el estado de información sobre la instancia workflow. Estas condiciones incluyen las siguientes:

Ø  Cuando transacciones atómicas en actividades TransactionScopeActivity y CompensatableTransactionScopeActivity son completadas.

Ø  Cuando una instancia workflow se torna lenta y el flag UnloadOnIdle es establecido en true para un WorkflowPersistenceService.

Ø  Cuando la aplicación host del runtime llama a  System.Workflow.Runtime.WorkflowInstance.Unload o a System.Workflow.Runtime.WorkflowInstance.RequestPersist en la instancia workflow.

Ø  Cuando una instancia workflow es terminada o finaliza.

Ø  Cuando una actividad personalizada que usa el atributo PersistOnCloseAttribute se completa.

Ø  Cuando una actividad CompensatableSequenceActivity se completa.

Si se cumple alguna de estas condiciones y el servicio de persistencia es agregado al motor del runtime, éste llama a métodos que son proporcionados por el servicio de persistencia para guardar el estado de información sobre la instancia workflow. De manera similar, cuando el motor del runtime tiene que recuperar una instancia workflow previamente persistida, llama a métodos que son proporcionados por el servicio de persistencia para cargar este estado de información. En otras palabras, el motor del runtime de workflow determina cuándo debería producirse la persistencia, pero la ejecución de las operaciones de persistencia necesarias depende de un servicio de persistencia.

Creando servicios de persistencia

Se pueden crear servicios de persistencia derivando una clase desde la clase WorkflowPersistenceService. Es posible agregar su servicio de persistencia al motor del runtime del workflow invocando a AddService o realizando una entrada apropiada en el archivo de configuración de la aplicación.

Windows Workflow Foundation provee la clase SqlWorkflowPersistenceService, un servicio de persistencia “out-of-box”, el cual se puede usar como está o extenderlo.

Bloqueando información de estado del workflow

El motor del runtime de workflow tiene semánticas para bloquear la información de estado del workflow, para usarlas en ambientes donde los servicios de persistencia que se están ejecutando en distintos procesos pueden llegar a tener acceso a un solo almacenador de datos. La clase WorkflowPersistenceService le permite soportar esta funcionalidad del runtime proporcionando un parámetro a SaveWorkflowInstanceState, que especifica si la información de estado de una instancia workflow debería ser destrabada en el almacenador de datos, y proporcionando un método UnlockWorkflowInstanceState para desbloquear información de estado del workflow previamente bloqueado. En un servicio de persistencia que involucra al bloqueado, una llamada a LoadWorkflowInstanceState debería bloquear la información de estado para una instancia workflow.

Cuando cree su propio servicio de persistencia, tire un PersistenceException si el servicio no guarda la información de estado en su almacenador de datos o carga información de estado desde su almacenador de datos. El runtime del workflow espera este comportamiento.

Persistence Service Batching Behavior

Un mecanismo de batching es proporcionado por servicios que usan un almacenador duradero para salvar información de estado de un workflow. En estos casos es importante mantener consistencia entre el almacenador que es usado por el servicio de persistencia y el estado interno del runtime del workflow. Se le puede agregar funcionalidad al servicio, que es definida por la interfaz IPendingWork, y hacer que participe en el batching de la transacción del workflow que es proporcionado por el servicio WorkflowCommitWorkBatchService, agregando estos cambios a su almacenador de datos como ítems de trabajo al WorkBatch.

Complex Hosting Scenarios

Un escenario posible para el despliegue de las soluciones de Windows Workflow Foundation es crear múltiples aplicaciones host, cada una con un conjunto diferente de servicios que estén corriendo en distintas configuraciones de escritorio y servidores. Bajo este escenario, un requerimiento puede ser que algunos workflows que están definidos en la solución sólo se puedan ejecutar en ciertos sistemas. Los servicios “out-of-box” en Windows Workflow Foundation, como el servicio SqlWorkflowPersistenceService, no soportan este tipo de configuración. Para controlar qué instancias workflow se cargaran en qué sistema, se deberá crear un servicio de persistencia personalizado.

Windows Workflow Tracking Services

Windows Workflow Foundation le permite rastrear su información relacionada con un workflow de una manera consistente, confiable y flexible. El framework de rastreo de Windows Workflow Foundation está diseñado para permitirles a los hosts observar las instancias workflow durante la ejecución capturando eventos que son disparados durante el tiempo de ejecución.

El framework es un diseño “conectable” que les permite a hosts escribir su propio servicio de rastreo o usar un servicio de rastreo “out-of-the-box” o de un tercero. Adicionalmente, debido a que el runtime de Windows Workflow Foundation permite agregar varios servicios de runtime durante su tiempo de vida, múltiples servicios de rastreo de diferentes tipos pueden ser habilitados simultáneamente. Por ejemplo, Windows Workflow Foundation contiene un servicio “out-of-box” SqlTrackingService que permite escribir una cantidad configurable de información de rastreo a una base de datos SQL Server.

Windows Workflow Foundation contiene varias características incorporadas para permitir el rastreo en una aplicación workflow.

l  Se asegura de que el rastreo ocurra de una manera consistente.

l  Provee escalabilidad y confiabilidad.

l  Permite que los datos sean rastreados a pesar del almacén de datos subyacente.

l  Provee una locación para consultar por datos relacionados con el workflow por medio de ambientes de hosting.

l  Brinda la habilidad para consultar en ciclos de vida de workflows pasados y presentes, y determinar posibles futuros pasos de ejecución de instancias workflow.

Perfiles de rastreo

Los servicios de rastreo determinan la cantidad de datos que reciben usando un perfil de rastreo para filtrar esos datos. Un servicio de rastreo puede recibir eventos workflow, estados de ejecución, e ítems de rastreo de datos personalizados del usuario. El servicio de rastreo es responsable por los datos de rastreo que recibe del runtime cuando una instancia workflow se está ejecutando. Puede almacenar los datos en un archivo o en una base de datos, crear un almacén de consultas en memoria, escribir los datos en el log de eventos del sistema, o sólo darle salida de los datos de rastreo a la consola.

Se pueden crear perfiles de rastreo usando un esquema de Perfil de Rastreo XML, o programáticamente, usando el modelo de objeto Tracking Profile. Adicionalmente, los perfiles de rastreo basados en XML pueden ser deserializados a una instancia TrackingProfile usando el TrackingProfileSerializer de la API.

Cuando se usa el rastreo en Windows Workflow Foundation, se puede rastrear un simple evento o un grupo de eventos que son levantados durante la ejecución del workflow. Los eventos que pueden ser rastreados para actividades están definidos en la enumeración ActivityExecutionStatus.

En adición a los servicios de rastreo para actividades, la infraestructura de rastreo también le permite rastrear eventos que ocurran a nivel de la instancia workflow. El nivel de instancias de eventos que es posible rastrear puede ser definido en la enumeración TrackingWorkflowEvent.

Tipos de Worflows Soportados

Existen dos modelos de workflow: Sequential y State-Machine.

El modelo Sequential ejecuta actividades con un patrón predefinido, mientras que el modelo de State-Machine sólo conoce los estados posibles del sistema, a qué se dedica cada estado, a qué eventos externos responde y cómo (aquí se suele incluir cierta lógica en forma de workflow secuencial).

Sequential Workflow

Los workflows secuenciales están orientados a aplicaciones donde las actividades del workflow son ejecutadas en algún tipo de secuencia. Esta secuencia puede incluir loops, decisiones y otros tipos de controles de flujo, pero, no obstante, el workflow tiene un camino definido de principio a fin.

wwf_Sequential

State-Machine Workflow

En un workflow State-Machine, el workflow en sí está formado por un conjunto de estados. Cada estado puede recibir una cierta cantidad de conjuntos de eventos. El workflow State-Machine puede tener un estado final. Cuando una transición es hecha al estado final, el workflow se completa.

Organizar actividades workflow de esta manera es útil cuando la secuencia exacta de eventos es desconocida, como para un proceso de negocio Event-Driven, o cuando el número de posibilidades hace que definir todos los caminos posibles sea poco práctico. Un ejemplo primario de esto es un workflow que coordina el trabajo de personas en vez de aplicaciones. Los workflows State-Machine hacen que sea más fácil saltear pasos “al vuelo”, saltar a cualquier paso del proceso de negocio, o cancelar el proceso de negocio en cualquier momento. Los State-Machines pueden, también, proveer una manera de definir workflows que coincida en el modo en que algunas organizaciones piensan y documentan sus procesos de negocios. En casos como éstos, modelar workflows de esta manera puede ayudar a los desarrolladores y a la gente de negocios a trabajar juntos de una forma más eficiente.

También es posible anidar estados. Un evento definido en un estado externo aplica ambos a ese estado y a todos los estados que contiene. Esto provee una manera directa de expresar eventos que puedan ocurrir en cualquier momento en cualquiera de estos estados, como la cancelación de una orden.

wwf_StateMachine

Jonnathan De La Barra Hot

About justindeveloper

I am MCP (Microsoft Certified Professional). MCTS (Microsoft Certified Technology Specialist) and MCPD (Microsoft Certified Professional Developer), also I am SAP Business One Certified!! Desarrollando desde el IDE de Visual Studio NET 2003 hasta ahora con el Visual Studio NET 2010. Desde Microsoft SQL Server 2000 hasta ahora con el Microsoft SQL Server 2008 R2 y tambien con SharePoint, desde WSS 3.0 y MOSS 2007 y ahora familirizandome con el Sharepoint Foundation 2010 & Sharepoint Server 2010. The software development will follow being every time more wonderful!
This entry was posted in Development. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s