Workflows (flujos de validación)

Workflow

Un workflow es el flujo de validación que tiene que seguir cada entidad o relación de Anjana para quedar con los cambios aplicados en Anjana según la acción que lo haya desencadenado y que pueda ser utilizada por otras estructuras. Estas acciones pueden ser creación de objeto, un cambio de estado, una solicitud de adherencia a un DSA, una modificación de algún atributo…

Para completar un workflow en Anjana es posible contar con tareas de envío de notificaciones, validaciones o evaluación de objetos para permitir bifurcaciones en distintos caminos dentro del mismo workflow.

Variables a evaluar

En los workflows configurados en Anjana es posible comprobar el valor de ciertos parámetros para poder configurar bifurcaciones en ellos.

Estos parámetros son:

• Cualquier atributo de la plantilla del objeto qué está siendo validado. Hay dos formas de hacer esta comparativa:

  • Comparación del atributo booleano con name=’pi’, ${pi == 'true'}

  • Comparación del atributo de reference metadata con name=’data_sensitivity’, ${execution.getVariable('data_sensitivity') != 'Confidential' || execution.getVariable('data_sensitivity') == null}

IS_VERSION: si el workflow es de versionado (cadena de caracteres así que es ‘true’ en caso de versionado y ‘false’ en caso de modificación). Un ejemplo de comparación es: ${ IS_VERSION == 'true'}

ORIGINAL_OBJECT_ID: identificador interno del objeto original en caso de que el workflow sea de versionado (número entero). Un ejemplo de comparación es: ${ ORIGINAL_OBJECT_ID >= 10} y ${ORIGINAL_OBJECT_ID < 10}

OBJECT_ID: identificador interno de Anjana para el objeto (número entero). Un ejemplo de comparación es: ${ OBJECT_ID >= 1}

OBJECT_NAME: nombre del objeto (cadena de caracteres). Un ejemplo de comparación es: ${ OBJECT_NAME == "Clientes"} y ${ OBJECT_NAME != "Clientes"}

OBJECT_SUB_TYPE: nombre del subtipo del objeto (cadena de caracteres). Un ejemplo de comparación es: ${OBJECT_SUB_TYPE == 'DATASET'} y ${OBJECT_SUB_TYPE != 'DATASET'}

OBJECT_TYPE: ENTITY o RELATIONSHIP (cadena de caracteres). Un ejemplo de comparación es: ${OBJECT_TYPE == 'ENTITY'} y ${OBJECT_TYPE != 'ENTITY'}

SOURCE_TYPE y DESTINATION_TYPE: nombre del subtipo de entidad de origen o del destino de una relación (cadena de caracteres). Un ejemplo de comparación es: ${SOURCE_TYPE == 'DATASET'} y ${DESTINATION != 'DATASET'}

ORGANIZATIONAL_UNIT: una o dos unidades organizativas a las que pertenece el objeto (una en caso de entidad y dos en caso de relación, por sus dos extremos) (lista de valores). Un ejemplo de comparación es: ${execution.getVariable("ORGANIZATIONAL_UNIT").contains("HQ/Legal")} y ${!execution.getVariable("ORGANIZATIONAL_UNIT").contains("HQ/Legal")}

ROLE_NAME: rol del usuario que lanza el workflow (cadena de caracteres). Un ejemplo de comparación es: ${ROLE_NAME== 'data_owner'} y ${ROLE_NAME != 'data_owner'}

SENDER_USER: usuario nominal que lanza el workflow (cadena de caracteres). Un ejemplo de comparación es: ${ SENDER_USER == 'maria.gonzalez'} y ${ SENDER_USER != 'maria.gonzalez'}

ACCEPTED: aprobación del usuario a la validación (cadena de caracteres así que es ‘true’ en caso de aprobación y ‘false’ de rechazo). Un ejemplo de comparación es: ${ACCEPTED == 'true'} y ${ACCEPTED == 'false'}

WORKFLOW_TYPE: tipo de workflow a ejecutar (valores posibles: ‘CREATE’, 'MODIFY’, ‘ACTIVATE’, ‘DEACTIVATE’, ‘TRANSFER’, ‘DEPRECATE’, ‘ADHERENCE’, ‘DISADHERENCE’, ‘RENAME’). Un ejemplo de comparación es: ${WORKFLOW_TYPE == 'CREATE'} y ${WORKFLOW_TYPE != 'CREATE'}

Opciones para configurar un workflow

Es posible configurar workflows en Anjana de dos formas:

Desde el panel de administración, en el apartado de BPM, desde donde se accede al editor de workflows: http://{{hostname}}/configpanel/bpmn-manager/edit

Creando directamente el xml para Activiti

A continuación se exponen ambas opciones.

Panel de administración

Funciones

En el front de administración están disponibles las siguientes opciones:

• Open → Permite importar un workflow previamente creado a través de su xml.

• Save as → Guarda el workflow configurado desde el editor de workflow. Esta opción permite guardar el xml o imagen en el Filesystem o desplegarlo en Anjana para poder usarlo. La extensión del fichero a guardar debe ser “.bpmn20.xml”.

  • Al crear una carpeta se deben tener en cuenta las convenciones de Amazon ( Buckets naming rules), la más importante siendo que no se permiten nombres de menos de 3 caracteres

  • Es recomendable que el id y el nombre usados para el workflow sean el mismo para evitar errores en la configuración

  • Es necesario que la clave del workflow sea única

• New → Abre una pizarra desde donde se puede configurar un nuevo workflow

• Validate → Valida la corrección del workflow configurado. Solamente aparecerán cuando el workflow se haya guardado a través de la API.

• Deploy → Despliega el workflow para poderlo lanzar desde Anjana. Solamente aparecerán cuando el workflow se haya guardado a través de la API.

Editor de workflows

Será el entorno de trabajo desde donde se creará un workflow, donde estarán las herramientas necesarias para incluir las acciones y flujos que formarán la estructura del workflow.

Introducción

La manera más sencilla de empezar un workflow es incluyendo en la pizarra el inicio y final del workflow para, a partir de ahí, ir incluyendo los elementos necesarios para formar el flujo de trabajo.

Elementos

Los elementos que se pueden añadir en un workflow, entre el inicio y el final aparecen a la izquierda de la pizarra de workflow.

Estos elementos son:

StartEvent

Inicio del workflow, necesario para el correcto funcionamiento del workflow.

Intermediate/Boundary Event

Se encargan de realizar las funciones de ‘listener’, son eventos que no se pueden lanzar, se activan automáticamente cuando detectan un cierto tipo de disparador, de esa manera el workflow se interrumpe y se sigue el flujo de secuencia que sale del evento.

EndEvent

Final del workflow, necesario para el correcto funcionamiento del workflow.

Sequence Flow

Son las líneas que unen los distintos elementos, pueden ser de dos tipos:

Condicionales → Se tiene que cumplir una condición para que pase el flujo de ejecución al siguiente elemento, como por ejemplo, que el usuario valide como OK la task.

Incondicionales → Siempre pasan al siguiente elemento del flujo de ejecución.

Gateway

Se usa para diversificar el flujo de ejecución del workflow, permite realizar tareas en paralelo.

Task

Tarea individual dentro del workflow, se pueden clasificar en diferentes tipos dependiendo de :

• Su función :

  • User → Necesaria la acción de un usuario para continuar el flujo.

Manual → Es una tarea externa al flujo interno del motor BPM, por tanto, no se conoce el proceso que realiza internamente, solo se controla su estado para saber si ha terminado.

Business Rule → Se usa para ejecutar de manera síncrona una o más reglas definidas por el cliente. Actualmente Activiti usa archivos .drl para incluir dichas reglas.

Service → Lanzan la ejecución de una clase java, dicha clase puede realizar funciones diversas, para Anjana se han creado las siguientes:

SendNotificationJavaDelegate → Envía una notificación que previamente debe de estar creada en la tabla notification del schema hermes en el modelo de datos de Anjana. Para configurar esta task, sólo es necesario incluir el código de la notificación que se desea enviar en el apartado ‘Field Injections’. El uso de este componente como notificación para validación queda deprecado y se eliminará en la siguiente versión.

Se recomienda fusionar con la validación del rol en una task de usuario configurándose de la siguiente forma. El uso de esta tarea para notificar validaciones de usuario está deprecado.

• LastExecutionJavaDelegate → Se usa para que Anjana realice los últimos procesos al finalizar un workflow. Es necesario llamar a esta tarea siempre antes de terminar el workflow, tanto si el resultado es OK como KO.

• CancelTaskWorkflowJavaDelegate → Cuando uno de los validadores no aprueba el workflow el flujo debe de pasar por esta task para indicar a Activiti que el proceso ha sido cancelado.

Script → Cuando el flujo del workflow llega a dicha tarea se ejecuta el script.

Expanded SubProcess → Sirve para agrupar diferentes task, se suele usar cuando el resultado se quiere que dependa de todas las task que están agrupadas dentro del subproceso.

Call Activity → Es un tipo de subproceso que agrupa varias task pero este tipo de subproceso puede ser llamado desde diferentes partes del flujo del workflow.

• Su ejecución :

  • En paralelo → El proceso de varias task se puede realizar en paralelo.

Secuencial → El flujo no puede avanzar hasta que se realice la task.

Loop → La tarea se ejecutará n veces.

DataObjectReference → Activiti permite definir data object como parte de un proceso o subproceso. De esta manera se pueden incluir estructuras XML complejas que se pueden importar desde XSD.

DataStorage Reference → Se pueden incluir referencias dentro del flujo del workflow a una base de datos.

• Pool/Participant → Permite crear otra pizarra de workflow.

• Group → Permite agrupar diferentes pizarras de workflows.

Acciones

Change Type → Permite cambiar el tipo del elemento.

Delete → Borra el elemento.

Connect using Sequence/MessageFlow or Association → Permite unir elementos entre sí.

Append Text Annotation → Sirve para incluir notas a un elemento.