Volver é

 Nota de Interés: 

  Workflow: 2da. Parte: Modelando Workflow                                                                                                                           Volver é

A pesar de la gran variedad de productos de Workflow que se encuentran en el mercado, se puede ver que los conceptos y terminologías utilizadas no varían en gran forma. Esto permite que se tienda a realizar un modelo de implementación general.

Actualmente se busca identificar los principales componentes de un sistema de Workflow, de modo tal de poder volcarlos dentro de un mismo modelo abstracto. Es necesaria la representación formal de un modelo que permita la realización de sistemas sobre diversos escenarios, de forma tal de tener la posibilidad que distintos sistemas de Workflow puedan interactuar entre sí.

4.2. Conceptos manejados para modelar el Workflow

Cuando se modela un sistema de Workflow generalmente se identifican y utilizan definiciones de los distintos elementos que se pueden encontrar dentro de dicho sistema. A continuación listamos estos elementos, para luego dar una descripción o definición de cada uno de ellos.

• Tareas.

• Personas (Usuarios).

• Roles.

• Rutas.

• Reglas de Transición.

• Datos.

• Eventos.

• Plazos (Deadlines).

• Procesos.

• Políticas.

• Tareas

Cada tarea es un conjunto de acciones o actividades manejadas como una sola unidad. Generalmente son desempeñadas por una única persona dentro de los roles que pueden realizar dicha tarea. Las tareas surgen del análisis del flujo del trabajo, donde se define por quienes deben ser ejecutadas

• Personas (Usuarios)

Las tareas son realizadas en un orden definido por determinadas personas (o agentes automatizados tomando el rol de las personas) basados sobre las condiciones o reglas del negocio.

• Roles

Cada rol define las distintas competencias potenciales que existen en el sistema. Se definen independientemente de las personas físicas a las cuales se les van a asignar dichos roles. Una persona puede tener más de un rol.

• Rutas

Una ruta define la secuencia de pasos a seguir por los documentos (o información) dentro de un sistema de Workflow. La capacidad de rutear las tareas a usuarios remotos u ocasionales es vital en una aplicación de Workflow. Para asegurar el éxito del flujo de información y decisiones, todos los miembros del equipo deben ser capaces de tomar parte en este proceso.

Se distinguen varios tipos de rutas:

• Rutas Fijas:

En este caso los documentos siguen siempre el mismo camino. Se define de antemano cual es la próxima etapa a seguir.

• Rutas Condicionales:

El camino a seguir depende de la evaluación de condiciones. Estas decisiones se toman en el mismo momento que se pasa por el punto donde hay que evaluar las condiciones.

• Rutas Ad Hoc:

En este caso el usuario elige explícitamente cual es la siguiente etapa a seguir.

Construcción de Rutas:

• AND-Split:

A partir de un lugar fuente, los documentos son distribuidos hacia varios destinos simultáneamente.

          --> Destino 1

Origen --> Destino 2

          --> Destino n

• AND-Join:

A partir de varios lugares fuentes, los documentos convergen, sincrónicamente, hacia un único destino.

Origen 1 -->

Origen 2 --> Destino

Origen n -->

• OR-Split:

A partir de un lugar origen, los documentos toman un destino entre varios posibles.

               Destino 1

Origen --> Destino 2

               Destino n

• OR-Join:

A partir de uno o más lugares de origen, dentro de varios posibles, convergen hacia un único destino (no se requiere sincronización).

Origen 1 -->

                  |-->Destino

Origen 2 -->

Origen n

• Loop:

En este caso se forma un circuito cerrado dentro del camino que recorren los documentos.

Origen   <---->   Destino

• Reglas de Transición

Son reglas lógicas que determinan la navegación del documento dentro del sistema. Expresan que acción se va a tomar dependiendo del valor de expresiones lógicas. La definición de las regla puede ser muy complicada, con múltiples opciones, variaciones, y excepciones. 

Un ejemplo sencillo podría ser el siguiente: Un cliente solicita un préstamo por $ 1000, entonces la siguiente regla expresa el camino a seguir sobre la base de la solicitud: "SI la cantidad solicitada es mayor que el tope del cliente ENTONCES enviar la solicitud al supervisor del área, SINO, entregar el dinero". La regla anterior muestra, de manera sencilla, el tipo de reglas que comúnmente se expresan.

• Datos

Los datos son los documentos, archivos, imágenes, registros de la Base de Datos, y otros utilizados como información para llevar a cabo el trabajo. Entre los datos manejados por el Workflow encontramos:

• Datos de Control:

Son los datos internos manejados por la lógica del sistema de Workflow.

• Datos Relevantes:

Son aquellos datos utilizados para determinar el ruteo de las distintas tareas del sistema.

• Datos de la Aplicación:

Estos datos son específicos de la aplicación, no son accedidos por la lógica del Workflow.

La noción de documento como recipiente de información que se transmite de una tarea a otra, es muy utilizada. Por esto, cuando nos refiramos a datos manejados por el sistema, los nombraremos por documentos.

Existen ciertas propiedades que se le pueden asociar a un documento, como ser: la definición de los derechos de acceso a los mismos; las vistas definidas sobre ellos; el permitir manejar los accesos concurrentes (o sea, que dos personas o procesos puedan acceder al documento simultáneamente); también se pueden definir formas de relacionar datos provenientes de fuentes externas al documento, como ser, datos de la aplicación o de la Base de Datos.

• Eventos

Un evento es una interrupción que contiene información, el mismo tiene un origen y uno o más destinatarios. La información contenida en el mensaje que se produjo por el evento puede ser implícita o dada por el usuario. Los eventos pueden ser disparados voluntariamente por el usuario; o en forma implícita durante un proceso según el estado de los datos o de decisiones tomadas por el usuario; o en forma automática. Por ejemplo, cuando un gerente de un banco hace una consulta sobre ciertos datos para hacer una auditoria, se dispara un evento que le devuelve la información de dicha consulta.

• Plazos (Deadlines)

Podemos ver a los plazos como los tiempos que se le asignan a ciertos elementos.

Ejemplos de plazos pueden ser: el tiempo máximo que se le asigna a una tarea para que sea terminada; el tiempo máximo para recorrer una ruta; terminar una tarea antes de cierta fecha; terminar el recorrido de una ruta antes de cierta fecha; y así podríamos seguir. 

A los plazos podemos asignarles eventos, de forma tal de que cuando venza determinado plazo se disparen ciertos eventos asignados por el usuario, o programados para que se disparen automáticamente.

• Procesos

Anteriormente definimos lo que son los procesos de empresas, pero cabe acotar que estos procesos son tan variados y personalizados, como la gente que toma parte en ellos.

Comúnmente los procesos no son "diseñados", sino que son identificados en la realidad, por el uso diario que se les da. "Nosotros siempre lo hemos hecho así" es una expresión común que se identifica al momento de evaluar estos procesos. Es común que se piense en poner todos los procesos dentro de una aplicación, pero suele ocurrir que sólo algunos de ellos compongan la aplicación final.

• Políticas

Las políticas son una manera formal de expresar sentencias de cómo serán manejados ciertos procesos. Por ejemplo, todas las empresas tienen políticas de licencias vacacionales y beneficios para sus empleados, y podrían definir además como se manejarán los distintos procesos de empresa que la componen.

A continuación se muestra un ejemplo donde se identifican algunos de los elementos explicados en los puntos anteriores:

Ejemplo

Proceso de solicitud de compra de algún producto en una empresa. 

Solicitud de compra de algún producto en una empresa. Esta solicitud ingresa al sistema vía teléfono. En él se pueden identificar las tareas que comprenden el proceso, ruta por la cual fluye la solicitud, reglas de transición entre las tareas, así como también usuarios, roles y eventos.

Las tareas son las que están representadas por rectángulos con una descripción asociada dentro de los rectángulos.

El diagrama está dividido en tres partes, cada una de las partes identifica las tareas realizadas por el rol que corresponde. Los roles que identificamos son: el empleado de atención al público, la sección de ventas y el empacador. Observar que el rol de empacador puede asociarse a una persona en particular y que el rol de sección de ventas no necesariamente identifica a una persona.

Vemos como el evento asociado al ingreso de una solicitud de compra por teléfono hace que se dispare todo un proceso donde la solicitud de compra va recorriendo ciertas rutas según las condiciones que se van dando. Las reglas de transición se identifican por rombos con una condición asociada. Según el valor de estas condiciones la solicitud de compra toma uno u otro camino. Una de las rutas más sencillas que se pueden identificar es cuando existe producto en stock para el producto de la solicitud de compra, luego de lo cual se pasa a facturar y finalmente se empaca y se envía.

En un producto de software de Workflow genérico se identifican una serie de componentes e interfaces. La implementación de esta estructura puede ser realizada de varias formas diferentes entre sí. Éste es un punto de desencuentro de los productos existentes.

En los puntos que siguen a continuación explicaremos los diferentes modelos de implementación en forma genérica. Previamente se dará una descripción de las principales componentes de un sistema de Workflow genérico.

Las principales componentes de un sistema genérico de Workflow son:

• De software: Proveen soporte para gran cantidad de funciones del sistema de Workflow.

• Datos y Definición de procesos: Usados por los componentes de software.

• Aplicaciones externas.

Los elementos más importantes:

• Herramienta de Definición de Procesos.

Forma parte de las componentes de software del Workflow. Es utilizada para crear una descripción de los procesos en una forma procesable para una computadora. Esta herramienta podría estar basada en un lenguaje de definición de procesos formal, en un modelo de interacción entre objetos, o simplemente en un conjunto de reglas de ruteo para transferir información entre los participantes.

Esta herramienta puede ser proporcionada como parte de un producto de software orientado a Workflow, o podría simplemente existir por si sola y tener integración con diferentes productos de Workflow.

• Definición de Procesos.

La Definición de Procesos, forma parte de los datos del Workflow. Contiene, toda la información necesaria acerca de los procesos, incluye información de comienzo de actividades, condiciones, y reglas de navegación. Podría tener referencias a la definición de roles, donde se almacena información de la estructura organizacional. Esto quiere decir que en la definición de procesos se puede mencionar que en cierto proceso participa cierto rol, el cual esta definido en la definición de roles.

• Workflow Enactment Service

Esta componente interpreta la descripción de procesos y controla las diferentes instancias de los procesos, secuencia de actividades, adiciona ítems (elementos) a la lista de trabajo de los usuarios (Worklist), e invoca aplicaciones necesarias. Todas estas tareas son hechas por uno o más motores de Workflow (engines), los cuales manejan la ejecución de las distintas instancias de varios procesos.

• Worklist (lista de trabajo)

La Worklist forma parte de los datos del Workflow. Ya que la interacción con los usuarios es necesaria en algunos casos, el motor de Workflow utiliza una worklist manejada por un manejador de worklist para controlar tal interacción. El motor deposita en la worklist ítems ha ser ejecutados para cada usuario. La worklist puede ser visible o invisible para los usuarios depende del caso, muchas veces se deja que el usuario seleccione ítems y los procese en forma individual.

• Manejador de Worklist

Es un componente de software el cual maneja la interacción entre los participantes del Workflow y el Workflow enactment service, vía la worklist. El manejador soporta en general un amplio rango de interacción con otras aplicaciones clientes. En algunos sistemas, la interfase con el usuario y el manejador de Worklist, están agrupadas como una única entidad funcional.

El Workflow Enactment Software consiste de uno o más Motores (engines) de Workflow, los cuales son responsables del manejo de toda, o parte, de la ejecución de las instancias de los procesos.

Este software puede ser implementado como un sistema centralizado con un único motor de Workflow, responsable del manejo de todas las ejecuciones de procesos que existen en el sistema. La otra alternativa es una implementación como un sistema distribuido, en la cual varios motores cooperan, la complejidad es mucho mayor pero en general redunda en mayores beneficios.

En el escenario distribuido varios motores cooperan en la ejecución de una instancia de un proceso, el control de datos asociado al proceso debe tener la capacidad de dialogar con diferentes motores. Este control de datos podría estar distribuido entre los motores o podría estar en un único motor (Motor maestro). El control de datos mantiene el estado de la información asociada a cada proceso, podría tener también checkpoints para ser usados en caso de fallas.

La definición de procesos, es usada para modelar la navegación entre los procesos, provee información acerca de entradas a procesos y criterios a tomar en cada paso de la navegación, asigna tareas a usuarios, asigna aplicaciones a cada actividad, etc. La definición de procesos también podría realizarse en forma distribuida o centralizada. La implementación de la opción distribuida implica una gran complejidad al establecer la relación entre la definición de procesos y los motores.

En el modelo de Workflow existe interacción entre el manejador de la worklist y un motor en particular. Recordamos que una worklist es una cola de tareas asignadas a un usuario en particular (o posiblemente un grupo de usuarios), la asignación es echa por el Workflow Enactment Service. Hay varias implementaciones para la interacción con la worklist, dependiendo principalmente del tipo de infraestructura utilizada para soportar la distribución del manejador de la worklist.

• Modelo local: La comunicación entre el motor y el manejador de la worklist es vía una interfase local. En este caso la interfase con el usuario podría ser vía una terminal local o una workstation remota.

• Archivos de almacenamiento compartido: El manejador de la worklist es implementado en el cliente y la comunicación con el motor es vía archivos compartidos.

• Modelo de correo electrónico: La comunicación es vía correo electrónico.

• Llamado a procedimientos remotos (RPC) o pasaje de mensajes: En este escenario la worklist podría estar físicamente en el motor o en el manejador de la worklist dependiendo de las características particulares de la implementación.

La WFMC es una agrupación compuesta por compañías, vendedores, organizaciones de usuarios, y consultores. El objetivo de esta agrupación es ofrecer una forma de "diálogo" común a todos. De esta forma las diferentes herramientas que se implementen en esta área podrán tener cierto nivel de interoperabilidad, es decir, podrán comunicarse entre ellas para poder realizar las distintas tareas involucradas en un sistema de Workflow.

Se estima que actualmente los distintos productos de Workflow que hay en el mercado sobrepasan los cien. Cada uno de ellos se enfoca sobre distintos aspectos funcionales, como ser, herramientas de diseño visual, en las cuales se ofrecen ciertos diagramas para representar la realidad. Otras se enfocan en la integración de los datos con las aplicaciones.

El desarrollo de estándares para la interoperabilidad de las diversas herramientas, nos permitiría la elección de los mejores productos, según el enfoque que le demos a nuestra aplicación. Por ejemplo, podríamos comprar una herramienta que nos ofrezca un entorno amigable para realizar el análisis y diseño de nuestro problema, y por otro lado comprar una componente que nos resuelva la auditoria de los datos y poder trabajar en forma integrada con las dos componentes.

Una de las estrategias que siguen actualmente las empresas, es rediseñar sus procesos, esta metodología es denominada como Reingeniería de los Procesos de Empresas (Business Process Re-engineering). Esto puede ser causa de cambios organizacionales, legislativos, cambios en los objetivos del negocio, etc. En esta situación, muchas veces es necesario relacionarse con otras organizaciones. Pero para poder hacer esto debe existir la posibilidad de que los productos de un vendedor puedan comunicarse con los de otro, pues es claro que cada empresa u organización comprará los productos que crea conveniente para su caso.

Vemos entonces la necesidad de estandarizar la forma de comunicación entre los distintos componentes de un producto de Workflow. De modo de poder tener flexibilidad a la hora de operar con distintos productos. Esta necesidad se justifica además por las proyecciones que se tienen actualmente, sobre la penetración de la tecnología de Workflow en el mercado en los próximos años. Por esto se debe atacar el problema de potenciales incompatibilidades de antemano, y no cuando existan miles de productos en esta área, cada uno con sus particularidades.

El modelo de referencia de Workflow fue desarrollado desde estructuras genéricas de aplicaciones de Workflow, identificando las interfaces con estas estructuras, de forma de permitir a los productos comunicarse a distintos niveles. Todos los sistemas de Workflow contienen componentes genéricas que interactúan de forma definida. Para poder tener cierto nivel de interoperabilidad entre los diversos productos de Workflow, es necesario definir un conjunto de interfaces y formatos para el intercambio de datos entre dichas componentes.

En la figura siguiente se muestra las distintas interfaces y componentes que se pueden encontrar en la arquitectura del Workflow.

En el modelo adoptado hay una separación entre los procesos y el control de la lógica de las actividades. Esta lógica esta dentro de lo que ya definimos como el Workflow Enactment Service. Esta separación permite la integración de las diversas herramientas con una aplicación particular.

La interacción del Enactment Service con los recursos externos se da por una de las dos interfaces siguientes:

• La interface de las Aplicaciones de los Clientes, a través de la cual el Motor de Workflow interactúa con el manejador de la Worklist, responsable de organizar el trabajo por intermedio de un recurso de usuario. Es responsabilidad del manejador del Worklist elegir y hacer progresar cada elemento de la lista de trabajo (Worklist).

• La interface de las Aplicaciones Invocadas, la cual le permite al motor de Workflow activar una herramienta para realizar una actividad particular. Esta interface podría ser basada en un servidor, es decir no existe la interacción con el usuario.

Hasta ahora hemos visto al Enactment Service como una entidad lógica, pero físicamente éste podría estar centralizado o funcionalmente distribuido.

En un Enactment Service distribuido, distintos motores de Workflow controlan una parte del proceso e interactúan con un subconjunto de usuarios y herramientas relacionadas con las

Es el software que provee el control del ambiente de ejecución de una instancia de Workflow.

Típicamente dicho software provee facilidades para:

• Interpretación de la definición de procesos.

• Control de las instancias de los procesos: creación, activación, terminación, etc.

• Navegación entre actividades.

• Soporte de interacción con el usuario.

• Pasaje de datos al usuario o a aplicaciones.

• Invocación de aplicaciones externas.

Podemos encontrar Workflow Enactment Services homogéneos, los cuales están constituidos por uno o más motores de Workflow compatibles. Estos proveen un ambiente de ejecución, con un conjunto definido (especifico del producto) de atributos en la definición del proceso. La interacción entre estos motores no está estandarizada, o sea, es especifica de los productos.

Se pueden encontrar también, Workflow Enactment Services heterogéneos, que están constituidos de uno o más servicios homogéneos, los cuales siguen un estándar para la interoperabilidad entre los mismos.

Se ofrecen distintos niveles de conformidad en cuanto a la estandarización. La interoperabilidad de los distintos productos depende del nivel de conformidad. Como se dijo anteriormente, tenemos distintos motores de Workflow controlando una parte del proceso e interactuando con otros motores en un dominio de trabajo distinto. Se espera que los siguientes puntos estén entre los niveles de conformidad de los productos para poder soportar la interacción de los diversos motores:

• Se debe tener un esquema de nominación común a través de motores heterogéneos.

• Se debe soportar un proceso de definición común para los objetos y atributos, de manera que los diversos motores puedan acceder a ellos.

• Se debe soportar la transferencia de los datos relevantes del Workflow, a través de los motores.

• Se debe soportar la transferencia de procesos, sub-procesos o actividades entre los distintos motores de Workflow.

• Se debe soportar funciones de administración y monitoreo comunes, dentro de un dominio de motores de Workflow.

El Workflow Enactment Service podría ser considerado como una máquina de estados, donde los procesos cambian de estados según eventos externos, o decisiones de control especificas, tomadas internamente por el motor de Workflow.

Los procesos están constituidos por diversas actividades. La culminación de las actividades que constituyen un proceso, implica la culminación del mismo.

Los estados básicos dentro de un esquema de transición para la instancia de un proceso son:

• Iniciado: Ha sido creada una instancia del proceso, pero no se han dado las condiciones para su comienzo.

• Corriendo: Se comenzó la ejecución del proceso, y cualquiera de sus actividades podría comenzar.

• Activo: Una o más actividades del proceso comenzaron.

• Suspendido: Se suspende la ejecución del proceso.

• Completado: El proceso culminó, se realizan las acciones programadas (auditoria) y luego se elimina la instancia del proceso.

• Terminado: No se pudo terminar normalmente la ejecución del proceso.

Cuando se crea una instancia de un proceso, se crean a su vez instancias para las actividades que forman parte de ese proceso.

Ignorando ciertas complejidades como por ejemplo la atomicidad de las actividades, se puede hacer un diagrama de estados básico para una instancia de una actividad:

En este caso los estados básicos son:

• Inactivo: La actividad dentro de la instancia del proceso ha sido creada pero no ha sido activada y no tiene ningún elemento (Workitem) para procesar.

• Activo: Un Workitem ha sido creado y asignado a la instancia para su procesamiento.

• Suspendido: Se suspende la ejecución de la instancia de la actividad. A la misma no se le asigna un Workitem hasta que no vuelve al estado Inactivo.

• Completado: La ejecución de la instancia de la actividad ha sido terminada normalmente.

Las WAPI pueden ser vistas como un conjunto de llamadas API (Application Programming Interface) y funciones de intercambio soportadas por el Workflow Enactment Service. Las APIs son un conjunto de llamadas a funciones de software que permiten a las aplicaciones acceder a funciones de un programa. Las WAPI permiten la interacción del Workflow Enactment Service con otros recursos y aplicaciones.

El Workflow Enactment Service mantiene el control interno de los datos, identificando el estado de un proceso o de las instancias de las actividades y eventualmente podría soportar algún estado interno más. Estos datos no están accesibles, pero se puede obtener cierta información en respuesta de ciertos comandos (por ejemplo consultar los estados de los procesos, obtener métricas, etc.). Estos datos son los que utiliza el motor de Workflow para mantener el control de las diversas instancias de los procesos. Los datos relevantes son aquellos que son usados por el motor de Workflow para determinar los estados de transición de una instancia de un proceso.

La manipulación de datos desde una aplicación puede ser requerida por alguna actividad en la definición de un proceso. Estos datos son específicos de la aplicación y no son accesibles por el motor de Workflow.

El intercambio de datos relevantes y datos de las aplicaciones es requerido a través de las WAPI para soportar la interacción de las tres funcionalidades siguientes en tiempo de ejecución:

• Manejador de la Worklist (interface 2)

• Aplicaciones Invocadas (interface 3)

• Intercambio entre los motores de Workflow (interface 4)

El intercambio directo de los datos de las aplicaciones es tipificado por sistemas de Workflow orientados al mail electrónico, en donde los datos son físicamente transferidos entre las actividades. En este caso no es necesario definir una relación explícita entre las actividades y la aplicación. En algunos casos es necesario proveer la conversión del formato de los datos entre las actividades. En este caso, la aplicación puede definir, como un atributo, el tipo de datos con el cual esta asociado el formato de los datos. Esto le permite a los sistemas de Workflow heterogéneos proveer la conversión de los datos sobre la base del tipo de datos de los mismos.

En el caso de un sistema de Workflow implementado por intermedio de documentos compartidos, no hay transferencia física de datos entre las actividades. En este tipo de sistema, los datos son accedidos in situ por la aplicación, usando la ruta de acceso apropiada. Las direcciones de los documentos deben mantenerse como variables globales en el sistema, de forma tal que los distintos servicios o motores puedan acceder a ellos. La conversión de datos puede ser modelada usando herramientas apropiadas para ello (por ejemplo un procesador de texto). Los sistemas homogéneos pueden usar convenciones privadas para el nombrado de los objetos y para el acceso a permisos; pero en sistemas heterogéneos se requiere de un esquema común.

Herramientas de definición de procesos.

Hay gran variedad de herramientas utilizadas para el análisis de procesos. Tales herramientas pueden variar desde las más informales (lápiz y papel), a las más formales y sofisticadas.

La salida de este proceso de modelización y diseño es una "definición de procesos" la cual pueda ser interpretada en runtime por el o los motor(es) de Workflow.

Existe gran cantidad de herramientas de definición de procesos (independientes de los productos en muchos casos), las cuales deben comunicarse con los motores de algún producto de Workflow, lo deseable es que esta herramienta pueda comunicarse con cualquier motor, esto únicamente sería posible si se establecen ciertas normas de comunicación entre las herramientas de definición de procesos y un motor de Workflow. Por esto la WFMC propone una interface para esta comunicación.

El objetivo de la interface es dar un formato de intercambio y llamadas a APIs (Application Programming Interface), para soportar el intercambio de información de definición de procesos. El intercambio podría ser una completa definición de los procesos o un subconjunto de la misma. En la figura se muestra la composición de la definición de procesos.

En el modelo planteado la interacción entre las aplicaciones clientes y el motor de Workflow esta sostenido en gran parte por el concepto de Worklist ya descrito anteriormente.

Parte de la información almacenada en la worklist es utilizada para trasmitirle al manejador de la worklist que aplicaciones hay que invocar.

La worklist podría contener items relacionados con diferentes instancias de un proceso o items de diferentes procesos. El manejador de la worklist podría estar interactuando con diferentes motores. La interface entre una aplicación cliente de Workflow y el motor de Workflow debe ser lo suficientemente flexible en los siguientes puntos:

• Identificadores de procesos y actividades.

• Estructuras de datos.

• Diferentes alternativas de comunicación.

El siguiente diagrama muestra el alcance de esta interface, la cual esta pensada para interactuar con agentes de una aplicación, o con una aplicación entera propiamente dicha.

Dichas aplicaciones deben estar orientadas con el contexto general de un sistema de Workflow, es decir, deben poder interactuar directamente con el motor de Workflow.

La aplicación invocada es manejada localmente por un motor de Workflow, usando la información suministrada en la definición del proceso para identificar la naturaleza de la actividad, el tipo de aplicación a ser invocada y los requerimientos de los datos. La aplicación que se invoca puede ser local al motor de Workflow, o sea, residente en la misma plataforma, o estar en otra plataforma dentro de una red. En este caso la definición del proceso debe contener la información necesaria para poder encontrar la aplicación que se va a invocar (como ser la dirección dentro de la red).

Los detalles semánticos y sintácticos de esta interface se pueden encontrar en el documento elaborado por la WFMC, donde se especifica en forma detallada esta interface.

Workflow Enactment Services Heterogéneos

El trabajo de la WFMC se ha enfocado en desarrollar varios escenarios de interoperabilidad.

La idea de estos escenarios es poder operar en diferentes niveles, desde las tareas más simples hasta las aplicaciones de Workflow con un nivel alto de interoperabilidad, con un intercambio completo de la definición de procesos, los datos relevantes y una vista común de esto entre los distintos ambientes de Workflow.

Se han identificado cuatro modelos posibles de interoperabilidad. A continuación se describen estos modelos. En las ilustraciones se usan cuadrados para representar las tareas o actividades; y con distintos sombreados para denotar las tareas coordinadas por Workflow Enactment Services individuales.

Este modelo permite a un punto de conexión del proceso A conectarse con otro punto en el proceso B. Los puntos de conexión pueden estar en cualquier parte de los procesos donde tenga sentido establecerla.

Este modelo soporta la transferencia de un único elemento de trabajo (una instancia del proceso o actividad) entre los dos ambientes de Workflow, el cual opera independientemente en el segundo ambiente sin sincronización adicional.

En este caso se le permite a un proceso ejecutado en un dominio de Workflow particular, ser completamente encapsulado como una única tarea, dentro de un proceso (superior) ejecutado en un dominio diferente. Existe una relación jerárquica entre el proceso y el proceso encapsulado, el cual es un subproceso del superior. La relación jerárquica puede ser extendida a través de distintos niveles, formando un conjunto de sub-procesos anidados.

La recursión en este escenario puede, o no, ser permitida por cada producto particular.

Este modelo le permite a dos procesos operar independientemente, posiblemente a través de Workflow Enactment Services distintos. Pero requiere que existan puntos de sincronización entre los procesos. Esto implica que una vez que los procesos alcanzan un punto predefinido dentro de su secuencia de ejecución se genere un evento común.

La sincronización puede ser utilizada como proceso de planificación de la ejecución en paralelo de procesos, además de la transferencia de los datos relevantes del Workflow entre las diversas instancias de los procesos.

Este modelo permite un ambiente completamente mezclado. 

En este escenario, el proceso puede progresar transparentemente de tarea a tarea, sin ninguna acción especifica de los usuarios o administradores, con interacciones entre los motores de Workflow cuando es necesario.

Este escenario requiere que ambos motores de Workflow soporten un conjunto común de APIs para la comunicación y para que ambos puedan interpretar una definición de procesos común. Ya sea que esta definición haya sido importada a ambos ambientes desde una herramienta de definición común, o que sea exportada entre los motores durante la fase de ejecución. Los datos de la aplicación y los datos relevantes del Workflow también deben ser pasados entre varios motores.

La figura siguiente muestra la forma general del intercambio y control de flujo entre sistemas de Workflow heterogéneos.

Hay dos grandes aspectos para la necesidad de la interoperabilidad:

• El alcance en el que la interpretación común de la definición de procesos es necesaria y que pueda ser realizada.

• Soporte en tiempo de ejecución para el intercambio de varios tipos de información de control y para la transferencia de los datos relevantes del Workflow y/o de las aplicaciones, entre los distintos enactment services.

Donde ambos enactment services pueden interpretar una definición de proceso común, por ejemplo generado con una misma herramienta, esto le permite a ambos ambientes compartir una única vista de la definición de los procesos y sus atributos. Esto permite, potencialmente, a cada motor de Workflow transferir la ejecución de actividades o subprocesos a un conjunto heterogéneo de motores de Workflow dentro del mismo contexto.

Este método es aplicable en el escenario 4 descripto anteriormente, donde distintos sistemas cooperan al mismo nivel, aunque puede también ser empleado en escenarios más simples.

En el caso en que no sea posible tener una vista común, un método alternativo podría ser exportar los detalles de un subconjunto de la definición de procesos, como parte del intercambio que se hace en tiempo de ejecución.

Ahora, si los dos casos anteriores no son factibles, la interoperabilidad se restringe al método de gateway. En el cual (típicamente un subconjunto de) nombres de objetos y atributos son mapeados entre los dos ambientes por medio de una aplicación que interactúa mediante gateway. En el caso más simple, los dos enactment services por separado usan su propio formato para la definición de procesos y existe algún tipo de mapeo entre los dos, manejado por un gateway. Este método podría encajar en escenarios simples del tipo 1 y 2 o algunos ejemplos triviales del escenario 3.

En tiempo de ejecución, los llamados a las WAPI son usados para transferir el control entre los motores de Workflow para representar sub-procesos o actividades individuales sobre un motor especifico. En el caso en que ambos motores soporten un nivel común de llamados a las WAPI y tengan una vista común de los objetos de la definición de procesos, la transferencia puede ser realizada directamente entre los motores de Workflow.

Pero en el caso en que no se pueda tener lo anterior, los llamados a las WAPI pueden ser usados para construir una función de gateway que permita la interacción entre distintos motores, mapeando los diferentes objetos y vistas de datos entre ellos. 

Una vez que las actividades comienzan a representarse sobre distintos (subordinado) motores, la interacción de las aplicaciones Workflow de los clientes con los motores originales (por ejemplo para consultar los estados de las actividades) puede necesitar "referenciar" al motor subordinado. Algunas operaciones pueden necesitar ser encadenadas a través de distintos motores. Son necesarios eventos de notificación del estado de las actividades y su terminación, para que el usuario tenga el conocimiento de cómo se desarrollan las actividades.

El propósito de esta interface es permitir una vista completa del estado del flujo de trabajo, además de poder realizar auditorias sobre los datos del sistema. El diagrama de más abajo ilustra como una aplicación de administración independiente, interactúa con los distintos dominios del Workflow. Es posible implementar otros posibles escenarios, como por ejemplo tener la aplicación de administración y monitoreo dentro del propio enactment services.

Fuente: www.WilliDev.net  

Volver é

 Resumen del Boletín Oficial (Temas de Salud): 2da. quincena - Abril 2004         Volver é

APE_3490-04