Panorama des moteurs BPM/workflow open source

Dans cet article nous allons dresser un panorama du domaine BPM (Business Process Management) : les enjeux, les normes et les acteurs, en privilégiant les solutions open source. Après un premier tour d’horizon, nous comparerons certaines de ces solutions d’après une mise en oeuvre pratique. Il s’agira workhospitality.com.au ici de dégager une première impression, l’article et le comparatif ne se voulant pas exhaustifs et étant implicitement guidés par nos besoins d’intégration à la plate-forme Improve Foundations.

Historique et solutions

Les solutions BPM, précédemment limitées au contexte BI, et donc à des applications types basées sur l’affectation de tâches, s’étendent aujourd’hui à d’autres domaines pour lesquels la notion de process est identifiable. Mais surtout, elles s’intègrent à des offres plus larges, comportant ESB et portails.

On distingue deux approches parmi ces solutions :

  • celles orientées développeur, avec un accès privilégié aux fonctionnalités du moteur BPM par programmation
  • celles orientées utilisateur fonctionnel, avec un accès limité au runtime et l’utilisation d’éditeurs propriétaires pour la définition et la gestion des processus.

Dans les deux cas, des applications dédiée sont buy Windows 7 Ultimate SP1 souvent proposées pour administrer les tâches créées par le moteur de workflow, cependant on préférera généralement bazoesoft.com l’intégration directe dans une application métier (utilisation de formulaires personnalisés définis par cette application cible).

La solution open source de référence était jusqu’à présent jBPM de JBoss, dont les créateurs originaux sont cependant partis pour lancer une nouvelle solution, Activiti. La version jBPM5 est donc davantage une nouvelle branche, jBPM4 étant lui directement à la base d’Activti. A travers la nouvelle version de jBPM, JBoss tente de se différencier en promouvant l’intérêt de l’intégration de sa solution avec un moteur de règles (Drools), arguant qu’une solution BPM sans cette fonctionnalité n’est pas concevable. S’ensuit une compétition sur plusieurs forums de discussion, dont celui-ci est représentatif :

http://salaboy.com/2011/01/19/jbpm5-vs-activiti5-dumb-question/#more-1534

Bonita, initialement développé par Bull et à présent proposé par la nouvelle société Bonita Soft, est logiquement à mi chemin entre open source et commercial, préférant contraindre à utiliser ses éditeurs graphiques (qui gèrent jusqu’à la création des formulaires) et limiter l’accès libre au runtime, afin d’inciter à l’utilisation de compléments qui ne sont pas en open source.

Enfin on trouve des solutions dont l’orientation est plus fortement commerciale, comme Intalio, dont la version gratuite community edition est particulièrement limitée. Une telle solution est finalement plus élégante que Bonita, mais chère comparée à Activiti et jBPM (à noter que JBoss cherche à intégrer jBPM à son offre de services globale, payante).

Comme elles représentent déjà un panel assez varié, nous nous sommes contentés d’évaluer ces 4 solutions, même s’il en existe d’autres : Orchestra du consortium OW2, équivalent d’Activiti mais orienté principalement vers le serveur Jonas, Enhydra Shark, plus limité dans sa version community (gratuite, LGPL) et proposé avec des extensions et outils supplémentaires dans une version payante buy Windows 7 Professional SP1 par Together (se positionne commercialement entre Bonita et Intalio), et enfin Process Maker, en licence GPL et technologie PHP.

Notion de tâche

Un worklow BPM est basé sur deux types de tâches :

  • des tâches automatiques : elles sont déclenchées lors du parcours de transitions du workflow (celui-ci peut comporter des conditions et des branchements – exécutions en parallèles et jonctions). Les étapes consistent typiquement en l’appel de services métiers. Elles correspondent au principe d’un automate.
  • des tâches utilisateur : il s’agit d’étapes nécessitant une action d’un utilisateur (soumission d’informations, choix). Ces étapes suspendent donc l’exécution (ou une branche) du workflow. Elles sont adaptées aux applications utilisant la notion de corbeille de tâches (réponse asynchrone).

Afin d’implémenter les tâches utilisateur, les moteurs de workflow sont souvent associés à un ESB, afin de disposer directement de connecteurs asynchrones.

Normes et standards

Le domaine BPM/workflow est basé sur des standards pour la définition de processus, d’enchaînement de processus et pour l’expression de tâches utilisateur (user tasks) :

BPMN : langage de description de processus (uniquement leur exécution). Les outils étudiés gèrent la norme BPMN 2.0.

BPEL : langage issu de WSFL (Web Services Flow Language) et XLANG permettant de décrire l’enchaînement de services asynchrones, ici des webservices dont les actions issues de leur WSDL sont liées aux processus.

XPDL : format défini par le Workflow Management Coalition (WfMC) afin d’échanger des définitions de processus/workflow (à la fois description de l’exécution et description graphique des diagrammes contrairement à BPEL).

WS-Human Task : norme pour la définition des tâches utilisateur.

PVM (Process Virtual Machine) définit un moteur de workflow indépendant du langage de description

L’idée derrière PVM est de permettre le choix d’un DSL (Domain Specific Language, langage adapté à une problématique particulière) pour chaque aspect (description de processus, description de navigation, mapping O/R, règles, grammaires).

Comparatif

Les informations issues des sites des projets et de divers forums utilisateurs permettent une première analyse, théorique, qui devra être confirmée par la pratique :

De ces informations ont peut tirer la synthèse suivante  :

Notes : 1 (très limité), 2 (limité), 3 (moyen), 4 (bon), 5 (excellent)

Activiti, bien que récent, capitalise sur l’expérience acquise avec les versions précédentes de jBPM. Il bénéficie d’un intérêt plus soutenu de la part des utilisateurs du fait de son activité et de la renommée de ses créateurs dans le domaine. Enfin, contrairement à jBPM, son orientation purement open source est claire (pas de monétisation de solution de services).

Bonita, qui possède une longue expérience et des fonctionnalités/interopérabilité meilleures (comparé à jBPM et Activiti – mais de même niveau que Intalio), prend une orientation commerciale (limitations de la version community), mais évidemment pas encore au point d’Intalio.

En pratique : Activiti vs Bonita

Afin d’affiner le premier comparatif issu des caractéristiques et des divers retours trouvés sur internet, un prototype a été réalisé, en utilisant tout d’abord Activiti (une version jBPM aurait été similaire, du fait qu’Activiti est dérivé de jBPM 4, pour ce cas n’utilisant pas de règles) puis Bonita (approche orientée métier et présenté comme utilisable sans licence commerciale).

L’application prototype met en oeuvre un workflow de gestion d’anomalies :

  • soumission d’une anomalie par un utilisateur du groupe reporters (soumission d’un formulaire qui correspond à l’étape initiale d’une instance de processus).
  • accès à la liste de tâches de type review (analyse/pré-validation) des soumissions d’anomalie, et validation (avec informations complémentaires) ou rejet par des utilisateurs du groupe reviewer.
  • accès à la liste des tâches de type resolve (anomalie à résoudre) et soumission d’un formulaire pour clôturer un bug corrigé par les utilisateurs du groupe developers (les tâches pour ce groupe sont créées par la validation des tâches de type review par les utilisateurs du groupe reviewers).

Afin de tester la facilité d’intégration des solutions avec des frameworks applicatifs existants (notamment pour les formulaires de saisie), les solutions Struts et Struts Layout ont été utilisées (les objets ActionForm représentant les propriétés saisies dans les formulaires utilisateur ).

L’étude préalable a été volontairement réduite (lecture du premier chapitre de Activiti in action et recherche dans quelques forums sur internet pour Activiti, documentation fournie et forums internet pour Bonita) afin d’évaluer l’intuitivité des deux approches et la présence d’informations nécessaires pour accéder au runtime.

Activiti

Orienté développeur, Activiti propose des services techniques pour soumettre les propriétés de user tasks forms ou rechercher des tâches (créées par le moteur de workflow) à partir de critères (groupe d’affectation, etc.) :

  • RuntimeService : permet de créer une instance de processus d’après son identifiant de définition (précisé dans le fichier xml à la norme BPMN 2), et rechercher des instances d’un processus.
  • FormService :soumet les propriétés (valeurs des champs) du formulaire associé à l’étape initiale (start event), ou soumet les propriétés d’un formulaire associé à une user task.
  • TaskService : permet de recherche des tâches suivant des critères.

Descripteur de processus

<process id="bugReport" name="Bug reporting process">

<startEvent id="submitBugReport" activiti:formKey="submitBugReportForm">
 <extensionElements>
  <activiti:formProperty id="project" />
  <activiti:formProperty id="version" />
  <activiti:formProperty id="summary" />
 </extensionElements>
</startEvent>

<sequenceFlow sourceRef="submitBugReport" targetRef="reviewBugReport"/>

<userTask id="reviewBugReport" name="Review bug report" activiti:candidateGroups="reviewers" activiti:formKey="updateBugReportForm">
 <extensionElements>
  <activiti:formProperty id="project" />
  <activiti:formProperty id="version" />
  <activiti:formProperty id="summary" />
  <activiti:formProperty id="priority" />
  <activiti:formProperty id="taskId" />
  <activiti:formProperty id="result" />
 </extensionElements>
</userTask>

<sequenceFlow sourceRef="reviewBugReport" targetRef="reviewResultExclusiveBranch"/>

<exclusiveGateway id="reviewResultExclusiveBranch" />
<sequenceFlow sourceRef="reviewResultExclusiveBranch" targetRef="resolveBugReport"><conditionExpression>${result == 'accepted'}</conditionExpression>
</sequenceFlow>
<sequenceFlow sourceRef="reviewResultExclusiveBranch" targetRef="theEnd">
 <conditionExpression>${result == 'rejected'}</conditionExpression>
</sequenceFlow>

<userTask id="resolveBugReport" name="Resolve bug report" activiti:candidateGroups="developers" activiti:formKey="resolveBugReportForm">
 <extensionElements>
  <activiti:formProperty id="project" />
  <activiti:formProperty id="version" />
  <activiti:formProperty id="summary" />
  <activiti:formProperty id="priority" />
  <activiti:formProperty id="resolution" />
 </extensionElements>
</userTask>

<sequenceFlow sourceRef="resolveBugReport" targetRef="theEnd"/>

<endEvent id="theEnd"/>

</process>

Start event / process instances / tasks

Le start event, étape initiale d’un worklfow Activiti, correspond à une tâche utilisateur particulière : celle-ci ne génère pas de tâche, mais suspend uniquement le workflow (en attente de soumission du formulaire correspondant). De plus l’instance de processus n’est créée qu’au moment de la transition depuis cette étape (donc après soumission du formulaire initial, ici création d’une entrée bug report) vers l’étape suivante (via un service technique Activiti appelé dans l’action Struts).

L’étape suivante, de type user tasks, crée une tâche (de type review) en mémoire pour l’instance de process précédente, et suspend ce dernier jusqu’à soumission du review form correspondant par un reviewer (après sélection de la tâche de type review en attente dans la liste des tâches de type review – voir ci-dessous) :

Le formulaire review permet au reviewer d’ajouter des informations/préciser la demande et accepter (orienter le traitement vers l’équipe développeurs) ou rejeter le bug report (on utilise des instructions conditionnelles dans la définition du workflow en fonction de paramètres résultats de la task form/données soumises – accès direct à l’événement de fin du workflow si rejet).

Si le reviewer valide le bug report (tâche review correspondante complétée et user task form terminée), la transition suivante déclenche/génère une instance de user task resolve bug, affectée au groupe developers.

La documentation trouvée est peu claire/précise sur la distinction entre définition de process (process definition key) et de tâches et instances de celles-ci. Il faut également bien considérer que par défaut les processus persistent en mémoire.

Deux problèmes ont été rencontrés lors du développement du prototype :

  • création d’instance de processus additionnelle lors de soumission de start form : un second process est listé dans la liste des taches bug review (l’un avec les données saisies valorisées, l’autre sans les données). En fait la soumission des propriétés d’un formulaire associé au start event démarre un nouveau process, on ne doit pas démarrer explicitement le processus auparavant.
  • problème pour terminer une tâche : le taskService ne trouve pas la tâche dont on passe l’id, récupéré pourtant via le service de recherche de tâches, et qui doit donc logiquement correspondre à un id d’instance de tâche existante. Les tâches utilisateurs ne doivent en fait pas être terminées explicitement, elles le sont implicitement (passage à l’étape suivante) lors de la soumission des propriétés du formulaire associé.

Bonita

Le runtime Bonita fournit des services techniques similaires à Activiti :

  • ManagementAPI : permet de lire et déployer une archive business (fichier BAR contenant une définition de processus créé et exporté depuis l’éditeur Bonita Studio – voir plus loin).
  • RuntimeAPI : permet d’instancier un processus depuis l’id de sa définition dans l’archive BAR (fichier process-def.xml de l’archive), et renvoie l’uuid de l’instance de process créée. Permet également d’affecter une tâche à un utilisateur et exécuter une tâche (pas automatique comme avec Activiti).
  • QueryRuntimeAPI : permet de récupérer des tâches selon leur état.

Bonita ne fournit pas d’informations détaillées sur la syntaxe de la définition de processus (fichier process-def.xml de l’archive BAR), ce qui est logique du fait que le mode de développement prévu est d’utiliser l’éditeur Bonita Studio pour les définir. En tous les cas la syntaxe n’est pas homogène avec celle d’Activiti. On s’attendait portant à une description normée, avec uniquement des extensions spécifiques à l’éditeur pour la définition des propriétés des formulaires utilisateur.

Activiti étant orienté développeurs (même s’il propose également des éditeurs) et Bonita étant orienté davantage utilisateurs (même si il propose donc des API runtime), on considérera que l’étape d’export du fichier BAR n’est pas une limitation pour cette comparaison (même si elle a constitué un point de blocage initial dans la mise en oeuvre du prototype).

Dans la pratique (adaptation du prototype Activiti pour le runtime Bonita) on note cependant les limites suivantes par rapport au runtime Activiti :

  • La documentation et les discussions sur les forums sont plus limitées.
  • La user task/start event initiale (soumission de bug) n’est pas créée automatiquement et le workflow ne génère pas de user task review après soumission de formulaire : il est en effet précisé que si on utilise le runtime Bonita uniquement (donc sans passer par l’éditeur de formulaire de Bonita Studio) les tâches utilisateur doivent être démarrées explicitement via runtimeAPI.executeTask(taskId).

http://www.bonitasoft.org/blog/tutorial/building-your-applications-with-bonita-runtime-%E2%80%93-part-3/

  • pas de fonctionnalité/service runtime pour la soumission de données de formulaires associés à des user task (uniquement si définis via l’éditeur de formulaire). L’utilisation de variables d’éxecution de processus est nécessaire.
  • possibilité de spécifier des URL externes pour les formulaires (sinon générés) depuis Bonita Studio ; cependant, en plus d’être complexe, cette option redirectToUrl n’est pas proposée dans la version community 5.6.2 mais seulement dans la version Teamwork subscription pack, payante :

http://www.bonitasoft.com/resources/documentation/bos-56/web-applications/use-process-instantiation-form

http://www.bonitasoft.com/resources/documentation/bos-56/web-applications

http://www.bonitasoft.com/resources/documentation/bos-56/web-applications/redirect-form-page-external-url-sp

http://www.bonitasoft.com/products/product-comparison

L’orientation de BonitaSoft semble donc avoir évolué depuis cet article : http://jduchess.org/duchess-france/blog/soiree-bpm-au-lyon-jug-%E2%80%93-rencontre-avec-mickael-istria/

« le BPM est généralement quelque chose d’onéreux, que les concurrents propriétaires vendent à coup des dizaines de milliers de dollars minimum. Si bien que Bonita offre aux organisations la possibilité d’évaluer gratuitement, simplement et sans engagement le BPM avant de se lancer Asus X550ZE-XO014H AC Adapter dans l’aventure et d’investir pour obtenir un support professionnel et accéder à des fonctionnalités additionnelles de productivité et d’industrialisation des déploiements »

La réalisation de la version Bonita du prototype dans les mêmes conditions (réutilisation des formulaires Struts existants, pas de licence additionnelle) n’a donc pas été possible.

Conclusion

Dans l’ensemble l’utilisation des solutions BPM/workflows étudiées n’est pas homogène, alors qu’on s’attendait à une approche systématique grâce aux nombreuses normes et standards mis en oeuvre. De plus les notions d’instances de processus et de tâches qui constituent les principes de base ne sont pas suffisamment expliqués, d’autant que la terminologie retenue par les outils ne coule pas de source.

Activiti semble plus intuitif. Les exemples fournis et les APIs permettent de définir, gérer, et intégrer un workflow à une application existante de manière immédiate, et sans limitation. Il est donc bien orienté développeur, pour intégration notamment à un framework existant. Bonita peut être envisagé dans le cadre d’une intégration plus large (moins spécifique) de l’ensemble des outils fournis par BonitaSoft (pouvant alors justifier une souscription).

De manière générale les informations et discussions sur internet pour les deux solutions mises en oeuvre sont encore limitées et ne couvrent pas encore l’ensemble des questions basiques, ce qui constitue un frein à leur adoption dans une approche pure open source.

Analyse et veille technologique , , , , , , ,

6 comments


  1. Vincent Couturier

    Activity est la seule véritable implémentation de BPMN 2.0 qui utilise le format natif BPMN et utilise les mécanismes d’extension. La note de 4 sur les standards ne me parraít pas adapter. Il n’est pas fait mention de l’intégration fine avec la dernière version d’alfresco.
    Concernant Bonita il faut noter la progression fulgurante de l’outil depuis la création de Bonitasoft.A ce sujet il faut noter une prise en main largement plus simple qu’Activiti pour la modélisation. L’outil de conception Bonita est plus accessible et pragmatique.

  2. Bonjour et merci pour cet article fort instructif.
    Comment une solution comme ProcessMaker se compare-t-elle à ténors ici présentés ?
    Bien à vous

  3. Pingback: How to integrate BOS engine in a Struts 2 application « Bonita open source BPM community blog

  4. bouquetf

    Bonjour,

    J’ai été étonné de voir que vous n’aviez pas réussi à pousser l’intégration avec Bonita. J’ai donc essayé de mon côté et comme le POC a été un succès, j’ai publié un article explicatif sur le blog communautaire du projet. Les sources y sont aussi disponibles.
    J’en ai aussi profité pour clarifier certains aspects relatifs à la vision qu’a la société à propos de la version open source.
    C’est ici : http://www.bonitasoft.org/blog/tutorial/how-to-integrate-bos-engine-in-a-struts-2-application/
    N’hésitez pas à revenir vers la communauté ou vers moi pour plus d’infos

    Bonne lecture.

    Fred

  5. Jerome Denanot

    Bonjour,

    Merci pour cette implémentation.
    La documentation précisait qu’il n’était pas possible d’utiliser des urls externes depuis l’éditeur Bonita Studio dans la version community. Il semble qu’il s’agit des sites générés, le runtime étant accessible depuis les actions Struts.
    Serait-il possible cependant d’utiliser un fichier bpmn simple, donc sans utiliser l’éditeur Bonita Studio (l’archive bar étant propriétaire) ?

    Après étude du code de l’implémentation Bonita, les autres remarques de l’article semblent validées :
    - Bonita ne gère pas de propriétés de tâches, les propriétés des formulaires sont soumises sous forme de variables de l’instance de processus.
    - certaines tâches doivent être créées manuellement (avec Activiti la user task suivante du workflow est créée automatiquement lors de la soumission des propriétés de la tâche précédente).
    L’utilisation du runtime Bonita semble moins intuitive (récupération de l’instance de processus depuis l’instance de tâche).

  6. Tout à fait d’accord avec vous sur le dernier paragraphe, il est vrai que le manque d’informations retardent l’appréhension de ces solutions.