Pattern 1 (Sequence)

_______________________________________________________________________

<process-definition
xmlns=”urn:jbpm.org:jpdl-3.1″
name=”simple”>
<start-state name=”start”>
<transition name=”to_state” to=”first”>
<action name=”action” class=”com.sample.action.MessageActionHandler”>
<message>Going to the first state!</message>
</action>
</transition>
</start-state>
<state name=”first”>
<transition name=”to_end” to=”end”>
<action name=”action” class=”com.sample.action.MessageActionHandler”>
<message>About to finish!</message>
</action>
</transition>
</state>
<end-state name=”end”></end-state>
</process-definition>

_______________________________________________________________________

public class SimpleProcessTest extends TestCase {

// Pattern １：Sequence

public void testSimpleProcess() throws Exception {

FileInputStream fis = new FileInputStream(“processes/simple/processdefinition.xml“);
ProcessDefinition processDefinition = ProcessDefinition.parseXmlInputStream(fis);

processInstance instance = new ProcessInstance(processDefinition);
assertEquals(“start state”,instance.getRootToken().getNode().getName(), “start”);

instance.signal();
assertEquals(“first state”,instance.getRootToken().getNode().getName(), “first”);

instance.signal();
assertEquals(“Instance is in end state”,instance.getRootToken().getNode().getName(), “end”);
assertTrue(“Instance has ended”, instance.hasEnded());
}
}

Viene de un blog de workflows que acabo de encontrar por Wordpress…

Para explicar por que son importantes los patrones, os redirecciono a una publicación de Rodrigo Corral en su blog que lo explica como nadie.

Arquitectos y modistas

Aalst clasifica los patrones en cuatro grandes ramas:

• Data Patterns : Estos patrones representan los posibles métodos de intercambio de datos entre los procesos
• Resource Patterns : Estos patrones representan la manera en la cual las fuentes (resources) externas deben ser dirigidos.
• Control-Flow Patterns : Estos patrones representan los posibles flujos en un workflow.
• Exception Handling Patterns : Estos partones representan las diferentes formas de manejar posibles excepciones.

Y para cada uno de ellos tiene su bonito artículo publicado :

• Workflow Data Patterns
• Workflow Resource Patterns
• Workflow Control-Flow Patterns, a revised view
• Exception Handling Patterns in Process-Aware Information Systems

Para mas información podeis ir a la página web del mismo Aalst

Un Workflow define acciones, ya estén hechas por seres humanos como por sistemas informáticos, y transiciones entre estas para definir el flujo que un proceso sigue.

Un Workflow puede ser visto como un autómata finito en el que los nodos representan las acciones y las arcos representan las transiciones. Sin embargo, los Workflows son capaces de representar patrones cuya complejidad no es representable en autómatas finitos.

Patrones tales como paralelización y sincronización de procesos no son directamente representables en este tipo de marcos teóricos. Los Workflows, tradicionalmente, vienen siendo utilizados para el modelado de procesos de negocios y a su coordinación. Sin embargo, nuevas aplicaciones pueden aprovecharse de estas técnicas; como por ejemplo, sistemas formales de guiado del cuidado del paciente, como pueden ser las vías clínicas, o sistemas de guiado del tráfico vehicular en las grandes ciudades.

Un Workflow no sólo está pensado para representar flujos de procesos, sino que también es posible interpretarlos para permitir el guiado automático de los procesos para que tanto personal humano como los sistemas informáticos, estén coordinados en la ejecución de los flujos de los procesos. Se conoce como Sistema de Gestión de Workflow (o Motor de Workflow) a los sistemas ideados para interpretar y automatizar Workflows. La automatización de un Workflow consiste en la interpretación de un Workflow para ejecutar sus acciones de forma ordenada tal y como vienen especificadas en este. La mayoría de los modelos comerciales de representación de procesos de negocio que se encuentran en el mercado cuentan con herramientas de ejecución de estos Workflows que permiten cierta interoperabilidad para facilitar la integración de los modelos de Workflow con los sistemas ya existentes.

Especificar un Workflow es equivalente a implementar un programa en un alto nivel, utilizando para ello librerías y lenguajes de especificación complejos que permiten no solo la automatización del proceso, sino también la posibilidad de saber en que punto del proceso estamos, e incluso cambiar el flujo de ejecución de una instancia del Workflow dinamicamente.

Actualmente existen multitud de sistemas de interpretación de Workflows disponibles tanto comerciales como de código libre. Normalmente los motores de Workflow van ligados a los lenguajes de representación, aunque existen excepciones como BPEL que es un estandar de representación sin motor oficial asociado. Comercialmente el estándar BPEL o BPEL4WS es el que actualmente está teniendo más auge debido a que está indicado para la ejecución de orquestación de Web Services para la creación de aplicaciones B2B (Bussiness to Business). Por otro lado, comercialmente existen marcos de programación para la creación e interpretación de Workflows como la Windows Workflow Foundations desarrollado por Microsoft y el jBPM desarrollado por Sun. Sin embargo, la expresividad de estos modelos se ve limitada, ya que estos modelos no cumplen muchos de los patrones de Van der Aalst, que son una importante herramienta de validación de lenguajes de especificación de Workflows.

Además, todos estos modelos suelen resultar muy pesados y requieren potentes ordenadores para funcionar. Como proyecto Open Source, YAWL es un lenguaje definido y diseñado específicamente para cumplir los patrones de Workflow de Aalst basado en Redes de Petri. Sin Embargo, uno de los problemas de implementación de YAWL son algunas limitaciones que ha sido necesario realizar en el modelo de interpretación para la implementación de Workflows.

Según los autores de YAWL ha sido necesario limitar la implementación del lenguaje en algunos aspectos, ya que la ejecución de Redes de Petri de alto nivel es complicada debido su complejidad. Además, a pesar de ser un modelo altamente expresivo, su mayor desventaja es que su definición gráfica está basada en Redes de Petri que tienen menos legibilidad, por lo que este modelo está teniendo un uso muy minoritario. Por otro lado, otra de las desventajas de los sistemas actuales de ejecución de Workflows es que no generan logs suficientemente potentes para ser utilizados por el Workflow Mining basado en Actividades, por lo que limitan la posibilidad de inferencia de Workflows utilizando estas técnicas inductivas.

]]> http://www.workflowsworld.com/2008/05/introduccion/feed/ 0 http://www.workflowsworld.com/2008/05/organiza-tu-vida-con-un-workflow/ http://www.workflowsworld.com/2008/05/organiza-tu-vida-con-un-workflow/#comments Tue, 13 May 2008 16:05:02 +0000 CarlosSM http://carlossm.wordpress.com/?p=3 “Automatización de un proceso de negocio, en su totalidad o en parte, cuando documentos, información o tareas se pasan de un actor a otro para realizar una acción, de acuerdo con una serie de reglas de procedimiento”

WfMC – Workflow Management Coalition Terminology Glossary

Si… eso de dibujar cuadraditos, flechitas y tal…

…