Introducción al hospedaje de Windows Workflow Foundation

 

Moustafa Khalil Ahmed
Program Manager
Microsoft Corporation

Agosto de 2006

Se aplica a:
   Windows Workflow Foundation
   Microsoft .NET Framework 2.0
   Microsoft .NET Framework 3.0

Resumen: Proporciona información general sobre cómo una aplicación que hospeda Windows Workflow Foundation (WF) puede administrar y supervisar los flujos de trabajo en ejecución y proporciona información general sobre los servicios en tiempo de ejecución y sus implementaciones de fábrica. Los lectores deben estar familiarizados con Microsoft .NET Framework, C# y el modelo de programación wf. (16 páginas impresas)

Contenido

Introducción
Administración del ciclo de vida de las instancias de flujo de trabajo
Capacidad de administración y supervisión
Confiabilidad y alta disponibilidad
Servicios en tiempo de ejecución base
Conclusión
Para obtener más información

Introducción

Este artículo está diseñado para desarrolladores que usan Windows Workflow Foundation (WF) para ayudarles a comprender las diferentes opciones disponibles para permitir que sus aplicaciones administren y supervisen las instancias de flujo de trabajo en ejecución. En el artículo se da por hecho que el lector tiene un conocimiento básico de Microsoft .NET Framework, C# y WF.

WF consta de una biblioteca de actividades y un marco, un motor en tiempo de ejecución y componentes de servicios en tiempo de ejecución que se deben ejecutar dentro de un proceso de aplicación host. Los flujos de trabajo se construyen como un conjunto de actividades ejecutadas por el motor en tiempo de ejecución. El motor en tiempo de ejecución debe ejecutarse dentro de un proceso de aplicación host. La ilustración siguiente muestra cómo los flujos de trabajo, las actividades y el motor de tiempo de ejecución del flujo de trabajo se hospedan en el proceso con una aplicación host.

Figura 1. Proceso de host de Windows Workflow Foundation

WF proporciona un motor en tiempo de ejecución, que es responsable de la ejecución del flujo de trabajo y la administración de estado. El entorno de ejecución de WF se puede hospedar en cualquier proceso de .NET, incluidos ASP.NET, servicios de Windows, aplicaciones de consola y aplicaciones de Windows Forms. El desarrollador es responsable de escribir este proceso de host al compilar una aplicación habilitada para flujo de trabajo. Los servicios en tiempo de ejecución funcionan en el proceso de host para proporcionar funcionalidad adicional al motor en tiempo de ejecución a medida que administra la ejecución de flujos de trabajo.

Hay muchos problemas que se deben tener en cuenta al implementar una aplicación host para WF. En este artículo se proporciona información general sobre cómo la aplicación host puede administrar y supervisar flujos de trabajo, así como un resumen de los servicios en tiempo de ejecución base y sus implementaciones de fábrica.

Administración del ciclo de vida de las instancias de flujo de trabajo

WF proporciona métodos de operaciones de control y actividades predeterminadas en la clase WorkflowInstance para administrar los estados de flujo de trabajo y el ciclo de vida. En la sección Administración del ciclo de vida de las instancias de flujo de trabajo se describen los distintos eventos en tiempo de ejecución específicos de la instancia de flujo de trabajo y las transiciones entre esos eventos y su relación con los estados del flujo de trabajo.

Puntos de persistencia

Los flujos de trabajo suelen estar inactivos y de larga duración, esperando una entrada de un usuario u otros sistemas para continuar. Dado que no es práctico contener los flujos de trabajo inactivos en la memoria, se recomienda conservar el estado de la instancia de flujo de trabajo en un medio de almacenamiento hasta que el flujo de trabajo reciba el evento que está esperando. Además, guardar el estado de la instancia de flujo de trabajo ayuda a reanudar el flujo de trabajo desde ese punto en caso de un error más adelante en el proceso.

En la figura 2 se describe cómo puede usar puntos de persistencia para reanudar la ejecución de instancias de flujo de trabajo.

Ilustración 2. Uso de puntos de persistencia para reanudar la ejecución de instancias de flujo de trabajo

Si un estado de instancia de flujo de trabajo se conserva en el punto B y se produce un error en el punto C, la aplicación puede reanudar la instancia de flujo de trabajo desde el punto B sin perder el trabajo realizado entre los puntos A y B. Sin embargo, si un servicio de persistencia no está disponible o no se conserva el estado de la instancia de flujo de trabajo, se pierde el trabajo realizado desde el punto A al B.

Si un WorkflowPersistenceService está presente (es decir, se agrega a la instancia WorkflowRuntime ), el motor de tiempo de ejecución de flujo de trabajo usa este servicio para conservar el estado de la instancia de flujo de trabajo en un medio de almacenamiento. Esto puede ocurrir en los puntos siguientes:

• Al finalizar las actividades marcadas con PersistOnCloseAttribute (por ejemplo, actividades de ámbito de transacción)
• Antes de la finalización de la instancia de flujo de trabajo
• Antes de la finalización de la instancia de flujo de trabajo
• Cuando el flujo de trabajo deja de estar inactivo
• Cuando se llama a WorkflowInstance.Unload o WorkflowInstance.TryUnload

El motor en tiempo de ejecución de WF llama al método SaveWorkflowInstanceState() en WorkflowPersistenceService para guardar el estado de la instancia del flujo de trabajo. Llama al método LoadWorkflowInstanceState() para recuperar el estado persistente de la instancia de flujo de trabajo cuando sea necesario. El tiempo de ejecución del flujo de trabajo controla toda la semántica con respecto a cuándo realizar la persistencia y los servicios de persistencia son responsables del ahorro y carga reales de la instancia de flujo de trabajo. Los estados de actividad y el identificador de instancia de flujo de trabajo se serializan y guardan en el almacén de persistencia. Además, toda la demás información necesaria para reanudar la ejecución de la instancia de flujo de trabajo (por ejemplo, colas) se incluye en el estado serializado y guardado.

Eventos de instancia de flujo de trabajo

Una instancia de flujo de trabajo puede estar en uno de los cinco estados: Creado, En ejecución, Suspendido, Completado y Finalizado. Los flujos de trabajo tienen 13 eventos que se producen durante toda la vigencia de la instancia de flujo de trabajo. Estos eventos pueden indicar una transición a un estado diferente. Por ejemplo, el evento WorkflowCompleted indica que la instancia ha pasado de Ejecutar a Completado. Algunos eventos no indican que la instancia ha pasado a un estado diferente. Por ejemplo, el evento WorkflowPersisted indica que la instancia se conserva pero sigue en estado En ejecución. De esos 13 eventos, 11 se comunican a la aplicación host a través de eventos en tiempo de ejecución y seguimiento de eventos de flujo de trabajo. Dos eventos, Changed y Exception, se comunican a la aplicación host solo a través de los eventos de flujo de trabajo de seguimiento.

WF proporciona métodos de operaciones de control en la clase WorkflowInstance para permitir que las aplicaciones host administren el ciclo de vida del flujo de trabajo. Además, una aplicación puede establecer directivas para administrar el ciclo de vida del flujo de trabajo. Por ejemplo, una aplicación puede tener directivas de descarga para indicar al motor de WF que descargue la instancia de flujo de trabajo. WF proporciona actividades de fábrica que pueden afectar a las estadísticas de la instancia de flujo de trabajo. Por ejemplo, las actividades SuspendActivity y TerminateActivity se pueden usar para suspender y finalizar la instancia de flujo de trabajo respectivamente. En las secciones siguientes se describen varios eventos específicos de la instancia de flujo de trabajo que genera el tiempo de ejecución del flujo de trabajo para comunicar eventos de instancia de flujo de trabajo y transiciones de estadísticas de la instancia de flujo de trabajo.

WorkflowAborted

Se considera que se anula una instancia de flujo de trabajo cuando el motor en tiempo de ejecución de flujo de trabajo elimina la instancia en memoria. Las aplicaciones host pueden anular la instancia de flujo de trabajo llamando a WorkflowInstance.Abort(). Las instancias de flujo de trabajo anuladas se pueden reanudar desde su último punto de persistencia llamando a WorkflowInstance.Resume(). La anulación de una instancia de flujo de trabajo se usa en situaciones extremas en las que una aplicación decide descartar todo el trabajo realizado desde el último punto de persistencia hasta que se llame a WorkflowInstance.Abort().

WorkflowCompleted

Una instancia de flujo de trabajo se completa cuando la instancia termina de ejecutarse. En ese momento, la aplicación host puede examinar las colas de mensajes y otros eventos que la instancia de flujo de trabajo no consumió.

WorkflowCreated

Se crea un flujo de trabajo cuando la instancia se construye completamente, pero antes de que las actividades empiecen a ejecutarse. La instancia de flujo de trabajo se crea llamando a cualquiera de los varios métodos sobrecargados WorkflowRuntime.CreateWorkflow().

WorkflowIdled

La instancia de flujo de trabajo está inactiva cuando espera a que un evento externo (temporizador, mensaje u otros eventos personalizados) continúe la ejecución. Para guardar los recursos del sistema, una aplicación puede establecer su directiva de descarga para descargar la instancia de flujo de trabajo desde la memoria cuando está inactiva. Si la aplicación host usa sqlWorkflowPersistenceService lista para usar, puede establecer una marca UnloadOnIdle en el archivo de configuración de la aplicación para indicar al motor en tiempo de ejecución de WF que conserve el estado del flujo de trabajo cuando la instancia esté inactiva.

WorkflowLoaded

El evento WorkflowLoaded se genera cuando el estado de la instancia se carga en la memoria desde un almacén de persistencia.

WorkflowPersisted

Cuando sqlWorkflowPersistenceService o un servicio de persistencia personalizado se ha agregado a la instancia WorkflowRuntime , la instancia de flujo de trabajo se conserva cuando el estado de la instancia de flujo de trabajo se guarda en el almacén de persistencia.

WorkflowResumed

La instancia de flujo de trabajo se reanuda cuando se llama a WorkflowInstance.Resume() en una instancia de flujo de trabajo suspendida o anulada.

WorkflowStarted

El evento WorkflowStarted se genera cuando se llama a WorkflowInstance.Start(). El evento de inicio del flujo de trabajo se genera antes de que el motor en tiempo de ejecución del flujo de trabajo comience a ejecutar actividades de flujo de trabajo.

WorkflowSuspended

La suspensión de la instancia de flujo de trabajo se realiza a través de una llamada WorkflowInstance.Suspend() o cuando se ejecuta una actividad SuspendActivity . Como resultado, la instancia de flujo de trabajo está en estado suspendido.

WorkflowTerminated

Finalizar la instancia de flujo de trabajo se realiza a través de una llamada WorkflowInstance.Terminate(), cuando se ejecuta una actividad TerminateActivity o cuando se produce una excepción no controlada en la instancia de flujo de trabajo en ejecución. Una vez generado este evento, la instancia de flujo de trabajo está en estado terminado.

WorkflowUnloaded

El evento WorkflowUnloaded se genera cuando la instancia de flujo de trabajo se descarga de la memoria en un almacén de persistencia. Esto se realiza en función de la directiva de persistencia, o a través de una llamada a WorkflowInstance.Unload() o WorkflowInstance.TryUnload().

Transiciones de eventos de instancia de flujo de trabajo

Los eventos de instancia de flujo de trabajo se comunican con el host a través de eventos en tiempo de ejecución de flujo de trabajo y seguimiento de eventos de flujo de trabajo. La aplicación host puede suscribirse a eventos en tiempo de ejecución o usar un servicio de seguimiento para recibir notificaciones. Los eventos Exception y Changed solo se comunican a la aplicación host a través de los servicios de seguimiento. Un evento Exception indica que se produjo una excepción al ejecutar la instancia de flujo de trabajo. Un evento Changed indica que la instancia de flujo de trabajo se actualizó dinámicamente mientras se ejecutaba.

En la figura 3 se muestran las transiciones entre varios eventos de flujo de trabajo y los estados de flujo de trabajo.

.

Figura 3. Transiciones entre los eventos de flujo de trabajo y los estados (haga clic en la imagen para ampliarla)

Si un servicio de persistencia está habilitado, los puntos de persistencia se producen como se muestra en la figura 3. Esas aplicaciones host deben esperar ver los eventos WorkflowPersisted, WorkflowUnloaded y WorkflowLoaded cuando corresponda. Si la instancia de flujo de trabajo no está en memoria y se habilita un servicio de persistencia, las operaciones válidas en la instancia (Reanudar, Anular, Finalizar, etc.) hacen que la instancia de flujo de trabajo se cargue primero y, a continuación, siga cumpliendo la solicitud. Por ejemplo, si tiene una instancia de flujo de trabajo suspendida pero descargada, llamar a Resume en ella hace que se cargue primero y, a continuación, continúe generando el evento Resume como se indica en el diagrama.

Operaciones de instancia de flujo de trabajo

Como se ha explicado anteriormente, la clase WorkflowInstance tiene métodos para controlar el ciclo de vida de la instancia de flujo de trabajo. En esta sección se describen estos métodos.

WorkflowInstance.Start()

Inicia la ejecución de la instancia de flujo de trabajo creada. WorkflowInstance.Start() hace que el tiempo de ejecución del flujo de trabajo genere el evento WorkflowStarted y la instancia de flujo de trabajo esté en estado En ejecución. Se produce una excepción InvalidOperationException si se llama a Start() en una instancia de flujo de trabajo ya iniciada.

WorkflowInstance.Abort()

Anula la instancia de flujo de trabajo. Cuando la anulación se realiza correctamente, el tiempo de ejecución del flujo de trabajo genera el evento WorkflowAborted .

WorkflowInstance.Load()

Carga una instancia de flujo de trabajo descargada desde un almacén de persistencia en la memoria. A continuación, la instancia se programa para su ejecución desde el estado en el que estaba antes de descargarse. Cuando la carga se realiza correctamente, el tiempo de ejecución del flujo de trabajo genera el evento WorkflowLoaded .

WorkflowInstance.Resume()

Reanuda (continúa la ejecución de) una instancia de flujo de trabajo suspendida o anulada. El tiempo de ejecución del flujo de trabajo genera el evento WorkflowResumed justo antes de reanudar la ejecución de la instancia de flujo de trabajo.

WorkflowInstance.Suspend()

Suspende la ejecución de la instancia de flujo de trabajo. Cuando la llamada a WorkflowInstance.Suspend() se realiza correctamente, el tiempo de ejecución del flujo de trabajo genera el evento WorkflowSuspended .

WorkflowInstance.Terminate()

Finaliza la instancia de flujo de trabajo y borra la instancia de flujo de trabajo en memoria. El tiempo de ejecución del flujo de trabajo informa al servicio de persistencia registrado de que la instancia de flujo de trabajo se ha borrado de la memoria. Para SqlWorkflowPersistenceService, esto significa que toda la información de estado de esa instancia de flujo de trabajo se elimina de la base de datos tras la finalización. No se puede volver a cargar la instancia de flujo de trabajo desde un punto de persistencia almacenado anteriormente. Cuando WorkflowInstance.Terminate() se realiza correctamente, el tiempo de ejecución del flujo de trabajo genera el evento WorkflowTerminated .

WorkflowInstance.Unload()

Descarga la instancia de flujo de trabajo desde la memoria al almacén de persistencia. WorkflowInstance.Unload() es sincrónico. Se bloquea hasta que finalice el trabajo programado actualmente o se alcance el final de un ámbito de transacción para realizar la descarga correctamente. Cuando WorkflowInstance.Unload() se realiza correctamente, el tiempo de ejecución del flujo de trabajo genera el evento WorkflowUnloaded . Se produce una excepción InvalidOperationException si se llama a Unload() cuando no hay ningún servicio de persistencia registrado.

WorkflowInstance.TryUnload()

A diferencia de WorkflowInstance.Unload(),WorkflowInstance.TryUnload() no se bloquea hasta que se pueda descargar el flujo de trabajo. WorkflowInstance.TryUnload() descarga la instancia de flujo de trabajo de la memoria en el almacén de persistencia y devuelve true cuando la instancia está suspendida o inactiva. De lo contrario, la llamada devuelve false. Se produce una excepción InvalidOperationException si se llama a TryUnload() cuando no hay ningún servicio de persistencia registrado.

Consulte el SDK de Windows Foundation para obtener más información sobre varios métodos de control en WorkflowInstance.

Capacidad de administración y supervisión

Las aplicaciones que hospedan flujos de trabajo son responsables de administrar y supervisar los flujos de trabajo que hospedan y ejecutan. WF proporciona compatibilidad con diversas herramientas de administración y supervisión. Por ejemplo, WF proporciona un seguimiento de un extremo a otro que puede usar para la depuración de bajo nivel y también para realizar el seguimiento de la infraestructura para la extracción y supervisión de datos de flujo de trabajo.

En esta sección se describe la capacidad de administración y la infraestructura de supervisión en su lugar y cómo usarla en las aplicaciones host.

Seguimiento

WF proporciona una infraestructura de seguimiento para capturar eventos y datos de flujo de trabajo, actividad y usuario mientras se ejecutan instancias de flujo de trabajo. Cualquier instancia de tiempo de ejecución de flujo de trabajo puede tener varios servicios de seguimiento registrados o ninguno. La información de seguimiento se envía a los servicios de seguimiento registrados. Los servicios de seguimiento son responsables de almacenar y procesar esta información según las necesidades de la aplicación host. WF proporciona un servicio de seguimiento basado en SQL (SqlTrackingService) que una aplicación host puede usar. Además, los desarrolladores de aplicaciones host pueden escribir sus propios servicios de seguimiento personalizados y usarlos para aplicaciones host.

Puede usar el seguimiento para examinar el historial de la ejecución de la instancia de flujo de trabajo y determinar el estado actual de las instancias de flujo de trabajo que se ejecutan en el sistema. Además, el seguimiento puede proporcionar información que puede usar junto con la definición de flujo de trabajo para predecir las futuras rutas de ejecución esperadas de las instancias de flujo de trabajo que se ejecutan en el sistema. WF proporciona un ejemplo de aplicación, ejemplo de monitor de flujo de trabajo, que usa sqlTrackingService y los controles del diseñador de flujos de trabajo para mostrar información de estado de flujo de trabajo y actividad sobre los flujos de trabajo completados y actualmente en ejecución.

Para obtener más información sobre la supervisión de flujos de trabajo mediante el seguimiento, consulte la herramienta sdk de Monitor de flujo de trabajo en el ejemplo ejemplos de aplicaciones o monitor de flujo de trabajo. Para obtener ejemplos que muestran cómo crear un servicio de seguimiento personalizado, consulte El servicio de seguimiento de archivos y el ejemplo consoleTrackingServicey el ejemplo de consulta en ejemplos de tecnología/seguimiento. Para obtener ejemplos que muestran cómo usar SqlTrackingService de fábrica, consulte ejemplo de seguimiento simple y consulta mediante sqlTrackingService sample in Technology Samples/Trackingout-of-box.

Seguimiento y seguimiento de un extremo a otro

Puede usar seguimientos para supervisar el estado de la aplicación y aislar y corregir problemas sin alterar un sistema en ejecución. WF usa las API de System.Diagnostics para realizar un seguimiento de la información sobre el tiempo de ejecución del flujo de trabajo y la ejecución de la instancia de flujo de trabajo, incluida la información de evaluación del conjunto de reglas. De forma predeterminada, los seguimientos están desactivados, pero puede activarlos si lo desea.

Además, WF participa en el seguimiento de un extremo a otro. Las funcionalidades de seguimiento de un extremo a otro permiten a los visores de seguimiento ver la información de seguimiento de continuación en varios componentes y las transiciones entre esos componentes. Esto facilita la depuración de un extremo a otro.

Si usa un archivo de configuración de aplicación, debe agregar lo siguiente para habilitar el seguimiento de registros para varios espacios de nombres WF:

<system.diagnostics>
    <switches>
        <add name="System.Workflow LogToTraceListeners" value="1" />
        <add name="System.Workflow.Runtime" value="All" />
        <add name="System.Workflow.Runtime.Hosting" value="All" />
        <add name="System.Workflow.Runtime.Tracking" value="All" />
        <add name="System.Workflow.Activities" value="All" />
        <add name="System.Workflow.Activities.Rules" value="All" />
    </switches>
</system.diagnostics> 

Cuando se usa LogToTraceListeners , WF enumera cada TraceListener que se crea en la aplicación host y envía toda la información de registro a ellos. Las líneas restantes del ejemplo permiten especificar los espacios de nombres para capturar información de registro y también la cantidad de información que se realiza a continuación. Los valores posibles para el atributo value incluyen All, Off, Critical, Error, Warning, Information y Verbose. Consulte el SDK de WF para obtener más información sobre el uso de los atributos de valor.

Eventos en tiempo de ejecución de flujo de trabajo

El tiempo de ejecución genera eventos en tiempo de ejecución y proporciona a la aplicación host los medios para administrar el ciclo de vida de las instancias de flujo de trabajo y de flujo de trabajo. Los controladores de eventos se definen en la clase WorkflowRuntime y la aplicación host debe suscribirse a esos eventos para usarlos.

Los eventos en tiempo de ejecución actúan como un sistema de notificación ligero cuando la aplicación host necesita actuar en un evento específico en lugar de almacenar esos eventos y sus datos asociados con fines de consulta. Para este último, se recomienda usar la infraestructura de seguimiento.

Una instancia de WorkflowRuntime podría estar ejecutando varias instancias de flujo de trabajo; cada instancia de flujo de trabajo tiene su propio ciclo de vida. Por lo tanto, los argumentos de evento para los eventos de instancia de flujo de trabajo contienen el identificador de instancia de flujo de trabajo y otra información. Esta información se puede usar para correlacionar el evento con la instancia de flujo de trabajo que provoca que el tiempo de ejecución del flujo de trabajo genere este evento.

En las secciones siguientes se describen los eventos en tiempo de ejecución de flujo de trabajo disponibles.

WorkflowRuntime.ServiceExceptionNotHandled

Este evento se genera cuando el subproceso propiedad del servicio produce una excepción. Un servicio derivado de la clase WorkflowRuntimeService puede llamar al método RaiseServicesExceptionNotHandledEvent() para informar a los suscriptores del evento ServicesExceptionNotHandled de que se produjo una excepción durante su ejecución y que no pudo controlar esta excepción. Los servicios predefinidos generan este evento en tales condiciones. La aplicación host puede suscribirse a este evento para implementar un mecanismo de recuperación. El argumento de evento asociado a este evento es ServicesExceptionNotHandledEventArgs.

WorkflowRuntime.Started

Este evento se genera cuando se inicia la instancia especificada de WorkflowRuntime . El argumento de evento asociado a este evento es WorkflowRuntimeEventArgs.

WorkflowRuntime.Stopped

Este evento se genera cuando se detiene la instancia especificada de WorkflowRuntime . El argumento de evento asociado a este evento es WorkflowRuntimeEventArgs.

Tabla 1. WorkflowInstanceEvents

Evento	Descripción	Argumento de evento
WorkflowAborted	Se genera cuando se anula la instancia de flujo de trabajo.	WorkflowEventArgs
WorkflowCompleted	Se genera cuando se completa la instancia de flujo de trabajo.	WorkflowCompletedEventArgs
WorkflowCreated	Se genera cuando la instancia de flujo de trabajo se construye completamente, pero antes de que se procesen las actividades; es decir, antes de que el flujo de trabajo empiece a ejecutarse.	WorkflowEventArgs
WorkflowIdled	Se genera cuando la instancia de flujo de trabajo entra en un estado inactivo; es decir, la instancia de flujo de trabajo está esperando un evento externo (por ejemplo, un temporizador, un mensaje, etc.) para continuar la ejecución.	WorkflowEventArgs
WorkflowLoaded	Se genera cuando la instancia de flujo de trabajo se carga en la memoria, normalmente desde un almacén de persistencia.	WorkflowEventArgs
WorkflowPersisted	Se genera cuando se conserva la instancia de flujo de trabajo.	WorkflowEventArgs
WorkflowResumed	Se genera cuando se reanuda la instancia de flujo de trabajo, normalmente desde un estado suspendido o anulado.	WorkflowEventArgs
WorkflowStarted	Se genera cuando la instancia de flujo de trabajo comienza a ejecutarse.	WorkflowEventArgs
WorkflowSuspended	Se genera cuando se suspende la instancia de flujo de trabajo.	WorkflowSuspendedEventArgs
WorkflowTerminated	Se genera cuando finaliza la instancia de flujo de trabajo.	WorkflowTerminatedEventArgs
WorkflowUnloaded	Se genera cuando la instancia de flujo de trabajo se descarga de la memoria en un almacén de persistencia.	WorkflowEventArgs

Consulte la sección "Administrar ciclo de vida del flujo de trabajo" anteriormente en este artículo para obtener más información sobre varios eventos y cómo el flujo de trabajo entra en varios estados.

Consulte los ejemplos del SDK de Windows Workflow Foundation para obtener información sobre cómo usar varios eventos en tiempo de ejecución de flujo de trabajo.

Contadores de rendimiento

Puede supervisar el rendimiento del flujo de trabajo mediante la herramienta de rendimiento de Windows. Se compone de dos partes: Monitor del sistema y Registros de rendimiento y Alertas. Mediante los registros de rendimiento y las alertas, puede configurar contadores de rendimiento para registrar los datos de rendimiento y establecer alertas del sistema para notificarle cuando el valor de un contador especificado está por encima o por debajo de un umbral definido.

WF proporciona un conjunto de contadores de rendimiento con el objeto de rendimiento wf que puede usar para realizar un seguimiento del rendimiento de un flujo de trabajo. Consulte la sección Contadores de rendimiento de flujo de trabajo del SDK de WF para obtener una lista completa de contadores de rendimiento.

Para obtener más información sobre cómo agregar contadores de rendimiento a la herramienta Rendimiento, consulte el sitio web de Microsoft TechNet.

Descargar directiva

Los sistemas podrían tener miles de flujos de trabajo ejecutándose simultáneamente en un momento dado. Puede resultar poco práctico permitir que todos ellos permanezcan en la memoria. Para administrar mejor los recursos de un sistema, puede establecer una directiva de descarga para conservar los estados de flujo de trabajo y descargarlos de la memoria.

WF proporciona una directiva de descarga inactiva si usa el servicio de persistencia estándar. La directiva está activa cuando se establece la propiedad UnloadOnIdle en la clase SqlWorkflowPersistenceService para indicar al motor en tiempo de ejecución que descargue el flujo de trabajo cuando esté inactivo. Si la aplicación host habilita SqlWorkflowPersistenceService a través de un archivo de configuración, puede hacerlo estableciendo la marca UnloadOnIdle en true. Si SqlWorkflowPersistenceService se construye y habilita mediante código, la aplicación host debe construirla mediante el constructor SqlWorkflowPersistenceService (String, Boolean, TimeSpan, TimeSpan). La aplicación host podría implementar otras directivas de descarga complejas.

Además, puede llamar al método WorkflowInstance.Unload() para solicitar descargar esta instancia de flujo de trabajo específica de la memoria y conservar su estado. La aplicación host puede llamar posteriormente al método Load() en las instancias para continuar ejecutándolas desde el último punto de persistencia. Cuando se descargan instancias de flujo de trabajo, se genera un evento en tiempo de ejecución, el evento WorkflowUnloaded .

Confiabilidad y alta disponibilidad

WF admite hosts que eligen ser confiables y de alta disponibilidad al proporcionar compatibilidad con lo siguiente:

Agrupación en clústeres de SQL

Los servicios basados en SQL estándar admiten la instalación de agrupación en clústeres. Los servicios basados en SQL estándar de WF proporcionan reintentos al confirmar el lote en SQL Server. Por lo tanto, admite escenarios de conmutación por error o servidores SQL temporalmente inaccesibles. La lógica de reintento se puede establecer en una combinación de cualquiera de los siguientes servicios:

• DefaultWorkflowCommitWorkBatchService
• SharedConnectionWorkflowCommitWorkBatchService
• SqlTrackingService
• SqlWorkflowPersistenceService

De forma predeterminada, la lógica de reintento es OFF. La aplicación host debe activar explícitamente la lógica de reintento para usar la característica. Las aplicaciones pueden optar por habilitar reintentos por servicio o en todos los servicios mencionados anteriormente. Para ello, establezca la propiedad EnableRetries en las clases de servicios o a través del archivo de configuración. Con un archivo de configuración, la aplicación host puede usar una marca compartida, EnableRetries, para establecer los reintentos habilitados en ON o OFF en todos los servicios afectados. Si la propiedad EnableRetries se establece en un servicio, su valor sobrescribe el valor de marca compartida EnableRetries . Los servicios basados en SQL estándar de WF vuelven a intentarlo durante un número constante de veces. El número de reintentos no es configurable. Sin embargo, las aplicaciones pueden ajustar el tiempo de espera de conexión en la cadena de conexión de los servicios para ajustar parcialmente el tiempo entre reintentos.

Establecer reintentos

En el ejemplo siguiente se muestra cómo establecer EnableRetries para todos los servicios listos para usar agregando un parámetro común, EnableRetries y estableciendo su valor en True. Muestra cómo puede deshabilitar EnableRetries para SqlWorkflowPersistenceService agregando una marca EnableRetries para este servicio y estando establecida en False.

<WorkflowRuntime Name="SampleApplication" UnloadOnIdle="false">
    <CommonParameters>
        <add name="ConnectionString" value="Initial Catalog=WorkflowStore;Data Source=localhost;Integrated Security=SSPI;" />
        <add name="EnableRetries" value="True" />
    </CommonParameters>
    <Services>
        <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, 
System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" EnableRetries="False"  />
    </Services>
</WorkflowRuntime>

Por lo general, se recomienda establecer reintentos en todos los servicios en ON o OFF.

Tenga en cuenta que la clase WorkflowCommitWorkBatchService es responsable de reintentar todas las confirmaciones por lotes relacionadas con las actividades que no son TransactionScopeActivity (puntos de persistencia). La clase WorkflowCommitBatchService no puede realizar reintentos de confirmaciones por lotes de trabajo para las actividades TransactionScopeActivity . Esto se debe a que, en este caso, no inició la transacción y, por lo tanto, no la posee. Los reintentos de confirmaciones por lotes de trabajo para las actividades TransactionScopeActivity deben modelarse en el flujo de trabajo. Esto suele hacerse en forma de bucle while y un controlador de excepciones fuera de TransactionScopeActivity.

Reintenta en sqlTrackingService de fábrica, si se ejecuta en un modo no transaccional y sqlWorkflowPersistenceService no está relacionado con el trabajo relacionado con SQL que no está relacionado con las confirmaciones por lotes de trabajo. Esto incluye la comprobación de temporizadores expirados y la carga de instancias de flujo de trabajo.

Equilibrio de carga y escalado de Front-End

La aplicación que hospeda WF es responsable de administrar escenarios de equilibrio de carga y escenarios de escalado de front-end. WF proporciona compatibilidad con el motor y los servicios basados en SQL de fábrica para permitir que diferentes instancias de aplicación host apunten a la misma persistencia o seguimiento de bases de datos SQL.

Si tiene varias aplicaciones host conectadas al mismo almacén de persistencia, cualquiera de ellas podría cargar cualquier tipo de instancia de flujo de trabajo desde la base de datos. SqlWorkflowPersistenceService no admite la asignación de tipos de flujo de trabajo o instancias que se cargarán en hosts específicos cuando comparten el mismo almacén de persistencia. Debe implementar un servicio de persistencia personalizado si este comportamiento no satisface las necesidades de la aplicación host.

El motor en tiempo de ejecución de WF proporciona semántica de bloqueo para admitir escenarios de escalado de front-end cuando varias aplicaciones host usan el mismo almacén de persistencia. La semántica de bloqueo impide que las aplicaciones carguen una instancia de flujo de trabajo ya cargada por otra aplicación. La clase WorkflowPersistenceService permite admitir esta funcionalidad del motor en tiempo de ejecución de flujo de trabajo proporcionando un parámetro al método SaveWorkflowInstanceState() que especifica si la información de estado de una instancia de flujo de trabajo debe desbloquearse en el almacén de datos y proporcionando el método UnlockWorkflowInstanceState() para desbloquear la información de estado del flujo de trabajo bloqueada anteriormente. En un servicio de persistencia que implementa el bloqueo, una llamada al método LoadWorkflowInstanceState() debe bloquear la información de estado de una instancia de flujo de trabajo.

Consulte las secciones Servicios de persistencia de flujo de trabajo de Windows y Creación de servicios de persistencia personalizados en la Guía de programación de WF para obtener más información sobre la semántica de bloqueo de instancias de flujo de trabajo.

Servicios en tiempo de ejecución base

El motor en tiempo de ejecución de WF ejecuta flujos de trabajo mediante servicios en tiempo de ejecución. El modelo de servicio en tiempo de ejecución proporciona a la aplicación host la flexibilidad de proporcionar varios servicios al motor en tiempo de ejecución de WF. En esta sección se describen los servicios en tiempo de ejecución proporcionados por WF y las implementaciones predeterminadas de esos servicios.

Consulta las secciones Windows Workflow Foundation Services y Desarrollo de Windows Workflow Foundation Services en la Guía de programación de WF para obtener más información sobre las implementaciones del servicio en tiempo de ejecución.

El tiempo de ejecución de WF proporciona cuatro servicios. Estos servicios tienen implementaciones predeterminadas, o bien, las aplicaciones host pueden implementar sus propios servicios y proporcionarlos al entorno de ejecución del flujo de trabajo.

Servicios de transacciones de flujo de trabajo

El propósito de los servicios de transacciones de flujo de trabajo de Windows (WorkflowCommitWorkBatchService) es habilitar la lógica personalizada con respecto al compromiso de los lotes de trabajo (también conocidos como puntos de persistencia). Cuando se confirma un lote de trabajo, el tiempo de ejecución llama al servicio de transacciones actual y pasa un delegado para llamar a para realizar la confirmación real del lote de trabajo. El tiempo de ejecución todavía debe realizar la confirmación, pero permitir que un servicio se inserte en el proceso habilita alguna personalización alrededor del proceso de confirmación.

El marco wf no admite la capacidad de traer su propia transacción desde el exterior a una instancia de flujo de trabajo. Los únicos tipos de transacciones ambientales compatibles con WorkflowCommitWorkBatchService son las transacciones originadas por la instancia de flujo de trabajo. Las transacciones ambientales originadas por la aplicación host que ejecuta el tiempo de ejecución del flujo de trabajo se quitan temporalmente del subproceso actual para reducir sus efectos secundarios. Una vez inactivo el flujo de trabajo, la transacción ambiental original de la aplicación host contenida en se coloca de nuevo en el subproceso.

WF proporciona dos implementaciones de fábrica para los servicios de transacción: DefaultWorkflowCommitWorkBatchService y SharedConnectionWorkflowCommitWorkBatchService.

El motor en tiempo de ejecución de WF requiere un servicio de transacciones de flujo de trabajo. De forma predeterminada, usa DefaultWorkflowCommitWorkBatchService. La aplicación host puede optar por reemplazar DefaultWorkflowSchedulerService por SharedConnectionDefaultWorkflowCommitWorkBatchService o por un servicio personalizado.

DefaultWorkflowCommitWorkBatchService

Cuando se inicia el motor en tiempo de ejecución de flujo de trabajo, se crea una instancia de DefaultWorkflowCommitWorkBatchService y se agrega a WorkflowRuntime si no se agrega ningún otro servicio de transacción. Este servicio crea transacciones de .NET Framework para cada conexión de base de datos. Por ejemplo, las conexiones entre SQL Tracking Services y SQL Persistence Services no se comparten. Puede usar este servicio en los flujos de trabajo para admitir transacciones necesarias para la integridad de los datos.

SharedConnectionWorkflowCommitWorkBatchService

Este servicio se utiliza para las transacciones de la base de datos que utilizan una conexión compartida entre diferentes objetos. Si la aplicación host quiere usar este servicio, debe agregarla a WorkflowRuntime mediante el método AddService o a través del archivo de configuración.

Servicios del programador de flujo de trabajo

Los servicios de Programador de flujo de trabajo administran cómo se programan las instancias de flujo de trabajo mediante el motor en tiempo de ejecución de flujo de trabajo, tanto si se administran en modo asincrónico como en un modo sincrónico manual. WF proporciona dos implementaciones predeterminadas para WorkflowSchedulerService: DefaultWorkflowSchedulerService y ManualWorkflowSchedulerService.

El motor en tiempo de ejecución de WF requiere un servicio de programador de flujo de trabajo para ejecutar flujos de trabajo. De forma predeterminada, usa DefaultWorkflowSchedulerService. La aplicación host puede elegir reemplazar DefaultWorkflowSchedulerService por ManualWorkflowSchedulerService o un servicio personalizado.

DefaultWorkflowSchedulerService

DefaultWorkflowSchedulerService crea y administra los subprocesos que ejecutan instancias de flujo de trabajo de forma asincrónica en el motor en tiempo de ejecución del flujo de trabajo e incluye compatibilidad predeterminada para tener varias instancias de flujo de trabajo en cola en el grupo de subprocesos en tiempo de ejecución. Si no se agrega ninguna otra instancia de servicio del programador de flujo de trabajo a WorkflowRuntime, usa DefaultWorkflowSchedulerService de forma predeterminada.

ManualWorkflowSchedulerService

ManualWorkflowSchedulerService se usa para la ejecución sincrónica de instancias de flujo de trabajo. Si se usa este servicio, las instancias de flujo de trabajo se ejecutan en el subproceso que realiza la llamada desde la aplicación host, lo que bloquea la ejecución de la aplicación host hasta que la instancia de flujo de trabajo deja de estar inactiva.

Servicios de persistencia de flujo de trabajo

Los servicios de persistencia son responsables de almacenar y recuperar (cargar y descargar) el estado de la instancia de flujo de trabajo. WF proporciona una implementación integrada basada en SQL del servicio de persistencia : SqlWorkflowPersistenceService.

SqlWorkflowPersistenceService

Esta implementación integrada almacena la información de estado y temporizador para SQL Server/MSDE. SqlWorkflowPersistenceService participa en las transacciones de flujo de trabajo e implementa el acceso de bloqueo. Además, SqlWorkflowPersistenceService proporciona funcionalidad para habilitar los reintentos cuando el servidor SQL Server no está disponible. Esto se puede controlar estableciendo la propiedad EnableRetries en el servicio. Para obtener más información sobre SqlWorkflowPersistenceService, consulte la Guía de programación de WF.

Servicios de seguimiento de flujo de trabajo

Los servicios de seguimiento administran perfiles de seguimiento y almacenamiento de información de seguimiento. WF proporciona una implementación integrada basada en SQL de un servicio de seguimiento implementado en la clase SqlTrackingService .

SqlTrackingService

Esta implementación almacena los perfiles de seguimiento y los datos en SQL Server/MSDE. El servicio admite lo siguiente:

• Participa en transacciones de flujo de trabajo de forma predeterminada; El comportamiento se controla mediante la propiedad SqlTrackingService.IsTransactional .

• Proporciona un mecanismo para usar perfiles de seguimiento predeterminados para todos los tipos o asociar perfiles de seguimiento por tipos de flujo de trabajo o instancias de flujo de trabajo.

• Admite el mantenimiento de datos proporcionando funcionalidad de creación de particiones dinámicas y a petición.

  En la sección Mantenimiento de datos con SqlTrackingService se proporciona información detallada sobre el mantenimiento de datos en la Guía de programación de WF.

Además, WF proporciona las API sqlTrackingQuery que puede usar para consultar los datos de seguimiento almacenados en SqlTrackingService. Para obtener más información sobre SqlTrackingService, consulte la Guía de programación de WF.

Conclusión

WF proporciona un motor en tiempo de ejecución y servicios para ejecutar flujos de trabajo y administrar su estado. Se debe escribir una aplicación host o un proceso para hospedar flujos de trabajo de WF. Esta aplicación host es responsable de proporcionar varios servicios en tiempo de ejecución al motor en tiempo de ejecución de flujo de trabajo. Los servicios de tiempo de ejecución estándar de WF están diseñados para abordar escenarios comunes. Sin embargo, si los servicios predefinidos no satisfacen las necesidades de la aplicación host, la aplicación host debe implementar servicios personalizados y suministrarlos al tiempo de ejecución del flujo de trabajo.

Además, WF proporciona infraestructura para administrar y supervisar las instancias de flujo de trabajo en ejecución y para admitir aplicaciones host que elijan ser confiables y de alta disponibilidad. Las aplicaciones host deben decidir cómo usar las distintas opciones en función de sus escenarios específicos de hospedaje.

Para obtener más información

Este artículo, junto con los siguientes recursos, debe ayudar a los desarrolladores que no están familiarizados con la tecnología de flujo de trabajo a obtener información sobre la tecnología y a convertirse rápidamente en productivos en su uso.

• Centro para desarrolladores de flujos de trabajo de MSDN
  • Contiene documentos y vínculos a webcasts y laboratorios.
• Ejemplos de sitios de la comunidad
• Documentación de Windows SDK
  • Si no tiene el SDK de Windows Foundation, descárguelo desde el sitio de Windows SDK. Windows Workflow SDK forma parte de Windows SDK. Contiene referencias de la guía de programación de WF, referencias de API y diversos ejemplos de tecnología y aplicación.
• Foro de flujo de trabajo de MSDN
  • Foro de discusión que puede proporcionar respuestas a preguntas relacionadas con el hospedaje en tiempo de ejecución de WF o WF en general.

 

Acerca del autor

Moustafa Khalil Ahmed es administrador de programas con el equipo de WF en Microsoft Corp., Redmond, WA. Desde que se unió a Microsoft en 2000, ha estado trabajando en el desarrollo de varios componentes de servidor y ha ayudado a enviar cuatro productos de servidor, incluido Microsoft BizTalk Server. Antes de trabajar en Microsoft, Moustafa era ingeniero de software, analista de negocios y administrador de cuentas en ITWorx, Cairo, Egipto.