Tutoriel jBPM : les fonctionnalités du BPM open source (partie 1/10)
Les nouveaux développements d'applications proposent que la conception puisse se faire par les utilisateurs finaux et des développeurs qui ne seraient pas des gourous des dernières tendances technologiques.
Ce tutoriel a pour but de montrer un cas concret simple d'un processus métier exécutable au sens de la norme BPMN2 ( http://www.omg.org/spec/BPMN/2.0/ ).
Pour bien comprendre les différents concepts comme l'exécution des "Human Task", j'utiliserais la suite open source jBPM ( http://www.jbpm.org/ ).
Au cours de mes différentes missions en conseil en urbanisation, j'ai eu l'occasion de mettre en oeuvre le moteur de règles métiers open source Drools ( http://www.drools.org/ ) permettant de concevoir, d'exécuter et de gérer de manière efficiente des règles métiers en dehors du code et des applications.
Cette brique éprouvée est devenue le standard des moteurs de règles open source.
Derrière cette suite logicielle se trouve jBoss (le serveur d'application JEE le plus utilisé en production) et Red Hat, l'éditeur de la distribution Linux la plus répandue en entreprise, à qui appartient jBoss.
Drools et jBPM appartiennent donc à la famille JBoss/Red Hat, mais jBPM fait il aussi que son frère Drools ?
Red Hat commercialise les 2 offres sous les appellations : Red Hat® JBoss® BRMS (Business Rules Management System) ( https://www.redhat.com/fr/technologies/jboss-middleware/business-rules ) et Red Hat® JBoss® BPM Suite ( http://www.redhat.com/en/technologies/jboss-middleware/bpm )
Pour Red Hat la société commerciale, il est clair que Drools et jBPM servent de laboratoire d'expérimentation. Les solutions opensource n'étant bien évidemment pas garanties contre le bogues, Red Hat s'engage par contre dans les solutions payantes a corrigé tous les défauts et à apporter son aide et son expertise aux futurs clients.
Si le moteur Drools est fiable, robuste et n'a plus de preuve à faire, qu'en est-il de jBPM ?
L'histoire de jBPM est un peu mouvementée.
Pour relancer la machine, on envoit les experts de l'équipe Drools à la rescousse. La version 5 reprend tout de A à Z avec l'objectif de supporter la nouvelle norme BPMN 2 exécutable et son XML associé..
JBoss tente de se différencier en promouvant l’intérêt de l’intégration de sa solution avec son moteur de règles (Drools), arguant qu’une solution BPM sans cette fonctionnalité n’est pas concevable.
Si jBPM est remis sur les rails, il lui reste beaucoup de chemin à parcourir car pendant ce temps les solutions open source concurrente ont beaucoup progressées. Si le moteur fonctionne, ce n'est pas le cas des outils pour Eclipse et encore moins pour ceux dédiés aux concepteurs de processus métiers. Dans la documentation, il est fait mention que pour le BAM (Business Activity Monitoring), les développeurs ont toutes les briques pour développés eux-mêmes leurs dashboard. L'exemple fourni est une caricature de ce qu'on exige d'une vraie solution de BAM.
Avec la nouvelle version 6, la norme BPMN 2 pour les processus exécutable est maintenant bien supportée.
La stratégie de Red Hat est de concurrencer les solutions commerciales et de pénétrer le marché des grandes organisations.
- Clustering et haute disponibilité
- Nouveau BAM entièrement revu à partir de la solution Polymita rachetée par Red Hat
- Utilisation du framework UberFire permettant de développer rapidement des écrans de reporting
- des outils de simulation
- le support du cloud
- des connecteurs BPM
- le support de la totalité de la norme BPMN2
- des outil web de modélisation des données
- des générateur de formulaires
- le « No code tooling », la possibilité aux experts métiers de créer, déployer, exécuter et surveiller leurs processus sans avoir à écrire du code.
- les "processus dynamique", c'est à dire la possibilité de changer dynamiquement une instance de processus en cours d’exécution comme ajouter une tâche à la volée.
- les support des applications mobiles
- les outil de migration d’un processus en cours d’exécution vers un nouveau, incluant un outil graphique gérant les différences
- l'analyse de processus pour détecter les problèmes et les optimiser
- le "Goal driven BPM" qui a pour ambition, au lieu de modéliser les processus comme une séquence d’étapes, de se focaliser plus sur les buts et les pré-conditions qui serviront à générer le processus résultant peut être à partir des concepts métiers et de la modélisation orientée but (GORE Goal Oriented Requirements Engineering).
"Deux choses sont infinies : l'Univers et la bêtise humaine. Mais en ce qui concerne l'Univers, je n'en ai pas encore acquis la certitude absolue."
Albert Einstein
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
A découvrir aussi
- Tutoriel jBPM : étude de cas avec human task (partie 2/10)
- Tutoriel jBPM : l'installation (partie 3/10)
- Tutoriel jBPM : démarrer l'ensemble des composants (partie 4/10)
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 757 autres membres