BPM

Overview

FlowerDocs embarque le moteur BPM Camunda (version 7.13). Il permet la gestion de workflows métiers ou techniques initiés à partir d’événements internes, par API ou à date.

Ce moteur permet le support des standards suivants :

Architecture

Le moteur Camunda est intégré pleinement à l’application FlowerDocs Core. Il est exécuté au sein de la même JVM.


Camunda s’appuie sur une base de données relationnelle pour stocker les données manipulées.

Dans le cadre de l’intégration avec FlowerDocs, les bases de données supportées sont :

  • PostgreSQL 9.4 / 9.6 / 10.4 / 10.7 / 11.1 / 11.2
  • Amazon Aurora PostgreSQL compatible with PostgreSQL 9.6 / 10.4 / 10.7

Les autres bases de données supportées par le moteur sont listées ici et peuvent être utilisées en ajoutant le driver JDBC approprié dans le classpath de la JVM de FlowerDocs Core (installation sur site seulement).

Isolation par scope

L’intégration forte de Camunda permet une isolation des données par scope. Pour cela, FlowerDocs Core s’appuie sur la notion de tenant fournie par le moteur pour isoler les données d’un scope vis à vis d’un autre.

La base de données est mutualisée entre les différentes scopes gérés par FlowerDocs où chaque ligne contient l’identifiant du scope. L’isolation est ainsi assurée applicativement pour :

  • les définitions (processus, cases et décisions)
  • les instances de processus et tâches associées
  • l’API Rest exposée

Déploiement

Une définition de processus peut être déployée dans le moteur en ajoutant un document de classe BPMNDiagram.

Les tâches

Les types de tâches supportés du standard BPMN 2.0 sont listés dans cette section.

Les tâches utilisateurs

Une User Task est une tâche d’un processus qui implique un utilisateur. Ce type permet de modéliser une action devant être effecutée par un utilisateur.

Une User Task peut être traitée directement à partir de l’interface graphique FlowerDocs lorsqu’elle possède un paramètre classId.


Pour ce type de tâche, des informations supplémentaires peuvent être définies :

  • Assignee : l’identifiant de l’utilisateur auquel assigner la tâche
  • ACL : l’identifiant de l’ACL afin de définir la sécurité de la tâche (si aucune ACL n’est définie, celle définie au niveau de sa classe est utilisée)
  • GroupCandidate :

Les tâches de type service

Une Service Task permet l’invocation de code Java depuis un processus. Elle permet d’exécuter un Java Delegate précisé à l’aide de l’attribut camunda:delegateExpression avec une valeur du type ${delegateName}.

FlowerDocs fournit un ensemble de Java Delegate permettant de profiter des différentes fonctionnalités depuis un processus. Ils sont listés dans une section suivante de la documentation.

Les tâches de type script

Une Script Task est définie à partir d’un script et d’un language de script. L’intégration de Camunda dans FlowerDocs Core supporte uniquement le format javascript. Le moteur Nahsorn est utilisé pour exécuter les scripts au sein de la JVM. La syntaxe Javascript et des classes Java chargées dans la JVM peuvent ainsi être utilisées pour ajouter de la logique spécifique au sein d’un processus.

Pour des questions de sécurité, un chargeur de classes spécifique est utilisé pour exécuter les scripts dans la JVM. Certaines classes ne peuvent donc pas être utilisées depuis ce type de tâche. Ce mécanisme peut être désactivé à l’aide de la propriété secured.classloader.enabled=false. Au besoin certaines classes ou packages peuvent être définis comme sécurisés à l’aide de la propriété secured.classloader.whitelist.additional.

Des nouvelles variables peuvent ainsi être calculées à partir des données du processus. La variable retournée par un script peut être mise à disposition au niveau de l’exécution du processus en définissant son nom grâce l’attribut camunda:resultVariable.


<bpmn2:scriptTask id="Task_1nisf8b" name="Format date" scriptFormat="javascript" camunda:resultVariable="date">
    <bpmn2:script>
    var date = new java.util.Date(java.lang.Long.parseLong("0"));
    var simpleDateFormat = new java.text.SimpleDateFormat("dd/MM/yyyy");
    simpleDateFormat.format(date); 
    </bpmn2:script>
</bpmn2:scriptTask>

<bpmn2:scriptTask id="Task_1nisf8a" name="Initiate case" scriptFormat="javascript" camunda:resultVariable="folder">
    <bpmn2:script>
    var builder = com.flower.docs.common.component.ComponentBuilder; 
    var Category = com.flower.docs.domain.component.Category; 
    builder.component(Category.fromValue('FOLDER')).name('myFolder').classId('Folder').build();
    </bpmn2:script>
</bpmn2:scriptTask>


Plus de détails peuvent être consultés sur la documentation Camunda.

Les tâches de type règle métier

Une tâche Business Rule Task exécute un ensemble de règles grâce au moteur de décision supportant le standard DMN 1.1. Ce type de tâche requiert l’identifiant d’une définition d’un diagramme DMN.

Plus de détails sur l’exécution de table de décisions peuvent être consultés dans la section dédiée.

Enchaînements

Les différentes étapes sont reliées entre elles grâce à différents éléments permettant le déroulement d’un processus.

Les transitions

Une transition (ou sequence flow) permet de passer d’une étape à une autre. Ces transitions peuvent être conditionnées par les variables du processus. Typiquement les transitions, en sortie d’une User Task, peuvent être conditionnées par la réponse sélectionnée par un utilisateur.

Les gateways

Les gateways contrôlent les enchaînements entre différents sequence flows.

Les parallel gateways permettent de joindre plusieurs branches parallèles fusionnant automatiquement les tâches des différentes branches. L’ensemble des tags, pièces jointes et participants sont ainsi récupérés en sortie de la gateway.

Fin d’un processus

La fin d’un processus est déterminée par le déclenchement d’un événement de fin (ou End Event). Lors d’une fin de processus, il est possible de déclencher la génération d’une empreinte du processus. L’empreinte générée permet de stocker de manière figée les informations à conserver d’un processus.

Pour plus détail sur les empreintes de processus, consultez la documentation du JavaDelegate concerné.

Le moteur de décision embarqué dans FlowerDocs permet d’externaliser les règles de gestion d’une application. Le moteur exécute des tables de décision et des Decision Requirements Diagrams pour déterminer une ou plusieurs sorties.

Une table de décision est composée de différents élements dont :

  • Inputs : les colonnes qui définissent les conditions d’application d’une règle
  • Outputs : les colonnes déterminant les valeurs obtenues lorsqu’une règle s’applique
  • Hit policy : la manière dont sont exécutées les différentes règles


Plus de détails sur les tables de décision peuvent être consultés sur la documentation officielle.

Exemple d'une table de décision
Exemple d'une table de décision

Ces tables de décision peuvent être exécutées depuis un processus ou bien à l’aide de l’API Rest :



curl -X POST '{{core}}/rest/process/decision-definition/key/routing/evaluate' \
-H 'token: <token>' \
-H 'Content-Type: application/json' \
-d '{
    "variables": {
        "type": {
            "value": "Facture",
            "type": "String"
        }
    }
}'

$.ajax({
    type: 'POST',
    url: './plugins/rest/process/decision-definition/key/routing/evaluate',
    data: '{"variables": {"type": {"value": "Facture", "type": "String"}}}',
    contentType: "application/json",
    success: function(result) { console.info('result: ' + JSON.stringify(result)); }
});
Tous
Connecteurs

Tous
Delegates