Si les tables jBPM dans la base de données séparée?

Question

Il y a deux options lors de la configuration de votre session JBPM.

1. Vous pouvez mettre vos applications de jBPM dans la même session de mise en veille prolongée, et par conséquent, leurs tables dans la base de données avec les tables d'applications.

2. Vous pouvez mettre les applications de jBPM dans une session distincte de mise en veille prolongée, et les avoir dans une base de données séparée.

Je l'ai vu un article qui recommande la méthode 1, et je ne vois pas pourquoi car il vous permet d'avoir des références clés étrangères aux objets données JBPM directement. La seule question que je l'ai vu pop up est si vous essayez et enregistrez l'objet jBPM alors qu'un processus de JBPM est en cours d'exécution, vous obtenez une impasse sur la base de données.

Autre que cela, la méthode serait mieux, et pour quelles raisons?

Answer 1

Cela dépend de l'architecture que vous voulez construire.

Si vous voulez un composant de flux de travail géré de manière centralisée, où plusieurs applications différentes de communiquer avec une base de données unique est le chemin à parcourir.

Otoh, si flux de travail est spécifique à seulement certaines applications, il est préférable de garder les bases de données séparées. De cette façon, vous pouvez mettre à niveau jBPM plus tard dans certaines applications et le laisser tel qu'il est dans d'autres.

Mais vous pouvez aussi décider d'avoir un DB séparé pour chaque application, même s'il y a beaucoup. De cette façon, les performances d'exécution reste super car il n'y a pas de table énorme pour gérer)

Comme vous pouvez le voir, jBPM est très flexible dans la façon de l'intégrer dans votre architecture. Vous aurez donc besoin de faire l'analyse pour vous-même et décider quelle est la meilleure approche, prise en compte des évolutions actuelles et futures de de votre architecture.

Answer 2

Mettre les deux tables de votre application et jBPM dans 1 base de données vous permet de mettre à jour les tables de jBPM et vos données d'application en une seule transaction. Ceci est utile si, par exemple, vous souhaitez mettre à jour un attribut sur vos données d'application lorsqu'une tâche est effectuée en jBPM. Cela permet de garder vos données à partir d'obtenir endommagé. Sinon, si vous vous engagez votre transaction jBPM puis exécutez dans une question engageant votre transaction de données d'application, vous avez un problème assez grand ...

Answer 3

Nous avons eu un cas où nous avons décidé de garder la base de données de jBPM séparée afin de pouvoir mettre à jour la version ou peut-être utiliser un autre fournisseur quand il serait nécessaire pour différents clients. Comme mentionné plus haut, nous avons couru dans des situations où nous avons dû faire face à des séances de mise en veille prolongée séparées pour une seule opération au niveau de l'application. Afin de maintenir la cohérence dans ces conditions, nous avons décidé d'utiliser un outil appelé Atomikos