Discussion :

[pedouille]

Bonjour,

Je souhaite présenter le projet Open Source sur lequel je travaille depuis quelques mois.

Il s'agit d'un gestionnaire de processus (BPM) basé sur GWT côté client, Java/Tomcat côté serveur et MySQL pour la persistence.

Pour commencer, quelques screenshots :
Création d'un ticket
Exécuter une action
Résultats d'une requête

Le principe de ce BPM est de définir le processus de gestion à travers la structure de la base de données, afin de simplifier la rédaction des requêtes, et de s'affranchir de la création d'une syntaxe complexe autour de la définition du schéma. Vous trouverez plus d'info sur le fonctionnement du projet sur http://osbpm.axeiya.com.

A l'heure actuelle, ce projet n'est absolument pas abouti, et inutilisable. J'ai cependant défini un processus de base permettant de tester les quelques concepts implémentés (je n'ai même pas encore défini de numéro de version) disponible sur le site (http://osbpm.axeiya.com/?/Example-de...ts-and-defects)

Il n'y a pas non plus de roadmap actuellement ; je souhaite implémenter de nombreux concepts :
- Notification par email lors des actions paramétrable
- Rappel de notification paramétrable (nouvelle notification une heure après, un jour après, etc...)
- Création de requêtes personnalisées à partir d'un éditeur de requêtes pour chaque utilisateur
- Création de rapports graphiques simples (2 axes) basés sur les résultats d'une requête
- Gestion de l'historique complet de chaque ticket.

Par ailleurs, les fonctionnalités disponibles (partiellement implémentées) :
- Gestion des champs (textes, chaine de caractère et combobox seulement)
- Gestion des tickets
- Gestion des requêtes générales (rédaction en SQL seulement)
- Gestion des contraintes Action->Champ : champ obligatoire, valeur obligatoire lors de l'exécution d'une action (comparaisons textuelles seulement)
- Pièces jointes

Je serais ravi d'avoir des avis sur ce logiciel, principalement sur son interface utilisateur, qui est la partie la plus aboutie du projet, mais aussi sur les concepts implémentés ou à implémenter, et éventuellement sur une roadmap pertinentes (quels sont les besoins fondamentaux d'un tel logiciel ?).

Accès direct à la démo :
http://osbpm.axeiya.com/WebUI/WebUI.html
Utilisateur : demo
Mot de passe : demo
Base de données : osbpm

(Il faut parfois insister pour arriver à se connecter, le temps que Tomcat renégocie la connexion avec MySQL ; il faut absolument que je songe à régler ce pb :p )

Merci.

[rlegall]

Bonjour pedouille,

c'est pas mal pour un début Du coup j'ai quelques questions à propos de ton projet:

1) Comment prévois tu la définition des processus ?
2) L'interface graphique sera t elle générée automatiquement à partir de la définition du processus ou faudra t il définir une interface en GWT pour chaque formulaire?
3) Ce projet est il soutenu par une société? Si oui laquelle ?

Bon courage à toi et merci d'avance pour tes réponses.

--
Rodrigue

[pedouille]

Bonsoir,

Merci pour ce retour .

1) La définition des processus se fait uniquement dans la base de données MySQL, sous différents formes.
Les champs d'un enregistrement correspondent aux champs de la table dans la base de données (mapping entre les types MySQL et les widgets dans le formulaire avec à terme, la possibilité de forcer les widgets).
Les états d'un enregistrement sont également défini dans la structure de la base, par un type MySQL ENUM.
Les actions et les contraintes sont définies par des lignes dans des tables "systèmes" liées à l'enregistrement.
Enfin, les relations unaires (jointures) sont définies dans les commentaires d'un champ de l'enregistrement.

Un exemple, implémentée dans la démo :

Enregistrement "Defect" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE TABLE IF NOT EXISTS `record_defect` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `state` enum('void','submitted','refused','accepted','qualified','fix in progress','fixed','closed') NOT NULL DEFAULT 'void',
  `Summary` varchar(500) NOT NULL,
  `Description` text NOT NULL,
  `Severity` enum('critical','major','normal','minor','trivial') NOT NULL DEFAULT 'normal',
  `Target component` bigint(20) NOT NULL COMMENT 'REL component UNIQUE SHOW  Name',
  PRIMARY KEY (`id`)
)

Tout les champs de cette table seront repris pour alimenter le formulaire d'un Defect. Les champs Id et State sont obligatoires pour tout les enregistrements, et ils ne sont pas modifiables directement (Id renseigné automatiquement et State modifié par les actions sur l'enregistrement).
Petite subtilité pour le champ "Target Component" : Le commentaire défini la règle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
REL component UNIQUE SHOW  Name

qui défini un RELation unaire (UNIQUE) vers un enregistrement de type Component, en affichant (SHOW) le champ "Name" du composant dans le widget sur le formulaire.

Actions sur Defect :
Les actions sont des tuples de la table "transition_defect" (le nom de la table est de la forme transition_[recordName]). Sa structure est, quant à elle, fixe, et les tuples de cette table définissent les actions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11

INSERT INTO `transition_defect` (`from`, `to`, `actionName`) VALUES
('accepted', 'qualified', 'qualify'),
('fix in progress', 'fixed', 'end fixing'),
('fixed', 'closed', 'close'),
('qualified', 'fix in progress', 'start fixing'),
('refused', 'closed', 'close'),
('submitted', 'accepted', 'accept'),
('submitted', 'refused', 'refuse'),
('void', 'submitted', 'submit');

Le principe de fonctionnement sera le même pour les droits des utilisateurs (ou groupes) sur les actions et les notifications/rappels

Enfin, la définition des contraintes se fait dans une table de structure fixe, dont les tuples formalisent les contraintes.

Contraintes sur Version :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
--
-- Structure de la table `constraint_version`
--

CREATE TABLE IF NOT EXISTS `constraint_version` (
  `actionName` varchar(30) NOT NULL DEFAULT '',
  `constraintType` enum('mandatoryField','checkValue','freeConstraint') NOT NULL DEFAULT 'mandatoryField',
  `constraintValue` varchar(50) NOT NULL DEFAULT '',
  `message` varchar(255) NOT NULL DEFAULT '',
  PRIMARY KEY (`actionName`,`constraintType`,`constraintValue`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

--
-- Contenu de la table `constraint_version`
--

INSERT INTO `constraint_version` (`actionName`, `constraintType`, `constraintValue`, `message`) VALUES
('create', 'mandatoryField', 'Name', 'The name is mandatory');

La contrainte définie ici oblige le champ "Name" à être renseigné "mandatoryField" lors de l'action "create" ; si la contrainte n'est pas respectée, le message d'erreur "The name is mandatory" est remonté à l'utilisateur.

2)L'interface graphique est en effet générée automatiquement à partir des structures et des règles évoquées ci-dessus. Il n'y a aucun code Java ou autre à fournir.

3)Le projet est soutenu par ma société (Axeiya).

Merci pour tes questions, j'espère que mes explications sont claires.

[toomsounet]

Je ne peux pas juger ton application mais je trouve l'initiative très bonne !

J'aime bien l'utilisation de GWT.

Pourquoi ne pas utiliser une brique bpm open source comme jbpm?

[pedouille]

Merci ! En fait, j'ai souvent besoin de gérer des processus, même simples. Comme je voulais me former à GWT, j'ai commencé à travailler sur un moteur de workflow en Java, et son interface graphique côté client en GWT.

Je n'ai pas utilisé de brique Open Source car je n'ai jamais cherché à savoir si ce genre d'outils existaient déjà en Open Source, et que je voulais implémenter le logiciel de A à Z ; ça a aussi et surtout un intérêt didactique pour moi.

J'aimerai ajouter quelques fonctionnalités que j'ai oublié de préciser dans le premier post :

- Accès total en webservices au moteur
- Gestion des droits d'utilisateurs et groupes par action (un utilisateur ou groupe a-t-il le droit d'exécuter une action sur un enregistrement ?)
- Gestion des relations n-aires (seul les relations unaires sont implémentées actuellement)

[rlegall]

Salut,

je rejoins l'idée de toomsounet. L'utilisation d'une brique open source pour ton moteur est une bonne idée. La raison est assez simple: le développement d'un moteur de processus est quelque chose de très spécifique, complexe et long. Si ton intérêt se situe plus dans l'interface graphique via la technologie GWT, tu gagneras du temps et ton projet de la crédibilité en te basant sur une technologie prouvée.

Au niveau des moteurs de processus open source, perso je vais prêcher pour ma paroisse: Bonita est un moteur qui pourrait te séduire. De plus la dernière version a été entièrement redéveloppée et est basée sur une technologie développée conjointement entre les équipes du projet Bonita et celle de JBPM.
Pour plus d'info: http://bonita.ow2.org

Courage pour la suitede ton projet

--
Rodrigue

[pedouille]

Salut,

Comme tout projet Open Source, mon intérêt se situe surtout dans l'auto-formation.
S'il est vrai que développer une interface graphique riche avec GWT est quelque chose d'important pour moi, développer le moteur, si imparfait soit-il, l'est aussi.

De plus, je souhaite proposer un outil rapide à déployer (un war sur un serveur tomcat au plus et éventuellement la lib extJS à ajouter dans un dossier, question de licence...) afin d'éviter les complexités de déploiement à n tiers, avec des contraintes sur les versions etc...

Cependant, je pense intégrer à terme un outil d'import/export de schémas XPDL, afin d'être compatible avec les normes du domaine...

Un petit UP du projet :

J'ai ajouté une première ébauche du système de notification.
On peut décrire, pour chaque action sur un ticket, un email à alerter (soit en absolu, soit un email contenu dans un champ du ticket).
Je mettrai à jour le site dès que possible, et probablement traduire en français tout la doc "fonctionnelle" du projet. (La javadoc restera en anglais).

[pedouille]

Bonjour,

J'ai au final choisi d'héberger le projet en partie sur Google Code : http://code.google.com/p/osbpm/
Et créer une mailing liste en prévision des questions (lorsqu'une version "présentable" sera proposée) : http://groups.google.com/group/osbpm

Pour les news, je suis passé à SmartGWT côté client, GWT-Ext étant abandonné.

[pedouille]

Bonjour,

Quelques nouvelles sur OsBPM ; nous avons commencé la réalisation d'un éditeur de requête, qui permet de sélectionner les données, leur affichage, gère les jointure, et permet l'écriture de la clause WHERE

Démo : http://osbpm.axeiya.com/demo/
Utilisateur : demo
mot de passe : demo
Base de données : osbpm

Pour créer une nouvelle requête : General -> New Query

Pour faire une requete simple montrant les jointures : Sélectionner la table "enhancement". Dans cette table, sélectionner quelques champs (id, status, summary).
Sélectionner ensuite "Target Component" ; lors de la sélection de ce champ, l'éditeur fait automatiquement la jointure sur la table component, et sélectionne son champ "name".
Dans le tableau, vous pouvez sélectionner les champs à afficher à l'aide de la clause "SELECT" ; vous pouvez changer l'ordre des champs avec un drag n drop.
Vous pouvez également éditer la clause where à l'aide de l'éditeur au dessus du tableau.

Lorsque c'est fait, cliquer sur "generate query" ; le code SQL de la requete est édité ; enfin, vous pouvez enregistrer la requete en cliquant sur "save query", et en lui donnant un nom. Vous la verrez apparaître dans la liste des requetes "General".

Sinon, il y a eu quelques corrections de bugs, et du reformatage du code (qui est loin d'être fini).

Bonne journée

[Titi41]

Bonjour,

Je prends la suite des nouvelles sur OsBPM.
Je me présente rapidement : Je suis étudiant à l'UTC (4ème année) et j'ai effectué durant le 2ème semestre 2009 un stage de 6 mois dans l'entreprise Axeiya. J'ai alors travaillé sur le projet OsBPM.

Aujourd'hui, je continue à travailler dessus.
Quelques modifications ont été apportées au projet. Nous avons appliqué un pattern MVC. La documentation du code et du MVC a également progressé. Elle n'est cependant pas terminée. Elle est consultable sur le site google code du projet : http://code.google.com/p/osbpm/
J'ai également démarré la gestion des bugs et des exigences grâce aux outils de google code.

D'un point de vue fonctionnel, nous prenons en compte de nouveaux types de données (des listes d'éléments existant déjà dans le BPM, des tests et suite de tests fonctionnels).
Les tests fonctionnels ne semblent pas fonctionner sur la démo. Cependant, vous pouvez télécharger le code source et compiler sur votre propre machine. L'exécution des tests fonctionnels nécessite l'application Sélénium RC (http://seleniumhq.org/projects/remote-control/). Encore une fois, un tutoriel viendra compléter la documentation.

Bonne soirée
Romain