BPEL (Business Process Execution Language), est un langage basé sur XML permettant de créer des processus d’entreprise. Les possibilités offertes par BPEL sont nombreuses, il est notamment utilisé pour la mise en œuvre d’orchestration de services.
BPEL offre la possibilité d’interagir avec des Web Services tiers et ainsi de faire communiquer tout type d’application ayant une interface Web Service, de mettre en place des processus complexes (traitements parallèles, interactions humaines, etc.), de gérer simplement les exceptions, etc. Cet article est une introduction à BPEL, il explique les principales activités et les concepts abordés lors du développement de flux BPEL.

JDeveloper

JDeveloper est l’outil de développement d’Oracle utilisé pour la réalisation de flux BPEL. Il existe différentes versions, généralement la version utilisée est celle qui coïncide avec la version de la SOA Suite cible, c’est-à-dire celle sur laquelle les flux vont être déployés.

• Gestion des projets, ressources, etc. : Cette partie permet de créer de nouveaux projets (BPEL, JAVA, etc.) et de gérer l’ensemble des connexions aux ressources accédées par le flux (base de données, serveur d’application, etc.). Avant de pouvoir déployer votre flux, il vous faudra créer une connexion vers le serveur d’application cible.
• Structure du flux : Cette partie permet d’avoir un aperçu de ce que contient le flux (variables, messages, schémas importés, etc.). Vous pouvez également gérer ce contenu directement depuis cette partie (créer, supprimer, modifier).
• Espace de travail : C’est dans cette partie que vous réalisez votre flux. Selon le fichier en cours de traitement, plusieurs vues sont disponibles, les principales sont « design » et « source ». L’ensemble des développements (bpel, xsl, xsd, etc.) peuvent se faire en mode design, c’est-à-dire via des glisser/déposer, ce qui rend le développement plus accessible.
• Ensemble des activités BPEL : Cette partie répertorie l’ensemble des actions que vous allez pouvoir glisser/déposer dans votre flux. Les « objets » disponibles vont dépendre du fichier en cours d’édition, pour un fichier .bpel, vous aurez les activités BPEL, pour un fichier .xsl, vous aurez un ensemble de fonctions XSL, etc.
• Messages de compilation : C’est dans cette fenêtre que les messages de compilation vont apparaître lors de la compilation du projet, de même que les messages de déploiement.

BPEL

Structre du projet

Ci-dessous, vous trouverez quelques notions de base sur BPEL, notamment la structure d’un projet (fichiers qui composent un projet BPEL), une présentation des principales activités qu’il est possible d’insérer dans un flux BPEL, un rapide aperçu sur les appels de service et les adaptateurs de ressource intégrés à la SOA Suite, et enfin une présentation des deux types de flux BPEL que l’on peut mettre en place. Les fichiers que l’on retrouve dans un projet BPEL sont toujours les mêmes :

• Le fichier MonProjet.wsdl : décrit le service web, en effet un flux BPEL n’est ni plus ni moins qu’un service Web. C’est dans ce fichier que l’on va décrire les messages d’entrée/sortie, les opérations disponibles, etc.
• Le fichier MonProjet.bpel contient l’implémentation, la logique des flux, c’est à dire l’ensemble des activités effectuées par les flux.
• Le fichier MonProjet.xsd : décrit notamment les structures des variables d’entrée et de sortie du flux.
• Le fichier bpel.xml : regroupe les url d’accès aux différents .wsdl des services web appelés par le flux, ainsi que les préférences associées au flux.
• Le fichier build.xml : décrit les opérations de déploiement et de compilation du flux (JDeveloper s’appuie sur ce fichier lorsqu’on déploie le flux).
• Le fichier build.properties : stocke les valeurs des propriétés utilisées lors du déploiement du flux (domaine de déploiement, adresse du serveur, etc.). Ce fichier est également utilisé lorsqu’on utilise des scripts ANT permettant de remplacer au déploiement les variables du projet relatives à l’environnement cible (remplacement des adresses des Services Web, etc.).

Les activités BPEL

BPEL comporte un bon nombre d’activités que vous aller pouvoir utiliser pour mettre en place la logique de votre flux. Ci-dessous, vous trouverez un descriptif des activités principales proposées par BPEL :

• Assign : Permet d’assigner la valeur d’une variable. On utilise la syntaxe XPATH pour désigner l’élément XML de la variable que l’on souhaite assigner. Les deux principales opérations proposées par cette activité sont la règle de copie (copy) et celle d’ajout (append). Par ailleurs, vous avez la possibilité d’assigner une variable à partir d’une expression, d’une autre variable ou d’un fragment XML (le type « Partner Link » permet par exemple de définir dynamiquement l’opération à utiliser lors de l’appel du service lié au « Partner Link » en question).
• Invoke : Permet d’invoquer un service web au travers d’un Partner Link qui doit être préalablement défini. Les activités Invoke prennent en entrée une variable dont le type est défini dans le WSDL du service web associé et une variable de sortie si le processus appelé est synchrone. Cette activité est bloquante dans le cas où l’appel est synchrone.
• Java Embedding : Permet d’insérer du code Java dans votre code BPEL. Cette activité joue également le rôle de point de déshydratation et permet ainsi de démarrer une nouvelle transaction suite à l’exécution de cette activité.
• Receive : Permet de recevoir un message provenant d’un Web Service tiers. Un Partner Link doit avoir été créé préalablement. Il s’agit de la première activité que l’on retrouve dans un flux, à la réception du message, une nouvelle instance du processus est déclenchée.
• Reply : Permet à un flux synchrone de renvoyer une réponse au Web Service appelant.
• Scope : Permet de découper le flux en divers ensembles d’activités. On peut faire l’analogie avec le bloc try en Java. BPEL permet également de gérer les exceptions au niveau des scope en offrant la possibilité d’associer à un scope, des blocs catch ou catchAll.
• Sequence : Certaines activités peuvent être composées de plusieurs activités (scope, while, switch, etc.). Si l’activité englobante contient plus d’une activité alors une séquence sera automatiquement créée. Elle permet de définir la séquence d’activités à exécuter.
• Switch : Permet de définir structure conditionnelle et peut contenir plusieurs séquences » if » et une séquence « otherwise » si aucune des conditions n’a été satisfaite. Il faut savoir que la séquence exécutée correspondra à celle dont la condition sera satisfaite en premier, les autres ne seront pas exécutées même si la condition est satisfaite.
• Terminate : Permet de stopper le flux.
• Throw : Permet de lancer une exception au cours du flux, elle pourra être rattrapée à l’aide d’un bloc « catch » associé au scope dans lequel l’exception a été lancée. A priori, les exceptions à lancer seront des exceptions fonctionnelles, il sera donc nécessaire de définir ces exceptions au préalable.
• Transform : Cette activité permet de réaliser une transformation XSL d’une variable vers une autre. Ainsi, on peut changer la structure des données manipulées. Pour cela, il vous faut une variable d’entrée avec son propre format (xsd) et une variable de sortie avec son propre format (xsd, qui peut être le même que l’entrée). Attention, les champs qui ne seront pas mappés au niveau de la variable de sortie ne seront pas présents dans la variable et ne pourront donc pas être affectés dans la suite du flux.
• While : Permet de définir une boucle au sein du processus. Cette activité peut contenir un ensemble d’activités définies par une séquence et possède une condition, qui, tant qu’elle sera satisfaite, permettra d’exécuter la séquence d’activités.

Appels de service, adaptateurs de ressource

Un flux peut faire appel à un autre flux ou à des services externes. Quelle que soit la nature du service appelé (BPEL, Java, etc.), l’interface BPEL entre celui-ci et le flux appelant va se faire avec la notion de « Partner Link ». Le « Partner Link » est donc un composant BPEL permettant au flux de communiquer avec des services externes.
Les interactions avec les ressources externes vont se faire de deux façons différentes, soit via des services web exposés par les applications, soit par les adaptateurs de ressources pour tout ce qui est accès au système de fichiers, base de données, files JMS, etc.
Le « Partner Link » se configure simplement puisqu’il suffit, pour les Services Web, de spécifier l’adresse du WSDL. Le composant « Partner Link » doit être créé dans la partie ‘Services’ du designer, pour cela, vous glisser/déposer un composant « Partner Link » depuis la palette de services vers cette zone ou vous faîtes un clic droit dans cette même zone et sélectionnez « Create Partner Link ». Les champs autres que l’adresse du WSDL vont être renseignés automatiquement par JDeveloper une fois que vous aurez spécifié l’adresse du WSDL.
En ce qui concerne les adaptateurs de ressources, la démarche est la même sauf que la configuration est un peu plus complexe puisqu’il y a un ensemble de propriétés à spécifier selon la nature de l’adaptateur : répertoire où on récupère les fichiers, fréquence de récupération, politique d’archivage, etc.
En résumé, le « Partner Link Type » précise le type de partenaire avec lequel on va interagir, le champ « Partner Role » précise le rôle du Web Service sollicité et le champ « My Role » qui est spécifié uniquement dans le cas d’un appel asynchrone permet de préciser le rôle du BPEL appelant.

Type de flux

On distingue deux types de flux, les flux synchrones et les flux asynchrones. Ce sont les considérations fonctionnelles qui vont vous permettre de décider de la nature du flux à créer. Est-ce que l’appel doit être bloquant, est-ce que le flux attend une réponse, etc.
Quelles sont les différences entre ces deux types de flux ?

• Un flux synchrone est un flux qui va recevoir des données en entrée, les traiter et envoyer une réponse à l’appelant.
• Un flux asynchrone est un flux qui ne va pas envoyer de réponse au flux appelant. Les flux asynchrones peuvent avoir des temps d’exécution longs. Le flux appelant peut poursuivre son traitement suite à l’appel du service asynchrone.

Comme exemple, on peut citer un service de réservation en ligne. Le service de réservation prend en entrée une réservation et dans un premier temps consulte un service de disponibilité qui va permettre au flux appelant de savoir s’il reste des places. Dans ce cas, le service de vérification de disponibilité doit être synchrone car la réservation ne peut se poursuivre tant qu’on ne sait pas s’il reste des places. Avec cet exemple, on voit bien que c’est avant tout la nature du traitement que le flux va exécuter qui va permettre de déterminer son type : synchrone ou asynchrone.

Conclusion

Cet article présente les notions que vous allez systématiquement mettre en œuvre lorsque vous créerez vos propres flux BPEL. Vous avez pu le constater, les possibilités sont immenses : orchestration, interaction avec de multiples ressources (queue JMS, système de fichiers, base de données, etc.), manipulation/transformation des messages grâce aux transformations XSL, etc.
Je me propose de prolonger cette initiation à BPEL dans un prochain article. J’illustrerai ces notions à travers un exemple simple…