Est-il préférable d'écrire un nouveau moteur de workflow ou d'utiliser un moteur BPM existant: jBPM 5, Activiti 5?
Mon application est une application Web et les performances sont importantes. Mon doute est de savoir si l'utilisation de jBPM/Activiti sera une surcharge de performances par rapport à l'écriture d'un moteur de workflow simple.
Si je choisis l'auto-implémentation, la visualisation du flux de travail me manquera. Pour la performance, il peut être échangé.
Cela dépend vraiment de vos besoins. Tout d'abord, voyez si vous avez vraiment besoin d'un moteur de workflow ( this ou d'autres sources). Sauf si vous en avez vraiment besoin, vous devriez probablement l'éviter.
Si vous avez vraiment besoin de ce qui fournit un moteur de workflow, je choisirais celui qui est déjà construit. Les personnes qui travaillent avec jbpm ou activiti ont beaucoup plus d'expérience que vous dans la création de moteurs de workflow, il est donc probablement déjà réglé pour améliorer les performances.
Je suis d'accord avec les gars qui ont déjà posté des réponses ici, ou une partie de leurs réponses de toute façon: P, mais comme ici dans l'entreprise où je travaille actuellement, nous avons eu un défi similaire, j'ai pris la liberté d'ajouter mon opinion, sur la base de notre expérience.
Nous devions migrer une application qui utilisait le moteur de flux de travail jBPM dans des applications liées à la production et comme il y avait pas mal de défis dans la maintenance de l'application, nous avons décidé de voir s'il y avait de meilleures options sur le marché. Nous sommes arrivés à la liste déjà mentionnée:
Nous avons décidé de ne plus utiliser jBPM car notre expérience initiale avec ce n'était pas la meilleure, en plus de cela, la compatibilité descendante était rompue avec chaque nouvelle version qui était sortie.
Enfin, la solution que nous avons utilisée était de développer un moteur de workflow léger, basé sur des annotations ayant des activités et des processus comme abstractions. C'était plus ou moins une machine d'état qui faisait son travail.
Un autre point qui mérite d'être mentionné lors de la discussion sur le moteur de workflow est le fait qu'ils dépendent de la base de données de support - c'était le cas avec les deux moteurs de workflow avec lesquels j'ai l'expérience ( SAG webMethods et jPBM ) - et d'après mon expérience, c'était un peu une surcharge, surtout lors des migrations entre les versions.
Donc, je dirais que l'utilisation d'un moteur de workflow n'est autorisée que pour les applications qui en bénéficieraient vraiment et où la plupart du workflow des applications tourne autour du workflow lui-même, sinon il existe de meilleurs outils pour le travail:
En ce qui concerne les machines à états, je suis tombé sur une réponse this qui contient une collection assez complète de frameworks d'état Java.
J'espère que cela t'aides.
Les moteurs de workflow basés sur Java comme Activiti, Bonita ou jBPM prennent en charge une large gamme de spécifications BPMN 2.0. Par conséquent, vous pouvez modéliser des processus de manière graphique. De plus, certains de ces moteurs ont des capacités de simulation comme Activiti (avec Activiti Crystalball). Si vous codez les processus par vous-même, vous n'êtes pas aussi flexible lorsque vous devez changer le processus. Par conséquent, je conseillerais également d'utiliser un moteur BPM basé sur Java.
J'ai fait une recherche concernant les moteurs open source basés sur BPMN 2.0. Voici les points clés qui étaient pertinents pour notre cas d'utilisation concret:
1. Bonita:
Bonita a une approche de zéro codage, ce qui signifie qu'ils fournissent un IDE facile à utiliser pour construire vos processus sans avoir besoin de codage. Pour y parvenir, Bonita a le concept de connecteurs. Par exemple, si vous souhaitez consommer un service Web, ils vous fournissent un assistant graphique. L'inconvénient est que vous devez écrire l'enveloppe SOAP XML ordinaire manuellement et la copier dans une zone de texte graphique. Le problème avec cette approche est que vous ne pouvez réaliser que des cas d'utilisation prévus par Bonita. Si vous souhaitez intégrer un système pour lequel Bonita n'a pas développé de connecteur, vous devez coder vous-même un tel connecteur, ce qui est très douloureux. Par exemple, Bonita propose un connecteur SOAP pour consommer les services Web SOAP. Ce connecteur fonctionne uniquement avec SOAP 1.2, mais pas pour SOAP 1.1 ( http: //community.bonitasoft.com/answers/consume-soap-11-webservices- bonita-secure-web-service-connector ). Si vous avez une application héritée avec SOAP 1.1, vous ne pouvez pas intégrer facilement ce système dans votre processus. Il en va de même pour les bases de données. Il n'existe que quelques connecteurs de base de données pour les versions de base de données dédiées. Si vous avez une version qui ne correspond pas à un connecteur, vous devez la coder vous-même.
De plus, Bonita ne prend pas en charge LDAP ou Active Directory Sync dans l'édition communautaire gratuite, ce qui est tout à fait un exemple pour un environnement de production. Une autre chose à considérer est que Bonita est sous licence GPL/LGPL, ce qui pourrait poser des problèmes lorsque vous souhaitez intégrer Bonita dans une autre application d'entreprise. De plus, le soutien communautaire est très faible. Il y a plusieurs postes qui ont plus de 2 ans et ces postes sont toujours sans réponse.
Une autre chose importante est l'alignement Business-IT. La modélisation des processus est une discipline collaborative dans laquelle l'informatique ET les analystes métier sont impliqués. C'est pourquoi vous avez besoin d'outils adéquats pour les deux groupes d'utilisateurs (par exemple, un plugin Eclipse pour les développeurs et un modeleur Web facile à utiliser pour les hommes d'affaires). Bonita propose uniquement Bonita Studio, qui doit être installé sur votre machine. Ce IDE est assez technique et ne convient pas aux utilisateurs professionnels. Par conséquent, il est très difficile de réaliser l'alignement Business-IT avec Bonita.
Bonita est un outil BPM pour des processus très triviaux et faciles. En raison de l'approche de codage zéro, la courbe de lerning est très faible et vous pouvez commencer la modélisation très rapidement. Vous avez besoin de moins de compétences en programmation et vous êtes en mesure de réaliser vos processus sans avoir besoin de codage. Mais dès que vos processus deviennent très complexes, Bonita n'est peut-être pas la meilleure solution en raison du manque de flexibilité. Vous ne pouvez réaliser que des cas d'utilisation prévus par Bonita.
2. jBPM:
jBPM est un moteur BPM Open Source très puissant qui possède de nombreuses fonctionnalités. Le modeleur Web prend même en charge les modèles préfabriqués de certains modèles de flux de travail van der Aalst (workflowpatterns.com). Business-IT-Alignment est réalisable car jBPM offre une intégration Eclipse ainsi qu'un modeleur basé sur le Web. Un peu délicat est que vous ne pouvez définir des formulaires que dans le modeleur web, mais pas dans le plugin Eclipse, à ma connaissance. Pour résumer, jBPM est un bon candidat pour une utilisation en entreprise. Notre showstopper était l'évolutivité. jBPM est basé sur les règles-moteur Drools. Cela conduit au fait que des instances de processus entières sont conservées en tant que BLOBS dans la base de données. Il s'agit d'un élément essentiel pour la recherche et l'évolutivité.
De plus, la courbe d'apprentissage est très élevée en raison de la complexité. jBPM n'offre pas de tâche de service comme le suggère le standard BPMN.En revanche, vous devez définir vos propres tâches de service Java et vous devez les enregistrer manuellement dans le moteur, ce qui entraîne une programmation de niveau assez bas.
3. Activiti:
En fin de compte, nous sommes allés avec Activiti car il s'agit d'un moteur basé sur un framework très facile à utiliser. Il offre un plugin Eclipse ainsi qu'un AngularJS Web-Modeler moderne. De cette façon, vous pouvez réaliser l'alignement Business-IT. L'API REST est sécurisée par Spring Security, ce qui signifie que vous pouvez étendre le moteur très facilement avec des fonctionnalités d'authentification unique. En raison de la licence Apache 2.0, il n'y a pas de copyleft, ce qui signifie que vous êtes complètement libre en termes d'utilisation et d'extensibilité, ce qui est très important dans un environnement productif.
De plus, la couverture BPMN est très bonne. Tous les éléments BPMN ne sont pas réalisés, mais je ne connais aucun moteur qui le fasse.
L'Activiti Explorer est une interface de démonstration qui montre l'utilisation des API Activiti. Comme ce frontend est basé sur VAADIN, il peut être étendu très facilement. La communauté est très active, ce qui signifie que vous pouvez obtenir de l'aide très rapidement en cas de problème.
Activiti offre de bons points d'intégration pour les technologies de formulaire externes, ce qui est très important pour une utilisation productive. Les technologies de forme de tous les candidats sont très restrictives. Par conséquent, il est logique d'utiliser une technologie de formulaire standard comme XForms en combinaison avec le moteur. Même des choses plus complexes sont réalisables via l'attribut formKey.
Activiti ne suit pas l'approche de zéro codage, ce qui signifie que vous aurez besoin d'un peu de codage si vous souhaitez orchestrer des services. Mais même la communication avec les services SOAP peut être réalisée en utilisant une tâche de service Java et Apache CXF. L'effort de codage est faible.
J'espère que mes points clés peuvent aider en prenant une décision. Pour être clair, ce n'est pas une publicité pour Activiti. Le bon choix de produit dépend des cas d'utilisation concrets. Je veux seulement souligner les points les plus importants de notre projet
La question est de savoir ce que vous voulez vraiment obtenir lorsque vous demandez un moteur de workflow.
L'objectif général que vous souhaitez atteindre en utilisant un moteur de workflow est de devenir plus flexible dans la modification de votre logique métier pendant l'exécution. La partie modélisation est certainement l'une des plus importantes ici. BPMN 2.0 est une norme de facto dans ce domaine et tous les moteurs discutés prennent en charge cette norme.
Le deuxième objectif est de contrôler le processus métier de manière à décrire les 'ce qui devrait arriver quand ...' . Et cette partie a beaucoup à voir avec les exigences commerciales auxquelles vous êtes confronté dans votre projet.
Certains moteurs de workflow ( Activity , JBPM ) peuvent vous aider à répondre à cette exigence en "codant" vos processus. Cela signifie que vous modélisez le 'ce qui devrait arriver quand ..' en quelque sorte, où vous décidez quelle partie de votre code (par exemple une tâche ou un événement) doit être exécuté par le moteur de workflow dans diverses situations. Beaucoup de discussions sont en cours sur ce concept. Et les développeurs demandent naturellement si cela ne peut même pas être mis en œuvre par eux-mêmes. (Ce n'est en fait pas si facile qu'il y paraît au premier coup d'œil)
Certains autres moteurs de workflow ( Imixs-Workflow , Bonita ) peuvent vous aider à répondre au 'ce qui devrait arriver quand ...' exigence d'une manière plus centrée sur l'utilisateur. Il s'agit du domaine de la gestion des processus métier centrée sur l'humain, qui prend en charge les compétences et les activités humaines par un moteur de workflow orienté tâche. L'accent est davantage mis sur la répartition des tâches et des processus au sein d'une organisation. Le moteur de workflow vous aide à distribuer une tâche à un certain utilisateur ou groupe d'utilisateurs et à sécuriser, consigner et surveiller un processus métier de longue durée. Ce sont peut-être les choses que vous ne voulez pas vraiment mettre en œuvre par vous-même.
Donc, mon conseil est de ne pas mélanger les choses qui doivent être considérées séparément, car le flux de travail couvre une zone très large.
Je voudrais ajouter mes commentaires. Lorsque vous choisissez un moteur prêt, comme jBPM, Activity et autres (il y en a beaucoup), alors vous devez passer un peu de temps à apprendre le système lui-même, cela peut ne pas être une tâche facile. Surtout, lorsque vous avez seulement besoin d'automatiser un petit morceau de code.
Ensuite, lorsqu'un problème survient, vous devez faire face à l'assistance du fournisseur, qui n'est pas aussi rapide que vous l'imaginez. Même payer pour certains conseils.
Et, enfin, une raison très importante, vous devez vous développer dans l'écosystème du moteur. Bien que les fournisseurs aient tendance à dire que leur système est flexible pour être incorporé à n'importe quel système, cela peut ne pas être le cas. Finalement, vous finissez par réécrire votre application pour l'adapter à l'écosystème BPM.
Je vous recommande d'utiliser une solution prête à l'emploi. Étant donné que le développement d'un moteur de workflow nécessite une grande quantité de ressources et de temps, un moteur prêt à l'emploi est une meilleure option. Jetez un œil à Workflow Engine . C'est un composant léger qui vous permet d'ajouter des workflows exécutables personnalisés de toute complexité à toutes les solutions Java.
Oui, à mon avis, il n'y a aucune raison pour que vous écriviez le vôtre. La plupart des frameworks Open Source BPM/Workflow sont extrêmement flexibles, il vous suffit d'apprendre les bases. Si vous choisissez jBPM, vous obtiendrez bien plus qu'un simple moteur de workflow, cela dépend donc de ce que vous essayez de créer.
À votre santé
J'ai récemment ouvert Piper ( https://github.com/creactiviti/piper ), un moteur de workflow distribué et très léger, basé sur Spring.
Vous pouvez regarder @ Apache Ant pour construire un moteur de workflow, beaucoup plus robuste et une machine à états pure avec la plupart des exigences nécessaires déjà intégrées.
En dehors de cela, vous pouvez également intégrer différents codes/scripts dynamiques dans le langage Java/Groovy/JS, ce qui le rend très puissant. Il permet également l'extension des tâches.
Il y a une bonne quantité d'outils autour d'elle ou vous pouvez construire dessus si un IDE est nécessaire.
Mise à jour: Spring State Machine est également disponible, relativement léger et non gonflé: https://projects.spring.io/spring-statemachine/