MemoireIng Tchoulegheu Iteration Finale PDF

UNIVERSITE DE YAOUNDE I UNIVERSITY OF YAOUNDE I
ECOLE NATIONALE SUPERIEURE NATIONAL ADVANCED SCHOOL OF

POLYTECHNIQUE ENGINEERING
DEPARTEMENT DE GENIE DEPARTMENT OF COMPUTER
INFORMATIQUE ENGINEERING
Industrialisation de la réalisation des Workflow

autour d'une plate forme de GED/BPM : Cas de
KoosseryGEDoc
Mémoire de fin d’études
Présenté et soutenu par :
TCHOULEGHEU NJEMOU Marcel Thierry

En vue de l’obtention du
Diplôme d’Ingénieur de Conception de Génie Informatique
Sous la Direction de :
Dr/PhD. Thomas DJOTIO NDIE
Ing. Prosper MENDOUGA, DG KoosseryTech CMR
Devant le jury composé de :
-Président : Thomas TAMO TATIETSE, Pr.

-Rapporteur : Thomas DJOTIO NDIE, CC.
-Membres : Rodrigue Carlos NANA MBINKEU, ASS.
: M. Olivier FOUDA
-Invité : Ing. Prosper MENDOUGA, DG KoosseryTech CMR
Année Académique 2010 – 2011
Date soutenance : 23 Juin 2011

Industrialisation de la réalisation des Workflow autour d'une plate forme de GED/BPM : Cas de KoosseryGEDoc|
DEDICACES
DEDICACES
A mes parents
Mr Njemou Yafa François

&
Mme Njemou née Tchotchepoué Mongoué Thérèse
Mémoire de fin d’étude présenté et soutenu par TCHOULEGHEU NJEMOU Marcel Thierry Page 2
REMERCIEMENTS
REMERCIEMENTS
Nos remerciements s’adressent aux personnes suivantes :
• Pr. Thomas TAMO TATIETSE, Directeur Adjoint de l’Ecole Nationale Supérieure

Polytechnique pour m’avoir fait l’honneur de présider ce jury.
• Pr. Claude TANGHA, Chef de département de Génie Informatique de l'ENSP, pour son
inestimable contribution à notre formation.
• Thomas DJOTIO NDIE, CC, Mon encadreur académique pour sa disponibilité, ses
remarques pertinentes, l’encadrement apporté tout au long de ces trois dernières années
d’étude au sein du Département Génie Informatique de l’ENSP.
• Rodrigue Carlos NANA MBINKEU, ASS et M. Olivier FOUDA pour l’honneur qu’ils
nous font en étant membre du jury.
• L’ingénieur Prosper MENDOUGA, invité ,Directeur de la société KOOSSERY

TECHNOLOGY CMR Sarl qui nous a permis de réaliser notre stage dans de très bonnes
conditions.
• L’ingénieur Baké Jc. BAKENEGHE pour sa rigueur au sein du training center.
• Les Ingénieurs Henvinno Diffo et Raphaël FONGANG, Vladivy Poaka pour leur
encadrement au sein du pool Ged/Doc tout au long de notre stage.
• Les ingénieurs, Ghislain PENKA, Cédric EVINA, et tous les autres employés de
KOOSSERY TECHNOLOGY CRM Sarl pour leur aide tout au long de notre stage.
• Mes frères Njemou : Willy, Edwige, Didier, Émeric, Judith, Berriane pour leur soutient et
leur encouragement
• A Mr & Mme Djomo Gerhard pour leur hébergement et leur encadrement
REMERCIEMENTS
• Tous les enseignants de l'ENSP, pour leur encadrement et leur dévouement tout au long
de notre formation.
• Mes camarades de stage Iselin Mfeubi, Gilles Djila,Silvère Djam ,Axelle Ngonpa, pour
tous les moments difficiles et gais passés durant notre formation académique durant que
ces quatre mois de stage.
• Mes camarades de classes Billong IV, Yomi ,Mbollo qui ont été des frères pour moi.
• Je remercie particulièrement Nguimbous,Nestorette,Ricardo,Marie pour la relecture de

ce mémoire.
• Tous ceux que nous avons omis de citer ici, et qui de près ou de loin ont contribué au bon
déroulement de ce stage.
GLOSSAIRE
GLOSSAIRE
BPA Business Process Automation

BPEL Business Process Execution Language
BPM Business Process Management
BPMI Business Process Management Initiative
BPMN Business Process Model Notation
BPMN Business Process Modeling Notation
DPR Diviser Pour Régner
DSI Direction des Systèmes d’Information
ECM Entreprise Content Management
EIM Enterprise Information Management
ERP Enterprise Resources Planning
GED Gestion Electronique des Documents
IBM International Business Machines
IDE Integrated Development Environment
IT Information Technology
jBPM Java for Business Process Management
KTC Koossery Technology Cameroun
OASIS Organization for the Advancement of
Structured Information Standards
PME Petites et Moyennes Entreprises
SI Système d'Information
WfMC Workflow Management Coalition
WfMS Workflow Management System
XPDL XML Process Definition Language
RESUME
RESUME
Les entreprises sont de plus en plus demandeuses de solutions leur permettant de structurer
leurs échanges d’informations au sein de leur système d’information. Chez Koossery
Technology, nous avons observés cette tendance par l’arrivée de nombreux projets incluant
des problématiques BPM fortes autour de la solution d’ECM/GED KoosseryGEDoc.
En effet il faut d’une part permettre à un expert fonctionnel de paramétrer lui-même ses
propres services dans une application déployé chez lui. D'autres parts faciliter le travail du
développeur et lui permettre de produire rapidement du code métier.
Pour ce faire, nous adoptons une démarche itérative qui consiste à combiner plusieurs
outils. En effet nous avons intégré un outil de gestion du projet pour organiser le projet de
bout en bout, un outil de modélisation graphique pour formaliser la définition des processus
métiers, un moteur de règle pour exécuter et mettre à jour rapidement sans passer par un long
processus de maintenance, le tout baignant sur un serveur d’application entreprise. Nous
avons fait évoluer le moteur de Workflow existant afin de bénéficier des atouts du Framework
technique Koossery.
Nous avons obtenu Koossery Workflow, un chaine d'outils logiciels hétérogènes intégrée,
extensible, évolutive, orientée processus. On ne fait recourt au code que pour des problèmes
complexes. Toute fois nous espérons après tests et améliorations arriver à fournir une
interface complète aux experts fonctionnels de production d’application sans intervention
extérieur.
MOTS CLÉS: BPM, Workflow, industrialisation, ECM, GED.
ABSTRACT
ABSTRACT
Companies are increasingly in demand for solutions enabling them to structure their
exchange in their information system. At Koossery Technology, we have observed this trend
with the arrival of many projects including high BPM issues.
Indeed we must first allow a business user to set itself its own services in an application
deployed. Other shares we have to facilitate the work of developers and allow them to quickly
produce the business code.
To do this, we adopt an iterative process of combining several tools. Indeed we have built a
project management tool to organize the project from beginning to end, a graphical modeling
tool to formalize the definition of business processes, a rule engine to run and update quickly
without going through a long process maintenance, all bathed in an application server
company. We have changed the Workflow engine to take advantage of existing strengths of
the Technical Framework Koossery.
We got Koossery Workflow, a chain of software tools integrated heterogeneous, extensible,

scalable, process-oriented. It uses the code does that for complex problems. Any time we hope
after testing and improvements come to provide a complete interface with functional experts
to produce application without external intervention.
KEY WORDS: BPM, Workflow, industrialization, ECM, EDM.
LISTE DES FIGURES
LISTE DES FIGURES
Figure 1 Rôle des Model en BPM [Havey2005] ..................................................................................16

Figure 2 Cycle de Vie DU BPM [Mitra2011]........................................................................................17
Figure 3 Cycle de vie des Tâches [Hofstede, Aalst2010] ....................................................................20
Figure 4 Architecture de KoosseryGEDoc [Djam2011] ....................................................................... 21
Figure 5 Architecture de openWFE [Hofstede, Aalst2010] ................................................................. 23
Figure 6 Architecture de Bonita[Anguela2010] ..................................................................................24
Figure 7 Architecture Enhydra Shark [Hofstede, Aalst2010]...............................................................25
Figure 8 Comparaison des éditeurs de Workflow [Valtech, ICCS] ......................................................26
Figure 9 Comparaison des moteurs de Workflow [Valtech, ICCS].......................................................26
Figure 10 Architecture jBPM [Hofstede, Aalst2010] .......................................................................... 27
Figure 11 Diagramme de Cas d'utilisation..........................................................................................30
Figure 12 Architecture solution d'un projet BPM [Havey2005] ..........................................................33
Figure 13 Architecture globale de la chaîne d'industrialisation ..........................................................35
Figure 14 Composant sur postes Fonctionnels...................................................................................36
Figure 15 Postes Développeurs .........................................................................................................37
Figure 16 Démarrer un Workflow......................................................................................................43
Figure 17 Voire les tâches complètes ................................................................................................44
Figure 18 réassigner une tâche .........................................................................................................45
Figure 19 File Workflow Détail ..........................................................................................................46
Figure 20 Réassigner une tâche .........................................................................................................47
Figure 21 Projet maven de Koossery Workflow .................................................................................48
Figure 22 Services offerts par Koossery Workflow .............................................................................48
Figure 23 Matrice de RACI .................................................................................................................54
Figure 24 Workflow approbation du crédit ........................................................................................55
Figure 25 Processus credit sous eclipse .............................................................................................56
Figure 26 Planification du projet ....................................................................................................... 57
Figure 27 Interface de prototypage de fomulaire ..............................................................................57
Figure 28 Génération automatique de Formulaires ...........................................................................58
Figure 29 Palette d'outils graphiques ................................................................................................59
Figure 30 Prototypage graphique avec jBossTools .............................................................................59
Figure 31 Déploiment du workflow ................................................................................................... 60
SOMMAIRE
SOMMAIRE
DEDICACES..........................................................................................................................................2
REMERCIEMENTS ................................................................................................................................3
GLOSSAIRE ..........................................................................................................................................5
RESUME ..............................................................................................................................................6
ABSTRACT ...........................................................................................................................................7
LISTE DES FIGURES ..............................................................................................................................8
SOMMAIRE .........................................................................................................................................9
CHAPITRE 1. INTRODUCTION GENERALE ...................................................................................11
1.1 Contexte............................................................................................................................11
1.1.1 Présentation de Koossery Technology ........................................................................ 11
1.1.2 Contexte du travail ....................................................................................................12
1.2 Problématique et positionnement .....................................................................................13
1.3 Motivation et objectifs ......................................................................................................13
CHAPITRE 2. ETUDE DE L’EXISTANT ...........................................................................................15
2.1 Etat de l’art-Business Process Management.......................................................................15
2.1.1 Définition...................................................................................................................15
2.1.2 Cycle de vie du BPM ................................................................................................... 16
2.2 Les workflow dans KOOSSERYGEDOC .................................................................................20
2.2.1 La solution de GED/ECM de KTC .................................................................................20
2.2.2 Les workflow dans KoosseryGedoc ...................................................................................21
2.3 Critique de l’existant.......................................................................................................... 22
2.3.1 Les Systèmes de gestion de workflow ........................................................................ 22
2.3.2 Existant a koossery technologies ................................................................................27
CHAPITRE 3. ANALYSE ET CONCEPTION .....................................................................................29
3.1 Analyse..............................................................................................................................29
3.2 Démarche de résolution ....................................................................................................30
3.3 Architecture de notre solution ...........................................................................................34
Description détaillée des poste de Production ...........................................................................35
SOMMAIRE
CHAPITRE 4. REALISATION DE LA SOLUTION ..............................................................................39

4.1 Outillages ..........................................................................................................................39
4.2 implementation de koossery workflow ..............................................................................42
CHAPITRE 5. ETUDE DE CAS .......................................................................................................52
implémentation d’un workflow de demande de credit .................................................................. 52
CONCLUSION .................................................................................................................................... 61
bilan..............................................................................................................................................61
Perspectives.................................................................................................................................. 62
REFERENCES BIBLIOGRAPHIQUES......................................................................................................63
Bibliographie................................................................................................................................. 63
Webographie ................................................................................................................................63
ANNEXES .......................................................................................................................................... 65
INTRODUCTION GENERALE
CHAPITRE 1.
1.1 CONTEXTE
1.1.1 PRESENTATION DE KOOSSERY TECHNOLOGY
KOOSSERY TECHNOLOGY CMR (KTC) est une entreprise spécialisée en conseil et

ingénierie informatique. Profitant des avancées actuelles en technologies de l’information,
Koossery Technology Cameroun améliore sans cesse la pratique de ses missions de conseil et
d’ingénierie en système d’information. Ses solutions inspirées en permanence de l’univers des
Innovations et des ‘Best Practices ‘ aux standards mondiaux, lui permettent de porter son
approche partenariale et sa vision agile.
Koossery Technology développe ses solutions autour des métiers de l’Audit conseil(SI), et
l’intégration de Business solutions (ERP, GED, Gestion des établissements de micro finance).
• Pour apporter une solution conforme aux besoins et aux contraintes de ses partenaires,
KTC effectue une phase préalable d’analyse technique des ressources du Système
d’Information(SI) existant, à travers l’audit de sa situation informatique.
• KTC déploie alors des solutions d’infrastructure qui repose principalement sur
l’approche open source, pour répondre aux contraintes de coûts et de gestion des
licences pour certains de ses partenaires.
Koossery Technology offre les solutions technologiques suivantes :
• Audit et conseil
• Infrastructure technique et Offre Koossery IT management
• Fabrication d’applications spécifiques
• Business solution
Elle s’appuie sur :
• Des équipes d’ingénieurs de haute technicité qui peuvent être des Architectes ou des
Concepteurs/Développeurs. Ils sont répartis au sein d’équipes de développement encore
appelés <<pool>>. Nous avons eu l’opportunité de faire partie du pool
GED/ECM/BPM/PORTAL.
• Un Centre de Support Technologique, KOOSSERY TECH’ Lab, centre de veille

technologique, de capitalisation et de diffusion des avoirs acquis.
1.1.2 CONTEXTE DU TRAVAIL
Koossery Technology comme la majorité des sociétés de développement se dote des

dernières technologies en matière de fabrique logicielle. Au moment où nous arrivons en
stage le pool Ged/Doc, voudrait fournir ses solutions à grande échelle et de façon
pragmatique. Ceci passe par un projet de ré-architecture de la principale solution
KoosseryGEDoc (Powered by Alfresco). Cette dernière est une solution de gestion
électronique de document (GED) qui inclue les aspects procéduraux de Workflow et de travail
collaboratif. Les Workflow permettent de formaliser et de fluidifier les processus d’entreprise,
via l’enchaînement des tâches unitaires entre différents acteurs. Cependant, les processus sont
différents selon le secteur d’activité, les pratiques, ou encore la taille des entreprises et
peuvent changer régulièrement. Ceci a pour conséquence directe de recourir à un nouveau
projet de développement manuel chaque fois qu’un besoin nouveau se fait ressentir. Pour
palier à ce problème le BPM (Business Process Management ) nous offre un ensemble d'outils
et de moyens pour représenter la capacité à décrire, modéliser, automatiser, structurer, suivre,
analyser, et informatiser les processus d'une entreprise
1.2 PROBLEMATIQUE ET POSITIONNEMENT
Actuellement aussi bien chez Koossery Technology que dans la plupart des entreprises
offrant des services GED, la définition et le déploiement d’un Workflow se fait par une
succession d’étapes manuelles et n’est réservé qu’aux développeurs .D’autres encore utilisent
des outils propriétaires qui sont rarement utilisés dans les Petites et Moyennes Entreprises
(PME) à cause de leur coût d’acquisition très élevé. Comment alors proposer rapidement de
nouvelles applications qui répondent aux besoins des utilisateurs fonctionnels et qui
complètent l’existant applicatif sans le remettre en cause? Comment faciliter le travail des
développeurs en combinant agilité et composants évolutifs?
1.3 MOTIVATION ET OBJECTIFS
L’objectif principal de Koossery Technology est de s’imposer en tant que leadeur de

développement d’application en général. Dans cette optique cet outil lui permettra de s’aligner
dans les standards mondiaux en matière de fourniture de service GED/BPM de qualité.
L’objectif technique est de réaliser une chaîne de production logicielle qui fait coopérer des
utilisateurs de profils variés mais impliqués dans les mêmes processus d’entreprise, en leur
fournissant des interfaces adaptés à leur mission Avec cette solution, Koossery pourra
désormais faire du BPM en «toute simplicité» avec un recours au code réduit, en s’appuyant
sur la description graphique des processus.
En résultat nous aurons :
• un outil pour rationaliser la gestion des processus métiers en tenant compte de la nouvelle
solution que nous aurons au préalable réarchitecturée
• L’allègement du temps de production d’une brique logicielle destinée à KoosseryGEDoc

(Powered by Alfresco) et fournissant un service bien précis.
• Permettre une production à grande échelle avec un minimum de coût sur les copies.
Pour atteindre ces objectifs, nous avons proposé une solution autour de « l’Industrialisation
de la réalisation des Workflow autour d'une plate forme de GED/BPM : Elle s’articule en 5
points.
Le Chapitre 2. Etude de l’existant : cette partie fera un tour d’horizon sur les technologies
et standards régissant le BPM. Nous y mènerons une étude critique de ce qui se fait
actuellement à KTC. Puis nous annoncerons notre démarche de solution.
Le Chapitre 3. Analyse et conception : cette partie présente tout d’abord une démarche
générale d’exécution des projets BPM, ensuite nous proposons une démarche particulière
destinées aux projets GED. Enfin nous fournirons l’architecture solution adoptée ainsi que les
axes d’améliorations.
Le Chapitre 4. Réalisation de la solution : cette partie se focalise sur les aspects techniques
qui ont concouru à la réalisation de la solution. Elle insiste ensuite sur l’intégration de notre
système avec l’extérieur.
Le Chapitre 5.Etude de cas : dans cette partie nous décrirons un problème réel et
appliquerons notre démarche de résolution pour illustrer notre concept. Elle dégagera ensuite
les gains obtenus par l’utilisation de notre chaine de production.
Conclusion : dans cette partie nous ferons un bilan de notre travail et donnerons les
perspectives à envisager pour le futur.
ETUDE DE L’EXISTANT
CHAPITRE 2.
Dans ce chapitre nous présentons les tentatives de solutions existantes pour répondre au
problème de l’automatisation des processus métiers. Nous menons ensuite une étude critique
de ce qui se faisait avant que nous n’arrivions à KTC. Et enfin nous introduisons des axes de
solutions.
2.1 ETAT DE L’ART-BUSINESS PROCESS MANAGEMENT
2.1.1 DEFINITION
Le Business Process Management (BPM) consiste à modéliser et à automatiser les
processus métiers d’une entreprise. C’est un moyen de communication partagé entre les
différents intervenants : managers, DSI, utilisateurs, experts BPM, directions métier… Le
processus est donc l’élément fondamental dans cette démarche et sert de point de départ pour
comprendre comment fonctionne l’entreprise. Quelles sont ses pratiques et quels bénéfices on
peut tirer en rationnalisant ses activités. De part sa dénomination, Business Process Modeling,
on comprend que le model est au centre de cette technique. Pour cette raison il est important
sur plus d’un plan. Premièrement, il est un outil qui permettra aux différents intervenants du
projet de discuter des orientations à prendre. Deuxièmement, il est utilisé pour analyser le
système et ces processus. Enfin, il est un outil de vérification et de tests de conformité. La
Figure 1 ci-dessous résume l’importance des modèles en BPM.
Figure 1 Rôle des Model en BPM [Havey2005]
2.1.2 CYCLE DE VIE DU BPM

Dans cette section nous décrivons le cycle de vie du BPM. Ce dernier va nous servir de base
pour décrire le cycle de vie dans notre suite logicielle. Actuellement, il n’existe pas de modèle
uniformisé pour la représentation de ce cycle. Dépendant de plusieurs critères on distingue
différents schémas. Ces phases sont toutes basées sur PDCA (Plan DO Check
ACT)[Wikipedia2011] qui est un processus itératif pouvant résoudre la majorité des projets
de BPM en général .
La Figure 2 présente le cycle de vie de BPM utilisé par IBM.
Figure 2 Cycle de Vie DU BPM [Mitra2011]
Selon IBM Software group[Mitra2011], ces phases sont décrites comme suit :
Envisager
Dans cette phase on définit et documente les objectifs de l’entreprise .Les indicateurs de
performance KPI (Key Performance Indicator); les objectifs sont analysés et combinés aux
exigences de performance. Une vision de la solution BPM est développée et une stratégie de
conduite du changement envisagée.
Evaluer
C’est dans cette phase que l’on modélise le processus si celui n’existe pas encore. Au cas
contraire on envisage une amélioration de celui ci. La vision du projet est réévaluée. Et rendue
réaliste en incluant l’architecture de la solution, le Framework technique, méthodologique, les
métriques sont mises sur pieds.
Définir
Cette phase définie l’étape suivante des processus de l’entreprise à développer. On fait des
simulations des processus implémentés et on définit les composants métiers qui constitueront
l’architecture technique.
Executer
Dans cette phase, les modèles de processus et les composants architecturaux existants sont
compilés, intégrés, assemblés, déployés et analysés.
Optimiser
Dans cette phase on détermine les principaux axes d’amélioration et le cycle recommence.
2.2.1 STANDARD DU BPM [Hofstede, Aalst2010]

Au fil des années il y a eu beaucoup d’approches de spécifications des processus. Avec le
temps, un certain nombre de normes et/ou approches couramment employées ont émergé.
Nous parlerons de certaines brièvement dans cette section.
XPDL : XML Process Définition Language [Hofstede, Aalst2010]
Définit par le Workflow Management Coalition (WfMC), c’est l’une des premières approches
de définition de processus exécutables. Il a été inventé pour faciliter l’interopérabilité entre
les environnements de Workflow.
BPEL: Business Process Execution Language [Hofstede, Aalst2010]
Proposé en 2003, ce langage combine XLANG (Web Services for Business Process Design)
de Microsoft et Web Services Flow Language (WSFL) d’IBM, deux approches
fondamentalement différentes de spécification des processus exécutables. Il a été standardisé
par l’organisation OASIS (Organization for the Advancement of Structured Information
Standards). Il définit une structure en block et supporte les dépendances de control de flux. Le
fichier BPEL définit le processus, l'enchaînement et la logique des actions qui seront
exécutées par le moteur d'orchestration.
BPMN: Business Process Modeling Notation[Havey2005, Hofstede, Aalst2010]
Il a été introduit par le Business Process Management Initiative (BPMI) pour faciliter la
compréhension et l’utilisation des notations graphiques utilisées pour le front end des
approches variées de l’exécution des processus métiers. C’est un langage qui peut être utilisé
aussi bien par les analystes que par les développeurs pour représenter les processus métiers
sous une forme visuelle intuitive. Le BPMN fournit un support pour la spécification des
dépendances dans le control des flux et une structure orientée graph.
a) La montée en gamme avec Les Workflow Patterns 1

L’initiative des Patrons de Workflow, de l’anglais << Workflow Patterns >> a pour but
d’identifier les constructions génériques et récurrentes de problèmes de BPM. On dénombre
aujourd’hui 126 patrons de Workflow[Aalst, Barros2011].
Dans cette section nous présenterons les 3 principales catégories de patrons avec quelques
exemples.
• Les patrons de control ou Control Flow Patterns :

Ils décrivent les fonctionnalités nécessaires au control de l’ordre d’exécution des différentes
tâches qui constituent le business process. Ils peuvent être subdivisés en huit groupes
distincts selon leur application. On distingue : les patrons de branchement, de synchronisation,
de répétition, d’instances multiples, de concurrence, d’annulation, de terminaison, et les
trigger.
• Les patrons de Données ou Data Patterns

Ils permettent de décrire les fonctionnalités nécessaires à la manipulation des données au
cours de l’exécution du business process. On distingue : La visibilité de données, l’interaction
entre les données, le transfert de données.
• Les patrons de Ressources ou Ressource Patterns

Ils caractérisent la façon dont les ressources associées à un processus sont distribuées et
gérées du démarrage jusqu'à son achèvement. On distingue le patron de création, de poussée,
de tirée, de détour, de démarrage automatique, de visibilité, de ressources multiples. Ces
patrons dépendent fortement de l’état auquel une ressource est associée à une tâche spécifique
à un moment du cycle de vie. La Figure 3 ci-dessous illustre le cycle de vie d’une des tâches
d’un Workflow.
Le site suivant dédié aux patrons de Workflow pourrait servir de référence : www .workflowpatterns.com
Figure 3 Cycle de vie des Tâches [Hofstede, Aalst2010]
2.2 LES WORKFLOW DANS KOOSSERYGEDOC
2.2.1 LA SOLUTION DE GED/ECM DE KTC

KoosseryGEDoc est un outil d’ECM (Entreprise Content Management) construit à partir du
noyau d’Alfresco. Il hérite donc des fonctionnalités et de l’architecture d’Alfresco. La
solution KoosseryGEDoc est destinée aux organisations et peut être accessible lors de
l’exécution à partir de l’Intranet, de l’extranet de l’organisation et même d’internet. La
solution KoosseryGEDoc offre plusieurs fonctionnalités reparties en trois modules :
• la gestion du courrier,
• l’archivage numérique,
• la GED et les processus métiers.
A notre arrivée au sein de l’équipe, cette solution est en pleine ré-architecture la Figure 20
présente la nouvelle architecture adoptée de KoosseryGEDoc.
Figure 4 Architecture de KoosseryGEDoc [Djam2011]
Cette architecture sera le socle de la réalisation de notre module : Koossery Workflow.
2.2.2 LES WORKFLOW DANS KOOSSERYGEDOC
KoosseryGEDoc intègre le moteur jBPM et supporte 2 principaux types de Workflow :
Workflow simples[KOUAM and Baké2009]

Le Workflow simple d'Alfresco est le mouvement des documents à travers les espaces
(dossiers) : il est possible d'attacher un Workflow simple à un document et de notifier les
collaborateurs qui peuvent traiter le document. Ces collaborateurs peuvent effectuer des
opérations Approval et Reject. A partir des règles de gestions il est possible de réaliser le
déplacement des documents entre espaces en fonction de l'état du document et de l'action
effectuée sur le document. L'implémentation de cette catégorie basique de Workflow ne
nécessite pas de code. Il s'agit ici d'implémenter le business process à partir de la plateforme
directement dans le Client Web.
Workflow avancés[KOUAM and Baké2009]

Une autre catégorie plus importante est celle des Workflow complexes (Advanced
Workflow). Alfresco utilise le moteur jBPM (JBoss Business Process Management) dans son
noyau. Alfresco a extrêmement rendu ce moteur extensible pour le développement de

Workflow complexes basés sur des processus orientés tâches (délégation de tâches à des
collaborateurs et des groupes de collaborateurs, avec un timing, des délais, des notifications
email etc...). Alfresco utilise le langage de Workflow jPDL pour l'expression de processus
métiers de façon graphique ou manuel (XML) en termes de tâches, d'état d'attente, de
synchronisation de la communication, de timers et d'actions automatisées.
2.3 CRITIQUE DE L’EXISTANT
2.3.1 LES SYSTEMES DE GESTION DE WORKFLOW

Le but de cette section est de faire un tour d’horizon sur les WfMS. En effet nous avons
réalisé cette étude afin de choisir celui qui sera intégré dans notre solution. Nous nous
sommes basés sur les statistiques de téléchargement et sur les fonctionnalités les plus
courantes des WfMS. Nous discuterons sur les différentes approches d’implémentations
utilisée par les différents éditeurs et solutions.
OpenWFEru [Hofstede, Aalst2010] : Encore appelé Ruote, c’est un WfMS développé en

Ruby . Il consiste en un ensemble de composants présentés sur la Figure 5 ci-dessous.
Figure 5 Architecture de openWFE [Hofstede, Aalst2010]
Comme limites nous avons constaté que cet outil n’était réservé qu’aux développeurs. De
plus, son langage de définition des processus est une notation textuelle structurée ressemblant
à un langage de programmation. Ce qui rend fastidieux le travail du développeur. Toute fois
ce dernier peut avoir recours à un éditeur tiers XML ou Rugby pour alléger son travail.
Bonita Open Solution[Anguela2010] : Développé par Object Web et Bull, ce moteur est
également orienté J2EE. Son interface est conviviale, et orientée Web 2.0. L’équipe derrière
le projet est très active, et les mises à jour sont très fréquentes. Il permet de designer un
processus depuis une palette BPMN 2.0 et de générer automatiquement l’application web
correspondante. En outre il offre une panoplie de connecteurs permettant de connecter et
exécuter l’application java Workflow sur les systèmes existants (oracle, Alfresco, twitter,
Facebook,…) via un simple click. La suite BPM Open Source BonitaSoft [www2011] a
reçu plusieurs distinctions dont la plus récente est le prix <<Meilleur outil de Modélisation >>
à « EclipseCon 2011 » . Son architecture est représentée dans la figure ci-dessous.
Figure 6 Architecture de Bonita[Anguela2010]
OSWorkflow[Hofstede, Aalst2010] : Un moteur de Workflow assez spécial puisqu’il impose

aux designers d’écrire tous les processus “From Scratch” en XML. Très fastidieux, mais
extrêmement efficace pour des processus compliqués, et permet plus de flexibilité que les
outils graphiques.
Enhydra[Hofstede, Aalst2010] : c’est un moteur de Workflow java open source. Son

architecture permet aussi bien l’utilisation d’un code fortement couplé que l’utilisation des
plug-ins pour l’étendre. Son architecture comporte un moteur de Workflow nommé SHARK.
Un outil de définition des processus appelé TWE Together Workflow Editor, une console de
management, TWS Admin qui est aussi bien un client Workflow qu’un outil d’administration
ou de monitoring
Figure 7 Architecture Enhydra Shark [Hofstede, Aalst2010]
Taverna[Hofstede, Aalst2010] : Développé en milieu universitaire, il a la particularité d’être

développé en Java Swing, ce qui permet une installation facile sur quelques postes, mais un
déploiement problématique si on ne dispose pas d’un parc conséquent.
Nuxeo EP [Hofstede, Aalst2010]: Beaucoup plus qu’un simple moteur de Workflow, Nuxeo
Entreprise Platform fournit aux utilisateurs des espaces de travail collaboratif comprenant le
partage de documents, la gestion des versions, les relations, les droits d’accès, des Workflow
Les Figure 8 et Figure 9 donnent le résultat d’une étude comparative menée conjointement par
Valtech ,ICCS et UAM.
Figure 8 Comparaison des éditeurs de Workflow [Valtech, ICCS]
Figure 9 Comparaison des moteurs de Workflow [Valtech, ICCS]
L’étude de ces différents WfMS nous révèle que plusieurs méthodes sont employés par les
Editeurs ou les solutions offrent une suite d’outils (moteur, simulateur, …) pour répondre aux
besoins précis.
Notre choix a été définitivement orienté vers jBPM, car supportant le plus de standards
pris en charge par KoosseryGEDoc.
2.3.2 EXISTANT A KOOSSERY TECHNOLOGIES
La solution KoosseryGEDoc (Powered by Alfresco) inclue en son sein le moteur de

Workflow JBOSS jBPM 2 version 3.2. Ce dernier inclue le moteur de Workflow de JBOSS
écrit en java. Selon les statistiques de téléchargements de SourceForge, il est de loin le
Workflow Management System (WfMS). Le plus populaire, le plus téléchargé d’un
entrepôt de code open source. Dans cette section nous présentons l’architecture détaillée de ce
WfMS ainsi que les insuffisances constatées.
a) Architecture de Jboss jBPM
Figure 10 Architecture jBPM [Hofstede, Aalst2010]
2
www.jboss.com/products/jbpm
L’architecture ci-dessus contient les composants suivant :
• Le jBPM core component ou core process engine, est le moteur de Workflow qui
s’occupe de l’exécution des instances de processus.
• Un outil de définition du processus appelé jBoss jBPM Graphical Process Designer

(GPD). C’est un plug-in éclipse qui fournit un support de jPDL.
• Un client d’administration nommé jBPM console ; c’est un client web à travers lequel on
peut initier et exécuter les différentes activités d’un Workflow. C’est aussi un outil
d’administration des instances de Workflow en cours.
JBPM fournit 2 types de mécanismes d’accès : la gestion des utilisateurs qui est prédéfinie et
la gestion des groupes qui est définie par un utilisateur. On distingue les rôles user, manager
et administrator.
b) Critiques
Ici nous relevons les limites trouvées dans les différentes composantes de jBPM.
jBPM, nous l’avons vue propose un outil pour modéliser le Workflow. Mais ce dernier
comme la majorité nécessite une formation pour être utilisé par un public non développeur.
Aussi il faut écrire encore à la main des fichiers XML de configuration (contexte, model, …).
Nous proposerons des axes d’amélioration de notre architecture afin de minimiser le

recours au développement en fournissant des interfaces intuitives.
ANALYSE ET CONCEPTION
CHAPITRE 3.
Une fois le tour des technologies effectué, nous présentons dans ce chapitre la démarche que
nous avons utilisée pour analyser et concevoir notre solution. Nous décrivons à chaque étape
la démarche à utiliser et les artéfacts à produire. De cette démarche nous déduisons
l’architecture solution finale.
3.1 ANALYSE
Nous avons mené une analyse de notre système et les différentes interactions entre notre
application et son environnement. Nous avons considéré l’ensemble des acteurs qui
interagissent sur le processus des entreprises, afin de déterminer les intentions d’acteurs et les
différents cas d’utilisation.
Cas d’utilisation
Nous avons pu recenser les acteurs suivants:
• Les utilisateurs finaux ou utilisateurs métiers : qui subissent les modifications des
processus métiers de l’entreprise.
• Les experts fonctionnels qui ont la vision globale des objectifs et de la politique globale
de l’entreprise. Ils agissent directement sur les Workflow et peuvent le modifier à souhait.
• Les développeurs : Ils se chargent principalement de produire le code métiers nécessaire à

l’exécution du Workflow tels que spécifier par l’expert fonctionnel.
La Figure 11 résume les cas d’utilisation génériques des acteurs récences dans notre
écosystème.
Figure 11 Diagramme de Cas d'utilisation
Ces acteurs pour accomplir leurs intentions ont besoin de collaborer, et de s’échanger les infos
à plusieurs niveaux. En effet les développeurs ont besoin de l’aide des experts fonctionnels
pour avoir une description détaillée du processus à développer. Les experts fonctionnels quant
à eux utilisent les statistiques d’exécution des processus et par les utilisateurs ou les
manageurs pour mener à bien leur travail. Connaissant les acteurs et leurs interventions
génériques sur le système, il nous faut maintenant définir une démarche globale pour pouvoir
résoudre tout problème de Workflow susceptibles d’être soumis à notre système
3.2 DEMARCHE DE RESOLUTION
Notre « industrie » doit pouvoir implémenter et déployer tout type de Workflow, les
spécifications fonctionnelles passées en paramètre. Pour ce faire nous fournissons une
démarche générique de résolution de problème en prenant comme domaine d’application le

BPM. Ceci nous assure une résolution de tous problèmes de Workflow car ce dernier n’en est
que restriction.
Nous décrivons ici les étapes pour aboutir à l’architecture générale d’une application de BPM
conceptuellement compréhensible et répondant à des exigences réelles. Pour ce faire, nous
utilisons l’approche Diviser Pour Régner (DPR) afin de décomposer les problèmes complexes
en des problèmes beaucoup plus simples, facilement maniables et dans la mesure du possible
solvable par une approche existante. Pour appliquer cette méthode, il est judicieux de se poser
les questions suivantes :
Dans une architecture BPM, quel est le problème à résoudre?
Quels sont les sous problèmes qu’il contient ?
Et quels standards utiliser pour le résoudre ?
Pour concevoir la solution, il faut dans un premier temps comprendre le problème, souligner
les perspectives à moyens et à long terme.
Phase 1 – Compréhension du problème :

Pour comprendre le problème, il faut s’approprier du champ d’application du problème à
résoudre. En général pour des applications BPM les principaux besoins sont : la capacité de
modéliser, d’exécuter, de surveiller et administrer les processus d’entreprises qui incorporent
les interactions humaines. A la fin de cette phase on doit produire un ensemble d’artefacts
nécessaires à la bonne compréhension du but du projet.
Matt Cumberlidge [Matt2007]recommande au chapitre 1 de son livre de fournir les artefacts

suivants :
. Le diagramme d’activité : qui donne les interactions au sein de l’écosystème.
. La matrice RACI : qui est matrice de responsabilité. Elle donne une vision simple et
claire de qui fait quoi dans le projet, permettant ainsi d'éviter une redondance de rôles
ou une dilution des responsabilités [Wiki2011].
. Les métriques d’analyse de processus :
. plan d’implémentation :
Modéliser :
Modéliser le problème revient intuitivement à faire un organigramme qui décrit les
différentes étapes nécessaires à la résolution d’un problème métier. Il se pose immédiatement
un problème de représentation graphique de ce model. A contrario des projets orientés objets,
la modélisation d’un processus fait intervenir les experts fonctionnels et techniques. On aura
comme besoin ici d’un outil graphique qui permettra de représenter fidèlement et
rigoureusement les processus métiers réels.
L’artefact produit à cette phase est une description formelle du processus.
Exécuter
L’exigence fondamentale demandée au moteur de Workflow est d’« exécuter ce qui a été
dessiné ». Il est question ici d’avoir une correspondance entre le graphique conçu
précédemment et le langage exécutable par le moteur de Workflow utilisé, ce qui permettra la
génération automatique de code exécutable à partir de la conception.
Administration et Monitoring
Le monitoring permettra de regarder les progrès des processus en cours. Il est crucial pour la
production pour plusieurs raisons: détecter les exceptions (assurer que les processus
progressent comme prévu sans interruption non prévue) et permettre des requêtes en temps
réel. L’administration quant à elle est la capacité d’effectuer des changements (installer,
arrêter, activer, suspendre, reprendre ou résilier) le Workflow en cours d’exécution. Nous
proposerons à l’utilisateur une console graphique qui va permettre de visualiser et modifier
les processus du système BPM. Nous proposons une architecture du modèle qui assure les
interactions humaines et machines.
Interaction Homme et machine :

D’une part, une tâche manuelle dans un processus est censée être exécutée soit par une
personne dans un rôle spécifique, ou un groupe de personnes ayant le même profil au sein de
l'entreprise. Pour pouvoir offrir cette fonctionnalité, l'architecture doit être appuyée par une
politique de sécurité basée sur les rôles, et une interface pour l’interaction avec le moteur
d’exécution.
D'autres parts, dans un processus on doit pouvoir appeler ou être appelé par des composants
logiciels qui ne sont pas intégrés dans le moteur. Ces composants peuvent provenir d'un autre
processus de l'entreprise), les systèmes internes (par exemple, envoyer un email, requêtes en
base de données)
Phase 2 – Définition de l’architecture solution
Pour bien définir l’architecture il faut se concentrer premièrement à la mise sur pied du
Workflow interne.
Dans le chapitre 2 de son livre «Essential Business Process Modeling» [Havey2005] , Mike
Havey, nous donne la prescription d’une bonne architecture BPM . La Figure 11 nous
illustre cette architecture.
Figure 12 Architecture solution d'un projet BPM [Havey2005]
Nous avons donc conçu une architecture concrète s’inspirant de celle présentée ci-dessus.
Nous greffons sur cette architecture les éléments additionnels (dépendant de

l’environnement cible ou de la nature de l’utilisateur) pour constituer notre chaine
d’industrialisation du Workflow.
Phase 3 – Exécution sur un serveur d’application

Il faut tirer parti des services offerts par les serveurs d'applications comme la sécurité, les
transactions, la gestion du système, et la mise en commun des connexions client et des
ressources. Cela évite de partir de zéro et surtout permet au développeur de se concentrer
uniquement sur des aspects métiers.
La démarche décrite ci-dessus est conduite autour d’une chaîne logicielle hautement
collaborative et itérative. La section qui suit présentera l’architecture physique de cette chaîne
et détaillera les différents postes de fabrication constituant la chaîne.
3.3 ARCHITECTURE DE NOTRE SOLUTION
Notre solution est un ensemble de poste de fabrication, chaque poste étant plus ou moins
spécialisé. Chaque poste peut être remplacé par un autre ayant les mêmes fonctionnalités (et
respectant plus ou moins les mêmes standards). La Figure 13 montre un schéma de ce poste
de travail. Nous allons faire une emphase sur les outils du développeur et les outils pour
fonctionnels.
Figure 13 Architecture globale de la chaîne d'industrialisation
DESCRIPTION DETAILLEE DES POSTE DE PRODUCTION
Dans cette partie nous décrivons les éléments que nous déployons chez chacun des acteurs de
notre écosystème. Un poste de production dans notre chaîne logicielle est constitué par un
acteur et les outils qui lui sont associés.
a. Le poste des experts fonctionnels

Les experts fonctionnels ont besoin de voir sur leur poste les éléments suivant :
- Un designer graphique : pour produire des diagrammes de processus ou des

diagrammes d’activité.
- Une console : Pour interagir avec les Workflow en cours d’exécution (administrer,
démarrer, suspendre, arrêter …).
- Outil d’aide à la décision et de Business Intelligence: Une fois assuré du bon

fonctionnement des processus, il est vital pour les fonctionnels de mesurer leurs
exécutions pour les piloter en temps réel, de s’assurer de la performance de ces
derniers au regard de leur degré de criticité. D’où la nécessité d’un outil de BAM
(Business Activity Monitoring).
La figure ci-dessous résume les composants nécessaires à déployer sur un poste de

fonctionnel :
Figure 14 Composant sur postes Fonctionnels
b. Le poste des développeurs

Les développeurs ont besoins dans leurs postes :
- Des outils d’analyse et de design
- Des outils de développement
- Des outils de tests et de production de scénarios
- Des outils de persistance et stockage de données
Figure 15 Postes Développeurs
c. Le poste de Team Leader

En plus des éléments disponibles sur les postes des développeurs, le Team Leader a en plus
des outils de control, de vérification et d’évaluation de code.
d. Le serveur des versions

Pendant toute la durée de développement du projet, les différents codes et artefacts produits
seront gérés par un serveur de version. Cette gestion est nécessaire pour un bon travail
d’équipe et permet à chaque fois de suivre l’historique du projet ou encore de faire de
l’intégration continue.
e. Le serveur de repository
Toutes les classes nécessaires au développement nécessite d’inclure des librairies d’autres
projets développés par nous même ou par la communauté open source. Il faut donc un outil
spécialisé de gestion de version pour résoudre de façon élégante les dépendances directes ou
symétriques éventuelles.
f. Le serveur GED: KoosseryGEDoc

Une fois les composants développés et testés il faudra les déployer sur une copie de
KoosseryGEDoc.
Maintenant que nous avons analysé et trouvé une démarche de résolution à notre problème,
nous pouvons maintenant passer à sa réalisation.
REALISATION DE LA SOLUTION
CHAPITRE 4.
Dans ce chapitre nous décrivons l’outillage logiciel et technique nécessaire à la mise en

place de notre solution. Ensuite nous décrivons les différentes étapes que nous avons
parcourues pour la mise en œuvre. Enfin nous terminerons par une description technique du
module de Workflow développé pour KoosseryGEDoc : Koossery Workflow.
4.1 OUTILLAGES
Pour réaliser notre suite logicielle de production de Workflow pour la GED /BPM, nous
avons intégrés des outils de modélisations graphique, une d’outils de BPM, et le module
Koossery Workflow qui hérite des fonctionnalités de jBPM.
Dans cette partie, nous décrivons les outils utilisés (sans parler de la façon dont nous les avons
intégrés vue leur nombre important) et nous décrivons le développement du module de
Workflow.
1) Outils de gestion du projet

L’outil retenu pour gérer le projet est Ms Project ; On peut aussi utiliser Gantt Project qui
est open source.
2) Outils de modélisation graphique de processus

Il est important de choisir ici le plus simple outil de modélisation qui pourra fournir les
informations requises. Nous avons retenus 3 outils qui se succèdent dans l’étape <<
MODELISER : >> de la PHASE 1 – COMPREHENSION DU PROBLEME :
• Le « Stylo – Papier » : qui permettra de dessiner à la main les besoins récupérés des
utilisateurs et de s’assurer que le processus final prend tous les paramètres en compte.
• Un outil de modélisation familier à l’expert fonctionnel : Ici tout outil se rapprochant

de BPMN 2 .0 peut être utilisé. Nous laissons donc libre court au fonctionnel de choisir
l’outil de modélisation de processus qui lui convient le plus. Le plus important est de
pouvoir partager la vision du projet entre les différents acteurs. On peut citer comme
exemples : Microsoft Visio 2007 ou encore sa version en ligne Gliffy
(http://www.gliffy.com)
• jBPM 3.2 : Une fois le model final obtenu, il faut le formaliser sous jBPM afin de
pouvoir faire les générations nécessaires. Nous avons pour cela installer les plugins
éclipse correspondant.
• Enterprise Architect 6.5 : Peut aussi être utilisé dans cette phase par les développeurs
ou les architectes logiciels pour la modélisation des Workflow en UML. Pour ce faire
nous utiliserons le plugin EA XPDL Designer de BULL [AZZOUZI 2009]
3) Le serveur d’application
Le serveur retenu pour notre application est JBOSS Application Server. C’est lui qui se
charge de mettre à disposition notre application web auprès des utilisateurs.
4) Le moteur de règle
Nous avons remarqué au cours de notre analyse que le designer graphique de jBPM génère du
code qui hérite de toute la puissance du XML, combiné au langage objet java, et de la
programmation orienté graphe. Toute fois il n’est pas adéquat pour des problèmes donc les
règles de gestion changent tout le temps.
Nous avons donc utilisé ici JBOSS DROOLS : grâce à son moteur d’inférence, notre chaine
logicielle sera capable d’entreprendre des actions métiers sur la base des faits et des règles
d’une situation spécifique. Et quand bien même l’entreprise changera ses règles on n’ajoutera
simplement des règles au moteur et tout ceci sera pris en compte.
5) Outils de reporting et business Intelligence

Une fois que les Workflow sont en marche, on peut avoir besoin de mesurer leur exécution ou
de faire des états et autres outils divers. L’intégration de ces outils exploite les possibilités de
programmation évènementielle supportée par jBPM.
On peut utiliser pour cela :
- jBPM console : offre un ensemble de fonctions mineures via sa console qui offre en
ensemble d’informations pour effectuer des statistiques ou interactions. Notons que
cette console est largement améliorée dans les versions 5 de jBPM.
- Microsoft Excel pour faire du reporting ou toutes autres statistiques éventuelles à

partir des données provenant de la base de données.
- DESMO-J [Rücker2008]: Qui est un Framework de modélisation discret pour Java.

Rucker a pu mettre sur pied un outil de simulation basé sur jBPM.
6) Outils de build
Le choix se base sur les résultats des travaux de [Ricardo2010] , et l’outil de build retenu
ici pour notre travail est Maven 2 . C’est un outil open-source de build pour les projets Java
très populaire, conçu pour supprimer les tâches difficiles du processus de build. Maven utilise
une approche déclarative, où le contenu et la structure du projet sont décrits, plutôt qu'une
approche par tâche utilisée par exemple par Ant ou les fichiers make traditionnels. Cela aide
à mettre en place des standards de développements au niveau d'une société et réduit le temps
nécessaire pour écrire et maintenir les scripts de build.
7) SGBD
Notre choix s’est porté sur MySQL 5 qui est le serveur de base de données actuel de
KoosseryGEDoc. Nous y accéderons via Hibernante qui nous a permit de faire le mapping
objet relationnel, la génération d’opérations de base d’accès à la base de données.
8) IDE
L’IDE en vigueur chez Koossery Technology est Eclipse Hélios for JAVA EE Developers. Il
est enrichit de plusieurs plugins facilitant la mise sur pied et le développement des projets.
9) Outils de prototypages et génération de configuration

Nous avons besoin de générer les "task forms". Ces derniers sont des formulaires qui
permettent aux utilisateurs de fournir les informations nécessaires à l’exécution des
Workflow. Pour ce faire, nous avons développés un composant qui utilise XHTML JavaServer
Faces Tags pour générer des interfaces.
Nous utilisons aussi du XSLT pour générer les configurations qui seront nécessaire au déploiement
ultérieur dans KoosseryGEDoc.
4.2 IMPLEMENTATION DE KOOSSERY WORKFLOW

Dans cette partie, nous décrivons les étapes parcourues pour développer le moteur de:
Koossery Workflow.
1) Workflow Reengineering de KoosseryGedDoc

La solution KoosseryGEDoc étant en pleine ré architecture, nous avions pour responsabilité
de faire migrer sa partie Workflow. Pour ce faire il nous fallait trouver une méthode de
modélisation qui nous permettrait de comprendre le fonctionnement actuel. Ceci afin de
définir des axes d’améliorations. Pour ce faire nous avons analysé la partie Workflow de
Alfresco s’inspirant des phases de la méthode de BPR (Business Process Reengineering).
Nous avons pu obtenir les séquences qui suivent:
2) Quelques Diagrammes de séquences
Figure 16 Démarrer un Workflow
Figure 17 Voire les tâches complètes
Figure 18 réassigner une tâche
Figure 19 File Workflow Détail
Figure 20 Réassigner une tâche
3) Architecture Technique
Nous avons configuré le projet Kossery Workflow conformément à l’architecture des projets
j2EE de KTC
C’est un projet maven 2 comportant : un projet serveur, un projet contrat et une webapp
comme indiqué sur la figure ci-dessous
Figure 21 Projet maven de Koossery Workflow
La figure 22 montre des exemples de services fournit par la couche des services de Koossery
Workflow ils seront détaillés dans le point suivant.
Figure 22 Services offerts par Koossery Workflow
Mémoire de fin d’étude présenté et soutenu par TCHOULEGHEU NJEMOU Marcel Thierr Page 48
4) Architecture fonctionnelle
Cette architecture est conforme à celle évoquée à la Figure 4 . Nous avons changé la logique
métier des « backing beans » afin de rendre plus souple et adapté à l’architecture Technique
de Koossery Technologie.
Couche Backing beans:

Ce sont les beans qui sont directement accessibles par le web client (les pages web JSP,
JSF, etc.), exposant les actions possibles par l’utilisateur final, et leurs évaluateurs. Nous
regroupons ces beans en deux principales catégories: les evaluators et les simples beans.
Evaluators:
Ici seront regroupés les classes dont leur but est de s’assurer que le contexte d’exécution du
Workflow est cohérent (c'est-à-dire que. si l’utilisateur a les droits nécessaires, si l’état
courant est valide et d’autres conditions éventuelles aussi). Ils agissent un peu comme des
filtres de certains beans. Comme instances, nous aurons:
• StartWorkflowEvaluator : qui s’assure que les étapes du processus sont déjà définies et
que l’utilisateur a les droits nécessaires;
• CancelWorkflowEvaluator : passe par le NodeService pour s’assurer que l’initiateur du

Workflow est bel et bien celui qui lance l’action d’annulation;
• WCMWorkflowEvaluator : vérifie les droits d’accès pour l’édition des propriétés d’un
contenu, quel que soit son type;
• CheckinDocEvaluator : vérifie si le contenu possède l’aspect permettant de travailler sur

une copie, et possède la permission d’enregistrement;
• CheckoutDocEvaluator : vérifie si le contenu que l’on veut consulter possède des aspects
de copie de travail, de traduction, si le contenu n’est pas verrouillé et qu’il a la permission
de consultation;
• CancelCheckoutDocEvaluator : idem que le CheckinDocEvaluator sauf pour la

permission de d’enregistrement, remplacée par la permission d’annulation de consultation;
Simples beans:
Les beans dont la plus part des méthodes sont les actions exposées directement sur les clients
légers. Nous pouvons citer:
ManagerBean:
WorkflowBean:
Il possède les méthodes dont les actions concernant le Workflow sont affichées sur la vue de
l’utilisateur:
• ManageTaskBean: qui possède les méthodes d’action sur les tâches:
• ContentBean: contient toutes les méthodes effectuant une ou des actions sur un contenu:
• AVMBean: gestionnaire avancé de version des documents dans l’entrepôt d’Alfresco:
• WorkflowDTO et TaskDTO: qui contiendront les données transitant entre les vues et les
SVCO;
Couche des services composés (SVCO):

Nous présentons ici les services qui, pendant leur implémentation, se serviront des services de
base de l’entrepôt d’Alfresco pour accomplir les actions initiées depuis la couche web client.
Nous avons donc ainsi:
• IWorkflowSVCO: composant dont les services exposés concernent le Workflow;
• ITaskSVCO: composant dont les services exposés concernent les tâches;
• IPermissionSVCO:
• INodeSVCO: interface sur le NodeServie: (node concernant le Workflow)
• IDictionarySVCO: interface sur le DictionaryService:
Les classes utilisées par les SVCO:

• Repository: jouera un peu le rôle de Registre des services;
• BPMEngineRegistry: c’est le registre des TasksComponents et des

WorkflowsComponents;
• WorkflowUtil: contiendra les implémentations approve(), reject() qui respectivement

approuvent et rejettent une étape dans un Workflow, et prepareTaskParams() pour
préparer le nœud pour la persistance dans le moteur de Workflow;
Les services utilisés pour l’interaction avec l’entrepôt:

Ici, ce sont les services nécessaires au volet “Workflow” d’Alfresco, sur lesquels nous nous
appuierons pour accomplir les actions initiées par l’utilisateur final.
• WorkflowService: c’est le service de base du volet “Workflow”, il contient les

implémentations du «startWorkflow», «deleteWorkflow», propager les évènements,
obtenir le «startTask», obtenir les tâches assignées à une personne, mise à jour des tâches,
terminer une tâche, et évidemment des «getters» et «setters» pour les attributs.
• PermissionService: intervient lorsqu’un utilisateur tente d’effectuer une opération qui

requiert des droits;
• DictionaryService: intervient lors de la création du startTaskNode entre autres.
• NodeService: très important dans la manipulation de l’entrepôt, il intervient dans la

création d’un Workflow, son édition, la mise à jour et l’obtention de certaines propriétés
d’une tâche.
• AVMService: gestionnaire avancée de gestion de version dans l’entrepôt;
• WorkflowInstance: permet d’avoir une instance d’un Workflow.
Nous avons décrit dans cette partie les aspects techniques, côté développeur de
l’implémentation du module Koossery Workflow. Notre chaîne logicielle étant prête, nous
nous proposerons de l’appliquer sur un exemple simple, mais pratique
ETUDE DE CAS
CHAPITRE 5.
ETUDE DE CAS
Cette étude de cas est une reprise du tutoriel publié par Koossery Technology [KOUAM and
Baké2009] disponible à l’adresse http://koossery-tech.developpez.com/tutoriels/java/alfresco-
jBPM/20090503/
Nous l’implémentons en suivant la démarche vue au CHAPITRE 3.
IMPLEMENTATION D’UN WORKFLOW DE

DEMANDE DE CREDIT
Spécification de l’étude de cas
Un organisme de prêt à la consommation souhaite mettre en place un Workflow d'approbation

de crédit qui combine l’étude du dossier de crédit avec son passage par plusieurs étapes, de
l'approbation jusqu'à son archivage.
Ci-dessous les différentes étapes de l'approbation:
1. Le cycle commence par la réception de la demande de crédit du client. Cette demande peut
être faite par courrier électronique ou par courrier papier.
ETUDE DE CAS
2. La demande est transmise au service du crédit qui ensuite quotte le dossier à l'agent chargé
du crédit.
3. L'agent chargé du crédit rentre en contact avec le client, lui remet un formulaire (fiche
interne de demande de crédit) qui contient au moins une trentaine (30) de questions
(création d'un type de crédit, conditions d'attribution, remboursement, garanties etc..).
4. Suite aux réponses du client, l'agent de crédit fait un 1er filtrage. A l'issue de ce filtrage, le
dossier de crédit est soit rejeté, soit présenté au COC (Comité d'Octroi de Crédit).
Dans la suite on suppose que le dossier est présenté au Comité d'Octroi de Crédit.
5. Le Comité d'Octroi de Crédit reçoit le dossier et l'étudie. Un avis est donné au dossier: le
dossier est soit approuvé, soit rejeté. Lorsque le dossier est approuvé un rapport de synthèse
est élaboré et transmis simultanément au service juridique et à la cellule en charge de
formaliser les décaissements de fonds. Dans la suite on suppose que le dossier est approuvé et
qu'un rapport de synthèse est établi.
6. Le service juridique reçoit le rapport de synthèse et sur la base de ce rapport, il s'occupe de

la préparation du contrat stipulant les engagements des deux parties avec des précisions
d'autres clauses clés (pénalités, garanties, etc..). S'il y a nantissement sur les garantes la
procédure recommence (on retourne à l'étape 5). La cellule en charge de formaliser les
décaissements de fonds quant à elle commence à formaliser le décaissement des fonds sur la
base du rapport reçu.
7. Une fois le contrat élaboré et le traitement des garanties achevé, l'organisme de Crédit
contacte le client pour signature dudit contrat.
8. Le dossier est alors transmis à la Direction Administrative et Financière pour le déblocage

des fonds. (Signature des chèques, des ordres de virements, etc..).
9. Le déblocage du crédit peut être fait soit par chèque à l'ordre du client bénéficiaire du
crédit, soit par virement du compte de l'organisme de crédit au compte du client bénéficiaire
du crédit.
Remarque :
ETUDE DE CAS
- A chaque passage du dossier dans une étape, la date et la signature doivent être portées sur le
dossier pour mesures de sécurité (qui a fait quoi et quand).
Résolution de l’étude de cas :
Dans cette partie nous utilisons la démarche itérative décrite tout au long de notre
document pour montrer comment on pourrait résoudre un problème concret dans un contexte
réel. Nous verrons aussi que dans notre méthode avant de résoudre le problème proprement
dit, on doit faire un ensemble d’actions qui permettront de personnaliser la solution en
fonction des problèmes posés.
Compréhension du problème
Après discussion avec les experts du crédit du dit organisme nous récoltons les spécifications
décrites ci-dessus.
Document d’initiation du projet

Une fois le recueil des spécifications et les premiers besoins récoltés, nous produisons un
document d’initiation du projet dont un prototype est donné en ANNEXE A.
Matrice de RACI
Nous présentons dans la Figure 23 l’extrait de la matrice de RACI réalisé sous microfots Excel.
Figure 23 Matrice de RACI
ETUDE DE CAS
L’étape qui doit suivre directement est l’organisation des réunions de lancement du projet.
Cette réunion peut être organisée en ligne ou dans un cadre adapté à cet effet. Pour s’assurer
que l’équipe est assez bien imprégnée du projet. On peut dès lors analyser et modéliser les
processus.
Modélisation du problème
Une fois les spécifications décrites , nous discutons avec l’expert du crédit et tentons une
première modelisation avec lui. Nous supposons que celui – ci est habitué à Microsfot Visio.
La Figure 24 nous donne le résultat du model produit.
Figure 24 Workflow approbation du crédit
Nous pouvons éventuellement itérer ce schéma.
Modelisation sous éclipse
L’équipe de développement doit formaliser ce model en jPDL pour permettre les générations
d’applications. La Figure 25 présente le model obtenu
ETUDE DE CAS
Figure 25 Processus credit sous eclipse
Plan d’implémentation
Nous fournissons ensuite un plan d’implémentation du projet qui est en réalité la planification
du déroulement complet du projet réalisé sous Ms Project.
La Figure 26 montre un extrait de cette planification.
ETUDE DE CAS
Figure 26 Planification du projet
Prototypage des interfaces

Nous fournissons dans un premier temps une interface sous JBOSS permettant de prototyper
les « task Form ». La Figure 24 montre l’interface qui permet de faire les prototypes .
Figure 27 Interface de prototypage de fomulaire
ETUDE DE CAS
Les prototypes réalisés sont transmises à l’équipe de développement qui génère

automatiquement les formulaires JSF depuis leur environnement Eclipse. Figure 28 montre
l’interface de génération automatique de formulaire fournit.
Figure 28 Génération automatique de Formulaires
On peut aussi tirer profit des palettes de prototypages rapides Rich Faces ou JSF comme
illustré ci –dessous.
ETUDE DE CAS
Figure 29 Palette d'outils graphiques
Figure 30 Prototypage graphique avec jBossTools
ETUDE DE CAS
Déploiement de la l’application et test

Il ne reste plus qu’à déployer et tester l’application et le processus recommence jusqu’à
satisfaction des différentes parties.
Figure 31 Déploiment du workflow
Nous avons montré ici un exemple de conduite de projet workflow en utilisant notre solution
(Démarche et outils utilisés). Cet étude de cas met en évidence la communication entre les difféents
acteur, pour parvenir à concevoir le projet.
CONCLUSION
CONCLUSION
BILAN
KOSSERY TECHNOLOGY CMR nous a confié comme travail d’industrialiser le
processus de développement de ces projets Workflow en environnements GED/BPM. Le défi
principal étant de fournir une architecture qui permettra à un analyste fonctionnel de
s’affranchir des développeurs.
Pour ce faire, la première partie de notre travail a consisté à comprendre la discipline

même du Business Process Management. Etudiant cette dernière, nous avons pu ressortir une
démarche de résolution de tout problème s’y rapportant. Nous avons ensuite décrit des phases
fortement itératives dans le souci d’améliorer à chaque fois la solution produite combinant
cette démarche aux bonnes pratiques et au retour d’expérience des experts du domaine. Une
fois la démarche trouvée, nous sommes redescendus au niveau génie logicielle pour chercher
des méthodes rapides de développements logiciels.
La deuxième partie de notre travail a été d’abord de développer l’outil Koossery Workflow,
ensuite nous avons intégré les outils pour la plupart open source adéquats pour la résolution
de problèmes précis. Il existait déjà des outils de Workflow offrant chacune des
fonctionnalités diverses et variées. Nous avons pu remarquer que ces systèmes sont de 3 types
: ceux « human-centric», ceux «application-centric» et ceux qui combinent les deux. Notre
solution quant à elle garde le meilleur de la combinaison de 2 philosophies et lui ajoute une
dimension «process-centric». Nous avons recherché et intégré les outils qui permettent le
développement automatisé du logiciel. Parmi ces outils intégrés, nous avons intégré un
moteur de règles qui à notre système de lui donner une dose d’intelligence et lui permettre de
s’adapter facilement aux changements.
CONCLUSION
PERSPECTIVES
• Nous allons poursuivre avec l’implémentation de Koossery Workflow et l’éprouver

dans la nouvelle architecture de KoosseryGEDoc.
• Nous devons aussi éprouver notre solution en environnement réelle et l’optimiser

grâce aux retours d’expérience des utilisateurs dans plusieurs domaines précis.
• Nous devons continuer à améliorer les différents composants et générateur utilisé afin
d’arriver à la génération d’application en un click Notamment par une migration
actuelle de KoosseryGEDoc pour le support de la norme BPMN 2.0 profitant ainsi de
nombreuses possibilités.
REFERENCES BIBLIOGRAPHIQUES
BIBLIOGRAPHIE
[Havey2005] Havey, M., Essential Business Process Modeling.(2005): O'Reilly Media, Inc.
[Hofstede, Aalst2010] Hofstede, A.t., et al., Modern Business Process Automation.(2010). Springer-
Verlag Berlin Heidelberg ed. 664.PP
[Djam2011] Djam, S.Contribution à la réarchitecture de la solution d'ECM ALfresco
Département de Génie Informatique 2011, Université de Yaoundé 1. 50. p.
[KOUAM, Baké2009] KOUAM, L. and J.B. Baké.Tutorial Alfresco - jBPM: exemple d'implémentation
d'un workflow avancé, C.d.C. Alfresco/jBPM. 2009, Centre de Compétence
Alfresco/jBPM, Koossery Technology. p.
[Anguela2010] Anguela, J.Open Source BPM comes of age A contributor's view of Bonita
Open Solution by. 2010. 12. p.
[Valtech, ICCS] Valtech, B.G., et al., D2.2 – Workflow Software Analysis and Comparison.
Todor Stoilov (ICCS) ed. 240.
[Matt2007] Matt, C., Business Process Management with JBoss jBPM.(2007):
Published by Packt Publishing Ltd. 217.
[AZZOUZI 2009] AZZOUZI, M.I.E.Modélisation des workflows en UML.M2 MIAGE. 2009,

Université Joseph Fourier. p.
[Rücker2008] Rücker, B.Building an open source Business Process Simulation tool with
JBoss jBPM. 2008, Stuttgart University of applied science: Stuttgart p.
[Ricardo2010] Ricardo, N.S.J.Conception et Mise en œuvre d’une software
factory.DEPARTEMENT DE GENIE INFORMATIQUE. 2010, ECOLE NATIONALE
SUPERIEURE POLYTECHNIQUE: Yaoundé. 76. p.
WEBOGRAPHIE
[Mitra2011] Mitra, T. Architecture in practice, Part 6: Why business process management
(BPM) is important to an enterprise. 2011 29 Jan 2008 [consulté le 10 JUIN
2011; Disponible sur Internet:
http://www.ibm.com/developerworks/library/ar-arprac6/
[Wiki2011] Wiki. Wikipedia - RACI 2011 29 Avril 2011 [consulté le 08 JUIN
2011]; WIkipedia Inc:[Disponible sur Internet:]
www.wikipedia.org/wiki/RACI.
[Bonita2011] www. Bonita Open Solution reçoit le prix du « Meilleur Outil de

Modélisation » à EclipseCon 2011. [Consulté le 03 Mai 2011];
Disponible sur Internet:
http://fr.bonitasoft.com/blog/news/bonita-open-solution-recoit-le-prix-
du-%C2%AB-meilleur-outil-de-modelisation-%C2%BB-a-eclipsecon-
2011/.
[Wikipedia2011] Wikipedia. PDCA. [Consulté le 13 JUIN 2011]; Disponible sur Internet:
http://en.wikipedia.org/wiki/PDCA
[Mitra2011] Mitra, T. Architecture in practice, Part 6: Why business process

management (BPM) is important to an enterprise. 2011 29 Jan 2008
[consulté le 10 JUIN 2011; Disponible sur Internet:
http://www.ibm.com/developerworks/library/ar-arprac6/
[Aalst, Barros2011] Aalst, W.v.d., et al. 2011 [consulté le 06 Mai 2011]; Disponible sur
Internet:
www.workflowpatterns.com.
ANNEXES
ANNEXES
Annexe A
Prototype de Document d’initiation du projet
ANNEXES
[Automatisation du Workflow
d’approbation du crédit]
Document De Lancement du
Projet
Historique des versions
Rédaction du document
Entité/Fonction Date Nom Visa
Stagiaire Gi2011 14/06/2011 Marcel Tchoulegheu
Versionning
Version Date Modifications effectuées
1.0 14/06/2011 Création
Liste de Distribution
Version Département/Fonction Rôle / Poste
1.0 Direction Directeur

ANNEXES
Résumé du projet
Objectifs
Mise sur pieds mettre en place un Workflow d'approbation de crédit qui combine l'étude du
dossier de crédit avec son passage par plusieurs étapes, de l'approbation jusqu'à son archivage.
Positionnement
Préciser ici de ce projet par rapport à l’entreprise.
Jalons
Identifier ici les points clés du projet et faire un tableau récapitulatif de leur planification ?
Phases du projet Durée Démarrage Fin
Ressources
Ressources du Project
Responsabilités:
Processus Rôle Nom

Start Initiateur
Etude Comité d’étude
ANNEXES
Bureau du Projet
Rôle Responsabilités Nom
Responsable Responsable du suivit du projet et s’assure
Projet de la fourniture des ressources nécessaires
au déroulement du projet tant financières
que humaines.
Manageur du - Planification du projet
Projet - gestion des risques
- mise à l’échelle
Experts BPM Responsables des analyses et réalisation
métiers. Des stratégies et de la conduite du
changement.
Team Dirige l’équipe de développeurs, fournit

Leadeur
l’architecture et l’outillage nécessaire à
ceux-ci pour effectuer leur tâches.
Développeurs Prototypent et customisent les interfaces

utilisateurs. Réalisent l’intégration avec les
systèmes extérieurs.
Management du projet
Critères d’évaluation et de succès
Décrire ici les critères d’évaluation et de succès du projet.
Reporting et Monitoring
Outils de génération des rapports et de monitoring des taches :

MemoireIng Tchoulegheu Iteration Finale PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MemoireIng Tchoulegheu Iteration Finale PDF

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITE DE YAOUNDE I UNIVERSITY OF YAOUNDE I

ECOLE NATIONALE SUPERIEURE NATIONAL ADVANCED SCHOOL OF

Industrialisation de la réalisation des Workflow

Présenté et soutenu par :

TCHOULEGHEU NJEMOU Marcel Thierry

Diplôme d’Ingénieur de Conception de Génie Informatique

Dr/PhD. Thomas DJOTIO NDIE

Ing. Prosper MENDOUGA, DG KoosseryTech CMR

Devant le jury composé de :

-Président : Thomas TAMO TATIETSE, Pr.

Année Académique 2010 – 2011

Date soutenance : 23 Juin 2011

Mr Njemou Yafa François

Nos remerciements s’adressent aux personnes suivantes :

• Pr. Thomas TAMO TATIETSE, Directeur Adjoint de l’Ecole Nationale Supérieure

• L’ingénieur Prosper MENDOUGA, invité ,Directeur de la société KOOSSERY

• L’ingénieur Baké Jc. BAKENEGHE pour sa rigueur au sein du training center.

• A Mr & Mme Djomo Gerhard pour leur hébergement et leur encadrement

• Je remercie particulièrement Nguimbous,Nestorette,Ricardo,Marie pour la relecture de

BPA Business Process Automation

MOTS CLÉS: BPM, Workflow, industrialisation, ECM, GED.

We got Koossery Workflow, a chain of software tools integrated heterogeneous, extensible,

KEY WORDS: BPM, Workflow, industrialization, ECM, EDM.

LISTE DES FIGURES

Figure 1 Rôle des Model en BPM [Havey2005] ..................................................................................16

CHAPITRE 4. REALISATION DE LA SOLUTION ..............................................................................39

1.1.1 PRESENTATION DE KOOSSERY TECHNOLOGY

KOOSSERY TECHNOLOGY CMR (KTC) est une entreprise spécialisée en conseil et

Koossery Technology offre les solutions technologiques suivantes :

• Infrastructure technique et Offre Koossery IT management

• Fabrication d’applications spécifiques

Elle s’appuie sur :

• Un Centre de Support Technologique, KOOSSERY TECH’ Lab, centre de veille

1.1.2 CONTEXTE DU TRAVAIL

Koossery Technology comme la majorité des sociétés de développement se dote des

1.2 PROBLEMATIQUE ET POSITIONNEMENT

1.3 MOTIVATION ET OBJECTIFS

L’objectif principal de Koossery Technology est de s’imposer en tant que leadeur de

En résultat nous aurons :

• L’allègement du temps de production d’une brique logicielle destinée à KoosseryGEDoc

2.1 ETAT DE L’ART-BUSINESS PROCESS MANAGEMENT

Figure 1 Rôle des Model en BPM [Havey2005]

2.1.2 CYCLE DE VIE DU BPM

La Figure 2 présente le cycle de vie de BPM utilisé par IBM.

Figure 2 Cycle de Vie DU BPM [Mitra2011]

2.2.1 STANDARD DU BPM [Hofstede, Aalst2010]

XPDL : XML Process Définition Language [Hofstede, Aalst2010]

BPEL: Business Process Execution Language [Hofstede, Aalst2010]

BPMN: Business Process Modeling Notation[Havey2005, Hofstede, Aalst2010]

a) La montée en gamme avec Les Workflow Patterns 1

• Les patrons de control ou Control Flow Patterns :

• Les patrons de Données ou Data Patterns

• Les patrons de Ressources ou Ressource Patterns

Figure 3 Cycle de vie des Tâches [Hofstede, Aalst2010]

2.2 LES WORKFLOW DANS KOOSSERYGEDOC

2.2.1 LA SOLUTION DE GED/ECM DE KTC

• la GED et les processus métiers.

Figure 4 Architecture de KoosseryGEDoc [Djam2011]

Cette architecture sera le socle de la réalisation de notre module : Koossery Workflow.

2.2.2 LES WORKFLOW DANS KOOSSERYGEDOC

KoosseryGEDoc intègre le moteur jBPM et supporte 2 principaux types de Workflow :

Workflow simples[KOUAM and Baké2009]

Workflow avancés[KOUAM and Baké2009]