Configuration
Configuration
Breadcrumbs

Workflows (Validation Flows)

Workflow

A workflow is the validation flow that each entity or relationship in Anjana must follow in order to have the changes applied in Anjana according to the action that triggered it, so that it can be used by other structures. These actions can be object creation, a status change, a request for adherence to a DSA, a modification of some attribute…

To complete a workflow in Anjana it is possible to include notification sending tasks, validations or object evaluation tasks to allow branching into different paths within the same workflow.

Variables to evaluate

In the workflows configured in Anjana it is possible to check the value of certain parameters in order to configure branches within them.

These parameters are:

  • Any attribute of the template of the object being validated. There are two ways to make this comparison:

    • Comparison of the boolean attribute with name=’pi’, ${pi == 'true'}

    • Comparison of the reference metadata attribute with name=’data_sensitivity’, ${execution.getVariable('data_sensitivity') != 'Confidential' || execution.getVariable('data_sensitivity') == null}


IS_VERSION: whether the workflow is for versioning (string, so it is ‘true’ in the case of versioning and ‘false’ in the case of modification). An example comparison is: ${ IS_VERSION == 'true'}

ORIGINAL_OBJECT_ID: internal identifier of the original object in case the workflow is for versioning (integer). An example comparison is: ${ ORIGINAL_OBJECT_ID >= 10} y ${ORIGINAL_OBJECT_ID < 10}

OBJECT_ID: internal Anjana identifier for the object (integer). An example comparison is: ${ OBJECT_ID >= 1}

OBJECT_NAME: name of the object (string). An example comparison is: ${ OBJECT_NAME == "Clientes"} y ${ OBJECT_NAME != "Clientes"}

OBJECT_SUB_TYPE: name of the subtype of the object (string). An example comparison is: ${OBJECT_SUB_TYPE == 'DATASET'} y ${OBJECT_SUB_TYPE != 'DATASET'}

OBJECT_TYPE: ENTITY or RELATIONSHIP (string). An example comparison is: ${OBJECT_TYPE == 'ENTITY'} y ${OBJECT_TYPE != 'ENTITY'}

SOURCE_TYPE and DESTINATION_TYPE: name of the entity subtype of the source or the destination of a relationship (string). An example comparison is: ${SOURCE_TYPE == 'DATASET'} y ${DESTINATION != 'DATASET'}

ORGANIZATIONAL_UNIT: one or two organizational units to which the object belongs (one in the case of an entity and two in the case of a relationship, due to its two endpoints) (list of values). An example comparison is: ${execution.getVariable("ORGANIZATIONAL_UNIT").contains("HQ/Legal")} y ${!execution.getVariable("ORGANIZATIONAL_UNIT").contains("HQ/Legal")}

ROLE_NAME: role of the user who launches the workflow (string). An example comparison is: ${ROLE_NAME== 'data_owner'} y ${ROLE_NAME != 'data_owner'}

SENDER_USER: nominal user who launches the workflow (string). An example comparison is: ${ SENDER_USER == 'maria.gonzalez'} y ${ SENDER_USER != 'maria.gonzalez'}

ACCEPTED: user approval of the validation (string, so it is ‘true’ in the case of approval and ‘false’ for rejection). An example comparison is: ${ACCEPTED == 'true'} y ${ACCEPTED == 'false'}

WORKFLOW_TYPE: type of workflow to execute (possible values: ‘CREATE’, 'MODIFY’, ‘ACTIVATE’, ‘DEACTIVATE’, ‘TRANSFER’, ‘DEPRECATE’, ‘ADHERENCE’, ‘DISADHERENCE’, ‘RENAME’). An example comparison is: ${WORKFLOW_TYPE == 'CREATE'} y ${WORKFLOW_TYPE != 'CREATE'}

Options for configuring a workflow

It is possible to configure workflows in Anjana in two ways:

From the administration panel, in the BPM section, from where the workflow editor is accessed: http://{{hostname}}/configpanel/bpmn-manager/edit

att_71_for_171999858.png


By directly creating the xml for Activiti.

Both options are described below.


Administration panel

Functions

The following options are available in the administration front-end:

  • Open → Allows importing a previously created workflow through its xml.

  • Save as → Saves the workflow configured from the workflow editor. This option allows saving the xml or image to the Filesystem or deploying it in Anjana to be used. The extension of the file to be saved must be “.bpmn20.xml”.

    • When creating a folder, Amazon naming conventions must be taken into account (Buckets naming rules), the most important being that names shorter than 3 characters are not allowed

    • It is recommended that the id and name used for the workflow be the same to avoid configuration errors

    • The workflow key must be unique

  • New → Opens a canvas from where a new workflow can be configured

  • Validate → Validates the correctness of the configured workflow. They will only appear when the workflow has been saved through the API.

  • Deploy → Deploys the workflow so it can be launched from Anjana. They will only appear when the workflow has been saved through the API.

Workflow editor

This will be the working environment from which a workflow is created, where the necessary tools will be available to include the actions and flows that will form the workflow structure.


Introduction

The easiest way to start a workflow is by including in the canvas the start and end of the workflow, and from there, adding the necessary elements to form the workflow.

att_72_for_171999858.png

Elements

The elements that can be added in a workflow, between the start and the end, appear on the left side of the workflow canvas.

att_1_for_171999858.png

These elements are:

StartEvent

Start of the workflow, required for the correct functioning of the workflow.

att_2_for_171999858.png
Intermediate/Boundary Event

They are responsible for performing ‘listener’ functions; they are events that cannot be triggered manually, they activate automatically when they detect a certain type of trigger, at which point the workflow is interrupted and the sequence flow coming out of the event is followed.

att_3_for_171999858.png
EndEvent

End of the workflow, required for the correct functioning of the workflow.

att_4_for_171999858.png
Sequence Flow

These are the lines that connect the different elements; they can be of two types:

Conditional → A condition must be met for the execution flow to pass to the next element, such as, for example, the user validating the task as OK.

att_5_for_171999858.png

Unconditional → Always pass to the next element in the execution flow.

att_6_for_171999858.png
Gateway

Used to diversify the execution flow of the workflow, allowing tasks to be performed in parallel.

att_7_for_171999858.png
Task

Individual task within the workflow, they can be classified into different types depending on:

Their function:

  • User → Requires the action of a user to continue the flow.

att_8_for_171999858.png

  • Manual → It is a task external to the internal flow of the BPM engine; therefore, the process it performs internally is not known, only its status is monitored to determine whether it has finished.

att_9_for_171999858.png

  • Business Rule → Used to synchronously execute one or more rules defined by the client. Currently Activiti uses .drl files to include these rules.

att_10_for_171999858.png

  • Service → They trigger the execution of a Java class; this class can perform various functions. For Anjana the following have been created:

att_11_for_171999858.png

SendNotificationJavaDelegate → Sends a notification that must have been previously created in the Notifications table of the Configuration Panel. To configure this task, it is only necessary to include the notification code to be sent in the ‘Field Injections’ section. This component is not the only option for sending notifications, as they can also be embedded in User Tasks.


att_12_for_171999858.png


When notifications are related to user tasks, it is recommended to merge them with the role validation in a user task configured as follows.

att_62_for_171999858.png

LastExecutionJavaDelegate → Used for Anjana to perform the last processes at the end of a workflow. It is necessary to call this task always before ending the workflow, whether the result is OK or KO.

CancelTaskWorkflowJavaDelegate → When one of the validators does not approve the workflow, the flow must pass through this task to indicate to Activiti that the process has been cancelled.

  • Script → When the workflow flow reaches this task, the script is executed.

att_13_for_171999858.png

  • Expanded SubProcess → Used to group different tasks; it is typically used when the result is intended to depend on all the tasks grouped within the subprocess.

att_14_for_171999858.png

  • Call Activity → It is a type of subprocess that groups several tasks, but this type of subprocess can be called from different parts of the workflow flow.

att_15_for_171999858.png

Their execution:

  • In parallel → The processing of several tasks can be done in parallel.

att_16_for_171999858.png

  • Sequential → The flow cannot advance until the task is completed.

att_17_for_171999858.png

  • Loop → The task will be executed n times.

att_18_for_171999858.png

DataObjectReference → Activiti allows data objects to be defined as part of a process or subprocess. In this way, complex XML structures can be included that can be imported from XSD.

att_19_for_171999858.png

DataStorage Reference → References to a database can be included within the workflow flow.

att_20_for_171999858.png

Pool/Participant → Allows creating another workflow canvas.

Group → Allows grouping different workflow canvases.


Actions

Change Type → Allows changing the type of the element.

att_21_for_171999858.png

Delete → Deletes the element.

att_22_for_171999858.png

Connect using Sequence/MessageFlow or Association → Allows connecting elements to each other.

att_23_for_171999858.png

Append Text Annotation → Used to add notes to an element.

att_24_for_171999858.png