Chapitre IV : Utilisation de BPEL pour les concepts
IV.2. Langage d’exécution des processus métiers
IV.2.1. Introduction au BPM : Business Process Management
La conception et l’exécution des processus métiers de l’entreprise nécessitent la collaboration d’utilisateurs ayant des profils différents et manipulent des concepts et des outils souvent hétérogènes (voir Figure 27) :
- Les équipes méthodes précisent un formalisme pour la modélisation des processus métiers, et peuvent définir des processus normalisés soit d’une manière verticale
(spécifique à un corps de métier), ou horizontale (indépendante du corps de métier de l’entreprise) ;
- Les décideurs et les analystes métiers définissent les processus métiers de haut niveau, les cas d’utilisation et les scénarios détaillés, en s’appuyant sur les recommandations des équipes méthode ;
- Les équipes techniques traduisent ces processus en termes d’applications, services et intégration de l’existant, tout en capitalisant sur les applications du système d’information [67].
Figure 27 : Collaboration entre différents acteurs
Cette hétérogénéité rend la collaboration entre les différents acteurs assez difficile. Tout d’abord, ces acteurs manipulent des concepts différents : un diagramme UML a par exemple peu de signification pour un analyste métier. De plus, leurs outils ne fournissent pas les moyens de cette collaboration : pour implémenter un processus métier modélisé avec Aris, il est nécessaire de le modéliser à nouveau sous Rational, pour pouvoir générer du code de manière plus ou moins efficace lors de la phase d’implémentation.
Actuellement, que ce soit dans les phases de modélisation métier et technique, ou d’implémentation, des outils de conception sont rarement utilisés de bout en bout, de la modélisation à l’exécution. On retrouve un fossé entre les phases de spécification et d’implémentation, même dans la partie technique.
De ce fait, il est difficile pour les décideurs d’avoir une vue claire sur les besoins auxquels répondent les applications du système d’information, et donc de justifier les nouveaux investissements IT. La maîtrise des processus est actuellement dans les mains des techniques, pas des personnes qui les définissent.
L’objectif de BPM (Business Process Management) est de permettre aux décideurs, analystes métiers, équipes fonctionnelles et équipes techniques de collaborer pour la définition et la modélisation des processus métiers via un seul outil fédérateur. Un des objectifs clés du BPM est de capitaliser sur les applications du système d’information : le mot d’ordre est la réutilisabilité. La réutilisabilité est rendue effectivement possible, tant au niveau technique (connecteurs, règles techniques, transformation de données) que fonctionnel (réutilisation d’un processus de facturation dans un processus de gestion de bons de commande par exemple).
Un processus métier est défini généralement selon trois niveaux :
- le niveau métier : le niveau haut de la vue métier du processus, définissant ses principales étapes et l’impact sur l’organisation de l’entreprise. Ce niveau est défini par les décideurs, et les équipes méthodes ;
- le niveau fonctionnel : formalisation des interactions entre les participants fonctionnels du processus où sont formalisées les règles métiers conditionnant son déroulement. Ce niveau est modélisé par les équipes fonctionnelles ;
- le niveau technique : établit le lien entre les activités (modélisés dans le niveau fonctionnel) et les applications du SI. Ce niveau est réalisé par les architectes et les équipes techniques de l’entreprise.
Pour la prise en compte de l’analyse et de la modélisation des processus métiers, l’OMG a développé son approche qui s’inscrit dans l’architecture générale de modélisation sous le nom de MDA (Model Driven Architecture).
La MDA est un cadre de définition et de transformation des méta-modèles, de spécification des notations associées ainsi que d’échange des modèles et de leurs diagrammes sous un format normalisé (XMI). L’OMG a lancé l’initiative de spécification des processus métiers–
BPDM qui s’appuie sur les modèles d’activités d’UML 2.0 en prenant en charge les différents
niveaux d’analyse des processus : implémentation, organisation et stratégie. Ainsi la BPMI a publié la spécification BPMN (Business Process Modeling Notation) 1.0, qui présente une avancée indéniable dans la formulation graphique des processus.
Cependant, le véritable défi se situe dans la capacité des processus, dont la description a été formalisée par les acteurs métier, de déboucher directement sur la génération de langages
exécutables par des applicatifs informatiques et des services web. Le langage BPEL4WS1 est une spécification de standards pour l’orchestration des web services annoncée en août 2002 par BEA, IBM et Microsoft.
IV.2.2. Langage BPEL
Le BPEL est la représentation XML d’un processus exécutable, qui peut être déployée sur n’importe quel moteur de processus métier. Ce langage est construit en se basant sur le WSFL (Web Services Flow Language) d'IBM et le XLANG (Web Services for Business Process Design) de Microsoft. Il fournit un langage de spécification des processus métiers et des protocoles de leur interaction [68]. Il combine les dispositifs d'un langage de processus structuré par bloc (XLANG) avec ceux d'un langage de processus graphique (WSFL). BPEL est prévu pour décrire un processus de métiers de deux manières différentes [69] :
- un processus abstrait est un protocole de métiers spécifiant le comportement d'échange de message entre différentes parties, sans préciser leur comportement interne ;
- un processus exécutable spécifie l'ordre d'exécution entre un certain nombre d'activités, les partenaires impliqués, le message échangé entre ces partenaires et les mécanismes de gestion d’erreur et d'exception.
La composition d’un service au niveau BPEL est décrite en termes de processus. Chaque élément du processus est appelé une activité. BPEL fournit deux genres d'activités [69] :
- Les activités primitives effectuent des opérations simples comme réception (attendre un message d'un partenaire externe), réponse (répondre un message d’un partenaire), appel (appeler un partenaire), assignation (copier une valeur d'un endroit à l'autre), rejet (générer une erreur), terminaison (arrêter l'instance de processus entier), attente (attendre un certain temps) et vide (ne fait rien) ;
- les activités structurées sont employées pour définir l'ordre des activités primitives. Elles peuvent résider avec d'autres activités structurées. Ces activités prennent la forme de : séquence (collection d'activités à exécuter séquentiellement), flux
1Business Process Execution Language for Web Services, qui remplace BPML Business Process Modeling Langage, devenu
(indiquant une ou plusieurs activités à exécuter concurremment), while (la boucle while), commutateur (choisit un chemin de contrôle à partir d'un ensemble de choix) et sélection (blocage et attente d’un message approprié).
La séquence, le flux, le commutateur, la sélection et la construction « while » fournissent les moyens d'exprimer des dépendances de flux structurées. En plus de ces constructions, BPEL en fournit une autre appelée « liens de contrôle » ainsi que les notions associées « join condition » et « transition condition », qui supportent la définition de la priorité, la synchronisation et les dépendances conditionnelles des activités structurées.
Un lien de contrôle entre les activités A et B indique que B ne peut pas commencer avant que A ait terminé ou A ait sauté. D'ailleurs, B peut seulement être exécuté si ses associés «join condition » ont la valeur « True », sinon B sera sauté.
Une activité X propage une valeur positive le long d'un lien sortant L si et seulement si X était exécutée et la 'transition condition' associé à L a la valeur « True ».
Les 'transition condition' sont des expressions booléennes au-dessus des variables de processus. Le processus par lequel des valeurs positives et négatives sont propagées le long des liens de contrôle, causant l’exécution ou le saut des activités, est nommé DPE (dead path elimination).
La Figure 28 ci-dessous est le méta modèle BPEL représenté par un diagramme de classe UML, qui décrit de manière précise tous les éléments de modélisation ( les concepts véhiculés et manipulés par le langage), leur définition et le sens de leur d’utilisation. A partir de ce schéma, il devient possible de faire un mapping entre les concepts du comportement du langage d’entreprise et ceux du BPEL.
Figure 28 : Méta-modèle du langage BPEL [56]