| Mardi prochain, le 15 février, le Lyon JUG présente une soirée autour de la thématique du Business Process Management (BPM) et de Bonita Open Solution, solution Open-Source complète BPM. Une soirée particulière puisque les personnes intéressées auront l’opportunité de se lancer dans l’utilisation de Bonita, avec un mini-exercice encadré sous les conseils du speaker, Mickael Istria. | Mickael est l’un des développeurs du Studio de Bonita Open Solution chez BonitaSoft, C’est un grand fan d’Eclipse depuis quelques années, et avant de rejoindre BonitaSoft, il était committer et release engineer sur le project Eclipse Java Workflow Tooling. Au-dela d’Eclipse, il s’intéresse notamment aux différentes manières de rendre le développement Agile, grâce à l’architecture logicielle et l’intégration continue.

bonitasoft

Follow Mickael on Twitter

@mickaelistria

Agnès : Tu vas aborder dans ta session du Lyon JUG le vaste domaine du Business Process Management (BPM). Pour commencer, peux-tu nous dire ce qu’est pour toi un processus métier? Peut-on en distinguer plusieurs catégories en fonction des acteurs qu’ils impliquent ou de leur granularité ?
Mickael : Une définition formelle que je donne d’un processus est qu’un processus métier est la définition d’un ensemble d’étapes (humaines, automatiques ou interagissant avec d’autres parties du SI) qui permettent de répondre à un besoin métier (production d’une pièce d’usine, gestion d’une commande, accueil d’un nouvel employé…). On pourrait comparer un process métier à une recette de cuisine, sauf que le résultat n’est pas nécessairement quelque chose qu’on peut manger.
On peut observer différents types de processus métiers en fonction des besoins et des gens qui les développent. Des fonctionnels très haut niveau auront tendance à dessiner des processus très abstraits, assez loin de l’exécutable, privilégiant les interactions humaines ; alors que des développeurs habitués à une logique de « flow » auront tendance à rentrer dans des détails de connectivité avec les autres parties du SI, et utiliseront le BPM plus dans une optique de chorégraphie entre les différents acteurs et systèmes.
La différence fondamentale est que quand on dit BPM à un fonctionnel, il comprend dessin ; là où un développeur entend API.

Agnès : Comment décrire un processus métier? UML me suffit-il? Peux-tu nous présenter les autres normes existantes permettant de modéliser un processus métier ou de décrire leur exécution? Ces normes sont-elles majoritairement adoptées par les solutions BPM, ou le mode propriétaire prédomine-t-il?
Mickael : UML s’est révélé trop technique et insuffisant pour le BPM. Du coup un standard graphique a émergé et a été rapidement adopté par le monde du BPM (open-source et propriétaire). C’est une version modernisée et légèrement étendue des diagrammes d’activité d’UML. Du coup tout le monde est aligné sur cette notation graphique. Mais il s’agit juste de dessin et pas d’un format d’échange entre solutions. Le cœur de BPMN2 est extrêmement simple: des boites, des losanges, des ronds et des flèches… Ce langage se révèle plus agréable qu’UML, mais aussi plus puissant grâce à ses constructions avancées. BPMN2 possède aussi une spécification de sérialisation, qui permet d’en faire un format d’échange entre les différentes solutions BPM.
Mais pour ce qui est des langages d’exécution, c’est un autre histoire. Il y a eu BPEL, trop complexe pour la problématique BPM ; XPDL 1 puis 2, qui spécifiait l’essentiel d’un processus métier, mais pas assez pour supporter les features de tous les éditeurs ; et maintenant BPMN2, qui souffre des mêmes problèmes que XPDL lorsqu’on l’utilise comme format de sérialisation. Du coup, même les solutions qui suivent les standards d’exécutions sont obligées d’ajouter des extensions propriétaires pour supporter leurs features.
Bonita a pris le parti de ne pas se reposer sur un standard d’exécution précis, mais de conserver la possibilité d’échanger avec les autres solutions via des imports (XPDL, jBPM3, BPMN2) et exports (BPMN2) des standards et formats courants.
Je n’ai pas le sentiment que le monde propriétaire prédomine sur l’open-source en terme de technologie et de standard de BPM.

Agnès : Le grand spectre d’une architecture SOA met en exergue des processus métiers dits _transverses, impliquant plusieurs services ou processus d’applications différentes communiquant à travers un Bus d’entreprise (ESB). Un point qui m’intéresse particulièrement est la manière dont la gestion transactionnelle peut être réalisée sur de tels processus (utilisation de transactions distribuées, de mécanismes de compensation). Quels sont tes retours d’expériences sur la question ?_
Mickael : Le moteur de Bonita est suffisamment flexible et paramétrable pour utiliser JTA (Java Transaction API). Cela permet aux personnes qui seront responsables de l’intégration de choisir, voire de développer, leur propre gestion de transactions pour résoudre leur cas spécifique à leur système d’intégration. Ainsi il est possible d’utiliser des transactions distribuées en restant en JEE standard. Une autre solution technique est de se reposer sur la gestion de transactions d’Hibernate, utilisé par Bonita. Mais comme tu l’as compris, il s’agit de tweaker le déploiement. L’implémentation par défaut des transactions dans Bonita gère l’intégrité du moteur BPM, pas celles de tout le SI, qui sont dans la plupart des cas vraiment spécifiques. Le partage de transaction est quelque chose qui a été déjà implémenté par quelques uns de nos gros utilisateurs/clients.
Bonita sait gérer les évènements et les erreurs dans le processus, qui ont grosso-modo le même comportement que des exceptions dans le monde du Java, et permet de catcher ces erreurs pour les corriger ensuite. La compensation est donc logiquement possible dès qu’on a la possibilité d’envoyer et de rattraper les erreurs. On peut donc l’appliquer avec Bonita. Elle s’implémente facilement à l’aide de sous-process évènementiels, qui sont une construction standard de BPMN2 et supportés par Bonita.

Agnès : Tu travailles sur Bonita Open Solution, présentée comme une solution complète de BPM. Cela signifie-t-il qu’avec ce seul outil je peux à la fois modéliser, implémenter, exécuter et monitorer mes processus? Peux-tu nous en dire un peu plus sur les fonctionnalités offertes par Bonita Open Solution ?
Mickael : Yes you can ! Et plus encore… En fait, Bonita se compose de plusieurs parties :

  • Le process modeling depuis le studio, qui te permet de modéliser des processus métiers, mais pas juste le dessin. Tu peux aussi modéliser dans ton process les interactions avec les différentes parties de ton SI, assigner les « Actors resolvers » qui serviront à affecter les tâches aux bonnes personnes lors de l’exécution, créer de nouveaux connecteurs (on génère les fichiers et les squelettes nécessaires pour que tu n’aies que ton code métier à écrire sans avoir à connaître les API Bonita). On a aussi des features plus high-level, comme la simulation de processus ou la génération automatiques de documentation.
  • La customisation d’application: depuis ce même studio, on peut générer pour chaque étape où il y a une interaction humaine des formulaires dynamiques que l’utilisateur final pourra manipuler dans son navigateur. Pour chaque processus, on peut alors exporter une application (sous forme de WAR), qui pourra être l’UI du process pour les utilisateurs finaux.
  • Le moteur : Clé de voûte de la solution, le moteur est la partie responsable de l’exécution des processus. Il s’agit d’une simple API Java qui cache toute la partie persistance & cie (très technique) pour que les développeurs n’aient qu’à manipuler de la logique de business processes. Il est distribué en LGPL v2 pour que chacun puisse l’intégrer dans ses applications maisons.
  • La User XP est une console qui permet à l’utilisateur final de gérer ses tâches, et qui fournit aussi des fonctions d’administration. Les administrateurs peuvent gérer les taches de ses utilisateurs (les effectuer pour lui, les réassigner, les mettre en pause…), gérer les utilisateurs en user/group/role, mettre en place des permissions quant à la création de nouvelles instances du process, ajouter et mettre en place des rapports qui lui permettent de monitorer l’état actuel de son business.
  • La partie application de formulaires, qui est la partie cachée derrière les applications web générées par le studio. Il s’agit de toute la logique qui permet de lire la description des applications et des formulaires telle que modélisée dans le studio pour les afficher à l’utilisateur final de manière dynamique, et transparente pour lui.

Je pense que là où Bonita se démarque le plus, c’est dans son approche duale : BPM tout intégré, où on génère des applications prêtes à l’emploi pour les processus, mais BPM pour les développeurs aussi avec une API facile à mettre en place et à utiliser ; le tout avec un tooling qui permet une grande productivité. La plupart des autres acteurs du milieu ne s’attaquent qu’à un seul de ces problèmes.

Agnès : Sur les choix stratégiques de développements de l’offre Bonita Open Solution… Je note que Bonita Open Solution est open source dans un marché du BPM encore aujourd’hui assez dominé par quelques éditeurs propriétaires. Quelles sont les raisons qui ont poussé l’entreprise à choisir ce type de licence? En quoi cela est-il potentiellement un atout pour la solution ?
Mickael : C’est avant tout culturel et historique. Bonita est né dans les laboratoires de l’INRIA de Nancy il y a maintenant 10 ans. A l’époque, c’était Miguel Valdes Faura, aujourd’hui PDG de BonitaSoft, qui le développait (depuis Bonita a été entièrement réécrit plusieurs fois, je vous rassure ;) ). Le lien entre la recherche et l’Open-source est très fort, si bien que Bonita a toujours été Open-source, et que ça ne changera pas, ça fait partie du produit, des développeurs et de l’entreprise.
Ceci présente de nombreux avantages sur le marché, ce qui tombe bien car le mot d’ordre de BonitaSoft est « démocratiser le BPM ». D’abord Open-source implique qu’on peut s’attaquer au problème sans payer le moindre dollar. Or 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 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. C’est plutôt rassurant d’avoir cette possibilité lorsqu’il s’agit de mettre en place des projets critiques ! Ensuite, Open-source implique aussi que le code est ouvert et que donc quoiqu’il arrive au produit ou à l’entreprise, l’accès au code assure une certaine sécurité sur le long terme. Enfin, il y a la transparence vis-à-vis du code, de la communauté et des clients. Bref, être open-source sur un marché si cher et risqué permet cette démocratisation.

Agnès : Toujours sur les choix stratégiques de développement, tu indiques que l’équipe de Bonita utilise Scrum pour gérer le cycle de développement du produit. Quel est ton retour d’expérience sur cette méthode Agile ? Qui représente le product owner? Organisez-vous des sessions de tests fonctionnels / tests d’intégration à chaque sprint?
Mickael : Ce que j’adore dans les méthodes Agiles, c’est leur réalisme. On ne se fixe pas d’objectif impossible, on se félicite des succès et on s’avoue les échecs, et on peut en tirer les conséquences très vite. Tout ce réalisme amène à un cadre de travail très plaisant et à une bonne ambiance dans l’équipe. Au final, Scrum nous a permis de produire très vite un produit de très bonne qualité, que ce soit vu de l’extérieur (features) ou de l’intérieur (qualité du code).
Le rôle de product owner est joué par Charles Souillard, directeur technique et co-fondateur de BonitaSoft, qui nous élabore la roadmap à partir des diverses évolutions demandées au produit, par la communauté d’utilisateurs, de clients, par le marché, ou encore par nous qui avons parfois nos petits caprices qu’on veut vraiment implémenter ;)
Pour le testing, on se félicite déjà de notre suite de tests automatisés (~2300 tests sur chaque OS), qui contient environ 50% de tests unitaires et 50% de tests d’intégration. Chaque jeudi après le repas, on organise une petite session de tests d’une ou 2 heures pour tester les nouveautés, puis une demie-journée en fin de sprint, et une semaine avant chaque release. On a récemment eu le plaisir d’étendre l’équipe R&D avec en place une équipe QA à Pékin en Chine qui effectue des tests fonctionnels, et je dois avouer qu’on a quasi-immédiatement ressenti un grand progrès dans la qualité du produit et dans notre confort de développement. On est actuellement dans une période ou bien qu’on ajoute des features, le code continue de s’améliorer, et ce en grande partie grâce aux méthodologies Agiles.

Merci Mickael!

Les inscriptions sont ouvertes! Rendez-vous sur le site du Lyon JUG