Une approche de transformation de la notation BPMN vers BPEL basée sur la transformation de graphe

(1)

République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de La Recherche Scientifique

Université Mentouri Constantine

Faculté Des Sciences De L’ingénieur

Département d’Informatique

N°358/MAG/2009

Série : 015/INF/2009

Mémoire de Magister en Informatique

Option : Génie logiciel

Dans le cadre de l‟école doctorale de l‟est

Titre du mémoire :

Une Approche de transformation de la

notation BPMN vers BPEL basée sur la

transformation de graphe

Présenté par :

Kholladi Mohamed Naoufel

Devant le jury :

Président : Pr Benmohammed Mohamed Rapporteur : Dr Chaoui Alloua

Examinateur : Dr Chikhi Salim

(2)

I

Remerciements

D‟abord, je rends grâce à Dieu de m‟avoir donné la chance de faire un

Magister et surtout de m‟aider à m‟en sortir.

J‟adresse toute ma reconnaissance au Dr Chaoui Alloua qui a dirigé ce

travail. Je le remercie pour sa patience et sa compréhension durant ces années de

Magister. Je le remercie infiniment pour son apport scientifique incontestable,

mais aussi pour toutes ses qualités humaines, sa compréhension, sa tolérance, sa

patience et son aide. Mes remerciements vont aussi à Mr Kerkouche El Hilali

pour sa coopération et son esprit d‟équipe.

Je tiens à remercier les membres du jury d‟avoir fait l‟honneur d‟accepter

de participer au jury et de juger ce travail.

Je tiens à remercier tous mes collègues et amis qui m‟ont soutenue durant

ces deux années pour leur soutien moral et surtout ma famille (mes parents, mes

sœurs, mon frère et tous les autres membres de la famille : surtout les grands

parents) pour tout ce qu‟ils ont fait et ce qu‟ils font encore pour moi.

(3)

II

Abstract

Present methods for enterprise systems analysis rely on the

representation of work practices in the form of business process

models. A standard for representing such models is the Business

Process Modeling Notation (BPMN). BPMN models are mainly

intended for communication and decision-making between domain

analysts, but often they are also given as input to software

development projects. Meanwhile, development methods for

process-oriented systems rely on detailed process definitions that are executed

by process engines. These process definitions refine BPMN models by

adding implementation details. A major standard for process

implementation is the Web Service Business Process Execution

Language (WS-BPEL, or BPEL for short). Accordingly, a natural

method for end-to-end development of process-oriented systems is to

translate BPMN models to BPEL definitions. However, instrumenting

this method is challenging because BPEL imposes far more syntactic

restrictions than BPMN. In our work we propose automatic technique

based on graph transformation to translate BPMN specification to

BPEL code.

(4)

III

Résumé

Les méthodes actuelles pour l‟analyse des systèmes d‟entreprise, se

basent sur la représentation des travaux pratiques sous forme de

modèles de processus d‟entreprise. Un standard pour représenter de

tels modèles est la BPMN. Ce dernier est destiné à mettre en

collaboration les analystes du domaine. De ce fait, il est considéré

comme une entrée pour les projets de développement de logiciel. En

même temps, les méthodes pour les systèmes orientés processus

comptent sur les définitions détaillées des processus qui sont exécutés

par des moteurs de processus. Ces définitions de processus raffinent

les modèles BPMN par le rajout des détails d‟implémentation. Le

standard pour l‟implémentation des processus est le BPEL

(WS-BPEL ou (WS-BPEL pour faire court). Par conséquent, la méthode

naturelle pour un développement bout à bout des systèmes orientés

processus est de convertir les modèles BPMN vers les définitions

BPEL pour des raffinements ultérieur. Toutefois, l‟instrumentation de

cette méthode est un challenge parce que le BPEL impose beaucoup

plus de restrictions syntaxiques que la BPMN. Dans notre travail nous

proposons une technique automatique basée sur la transformation de

graphes pour transformer les spécifications du BPMN vers du code

BPEL.

(5)

IV

صخلم

ضشع ىهع ذمخعح ثاسسؤمنا تمظوأ مٍهحخن تٍناحنا قشطنا

جرامو مكش ىهع تٍمٍبطخنا لامعلأا

.

ًٍهع فساعخم زٍمشح ناىٌ

ـب فشعٌ جرامىنا يزٌ ضشع ىهع ممعٌ

BPMN

.

ازٌ ممعٌ

تٌاذب تطمىك ذعٌ َ هٍههحمنا هٍب ثلاصاُمنا عٍدشح ىهع زٍمشخنا

حماشبنا شٌُطح عٌساشمن تبسىناب

.

ًخنا تمظولأن ،جلُنا سفو ًف

ساُطلأن تهصفم ثافٌشعح ىهع ذمخعح قشط يسُطح مكشب ممعح

اٍهٍغشخب ساُطلأا نشحم وُمٌ ًخنا

.

ـنا جرامو كلذح ثافٌشعخنا يزٌ

BPMN

مٍغشخناب تصاخنا ثاٍئزدنا تفاضإ شبع

.

زٍمشخنا

ساُطلأا ثأٍٍح ىهع ممعٌ يزنا َ ًٍهع فساعخمنا

(

هكمٌ ىخح

اٍهٍغشح

)

ـب فشعٌ

BPEL

.

تٌٍٍذبنا تمٌشطنا نأ كبس امع حخىٌ

تٌاذبنا هم ازٌ َ يسُطح مكشب ممعح تمظوأ شٌُطخن

(

جرُمىنا

)

ىنإ

تٌاٍىنا

(

مٍغشخنا

)

ـنا جرامو تمخشح ًف مثمخح

BPMN

ىنإ

ـنا ثافٌشعح

BPEL

.

بعص تٍهمعنا يزٍب وُمح تهٍسَ داذعإ هكن

ـنا نلأ

BPEL

عم توساممناب ةشٍثك تٌُحو ذعاُل ضشفٌ

ـنا

BPMN

.

تمٌشط ىهع ذمخعح تٍنآ تٍىمح ذشخمو ،ازٌ اىهمع ًف

جرامو تمخشخن جرامىنا مٌُحح

BPMN

ـنا ًف اٍهٍثم ىنإ

BPEL

.

ةيسيئرلا تاملكلا

:

BPMN

،

BPEL

جرامىنا مٌُحح تمٌشط ،

.

(6)

V

Table des matières

pages Introduction générale 1 1. Processus d’entreprise BPMN 3 1.1 Introduction. . . 4 1.2 Diagramme BPMN (BPD) . . . 4 1.2.1 Objets de flux. . . 5 1.2.1.1 Evènements . . . 6 1.2.1.2 Activités. . . 8 1.2.1.3 Portes. . . 10 1.2.2 Groupements. . . 11 1.2.2.1 Groupement graphique. . . 12 1.2.2.2 Sous- groupement. . . 12 1.2.3 Objets symboliques. . . 12 1.2.3.1 Objet de données. . . 13 1.2.3.2 Groupe. . . 13 1.2.3.3 Annotation. . . 13 1.2.4 Objets de relation. . . 14 1.2.4.1 Flux de séquences. . . 14 1.2.4.2 Flux de messages. . . 15 1.2.4.3 Associations. . . 15

1.3 Illustration par un exemple. . . 15

1.3.1 Diagramme BPMN de l‟exemple. . . 16

1.3.2 Interprétation du diagramme. . . 16

1.4 Conclusion. . . 19

2. Langage d’exécution BPEL 20 2.1 Introduction. . . 21

2.2 Structure des processus BPEL. . . 22

2.3 Relation entre BPEL et ses partenaires. . . 23

2.4 Etat d‟un processus BPEL. . . 23

2.5 Comportement d‟un processus BPEL. . . 24

2.5.1 Fournir et consommer des services web. . . 24

2.5.2 Structuration de la logique des processus. . . 26

2.5.3 Activités répétitives. . . 27

2.5.4 Traitement parallèle. . . 28

2.5.5 Manipulation des données. . . 32

2.5.6 Traitement des exceptions. . . 34

2.6 Raffinement de la structure d‟un processus. . . 35

2.6.1 Cycle de vie d‟un scope. . . 36

2.6.2 Gestion d‟erreur d‟un scope. . . 37

2.6.3 Terminaison d‟un travail en court d‟exécution. . . 37

2.6.4 Annulation d‟un travail terminé. . . 38

2.6.5 Gestion d‟événements. . . 39

2.7 Conclusion. . . 39

3. Transformations des modèles à l’aide de transformation de graphes 40 3.1 Introduction . . . 41

(7)

VI

3.2. Architecture dirigée par les modèles. . . 41

3.2.1 Notion de modèle . . . 41

3.2.2. La transformation des modèles. . . 43

3.2.3. Méta- modélisation et transformation. . . 44

3.2.4 Classification des approches de transformation. . . 46

3.2.4.1 Transformations de type Modèle vers code. . . 46

3.2.4.2 Transformations de type modèle vers modèle . . . 46

3.3 Les transformations de graphes. . . 48

3.3.1. Grammaires de graphes . . . 48

3.3.2 Le principe des règles. . . . . . .. . . 49

3.3.3 Application des règles. . . . . . 49

3.3.4 Système de transformation de graphes . . . 50

3.3.5 Outils de transformation de graphes . . . 50

3.4 Conclusion . . . 51

4. Une approche automatique de transformation d’un diagramme BPMN vers un code BPEL 52 4.1 Introduction. . . 53

4.2 Diagramme BPMN. . . 53

4.3 Code BPEL. . . .. 54

4.4 Ecriture du code BPEL à partir un diagramme BPMN. . . 55

4.5 Transformation d‟un diagramme BPMN vers un code BPEL. . . 55

4.5.1 Méta- modélisation du diagramme BPMN . . . 55

4.5.2 Génération de l‟environnement BPMN. . . 56

4.5.3 Grammaire de graphe pour la transformation d‟un diagramme BPMN vers un code BPEL. . . 57 4.5.4 Exemple. . . 69 4.5.4.1 Exemple 1. . . 69 4.5.4.1 Exemple 2. . . 72 4.6 Conclusion. . . 76 Conclusion et perspectives 77 Références bibliographiques 78

(8)

VII

Liste des figures

Pages Figure 1.1. Attributs d‟un BPD 05

Figure 1.2. Attributs communs à tous les composants d‟un BPD……….. 05

Figure 1.3. Attributs partagés par la catégorie objet de flu x……….. 06

Figure 1.4. (a) Début (b) Intermédia ire (c) Fin ……….. 06

Figure 1.5. Attributs des événements………. 07

Figure 1.6. Aperçu sur les causes du déclenchement et du résultat……… 08

Figure 1.7. (a) Sous-Processus (b) Tâche ………... 09

Figure 1.8. (a) Boucle (b) Instance Multiple (c) Exécution libre (AdHoc) (d) Co mpensation …. 09 Figure 1.9. Attributs communs aux activités ………. 10

Figure 1.10. les portes……….. 11

Figure 1.11. Attributs communs aux gateways……… 11

Figure 1.12. Un pool contenant deux lanes ……… ………. 12

Figure 1.13. Objet de données ……….. 13

Figure 1.14. Groupe………. 13

Figure 1.15. Annotation ……… 14

Figure 1.16. Attributs communs aux Ob jets de relation ………... 14

Figure 1.17. (a) Flux de séquence de base (b) Flux de séquence conditionné (c)Flux de séquence par défaut 14 Figure 1.18. Flu x de messages ………. 15

Figure 1.19. (a) Association non orienté (b) As sociation orienté ……….. 15

Figure 1.20. Processus de vote par Email ………. 16

Figure 1.21. Détaille du cycle de discussion ……… 17

Figure 1.22. Détaille du sous-processus: période de vote ……… …… 19

Figure 2.1. Processus BPEL……… 22

Figure 2.2. Interaction entre un processus et son partenaire ……… 23

Figure 2.3. Variables BPEL ……… 24

Figure 2.4. Activité « receive » ………. 25

Figure 2.5. Activité « reply » ……… 25

Figure 2.6. Activité « invoke » ……… 25

Figure 2.7. Activité « invoke » pour une opération WSDL requète-réponse……… 26

Figure 2.8. Activité « sequence » ……… 26

Figure 2.9. Activité « if-e lse » ……… 27

Figure 2.10. Activité « while » ……… 27

Figure 2.11. Activité « repeatUntil » ……… 27

Figure 2.12. Activité « forEach » ……… 28

Figure 2.13. Activité « flo w » ……… 28

(9)

VIII

Figure 2.15. Activité « flo w » avec « lin k » et « transitionCondition » ……… 30

Figure 2.16. Activité « flo w » avec « lin k », « transition Condition » et «join Condition »……… 31

Figure 2.17. Activité « assign » ……… 33

Figure 2.18. Activité « assign » avec les attributs du langage de requête……… 33

Figure 2.19. Gestionnaire d‟erreur dans un processus……… 34

Figure 2.20. Gestion d‟erreur d‟un scope……… 37

Figure 2.21. Gestion des terminaisons……… 37

Figure 2.22. Gestion d‟une compensation………. 38

Figure 3.1.. Aperçu globale du processus de transformations de modèles de l‟approche MDA …….. 43

Tableau 3.1. Niveau x d‟abstraction de la méta-modélisation 44

Figure 3.2: Niveau x d‟abstraction de la méta-modélisation. ……….. 45

Figure 3.3: (a) Modèle AFD des nombre b inaires pairs (b) Méta-modèle : Forma lisme AFD (Diagramme de classe UML + OCL) ………. 48 Figure 4.1: Un e xe mp le BPM N……….. 54

Figure 4.2 : Un code BPEL représentant le diagra mme BPM N de la Figure 4.1 ……… 54

Figure 4.3 : Meta-Model d‟un BPM N……….. 56

Figure 4.4 : Environnement BPMN sous ATOM3………... 56

Figure 4.5 : (a) LHS de la règle 1 (b) code généré par la règle 1 ………. 57

Figure 4.6 : (a) LHS de la règle 2 (b) Code généré par la règle 2 ……… 58

Figure 4.10 : (a) LHS de la règle 6 (b) Code généré par la règle 6……… 61

Figure 4.14 : LHS de la règle 10……… 63 Figure 4.15 : LHS de la règle 11……… 63 Figure 4.16 : LHS de la règle 12……… 64 Figure 4.17 : LHS de la règle 13……… 64 Figure 4.18 : LHS de la règle 14……… 64 Figure 4.19 : LHS de la règle 15……… 64 Figure 4.20 : LHS de la règle 16……… 65 Figure 4.21 : LHS de la règle 17……… 65

Figure 4.22 : (a) LHS de la règle 18 (b) Code généré par la règ le 18……… 65

(10)

IX

Figure 4.29 : BPD du processus " complaint-handling " ……… 69

Figure 4.30 : BPD du processus " plusieurs-scopes "……… 70

Figure 4.31 : Processus BPEL……….. 72

Figure 4.32 : Code BPEL du processus "Plusieurs-scopes"……… 72

(11)

Introduction Générale 1

Introduction générale

Le besoin d‟adaptation rapide des entreprises à de nouveaux contextes du marché offrant aux clients de meilleurs services plus complets dans les plus courts délais, a créé des demandes d‟établir des méthodologies de modélisation pour organiser et coordonner leurs actions, ou plus exactement leur processus d‟entreprise qui est par définition, le processus de mise en œuvre au sein d‟une organisation et dont les sorties répondent aux besoins d‟un client interne ou externe à cette organisation.

Un processus d‟entreprise consiste en une succession d‟étapes. Une personne ou plusieurs, éventuellement dans différents départements, se confient l‟une l‟autre des tâches et des données jusqu‟à ce que la mission soit remplie. Un processus d‟entreprise a un début et une fin. Certaines actions sont parfois répétées, la voie se sépare parfois en deux routes différentes. Quelle est la meilleure façon de schématiser tout cela? .Aujourd‟hui, il existe de multiple façons pour modéliser un processus d‟entreprise. Chacune avec son propre vocabulaire (les éléments graphiques ou les primitives d‟un langage de bas niveau) et sa propre grammaire (la sémantique de l‟assemblage). Il devient alors difficile pour les non initiés de travailler avec des modèles dans des langages différents. C‟est pourquoi une norme pour la représentation des processus d‟entreprise est fortement recommander tant au niveau schématique qu‟au niveau exécution.

D‟un coté, La BPMI (Business Process Management Initiative) a créé un groupe de travail international chargé de se pencher sur la question. Les participants ont notamment étudié la technique de „flowcharting‟, une technique de dessin que les programmateurs utilisent déjà depuis trente ans pour illustrer le fonctionnement d‟un programme. Ils se sont aussi tournés vers l‟UML, l‟Unified Modeling Language, une technique moderne servant à illustrer le fonctionnement d‟un programme orienté objet. Ils ont passé en revue une foule de techniques, discuté pendant deux ans et la notation BPMN (business process modeling

notation) a vu le jour en mai 2004.

De l‟autre, L‟organisme OASIS a établit un standard BPEL (business process

exécution language) chargé de coordonner les services des entreprises dans un contexte web.

Par conséquent, la méthode naturelle pour un développement bout à bout des systèmes orienté processus est de convertir les modèles BPMN vers les définitions BPEL. Toutefois, l‟instrumentation de cette méthode est un challenge parce que BPEL impose beaucoup plus de restrictions syntaxiques que BPMN.

(12)

Introduction Générale 2

Dans notre travail, nous proposons une technique automatique basée sur la transformation de graphes. Nous substituons à un élément atomique du graphe portant une étiquette spécifiée une nouvelle structure sous forme d‟un code textuel. Bien entendu, la nature complexe des graphes exige beaucoup d‟informations pour réaliser cette substitution ; en particulier, il faut indiquer de quelle manière le code obtenu va se rattacher au graphe d‟origine. Nous proposons une transformation dans laquelle les éléments atomiques considérés ne se limitent pas aux nœuds ou aux arcs, mais elle comprend les deux. Nous avons opté pour une approche entièrement automatique basée sur la méta- modélisation et les grammaires de graphes pour générer un code BPEL à partir d‟un schéma BPMN.

L‟objectif du premier et deuxième chapitre de ce mémoire est de présenter le vocabulaire et la grammaire des deux langages BPMN et BPEL.

Le troisième chapitre sera dédié à la transformation de modèles à l‟aide de transformation de graphe.

Le quatrième chapitre quand à lui, présentera notre contribution qui consiste en une approche automatique de transformation des spécifications BPMN vers du code BPEL.

(13)

Chapitre 1. Processus d’entreprise BPMN 3

Chapitre 1

(14)

Chapitre 1

Processus d’entreprise BPMN

1.1 Introduction

Un processus d‟entreprise est considéré comme une suite d‟étapes. Une ou plusieurs personnes se partagent des tâches en vue d‟atteindre un certain objectif. De nos jours, beaucoup de sociétés esquissent des représentations graphiques pour leur processus d‟entreprise grâce a des techniques de dessin que les programmateurs ont presque toujours utilisé pour illustrer le fonctionnement de leurs programmes. Etant des diagrammes de flux et plus connus sous le nom „flowcharts‟, leur simplicité à représenter des processus à petite ou grande échelle, les rend une source d‟inspiration pour tout individu souhaitant mettre de l‟ordre dans ses projets. Ce qui a impliqué la circulation de plusieurs variantes, chacune avec son degré d‟expressivité et de complexité. Le dessin devient alors rapidement complexe, illisible et ambigüe, d‟où la nécessité d‟établir une norme facilement compréhensible par tous les acteurs impliqués dans l‟utilisation d‟un processus (depuis les analystes métier chargés d‟industrialiser le processus jusqu'aux développeurs qui exécuteront ce dernier).

Après six années et plus de 140 réunions, physiques et virtuelles, la BPMN (Business

Process Modeling Notation), une nouvelle norme, fait son apparition en proposant un

ensemble d‟éléments graphiques normalisés et une grammaire permettant leur manipulation. La BPMN doit à la fois être simple et capable de gérer les complexités inhérentes au processus métier, elle doit aussi être facilement traduite en langage exécutable tel que BPEL (Business Process Execution Language) sur un moteur de Workflow.

Le but de ce chapitre est d‟introduire les objets graphiques de la BPMN (BPD Business

Process Diagrams), en se basant sur le document de travail de l‟OMG (Object Management Group) : « Business Process Modeling Notation » du 03 janvier 2009 [OMG09], Avec une

manière souple allant des objets les plus simples (les plus utilisés aussi) aux objets plus complexes. En fin de chapitre, nous mettrons en œuvre la BPMN au travers d‟un exemple.

1.2 Diagramme BPMN (BPD)

Un BPD représente les différentes étapes du processus et leur succession à l‟aide d‟un ensemble de nœuds (Objets de flux) connectés par un ensemble d‟arcs (Objets de relation) et regroupés dans des Groupements selon leur appartenance à un tel ou tel participant.

(15)

L‟ensemble du diagramme dispose d‟attributs qui l‟enrichissent avec des informations complémentaires comme sur la figure 1.1 :

ID : Name : Version : Author : Language : Que ryLanguage : CreationDate : ModificationDate : Pools : Documentation :

identifiant (unique) du diagramme. texte descriptif du diagramme. numéro de version.

auteur du diagramme. langue de la partie texte. langage de requête. date de création. date de modification.

les groupements du diagramme. documentation supplémentaire.

Figure 1.1. Attributs d‟un BPD

Le diagramme réunit également un ensemble d‟attributs communs à tous ses composants (voir la figure 1.2) :

Id : Categories : Documentation :

identifiant caractérisant un composant.

catégories auxquelles appartient le composant. documentation textuelle du composant

Figure 1.2. Attributs communs à tous les composants d‟un BPD

Nous présentons dans ce qui suit les composants d‟un diagramme BPMN qui font partie des trois catégories que nous venons de citer et aussi, une quatrième catégorie qui apporte des informations supplémentaires au diagramme.

1.2.1 Objets de flux

Ce sont les objets élémentaires composant le flux d‟un processus. Ces objets (Evènements, Activités et Portes) partagent les attributs suivants (en plus des attributs communs aux composants d‟un BPD) (voir la figure 1.3) :

(16)

Name : Assignments :

identifiant caractérisant un objet. expressions d‟affectation.

Figure 1.3. Attributs partagés par la catégorie objet de flux 1.2.1.1 Evènements

Avec une apparence en forme de cercle, les événements, selon les propriétés qui leurs sont assignées, réagissent à la survenu de situations particulaires pour affecter le flux du processus. Leurs réactions peuvent être séparées en deux catégories : Déclenchement (Trigger) et Résultat (Result).

Les événements peuvent être de trois types différents : Début (Start), intermédiaire (Intermediate), fin (End). L‟événement Début est représenté par un cercle fin, il indique le point de départ. L‟événement intermédiaire est représenté par un double cercle et peut être utilisé de deux façons : au milieu d‟un flux ou rattaché à une tache. Et celui de fin est représenté par un cercle épais et marque la fin d ‟un processus (voir la figure 1.4).

(a) (b) (c)

Figure 1.4. (a) Début (b) Intermédiaire (c) Fin

Les événements sont soumis à des règles d‟utilisation. Les règles les plus importantes à respecter dans un diagramme BPMN sont :

 Le diagramme peut contenir de « 0 » à « n » événements Début et événements Fin.

 S‟il contient au moins un événement Début, il doit contenir au moins un événement Fin.

 S‟il contient au moins un événement Fin, il doit contenir au moins un événement Début.

 S‟il ne contient pas d‟événements Début, alors, les objets de flux ne possédants pas d‟arcs entrants constituent le début du processus et doivent démarrer en parallèle.

(17)

 S‟il ne contient pas d‟événements Fin, alors, les objets de flux ne possédants pas d‟arcs sortants constituent la fin du processus. Ce dernier s‟achèvera une fois tous ses sommets sont atteints.

La figure 1.5 montre les attributs communs aux événements et ceux qui sont spécifiques aux types Début, Intermédiaire et Fin (ces attributs s‟ajoutent à ceux partagés par la catégorie objet de flux). EventType : (attribut commun) Trigger : (attribut du Début) Trigger : (attribut d‟Intermédiaire) Result : (attribut de Fin)

type d‟événement (Début, Intermédiaire ou Fin).

déclencheur (Message, Time, etc.)(voir Figure 1.6).

résultat (Message, Erreur, etc.)(voir Figure 1.6).

Figure 1.5. Attributs des événements

Les catégories déclenchement et résultat peuvent être affectées pas 10 causes distincts, chacune se concrétise par une icône placée à l‟intérieur du pattern de l‟événement, la figure 1.6 donne un aperçus sur chaque cause :

Cause Déclenche ment résultat

symboles

Attente Lancement

Début Inte rmédiaire Fin

AUCUN Aucune indication sur le type (qui existe) n‟est affichée.

MESSAGE Message reçus de la part d‟un

participant

Envoie de message à l‟un des participants

TIMER Un moment est déterminé (date,

heure, etc.)

ERREUR Une erreur s‟est _{produite dans} l‟activité (avec laquelle il doit être

Envoie d‟un rapport d‟erreur à un événement

(18)

Chapitre 1. Processus d’entreprise BPMN 8 attaché) intermédiaire ANNULATION Une annulation au niveau de l‟activité (de type transaction) (avec

laquelle il doit être attaché) Annulation d‟une activité de type transaction COMPENSATION Une compensation nécessaire de l‟activité (avec laquelle il doit être

attaché)

Demande de compensation

CONDITIONNEL Une condition doit être vérifié (ex :

Age > 5 ans).

LIEN _{Destination d‟un}

lien source Lien source

SIGNAL Recevoir un signal émit d‟un participant

Signal émit

FIN Arrêt immédiat de toutes les activités

du processus

MULTIPLE Plusieurs causes sont possible (une

seule cause suffi)

Plusieurs résultats sont attendus (ex : deux messages

envoyés)

Figure 1.6. Aperçu sur les causes du déclenchement et du résultat 1.2.1.2 Activités

Dans le but d‟atteindre l‟objective pour lequel le processus d‟entreprise est lancé, des activités sont effectuées par des humains ou des applications logicielles. Un BPD renseigne à la fois des activités manuelles et des activités automatisées.

(19)

Les activités peuvent être des processus (Process), des sous-processus (Sub-Process) ou des tâches (Task). Ce dernier type est atomique et ne renferme pas de détail interne (d‟autres tâches) contrairement aux deux premiers qui définissent des abstractions et permettent le choix de la granularité de l‟information à représenter.

Les processus n‟ont pas de symbole particulier, ils représentent une partie du BPD délimitée par un ou plusieurs Groupements. Les sous-processus et les tâches quand à eux, prennent la forme d‟un rectangle aux coins arrondis. Dans ce qui suit le rectangle avec un signe « + » en bas centre est un sous-processus masquant son détaille interne. Un double clic sur l‟activité permet de réafficher les détails internes (voir la figure 1.7).

(a) (b)

Figure 1.7. (a) Sous-Processus (b) Tâche

Dans une activité on retrouve jusqu‟à 5 symboles indiquant son comportement : le symbole du sous-processus que nous venons de voir (celui avec le signe « + »), le symbole de Boucle (Loop), le symbole d‟Instance Multiple (Multipe-Instance) qui affirme la possibilité d‟exécuté l‟activité plusieurs fois en parallèle, le symbole d‟exécution libre (AdHoc ) permettant une exécution avec un ordre aléatoire et le symbole de compensation qui se traduit par l‟exécution de son activité (reliée à un événement de compensation) en cas d‟interruption du sous-processus auquel l‟événement de compensation est rattaché (voir la figure 1.8).

(a) (b) (c) (d)

Figure 1.8. (a) Boucle (b) Instance Multiple (c) Exécutions libre (Ad Hoc) (d)

(20)

Il est possible de combiner les symboles dans une même activité si les règles suivantes sont respectées :

 Une activité peut contenir de 0 à 3 symboles.

 Une activité ne peut pas contenir conjointement les symboles Boucle et Instance Multiple.

 Une tâche ne peut comporter le symbole Ad Hoc.

Les activités comportent beaucoup d‟attributs car concrètement, ils représentent l‟intérêt principal d‟une modélisation en BPMN et schématiquement le processus, le sous processus et la tâche ont des vues et des symboles multiples. Les attributs communs aux activités sont comme sur la figur 1.9 :

ActivityType : Status : Performe rs : Properties : InputSets : OutputSets : IORules : StartQuantity : CompletionQuantity : LoopType :

type de l‟activité (tâche, sous-processus).

état de l‟activité par rapport à l‟ensemble du diagramme. participants.

les propriétés de l‟activité (locales). conditions d‟entrée.

conditions de sortie.

lien entre conditions d‟entrée et conditions de sortie. nombre de flux nécessaire pour commencer l‟activité. nombre de flux devants être générés depuis l‟activité. Type de boucle (Boucle, Instance Multiple).

Figure 1.9. Attributs communs aux activités 1.2.1.3 portes

Le flux circulant dans un processus rencontre souvent des carrefours à deux ou plusieurs voies possibles. Suivant leur nature, les carrefours convergent et divergent les flux qu‟ils rencontrent selon une stratégie prédéfinie. En BPMN c‟est le mécanisme de portes (Gateway) qui assure cette fonctionnalité.

Les portes sont représentées par un losange à l‟intérieur duquel, des symboles s‟intègrent à volonté (à l‟instar des évènements et des activités), pour illustrer son comportement. Cinq sortes de portes existent (voir la figure 1.10) :

(21)

Portes Description présentation

« O u E xc lu si ve » (X O R ) basé données (Data-Based)

Une seule option est choisie en fonction de la condition liée aux arcs sortants. Une option supplémentaire pour garantir le passage du flux (option par défaut) peut être ajoutée. S‟il existe plusieurs arcs entrants alors le gateway fait passer les flux (un par un) sans condition particulière.

ou

basé évènements (Event-Based)

Une seule option est choisie en fonction du changement d‟état des objets (évènement

Début, évènement End ou activité de type ‘Réception’ (receive)) qui se trouvent à

l‟arriver des arcs sortants. S‟il existe plusieurs arcs entrants alors le gateway se comporte comme le précédant.

« Ou inclusif » (OR)

Contrairement au XOR, le « ou inclusive » n‟exclut pas la possibilité d‟emprunté plus d‟un chemin. Une option par défaut est utile pour garantir le passage du flux.

« Parallèle » (Parallel)

Toutes les options sont choisies à l‟arriver du flux.

« Complexe » (Complex)

Si les gateways précédents ne suffisent pas, le modeleur peut avoir recours à ce dernier.

Figure 1.10. les portes

Les attributs communs des Gateways sont (voir la figure 1.11) :

GatewayType : Gates :

Détermine le comportement du Gateway (Exclusive, Inclusive…) Les sorties du gateway.

Figure 1.11. Attributs communs aux gateways 1.2.2 Groupe ments

Les groupements illustrent un mécanisme d‟organisation des activités dans différentes catégories pour mettre en valeur des fonctionnalités ou des responsabilités particulières. Ainsi, les groupements caractérisent les interactions entre processus en mettant en œuvre le contexte collaboratif (B2B) (Business to Business). Ils sont de deux types : Groupement (Pool), sous

(22)

groupement (Lane). Les attributs communs aux groupements se limitent à un seul : l‟attribut Name (nom). C‟est l‟intitulé du groupement.

1.2.2.1 Groupement graphique

Plus connu sous le nom « pool », le groupement graphique isole son contenu du reste du diagramme et coopère avec les entités externes par envoi et réception de messages. Il présente deux options : usage en tant que « boite noire » (aucun détail sur son contenu n‟est affiché) et usage en tant que « boite blanche » (affichage des détails internes).

1.2.2.2 Sous- groupement

Les sous-groupements (Lanes) ont pour but d‟organiser le contenu des groupements (pools) pour mettre l‟accent sur les sous-ensembles qui présentent un intérêt particulier. Un

Lane peut contenir un autre, en parle alors d‟une hiérarchisation de contenance. Dans la figure

1.12, les départements 1 et 2 présentent les deux sous-groupements du groupement « entreprise » dans un processus achat :

Figure 1.12: Un pool contenant deux lanes 1.2.3 Objets symboliques

Pour obtenir un diagramme suffisamment explicite, les objets symboliques (Artifacts) sont introduits pour apporter des informations supplémentaires au modèle. De plus, ces objets se différencient des autres objets par le fait qu‟ils n‟affectent en rien le déroulement du processus. L‟attribut « ArtifactType » (représentant le type de l‟objet symbolique) est commun à tous les objets de cette catégorie. La norme propose trois valeurs pour cet attribut : Objets de données, Groupe et Annotation. En outre, le rajout d‟autres valeurs est possible et permet au modeleur de choisir d‟autres formes s‟il trouve qu‟elles sont plus expressives ou

(23)

correspondent aux attentes de ses clients. Dans ce qui suit nous présentons les Trois types de base :

1.2.3.1 Objet de données

Son utilisation fréquente dans les documents de gestion orientés workflow et aussi dans d‟autre méthodologies de modélisation, fait de cet objet de données un élément incontournable dans la liste des objets symboliques. Cet élément présente des informations (le contenu, l‟état ? etc.) sur les documents, les données et d‟autres objets durant l‟exécution du processus (voir la figure 1.13).

Figure 1.13. Objet de données 1.2.3.2 Groupe

Le modeleur peut informellement réunir en groupes les éléments qui vont de pair dans son diagramme. Le groupe est représenté comme suit (voir la figure 1.14) :

Figure 1.14. Groupe 1.2.3.3 Annotation

Les annotations ajoutent des informations textuelles au diagramme pour lever les ambigüités qui peuvent y survenir. Le texte de l‟annotation est présenté à l‟intérieur d‟un croché dans ce qui suit (nous verrons la signification du très en pointillés dans la prochaine section) (voir la figure 1.15) :

(24)

Figure 1.15. Annotation 1.2.4 Objets de relation

Les objets de relation font la liaison entre les objets d u diagramme. La catégorie Flux de séquences relie une activité à une autre, une activité à un événement ou une activité à une condition de branchement (Gateway).

La catégorie Flux de messages quand à elle représente l‟envoie de messages d‟une entité à une autre et enfin, la catégorie Associations joint les Objets symboliques (artefacts) aux objets de modélisation.

Les attributs appartenant à tous les éléments de la catégorie Objets de relation sont (voir la figure 1.16) :

Name : Source Ref : TargetRef :

intitulé de l‟objet.

identification de l‟objet source. identification de l‟objet destination.

Figure 1.16. Attributs communs aux Objets de relation 1.2.4.1 Flux de séquences

Les flux de séquences sont utilisés dans le but d‟ordonnancer l‟exécution des activités du diagramme. Ils représentent les interconnexions au sein d‟un même Groupement et ne peuvent pas aller au-delà de ses frontières. Schématiquement, les flux de séquences ont la forme d‟une flèche orientée généralement de gauche à droite ou de haut en bas, allant d‟une seule source à une seule destination. Les trois formes possibles d‟un flux de séquence sont (voir la figure 1.17) :

(a) (b) (c)

Figure 1.17. (a) Flux de séquence de base (b) Flux de séquence conditionné (c)Flux de

(25)

Le flux de séquence conditionné doit obligatoirement comporter un petit losange s‟il a comme origine une activité. C‟est une manière, s‟ils sont deux ou plus, de distinguer le comportement conditionné du comportement parallèle. Le flux de séquence par défaut représente une option par défaut, il a une forme particulière pour le différencier des autres options.

1.2.4.2 Flux de messages

Les flux de messages assurent l‟envoi de messages d‟une entité à une autre. Ils doivent connecter un pool ou un objet se situant dans ce pool à un autre pool ou un objet se situant dans ce dernier. Souvent, la direction qu‟ils prennent forme un angle de 90° par rapport à celle emprunté par les flux de séquences et ce, par mesure de clarté. Il y a une seule représentation graphique possible pour le flux de messages (voir la figure 1.18) :

Figure 1.18. Flux de messages 1.2.4.3 Associations

Les associations, comme les autres flux de leur catégorie, font la liaison entre deux objets. Ils associent un objet symbolique à un flux ou à un objet de flux et aussi, un évènement de compensation à une activité. Deux représentations graphiques existent (voir la figure 1.19) :

(a) (b)

Figure 1.19. (a) Association non orienté (b) Association orienté 1.3 Illustration par un exemple

Les diagrammes de l‟exemple suivant sont une traduction de [Touzi07] des diagrammes du document de travaille BPMN [BPMI04] qui sont toujours présents dans la version actuelle [OMG09]. Ils présentent plusieurs aspects de la norme, des plus simples aux plus complexes et seront expliqués en détail dans les prochaines sections :

(26)

1.3.1 Diagramme BPMN de l’exemple (voir la figure 1.20)

Figure 1.20. Processus de vote par Email 1.3.2 Inte rprétation du diagramme

Pour une meilleure interprétation du diagramme, les parties début du processus et fin du

processus seront détaillées. Nous verrons aussi de plus prêt Les deux sous-processus cycle de discussion et période de vote.

Début du processus

Le processus commence avec un événement de type Timer qui lance le processus tous les vendredis. Le gestionnaire de listes des sujets traite ces derniers et choisi ceux qui pourront rentrer dans le cycle de discussion et de vote. La décision doit être prise (décider si les sujets sont prêts ou non) soit pour enclencher le cycle de discussion et de vote soit pour en arrêter là et attendre la semaine prochaine. Le sous-processus cycle de discussion possède deux flux de séquences entrants et peut être entrepris si l‟un des deux véhicule un flux et ce,

(27)

en cas de présence de sujets à traiter ou suite à un besoin de rediscuter un sujet (qui ne possède pas la voix de la majorité).

Fin du processus

Les résultats sont admis si le taux des votants est acceptable. Si les votants représentent un faible taux, les sujets ne peuvent pas être résolus. Dans ce cas, une vérification concernant l‟avertissement ou non des non-votants s‟impose. Si le membre du groupe qui ne s‟est pas présenté au vote n‟était pas prévenu au préalable (pour le vote de la semaine en cours), alors une annonce de vote accompagnée d‟un avertissement lui sont envoyés. Il est retiré de la liste des votants s‟il ne participe pas à un second vote (dans les mêmes conditions) et le taux des votants est recalculé (les sujets sont reportés pour la semaine prochaine si le taux n‟est pas concluant).

Si le taux des votants est acceptable, le traitement des sujets proposés est vérifié afin de déterminer l‟existence ou non d‟une voix majoritaire et concluante. Si oui, le processus se termine, sinon le processus sera amené à ne conserver que les deux résultats les plus cotés et relancera dans le vote ceux qui n‟avaient pas voté pour ces deux choix. Toutefois, une difficulté à déterminer ces deux résultats est possible, dans ce cas, on doit recourir à un nouveau cycle de vote et de discussion.

Cycle de discussion

Le détail du Sous-Processus (traduction de [Touzi07]) est le suivant comme sur la figure 1.21) :

(28)

Le gestionnaire de la liste de sujets envoie un Email aux membres votants afin d‟ouvrir une discussion sur les sujets (annonce des sujets de discussion). Trois différents chemins bifurquent en parallèle dans le sous-processus (notez l‟absence des petits losanges au début des arcs sortants) et qui par le biais du Gateway parallèle, se joignent.

La « modération des discussions par mails » comporte un événement intermédiaire de type Timer attaché à sa bordure. La présence des événements Début et Fin impose la sortie d‟un second arc depuis cette activité en plus de celui du Timer en cas où la tâche ne s‟achèvera pas convenablement. De plus, la tâche passe le flux à travers un seul de ses arcs sortants. Par conséquent, un Gateway exclusive joint les deux arcs originaires de cette tâche pour éviter une attente sans fin du Gateway parallèle.

L‟envoi des notifications de deadline est précédé par un Timer qui fixe un délai de 6 jours avant son entreprise. Il est à l‟origine du flux de séquence « Annonce deadline » de la figure 1.20. Un objet de donnée (document comportant le planning du groupe) est utilisé afin d‟établir un planning pour une conférence téléphonique. Un flux sort de cette activité après initialisation de la réponse à la question : « conférence téléphone cette semaine ? ». Si la réponse est affirmative, une date pour la conférence est attribuée au Timer qui précède l‟activité : « modération de la discussion ». Dans le cas contraire le flux emprunte le flux de séquence par défaut. Enfin, un Gateway assure la jointure des deux chemins pour les mêmes raisons que son congénère.

La provenance d‟un flux depuis le Gateway parallèle (après réception de tous les flux de ses chemins rentrants) provoque le démarrage de l‟activité : « évaluation de l‟évolution de la discussion ». Une variable est initialisée suite au résultat de l‟évaluation (selon l‟évolution est normale ou anomale) pour vérifier la condition de la boucle (modélisée par le symbole de boucle en bas centre de l‟activité).

Période de vote

Le détail du Sous-Processus (traduction de [Touzi07]) est comme suit (voir la figure 1.22) :

(29)

Figure 1.22. Détaille du sous-processus: période de vote

Puisque ce processus présente les objets: activité, événement de type Timer et objet de données comme son prédécesseur. En plus, il ne comporte pas de Gateway alors sa description dans le paragraphe suivant sera brève. Si les votes peuvent commencés (selon le gestionnaire de la liste des sujets) ou bie n doivent être relancés en cas de résultat non concluant alors le sous-processus démarre en empruntant quatre chemins afin de traiter en parallèle: la gestion des conférences téléphoniques, la modération des échanges par mails, l‟annonce de la deadline pour les votes et le décompte des voix.

1.4 Conclusion

BPMN est la notation standard la plus adaptée pour modéliser les processus

d‟entreprise. La plupart des outils du marché supportent la norme mais malgré cela, elle n‟est pas largement utilisée. Ce constat est logique car dans le monde des „flowcharts’, l‟objective de la modélisation constitue la première brique sur laquelle la grammaire d‟un processus métier est construite. La BPMN s‟oriente plus vers la transformation d‟un processus d‟entreprise en processus exécutable et il en résulte une grammaire qui ne répond pas aux attentes des annalistes et modélisateurs métier. De plus, l‟absence flagrante des approches d‟analyses telle que la gestion des risques impose la mise en œuvre des règles de validation et ainsi complique considérablement la tâche du staff métier.

(30)

Chapitre 2. Langage d’exécution BPEL 20

Chapitre 2

(31)

Chapitre 2

Langage d’exécution BPEL

2.1 Introduction

Aujourd‟hui, les entreprises ont besoin de s‟adapter rapidement aux nouvelles approches proposant des services meilleurs, rapides et complets. Des plates- formes communes d‟échange et de collaboration d‟information constituent un élément clé pour satisfaire ces besoins compte tenu leur implémentation facilitée par l‟utilisation de l‟architecture orientée services (SOA).

Les services les plus utilisés dans ces plates- formes sont des services web. Les services web ont gagné beaucoup d‟importance dans le développement des logiciels grâce à leur indépendance par rapport aux langages de programmation et pa rce qu‟ils permettent d‟être réutilisables pour fournir des services plus élaborés.

Pour réaliser une application basée sur les services web, il nous faut un plan prédéfini permettant de décrire la coordination des services. Ce plan s‟appel l‟Orchestration. L‟Orchestration décrit un modèle de coordination de services qui sera exécuté à l‟aide d‟un Moteur d'Orchestration.

L‟Orchestration est représentée par un workflow (flux de travail) coordonnant des services (et plus particulièrement des services web), ce qui offre des avantages comme l‟optimisation et l‟automatisation de tâches. Un workflow modélise la gestion informatique de l'ensemble des tâches à accomplir par les différents acteurs impliqués dans la réalisation d'un processus métier. Ces acteurs peuvent être des humains réalisant les tâches demandées, ou des services (services web, applications locales ou distantes…). Le workflow se charge de l‟administration ou le contrôle de la coordination de ces acteurs et services.

Comme toute modélisation d‟un processus métier, l‟orchestration des services web nécessite l‟élaboration d‟un langage. Plusieurs langages ont étaient développé dans ce but : WSFL (Web Service Flow Language) développé par IBM et étant une extension de FL, leur langage de modélisation de processus ; et XLANG de Microsoft qui était une extension de WSDL [Christensen01] (web service description language), un langage qui décrit les web

(32)

services. La fusion de ces deux langages a donné naissance à un standard basé sur le langage XML. Ce langage s‟appel BPEL (business process execution language).

En 2003, la collaboration entre IBM et Microsoft a mené à la publication de la norme BPEL4WS 1.1 [BEA03] (BPEL for Web Services) ; celle-ci a ensuite été soumise au consortium OASIS, et ce nouveau tra vail a abouti en 2007 à la norme WSBPEL 2.0 [OASIS07] qui apporte quelques nouveautés. Le terme « BPEL » désigne de manière globale ces deux langages. Dans le cadre de notre chapitre, nous présentons les concepts de base de ce langage avec quelques exemples et ce, depuis la dernière version de la spécification de ce langage [OASIS07].

2.2 Structure des processus BPEL

Un processus BPEL est un container dans lequel la relation avec des partenaires externes, des déclarations pour les données du processus, des gestionnaires pour des buts divers et plus important, des activités à exécuter, sont introduits. Le container du processus comporte deux attributs (« name » et une déclaration de l‟espace de nom) comme le montre l‟exemple suivant sur la figure 2.1 :

<process name="Process"

targetNamespace="http://oasis-open.org/WSBPEL"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" />

Figure 2.1. Processus BPEL

La déclaration de l‟espace de nom (http://docs.oasis-open.org/wsbpel/2.0/process/

executable) signifie que ce processus est exécutable. Un espace de nom additionnel est prévu pour les processus abstraits. Les processus abstraits décrivent partiellement le comportement des processus sans se préoccupé des détailles liés à l‟exécution. Ce comportement expose (de manière typique) un modèle de processus ou un comportement externe visible du processus à l‟égard des partenaires métiers sans montrer sa logique interne. Le processus exé cutable, par contre, définit le comportement métier complet des parties internes et externes. L‟élément « process » est le container le plus à l‟extérieur. En effet, tout partenaire, données de processus ou gestionnaires déclarer à l‟intérieur peut être considéré comme global. BPEL support également un mécanisme de déclaration de toutes ces propriétés de manière local. L‟élément structurant qui assure cette fonctionnalité est « scope ».

(33)

Chapitre 2. Langage d’exécution BPEL 23 Avec l‟aide des scopes, il est possible de diviser un processus métier chacun contenant une portion de la logique métier globale. Par exemple, les données du processus déclarées localement dans un scope ne sont pas visibles à l‟extérieur de ce dernier (seulement valide à l‟intérieur d„une partie spécifique du processus).

2.3 Relation entre BPEL et ses partenaires

Les processus métiers BPEL offrent la possibilité d‟agrégation des services web et définissent la logique métier pour chaque interaction entre services. Il s‟agit d‟une orchestration des interactions entre services web. Chaque interaction peut être vue comme une communication avec un partenaire métier. Une interaction est décrite à l‟aide de liens entre partenaires (partner links). Ce sont des instances spécifiant des connecteurs typés qui spécifient les types de ports WSDL se trouvant à chaque extrémité.

Pour un partenaire, il peut y avoir un ensemble de liens. Un lien peut être vu comme un canal de communication. Une telle interaction a deux côtés : le processus invoque le partenaire et vise versa. Ainsi, chaque partnerlink est caractérisé par un type (partnerLinkType) et un rôle. Cette information identifie la fonctionnalité qui doit être fournit par le processus métier et le service partenaire (voir la figure 2.2).

<partnerLink name="ClientStartUpLink"

partnerLinkType="wsdl:ClientStartUpPLT" myRole="Client" /> </partnerLinks>

Figure 2.2. Interaction entre un processus et son partenaire

Les déclarations d‟un Partner link peuvent prendre place directement à l‟intérieur de l‟élément « process » pour permettre leur accessibilité par les constructions BPEL à l‟intérieur du process, ou à l‟intérieur d‟un élément « scope » pour une accessibilité exclusive par les éléments fils du « scope ».

2.4 Etat d’un processus BPEL

Nous avons vue dans la section 2.2, les « données du processus ». ces données représentent l‟ensemble des variables déclarées dans le processus ou dans un « scope » à l‟intérieur de ce processus. Les variables contiennent les données qui constituent l‟état du processus métier durant son exécution. De plus, Les données peuvent être écrit sur ces

(34)

variables ou lu à partir de ces derniers. Les valeurs contenues dans ces variables peuvent provenir de deux sources : soit à partir des messages échangées avec un partenaire, soit à partir des données intermédiaires qui sont propres au processus (des données privées). Pour respecter la convention de type avec le partenaire, toutes les variables dans BPEL doivent être de type message WSDL, de type XML schéma simple, de type XML schéma complexe ou des éléments XML schéma. Afin de changer l‟état d‟un processus à travers le changement du contenu de ses variables, un langage d‟expression pour manipuler et interroger les variables est nécessaire. En BPEL, le langage par défaut prévu pour cet effet est Xpath 1.0 [Clark99a].

Il est possible de déclarer une variable par un nom et l‟un des trois types mentionnés plus haut (avec les trois attributs : « type », « messageType » ou « element ») (voir la figure 2.3).

Figure 2.3: Variables BPEL

Les déclarations de variables peuvent apparaitre directement à l‟intérieur des balises du « process », et ils sont ainsi visibles aux constructions contenues dans ces balises. Ils peuvent apparaitre également à l‟intérieur d‟un « scope » (ils sont ainsi visibles exclusivement aux fils du « scope »).

2.5 Comporte ment d’un processus BPEL

La majorité des structures d‟un processus BPEL sont des activités. Il y a deux types : Activités structurées (peuvent contenir d‟autres activités et définir la logique métier entre eux) et Activités de base (ne peuvent pas contenir d‟autre activités).

2.5.1 Fournir et consomme r des services web

En BPEL, il existe quelques activités simples qui ont pour but de fournir et consommer des messages à travers leur interaction avec les services web partenaires. Ces activités sont : « receive» (réception), « reply » (réponse) et « invoke » (appel ou invocation). Toutes ces activités permettent l‟échange des messages avec des partenaires externes (services). L‟intérêt de l‟activité « receive » est de recevoir les messages depuis ses partenaires externes. Par conséquent, ce type d‟activité spécifie toujours les Partner links et l‟opération des partenaires.

(35)

Des variables sont nécessaires également pour contenir les données essentielles reçus d‟un partenaire. Une activité de type réception peut avoir un « reply » associé si elle est utilisée pour fournir une opération WSDL de type requête-réponse (voir la figure 2.4).

<receive name="ReceiveRequestFromPartner" createInstance="yes"

partnerLink="ClientStartUpPLT" operation="StartProcess" ... />

Figure 2.4: Activité « receive »

L‟attribut « createInstance » à l‟intérieur de l‟activité «receive» signifie qu‟il est possible d‟utiliser une activité de type « receive » avec une valeur «yes» pour l‟attribut pour créer une nouvelle instance du processus. Par contre, si cette valeur est « no » alors le message reçu sera consommé par l‟instance déjà exécutée. Comme déjà mentionné, une activité de type «receive» peut avoir une activité « reply » associée. Par exemple, si un client veut commander un livre depuis un processus de vente. Un client enverrait une requête à l‟activité de type « receive » du processus de vente. Le processus ferait quelques vérifications d‟ordre logique (internes) (par exemple si le livre est disponible…). Ensuite, il serait naturel pour le processus de répondre au client pour le tenir informer à propos du succès ou de l‟échec de sa commande (voir la figure 2.5).

Figure 2.5. Activité « reply »

La troisième activité liée aux services web est « invoke ». C‟est une activité utilisée pour appeler un service web fournit par un partenaire. Le « partnerLink » et l‟opération du service web doivent être spécifiés (voir la figure 2.6).

Figure 2.6. Activité « invoke »

En WSDL il existe de multiples types d‟opérations. Deux d‟entre eux sont supportés par BPEL: les opérations à sens unique et les opérations de type requête-réponse. Une

(36)

activité « invoke » peut donc soit appeler une opération à sens unique (n‟attend pas de « reply »), soit faire une opération requête-réponse (qui bloque le processus jusqu‟à réception d‟un « reply » depuis le service partenaire). Si l‟opération invoquée est de type requête-réponse, des variables d‟entrée et de sortie doivent être fournies (voir la figure 2.7).

<invoke name="RequestResponseInvoke" partnerLink="BusinessPartnerServiceLink" operation="RequestResponseOperation" inputVariable="Input"

outputVariable="Output" />

Figure 2.7. Activité « invoke » pour une opération WSDL requête-réponse 2.5.2 Structuration de la logique des processus

BPEL fournit des moyens pour structurer la logique métier suivant les besoins. Si les activités ont besoin d‟être exécutés dans un ordre séquentiel alors l‟activité « sequence » est utilisée (voir la figure 2.8).

Figure 2.8. Activité « sequence »

Une autre activité utilisée pour structurer la logique métier est l‟activité « if-else » (si-sinon). La construction peut être devinée depuis les langages de programmation traditionnels. L‟activité « if-else » permet la sélection d‟une possibilité parmi plusieurs. Comme avec toutes les expressions de BPEL, Xpath peut être utilisé pour formuler la condition (voir la figure 2.9).

(37)

Chapitre 2. Langage d’exécution BPEL 27 <if name="isOrderBiggerThan5000Dollars"> <condition>  $order > 5000 </condition> <invoke name="calculateTenPercentDiscount" ... /> <elseif> <condition>  $order > 2500 </condition> <invoke name="calculateFivePercentDiscount" ... /> </elseif> <else> <reply name="sendNoDiscountInformation" ... /> </else> </if>

Figure 2.9. Activité « if-else » 2.5.3 Activités répétitives

BPEL offre trois activités permettant une exécution répétitive d‟une portion de logique métier. L‟une de ses activités est l‟activité « while ». L‟activité « while » est une activité structurée (elle a un fils emboité à l‟intérieur). Le « while » permet une exécution répétitive de l‟activité emboitée aussi longtemps que la condition est vrai. Cette condition est placée au début de l‟activité et elle est évaluée à chaque itération. Cela veut dire que le corps du « while » ne doit pas être exécuté (voir la figure 2.10).

<while> <condition> $iterations > 3 </condition> <invoke name="increaseIterationCounter" ... /> </while>

Figure 2.10. Activité « while »

Par contre, l‟activité « repeatUntil » est différente par le fait que son corps est exécuté au moins une fois, parce que la condition est évaluée à la fin de chaque itération (voir la figure 2.11). <repeatUntil> <invoke name="increaseIterationCounter" ... /> <condition> $iterations > 3 </condition> </repeatUntil>

(38)

La troisième activité du groupe d‟activités répétitives est le « forEach ». Dans son comportement par défaut, l‟activité « forEach » itère séquentiellement N fois sur un ensemble d‟activités. Concrètement, le « forEach » itère son contenu (son « scope ») exactement N fois. N étant égale le « finalCounterValue » moins le « startCounterValue » plus 1 (voir la figure 2.12).

<documentation>check availability of each item ordered</documentation> <invoke name="checkAvailability" ... />

</scope> </forEach>

Figure 2.12. Activité « forEach »

Deux variantes « forEach » existent : séquentielle et parallèle, comme spécifié par l‟attribut « parallel ». Une restriction est appliquée au « forEach » : toutes les activités que nous venons de voir peuvent avoir une activité emboité à l‟intérieur, ce qui n‟est pas le cas du « forEach » qui ne peut contenir que des « scope ».

2.5.4 Traitement parallèle

Jusqu‟ici, nous avons introduis des concepts variés sur la manière dont un processus métier peut être structuré séquentiellement. Toutefois, il est parfois préférable ou même nécessaire d‟exécuter en parallèle. Pour cette raison, BPEL offre l‟activité de type « flow ». Dans l‟exemple suivant, un ensemble composé de trois activités (checkFlight (vérifier le vole), checkHotel (vérifier l‟hotel) et checkRentalCar (vérifier la voiture de location)) sont exécutées en parallèle (leurs services web correspondants seront exécutés en concurrence). Les trois activités démarrent en concurrence au démarrage du « flow » (voir la figure 2.13).

check availability of a flight, hotel and rental car concurrently </documentation>