Groupe d’élément BPMn

Diagramme

BPMn dispose quatre configurations pour présenter un diagramme : – privé ou public – collaboration – chorégraphie – de conversation 

Diagramme Privé

Un processus privé est un type de modélisation qui permet de représenter un processus spécifique à une organisation en précisant que son contenu reste dans les limites du bassin et ne peut pas le traverser. Le flux de messages peut traverser les limites du bassin pour montrer les interactions qui existent entre des processus privés qui sont séparés.

 Diagramme public

Le processus public est un processus privé plus des interactions avec à un ou plusieurs Participants en définissant les flux de messages, leur séquence, leur ordre etc. Seules les activités de communication avec l’autre(s) participant sont présentées dans le processus public. Toutes les autres activités ou tâches internes du processus privé ne sont pas représentées. 

Collaboration

Le diagramme de collaboration permet de modéliser les processus et les interactions entre 2 entités au minimum. Figure 8.6 : Exemple diagramme de collaboration Un diagramme de collaboration ne peut contenir qu’un seul bassin (département, service). Ce bassin peut contenir plus d’un couloir (qui correspondent à des rôles : manager, assistante, collaborateur). Pour chaque couloir des activités sont définies. Pour illustrer les échanges entre 2 couloirs, on utilise des liaisons spécifiques appelées flux de message. 189 Figure 8.7 : Flux de message dans un diagramme de collaboration .

Diagrammes de chorégraphie

Un diagramme de chorégraphie est utilisé pour analyser la façon dont les participants échangent des informations afin de coordonner leurs interactions. On peut utiliser un diagramme de chorégraphie afin de développer et d’analyser en détails l’échange des messages associés à un nœud de conversation dans un diagramme de conversation. Figure 8.8 : Exemple d’un diagramme de chorégraphie Cet exemple illustre l’échange de messages entre un patient et son médecin. Une Chorégraphie est la modélisation d’un comportement attendu entre des Participants qui interagissent les uns avec les autres et qui veulent coordonner leurs activités ou leurs tâches à l’aide de Messages. Dans ce type de modélisation, la focalisation n’est pas sur l’Orchestration (processus public ou privé), c’est-à-dire sur la manière dont est accompli le travail selon le point de vue des participants, mais sur les échanges de Messages entre les Participants. 

Diagrammes de conversation

Le Diagramme de conversation est la description informelle d’un Diagramme de collaboration à haut niveau. Il représente des échanges de Messages (présentés sous la forme d’un regroupement de flux de messages), logiquement reliés entre les Participants et qui concernent un objet d’affaires d’intérêt, par exemple, un ordre, un envoi, une livraison ou une facture. Il représente un ensemble de Flux de Messages qui est regroupé ensemble. Une Conversation peut impliquer deux ou plusieurs participants. Un diagramme de conversation représente les conversations comme des hexagones, entre les participants (les bassins). Si l’on clique sur l’hexagone, on peut avoir le détail des Flux de Message échangés entre les Participants. Les bassins qui servent à la représentation d’un Diagramme de conversation, ne contiennent habituellement pas de processus et sont donc présentés vides. Aucun Diagramme de chorégraphie ne peut être placé entre les bassins du Diagramme de conversation. Figure 8.9 : Exemple d’un diagramme de conversation Dans cet exemple, les diverses conversations associées aux livraisons d’un fournisseur à un détaillant sont analysées. 191 ANNEXE 3 : Architecture Bus d’événement L’ESB (Enterprise Service Bus) est le composant central d’une architecture orientée services (SOA). Il autorise une approche de l’intégration hautement distribuée et indépendante de la plate-forme. Il s’appuie sur les standards pour soutenir la messagerie, les Services Web, le routage et la transformation de données. Figure 9.1 : Evolution de l’architecture de partage de message

Architecture

Le bus de services se base sur des principes suivants : – la découverte dynamique – l’exposition et l’orchestration des services – outil graphique permettant d’implémenter les processus et de les orchestrer – la distribution forte – la communication par message – la communication entre services se fait par message représenté par un document auquel le service consommateur s’abonne. Figure 9.2 : Les éléments liés aux Bus 192 Son architecture est basée sur : – échange asynchrone entre applications – interopérabilité entre le bus et les applications grâce aux services – transformation et enrichissement des données circulant sur le bus ESB se concentrent sur les fonctions d’interconnexion et de médiation, et s’appuient pour cela sur un ensemble de standards parmi lesquels : – Web Services pour gérer les communications synchrones. – XML pour définir les formats des messages – JMS2 pour adresser la communication asynchrone avec les MOM. – JCA pour la connexion aux progiciels et systèmes exotiques (ERP, CRM, Mainframes, etc.) 

Fonctionnement

Le bus de service d’entreprise achemine les messages entre les applications, qui sont demandeurs ou fournisseurs de services. Le bus convertit les protocoles de transport ainsi que les formats des messages entre les demandeurs et les fournisseurs. Dans ce schéma, chaque application utilise un protocole différent (représenté par les différentes formes géométriques de leurs connecteurs) et utilise différents formats de message. Figure 9.3 : Echange des informations au niveau du Bus A l’aide des médiations, un bus de service d’entreprise exécute les actions suivantes entre le demandeur et le service : – acheminement des messages entre les services : le bus de service d’entreprise offre une infrastructure de communication commune permettant de se connecter aux services et donc aux fonctions métier qu’ils représentent, sans que les programmeurs aient à écrire et gérer une logique de connectivité complexe. – conversion des protocoles de transport entre le demandeur et le service : le bus de service d’entreprise est un moyen cohérent normalisé d’intégrer des fonctions métier qui utilisent des normes informatiques différentes. Cela permet de disposer de fonctions métier qui ne pourraient normalement pas communiquer, telles que la connexion d’applications dans 193 des silos départementaux ou la participation des applications de différentes sociétés aux interactions de service. – conversion des formats de message entre le demandeur et le service : le bus de service d’entreprise permet aux fonctions métier de d’échanger des informations dans des formats différents, le bus garantissant que l’information distribuée à une fonction métier a le format correspondant à l’application. – traitement des événements métier provenant de sources différentes : le bus de service d’entreprise prend en charge les interactions basées sur l’événement en plus des échanges de message pour traiter les demandes de service.