ERP et moteurs WorkFlow applicatifs

[freud]

Bonjour,

Voilà, ci-dessous, j’ai quelques définitions sur les ERP’s applicatifs et non collaboratif et souhaiterais comprendre certains principes sur leurs fonctionnements.

Un ERP se caractérise également par l'usage systématique d’un moteur de workflow (système permettant d’automatiser un flux d’information au sein d’une organisation) pas toujours visible par l’utilisateur, qui permet, lorsqu'une donnée est entrée dans le système d'information, de la propager dans tous les modules du système qui en ont besoin, selon une programmation prédéfinie

Es-ce que cette propagation des données est faite par un module indépendant (sous formes d’executables, de dll’s ) de tout les autres modules ?

Définition "formelle"
On parle d'ERP lorsqu'on est en présence d'un système d’information composé de plusieurs applications partageant une même base de données, par le biais d'un système automatisé prédéfini, éventuellement paramétrable (un moteur de workflow).

Es-ce que ce paramétrage du moteur workflow est effectuer dans ces tables de regles ?
et dont je supposerais aussi qu’il y a d’autres tables à construire pour ce moteur ?
Y-a-t-il un moyen de connaître l’architecture de ces moteurs ?

Je vous remercie pour toutes ces informations.

[kisitomomotene]

Envoyé par freud

Bonjour,
Es-ce que cette propagation des données est faite par un module indépendant (sous formes d’executables, de dll’s ) de tout les autres modules ?

Le module de workflow est généralement intégré dans l'ERP, il est même au coeur de l'ERP Compiere ou Adempiere c'est à dire beaucoup de fonctionnalités de compiere sont implémentées par son moteur de workflow. Mais pour l'ERP OpenBravo, il faudrait utiliser un moteur de workflow externe, toute fois il est prévu une intégration native d'un moteur de workflow dans la futur version de openbravo.

Es-ce que ce paramétrage du moteur workflow est effectuer dans ces tables de regles ?
et dont je supposerais aussi qu’il y a d’autres tables à construire pour ce moteur ?
Y-a-t-il un moyen de connaître l’architecture de ces moteurs ?

Je vous remercie pour toutes ces informations.

Dans l'ERP Compiere, il ne faut construire aucune table. A travers une interface graphique intuitive, un non programmeur peut ecrire un programme en remplissant des formulaires. Il peut également connaître le fonctionnement d'un programme en consultant le graph du workflow qui représente ce programme.

[freud]

Merci,

Mais comme il est dit :

lorsqu'une donnée est entrée dans le système d'information, de la propager dans tous les modules du système qui en ont besoin, selon une programmation prédéfinie....

Et si par exemple j'envisage de construire un ERP comment vais-je faire en sorte que le moteur propage cette donnée vers les autres modules ?

es-ce qu'il y a un suivi de cette donnée ?
Es-ce que ca a un rapport avec cette notion de successeurs et prédécesseurs que j'ai vu sur un thread ici ?

[kisitomomotene]

Envoyé par freud

Merci,

Et si par exemple j'envisage de construire un ERP comment vais-je faire en sorte que le moteur propage cette donnée vers les autres modules ?

es-ce qu'il y a un suivi de cette donnée ?
Es-ce que ca a un rapport avec cette notion de successeurs et prédécesseurs que j'ai vu sur un thread ici ?

Réaliser un workflow c'est écrire un progamme qui utilise un langage très proche de celui de l'expert métier, on peut même écrire ses programmes en remplissant des formulaires ou des assistants graphiques. Le moteur propage les données en lisant le programme que vous avez écrit

Par exemple si vous créez un bon de commande d'un nouvel abonné d'une société GSM , vous pouvez démander au moteur de workflow de transporter ce bon de commande et la présenter sous forme de formulaire au responsable des ventes pour qu'il valide les prix proposés. Après validation du responsable vous pouvez demander au moteur de workflow de transporter ce bon de commande vers un module de provisioning qui va créer cet utilisateur dans les équipements GSM, etc.

Les workflows implémentent tout simplement un modèle de programmation appelé Graph oriented programming ( l'OOP et l'AOP sont aussi des modèles de programmation) où certaines tâches sont éxécutées automatiquement et d'autres manuellement. Le moteur de workflow peut être vu comme un processeur qui exécute un programme que vous avez écrit au préalable. Chaque moteur de workflow a son langage.

La plus part d'ERP intégre tout simplement un moteur de workflow, donc c'est en lisant la documentation de ce moteur que vous saurez précisement comment y écrire des programmes

[freud]

......ce bon de commande et la présenter sous forme de formulaire au responsable des ventes ......

Ce formulaire sera un document ou un ecran au sein du programme ?

[kisitomomotene]

Envoyé par freud

Ce formulaire sera un document ou un ecran au sein du programme ?

c'est un ecran que le moteur de workflow sait comment générer. Les langages pour workflow contiennent des instructions/fonctions pour dire au moteur de workflow quel type d'écran il doit générer ("ecran de simple validation yes/no, ecran avec possibilité de choisir plusieurs options avant de valider etc..), quand est ce qu'il doit le générer, qui est autorisé a voir cet écran, qui est autorisé à faire des choix de validation etc. En plus, à partir de cet écran on peut avoir accès au document à l'origine du workflow (le bon de commande), on a aussi accès à l'historique des activités déjà effectuées par le moteur de workflow.

[freud]

Merci kisitomomotene jusque là c'est trés clair mais j'aimerais etendre le sujet
de mon post aux aspects techniques de programmation relatif
au moteur WORKFLOW et à son mode de fonctionnement. Enfin la maniere dont il stockes ces données, par exemple comment je pourrais suivre un bon de commande lorsque celui ci est génerer et que son workflow est generer aussi, enfin comment le faire valider dans sa tache suivante etc...
Si quelqu'un d'autre aurait des infos sur ca car j'ai abusé du temps kisitomomotene.

[kisitomomotene]

Envoyé par freud

Merci kisitomomotene jusque là c'est trés clair mais j'aimerais etendre le sujet
de mon post aux aspects techniques de programmation relatif
au moteur WORKFLOW et à son mode de fonctionnement. Enfin la maniere dont il stockes ces données, par exemple comment je pourrais suivre un bon de commande lorsque celui ci est génerer et que son workflow est generer aussi, enfin comment le faire valider dans sa tache suivante etc...
Si quelqu'un d'autre aurait des infos sur ca car j'ai abusé du temps kisitomomotene.

Tu ne me génes pas du tout freud au contraire.
Voici comment compiere par exemple implémente son workflow.
Il y a des tables qui stockent les informations concernant la définition du workflow ( c'est à dire des instructions que le workflow engine doit éxecuter) , et des tables qui stokent des informations sur l'éxécution du workflow lui même.
La définition d'un workflow contient notamment les info suivantes:
- une reférence à la table du document qui génére le workflow, dans notre cas une reférence vers la table des bon de commande.
- Les "Nodes" qui contiennent la définition proprement dite des instructions que le workflow Engine doit éxecuter. Si par exemple un Node doit éxecuter un process, son enregistrement correspondant dans la table Node va contenir la référence à ce process, Si le node doit permettre l'affichage d'une fenêtre de validation, son enregistrement correspondant dans la table Node va contenir l'identité de la personne autorisée à valider le workflow, le mode de validation (yes/no) etc. Chaque Node contient une référence vers le workflow qui le contient ( on peut voir un workflow comme une collection de Node)
- les transitions qui sont contiennent les informations sur l'ordre d'éxecution des nodes.
- des informations sur les conditions ou les événements qui doivent déclencher l'éxécution d'une transition.

Ensuite on a des tables qui gérent le stockage des informations sur l'éxecution du workflow lui même. Prenons l'exemple de l'enregistrement d'un bon de commande (on admet bien sûr qu'on a associé l'éxecution d'un workflow défini, à l'enregistrement d'un bon de commande). Lorsque le bon de commande est enregistré et que le workflow engine est appelé, celui ci sait qu'il s'agit d'un bon de commande, car la table de définition du workflow contient un "pointeur" vers la table des bon de commande. Et au moment de l'appel du WF engine, l'ID du bon de commande en cours est passé au workflow engine. Le WF engine stocke l'ID du bon de commande dans une table WFactivity, et à partir des informations contenues dans les tables qui définissent le workflow, il sait qu'il doit avoir une validation utilisateur. Le WFengine enregistre donc dans la table WFActivity l'état "suspendu", ainsi que des informations comme l'id de l'utilisateur autorisé à valider le WF, l'ID du bon de commande, la référence à la table des bon de commandes. L'application cliente de chaque utilisateur consulte réguliérement la table WFactivity pour savoir quelles sont les activités suspendues, et si l'utilisateur en cours est autorisé à valider. Si l'utilisateur en cours est autorisé à valider le WF, l'application cliente affiche alors le formulaire de validation et ce formulaire peut afficher le bon de commande qui a déclenché le WF, car la table WFActivity contient un "pointeur" vers la table des bon de commande, donc l'appli cliente sait qu'il s'agit d'un BC et en plus il sait exactement de quel BC il s'agit car l'ID du BC est aussi enregistré dans la table WFActivity . Quand l'utilisateur valide, le workflow Engine est de nouveau appelé, le WF engine ayant au préalable stocké l'ID du node encours d'éxecution(le node suspendu) ainsi que l'ID du workflow en cours dans la table WFActivty, il consulte alors les tables de définitions des workflows pour savoir quel sera le node suivant à éxecuter.

[freud]

ah c'est super ! et c'est trés clair !!
Je ne comprenais pas comment un moteur suivait dans le détail un bon de commande, demande congé ect...

Le sujet etant vaste semble-t-il mais moi je met résolu car il me manquait ce détail pour la compréhension des moteurs que je ne trouvais pas dans les docs
expliquant les ERP's ou PGI. Et je dois dire que ce n'est pas une mince affaire pour réaliser un moteur WF.

Merci infiniment kisitomomotene