MEGA Designer - Integration. Guide d utilisation

MEGA Designer - Integration Guide d utilisation

MEGA 2009 SP5 1ère édition (mars 2011) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient en aucune manière constituer un engagement de la société MEGA International. Aucune partie de la présente publication ne peut être reproduite, enregistrée, traduite ou transmise, sous quelque forme et par quelque moyen que ce soit, sans un accord préalable écrit de MEGA International. MEGA International, Paris, 1996-2011 Tous droits réservés. MEGA Designer - Integration et MEGA sont des marques réservées de la société MEGA International. Windows est une marque réservée de Microsoft. Les autres marques citées appartiennent à leurs propriétaires respectifs.

SOMMAIRE Sommaire...................................................... 3 Introduction.................................................... 9 Conventions utilisées dans le guide........................................ 10 Créer un diagramme de broker.................................... 11 Méthodologie générale.................................................. 12 Etape 1 : Diagramme de flux général....................................... 13 Créer le diagramme d environnement d application.............................13 Etape 2 : Insérer les services et le broker................................... 16 Construire le diagramme de broker........................................16 Insérer les services...................................................17 Créer et relier le broker................................................18 Différents modes d'échange...........................................18 Structure du message...............................................18 Etape 3 : Créer les connecteurs........................................... 20 Rôle du connecteur....................................................20 Créer les connecteurs..................................................20 Etape 4 : Paramétrer les connecteurs...................................... 22 Transformation des données.............................................22 Ressource connectée..................................................23 Définir l'adaptateur...................................................24 Adaptateur classe..................................................25 Adaptateur emplacement.............................................26 Adaptateur file de messages...........................................26 3

2 Contrôler le modèle EAI.......................................... 29 Finition EAI...........................................................30 Les messages gérés par le broker......................................... 30 Service source et message........................................... 30 Acteur source et message............................................ 30 Service cible et message............................................. 31 Acteur cible et message............................................. 31 Les événements gérés par le broker....................................... 31 Service publiant l événement et l'événement............................... 32 Acteur publiant l événement et l'événement............................... 32 Service souscrivant à l'événement et l'événement........................... 32 Acteur souscrivant à l'événement et l'événement............................ 33 Les interactions gérées par le broker....................................... 33 Service source et message........................................... 34 Acteur source et message............................................ 34 Service cible et message............................................. 35 Acteur cible et message............................................. 35 Contenu d'un message................................................ 36 Vérification EAI........................................................37 Lancer la vérification du modèle EAI....................................... 37 Types d'analyse du modèle EAI........................................ 38 Contrôles de la méthodologie d analyse..................................... 38 Broker.......................................................... 39 Ressources des messages, événements, interactions échangés.................. 39 Contenus associés aux messages et aux événements......................... 41 Contraintes de gestion.............................................. 41 Acteurs d'un message, événement ou interaction............................ 42 Acteurs d'une application............................................. 42 Services........................................................ 43 Acteurs internes et services........................................... 43 Interaction et messages............................................. 43 Contrôles de l'implémentation........................................... 43 Connecteurs d'un message ou d'un événement............................. 43 Connecteurs..................................................... 45 Transformation de données et connecteurs................................ 45 Transformation de données et contenus.................................. 45 Contenus et schémas XML............................................ 46 Services d'application publiant ou souscrivant à un même événement............. 46 Services récepteurs avec connecteurs portant des transformations de données....... 46 Avertissements...................................................... 47 Contenus de part et d'autre de la transformation de données................... 47 Connecteurs et interactions........................................... 47 Décrire les interactions.......................................... 49 Contexte d'utilisation...................................................50 Carte des applications du processus des achats............................... 51 4 MEGA Designer - Integration

Sommaire Informatisation des échanges : les interactions................................51 Interactions composites................................................52 Exemple d interaction composite........................................53 Autre exemple d interaction composite....................................54 Message déclenchant un enchaînement d interactions............................55 Interactions élémentaires...............................................56 Description d'une interaction............................................. 58 Créer une interaction..................................................58 Propriétés d une interaction..............................................58 Propriétés d un protocole d interaction......................................59 Onglet Rôles......................................................59 Onglet Sous-Interactions.............................................60 Onglet Messages...................................................60 Description d'une bibliothèque............................................ 61 Créer une bibliothèque.................................................61 Mise en oeuvre des interactions : les services................................ 62 Mise en oeuvre d'une interaction..........................................62 Interaction " Traitement de l'ordre d'achat "................................63 Interaction " Modification de l'ordre d'achat "...............................63 Interaction " Annulation de l'ordre d'achat "................................63 Décrire un Workflow............................................. 65 Contexte d'utilisation................................................... 66 Créer le diagramme du workflow.......................................... 67 Créer un workflow et son diagramme.......................................67 Dessiner un diagramme de workflow.......................................67 Les rôles..........................................................69 Les opérations.......................................................69 Relier un sous-workflow à une opération..................................70 Les messages.......................................................71 Les boucles........................................................71 Les conditions.......................................................73 Les transactions.....................................................75 Transaction minutée................................................75 Transaction à exception..............................................76 Créer une transaction................................................76 Echec de transaction................................................77 Les variables..........................................................78 Définir les variables du workflow..........................................78 Définir les variables des opérations........................................79 Variables d un sous-workflow.............................................81 Relier le workflow au service............................................. 82 Relier un workflow au service............................................82 Créer les connecteurs du service..........................................82 Relier les connecteurs au workflow.........................................83 5

2 Le diagramme de workflow BPMN.................................. 85 Créer le diagramme de workflow BPMN.....................................86 Créer un workflow et son diagramme de BPMN................................ 86 Dessiner un diagramme de workflow BPMN.................................. 86 Exemple........................................................ 86 Les opérations.........................................................88 Les messages.........................................................89 Les types de flux..................................................... 89 Echange entre deux messages........................................... 90 Les conditions.........................................................91 Les synchronisations....................................................92 Les rôles.............................................................93 Les transactions.......................................................94 Ressources des opérations...............................................95 Les variables..........................................................96 Export BPEL................................................... 97 Introduction à BPEL4WS.................................................98 BPEL4WS.......................................................... 98 Processus BPEL et Processus MEGA........................................ 98 Périmètre fonctionnel de l export BPEL....................................100 Principes de l export BPEL..............................................101 Concepts MEGA pris en compte par l'export BPEL............................. 101 Objets restitués dans le document BPEL exporté.............................. 101 Objets du modèle d'une procédure..................................... 102 Objets du modèle d'un Workflow...................................... 102 Séquence du processus BPEL........................................... 103 Début de la séquence du processus BPEL................................... 104 Ressources........................................................ 104 Exécuter l export BPEL4WS..............................................105 Lancer l export BPEL4WS depuis le navigateur............................... 105 Options de l export BPEL4WS........................................... 106 Nom du processus BPEL............................................ 106 Espace de nommage............................................... 106 Processus BPEL abstrait............................................. 106 Créer les balises <partnerlink>....................................... 107 Créer les balises <variable>......................................... 107 Créer le fichier WSDL complémentaire.................................. 107 Espace de nommage du WSDL........................................ 107 Alias de l'espace de nommage du WSDL................................. 107 Interprétation des différents éléments définissant la procédure ou le workflow....108 Interprétation des procédures et des workflows.............................. 108 Interfaces et intervenants........................................... 108 Variables et messages.............................................. 109 6 MEGA Designer - Integration

Sommaire Interprétation des opérations........................................... 109 Fourniture de service/appel de service................................... 109 Opérations et acteurs/applications...................................... 110 Opérations et messages............................................. 110 Interprétation des messages depuis ou vers les rôles........................... 112 Messages d'opération sans réalisateur................................... 112 Messages d'opération avec réalisateur................................... 113 Messages vers Rôle avec Echange...................................... 115 Restitution des éléments algorithmiques.................................... 117 Conditions...................................................... 117 Parallélismes..................................................... 119 Boucles........................................................ 122 Attentes........................................................ 126 Traitement des noms et valeurs d'objets................................... 127 Langue d'export..................................................... 127 Filtrage des caractères................................................ 127 Contraintes de modélisation - Cas non valides............................... 128 Utilisation des boucles................................................ 128 Détection des bouclages............................................... 128 Cohérence des bouclages............................................ 129 Export vers WebSphere Integration Developer.............................. 131 Interface Homme-Machine....................................... 135 Créer un diagramme D IHM............................................. 135 Ouvrir un diagramme d IHM............................................ 135 Exemple d interface.................................................. 135 Dessiner l IHM...................................................... 136 Elément D IHM................................................... 137 Evénement d IHM................................................. 137 Traitements en chaîne.......................................... 139 Dessin de chaîne.................................................... 139 Planning d exploitation................................................ 140 Glossaire..................................................... 143 adaptateur........................................................ 143 boucle............................................................ 143 broker........................................................... 143 broker manager..................................................... 143 condition.......................................................... 143 7

2 connecteur........................................................ 143 contenu.......................................................... 144 dépendance:...................................................... 144 emplacement...................................................... 144 événement........................................................ 144 événement d IHM................................................... 144 fichier logique...................................................... 144 fichier physique.................................................... 144 file de messages.................................................... 144 interaction........................................................ 144 job............................................................. 144 jonction.......................................................... 145 message......................................................... 145 parallélisme....................................................... 145 planning d exploitation............................................... 145 protocole......................................................... 145 rôle............................................................. 145 schéma.......................................................... 145 service.......................................................... 145 step............................................................ 145 synchronisation.................................................... 145 transaction........................................................ 146 transformation de données (data transform)................................ 146 workflow......................................................... 146 Index....................................................... 147 8 MEGA Designer - Integration

Int INTRODUCTION Dans un contexte de B2B (Business to Business), un outil et une méthodologie permettant de traiter les échanges entre applications à l'intérieur et vers l'extérieur de l'entreprise sont un atout majeur pour tout architecte de système d'intégration d'applications. L architecture des systèmes informatiques tend à être de plus en plus complexe. Afin d en favoriser le pilotage, MEGA Designer - Integration permet de faire une cartographie de ces systèmes et de générer les spécifications techniques des moteurs d intégration et de workflow. Ce document présente les points suivants : "Créer un diagramme de broker", page 11 "Contrôler le modèle EAI", page 29 "Décrire les interactions", page 49 "Décrire un Workflow", page 65 "Le diagramme de workflow BPMN", page 85 "Export BPEL", page 97 "Interface Homme-Machine", page 135 "Traitements en chaîne", page 139 L éditeur de schémas, ainsi que la génération de schémas XML sont décrits dans le guide MEGA Designer - XML Schemas. Le diagramme de classes disponible dans MEGA Designer - Integration est présenté dans le guide MEGA Designer - Development. 9

Introduction CONVENTIONS UTILISÉES DANS LE GUIDE Remarque sur les points qui précèdent. Définition des termes employés. Astuce qui peut faciliter la vie de l utilisateur. Compatibilité avec les versions précédentes. Ce qu il faut éviter de faire. Remarque très importante à prendre en compte pour ne pas commettre d erreurs durant une manipulation. Les commandes sont présentées ainsi : Fichier > Ouvrir. Les noms de produits et de modules techniques sont présentés ainsi : MEGA. 10 MEGA Designer - Integration

1 CRÉER UN DIAGRAMME DE BROKER Le diagramme de broker est le modèle qui va vous servir à décrire les échanges entre les applications de votre entreprise et ses partenaires dans le cadre d un moteur EAI (Enterprise Application Integration). Ce premier chapitre décrit les différentes étapes entrant dans la construction d un modèle d intégration. "Méthodologie générale", page 12 "Etape 1 : Diagramme de flux général", page 13 "Etape 2 : Insérer les services et le broker", page 16 "Etape 3 : Créer les connecteurs", page 20 "Etape 4 : Paramétrer les connecteurs", page 22 11

1 MÉTHODOLOGIE GÉNÉRALE Il convient de passer par quatre étapes dans l'établissement du diagramme. Cela permet de partir d'un niveau abstrait d'analyse à un niveau plus technique dans la représentation des flux de messages. Etape 1 : Afin d'avoir une vision complète du système, une première étape est l'établissement simple des flux entre applications (il est conseillé de construire à cet effet un diagramme à part). Etape 2 : La seconde étape consiste à représenter les services précis des applications qui émettent et reçoivent les messages. Le broker est également représenté. Etape 3 : Une fois les flux des messages définis entre les différents services, vous allez créer les connecteurs. Ceux-ci permettent de relier l'application au gestionnaire de messages. Etape 4 : Enfin, il convient de paramétrer les connecteurs en fonction du broker que vous utilisez. Le broker est l'élément de regroupement et de classification des flux de données. Il permet de regrouper les événements, les messages et les interactions qui participent au même projet. Exemple : Etape 1 : Diagramme des flux généraux des messages Etape 2 : Représentation du broker et des services Etape 3 : Inclusion des connecteurs 12 MEGA Designer - Integration

Créer un diagramme de broker Etape 1 : Diagramme de flux général ETAPE 1 : DIAGRAMME DE FLUX GÉNÉRAL Au cours de cette étape, vous allez définir les différentes applications et leurs échanges. Vous pouvez décrire ces flux dans un diagramme d environnement d application. Vos flux et interactions ont peut-être déjà été modélisés dans MEGA. Dans ce cas, les objets existent déjà, et vous pouvez les insérer dans le diagramme en utilisant la fonction de recherche. Créer le diagramme d environnement d application Pour construire le diagramme : 1. Dans MEGA, cliquez sur la fenêtre de navigation Objets principaux. 2. Dans le navigateur, cliquez avec le bouton droit sur le nom de l application que vous voulez décrire et sélectionnez Nouveau > Diagramme. 3. Dans la fenêtre qui apparaît, sélectionnez le type de diagramme "Diagramme d environnement d application" et cliquez sur le bouton Créer. Pour insérer dans le diagramme les différentes applications du système que vous représentez : 1. Cliquez sur l'icône Application puis cliquez dans le diagramme. 2. Dans la fenêtre Ajout d une application, nommez l'application. 3. Si vous avez déjà créé ces applications dans MEGA, utilisez les fonctions Lister ou Rechercher à l'aide de la flèche 13

1 Pour insérer les échanges entre les différentes applications, utilisez les boutons correspondants : Message Interaction Evénement Si ces boutons ne sont pas visibles dans la barre d objets du diagramme, cliquez sur le bouton Vues et cochez les cases correspondants à ces objets. Par exemple, pour insérer un événement : 1. Cliquez sur le bouton puis cliquez dans le diagramme. 2. Dans la boîte de dialogue qui s'affiche, nommez ou recherchez l'événement. 3. Cliquez sur OK. Une fois les événements créés, cliquez sur le bouton Lien et reliez les événements aux applications. L interaction représente un échange de questions et de réponses, le service se bloquant tant qu'il n'a pas reçu sa réponse. Pour plus d informations sur les interactions, voir le chapitre "Décrire les interactions", page 49, ou les guides MEGA Architecture et MEGA Process. Pour plus de détails sur les messages et leur contenu, voir dans le guide MEGA Common Features, "Manipuler les objets MEGA, "Nommer des messages". 14 MEGA Designer - Integration

Créer un diagramme de broker Etape 1 : Diagramme de flux général Exemple : Dans ce diagramme, "MaBanque" consulte ses comptes courant et d'épargne qu'elle a auprès de différentes agences. Ces consultations sont représentées par deux interactions. "MaBanque" modifie par ailleurs ses comptes, ces modifications font l'objet d'événements, représentés par l'événement "Changement d adresse" (Mise à Jour des Informations Client). Au cours de l'étape suivante, nous allons modéliser ces flux en précisant les services utilisés et en insérant le broker. 15

1 ETAPE 2 : INSÉRER LES SERVICES ET LE BROKER Une fois la vision d ensemble du système établie, vous pouvez décrire comment correspondent les services de votre entreprise et/ou ceux de vos partenaires. Vous pouvez décrire ces échanges dans un diagramme de broker. Construire le diagramme de broker Pour créer le broker : 1. Cliquez sur la fenêtre de navigation Objets principaux. 2. Dans le navigateur, cliquez avec le bouton droit sur le dossier Brokers et sélectionnez Nouveau > Broker. 3. Dans la fenêtre Création d un broker, saisissez le nom du broker. Pour créer le diagramme du broker : 1. Dans le menu contextuel du broker créé, sélectionnez Nouveau > Diagramme. 2. Dans la fenêtre qui apparaît, sélectionnez le type "Diagramme de broker" et cliquez sur le bouton Créer. Lorsqu un broker est décrit par un diagramme, l icône apparaît à côté du broker. 16 MEGA Designer - Integration

Créer un diagramme de broker Etape 2 : Insérer les services et le broker Pour afficher les boutons appropriés pour la construction d'un modèle EAI : 1. Dans la fenêtre du diagramme, cliquez sur le bouton Vues Une fenêtre s'affiche. 2. Vérifiez que les cases Brokers, Evénements, Connecteurs et Interactions sont bien cochées. Insérer les services Un service est l'élément de découpage d'une application qui est mis à la disposition de l'utilisateur final de cette application dans le cadre de son travail. Les applications représentées contiennent des services qui sont techniquement les vrais exécutants de l'envoi ou de la réception des messages. Pour représenter les services dans le diagramme : 1. Cliquez sur le bouton Service 2. Cliquez dans le diagramme. 3. Dans la fenêtre qui apparaît, nommez ou recherchez le service. 4. Cliquez sur OK. 5. Recommencez la même opération pour chaque service. 6. Reliez les services aux applications : cliquez sur le bouton Lien et tirez une ligne de l application vers le service. 7. Dans la fenêtre qui apparaît, sélectionnez le type de lien "service défini". 17

1 Créer et relier le broker Le broker est l'élément de regroupement et de classification des flux de données. Il permet de regrouper les événements, les messages et les interactions qui participent au même projet. Le broker connaît l'émetteur et le destinataire des messages au sein du flux général. Il gère ainsi les échanges. Pour insérer le broker : 1. Cliquez sur le bouton Broker puis cliquez dans le diagramme. 2. Saisissez le nom du broker. 3. Cliquez sur OK. Pour relier le broker aux message, événement ou interaction : Cliquez sur le bouton Lien et tracez une ligne entre le broker et le message (ou l'événement ou l interaction) représenté. Différents modes d'échange On distingue différents modes d'échanges. Un message peut être : Envoyé d'un émetteur vers un récepteur. Envoyé par un émetteur et avoir plusieurs destinataires (mode "Publication et Abonnement"). Envoyé par un service qui se bloque tant qu'il n'a pas de reçu de réponse de la part du récepteur du message (mode question-réponse). Un seul destinataire du message Reliez le service émetteur au message, le service récepteur au message, et le broker au message. Mode publication et abonnement Reliez le service émetteur à l'événement, et tirez un lien de l'événement au service receveur. Il faut également tirer un lien entre le broker et l'événement. Mode question-réponse Le mode question/réponse est représenté par une interaction. Consultez la documentation relative à MEGA Architecture pour créer une interaction. Tirez un lien entre le broker et la interaction. Structure du message Il convient de dissocier le contenu d un message de la structure de ce contenu. En effet, indépendamment de la structure du message, des traitements peuvent être associés au flux comme par exemple, la mémorisation de données à des fins de datawarehousing. Une même structure peut être utilisée par différents messages, mais suivant l'émetteur, les données sauvegardées ne sont pas nécessairement les mêmes. Le 18 MEGA Designer - Integration

Créer un diagramme de broker Etape 2 : Insérer les services et le broker contenu peut être relié à un schéma XML qui décrit strictement la structure du message. Ce schéma est modélisé dans MEGA par une classe UML. XML Schéma : Avec l'introduction du XML, la structure d'un message est décrite avec un schéma ou avec une DTD. Dans MEGA, UML Class permet de décrire cette structure et de la générer sous forme de DTD ou de schéma XML. Vous pouvez retrouver les schémas gérés par un broker ainsi que les paquetages associés à l aide du menu Outils > Rechercher. Exemple : Le broker "Comptes" gère ici les interactions de consultation de compte et l'événement "Changement d adresse". Au cours de la prochaine étape, il est nécessaire de décrire l'interface entre les services (appartenant à l'entreprise) et le broker (acheté chez un éditeur) : les connecteurs. 19

1 ETAPE 3 : CRÉER LES CONNECTEURS Le connecteur désigne le point de contact entre le gestionnaire de messages et l'application, du point de vue du gestionnaire. Le document peut provenir ou être à destination d'un adaptateur, d'un emplacement ou d'une file de messages. Un connecteur ne peut avoir qu'une transformation de données. Rôle du connecteur Le connecteur connecte l'application au gestionnaire de messages. Un des rôles des connecteurs est de transformer les données de l'application dans le format connu du gestionnaire. Les connecteurs sont reliés aux services, ceux-ci représentant l'unité de coordination de messages. Pour chaque message échangé se créent deux connecteurs : l'un pour l'émission du message, l'autre pour la réception du message. Les échanges entre le gestionnaire de messages et les applications se font par l'intermédiaire d'un dossier, d'une adresse http, d'un exécutable ou encore d'une file de messages. Voir "Définir l'adaptateur", page 24. Créer les connecteurs Les connecteurs sont générés automatiquement par MEGA. Pour créer les connecteurs : 1. Dans le menu contextuel du broker, sélectionnez Contrôler > Description de contrôle. 2. Cliquez sur Complete Broker (EAI). Les connecteurs sont créés, ils sont accessibles à partir de la fenêtre de propriétés des services auxquels ils sont rattachés. Vous pouvez les insérer dans le diagramme pour les visualiser. Pour insérer un connecteur dans le diagramme : 1. Cliquez sur le bouton Connecteur (EAI) puis dans le diagramme. Si le bouton Connecteur n apparaît pas dans la barre d objets du diagramme, cliquez sur le bouton Vues "Connecteurs". et cochez le champ 20 MEGA Designer - Integration

Créer un diagramme de broker Etape 3 : Créer les connecteurs 2. Dans la fenêtre Ajout d un connecteur, saisissez le nom du connecteur ou recherchez-le à l aide de la flèche Il est ensuite nécessaire de préciser si le document doit être transformé avant d'être transmis, et de définir l'emplacement des documents échangés. Voir "Etape 4 : Paramétrer les connecteurs", page 22. 21

1 ETAPE 4 : PARAMÉTRER LES CONNECTEURS L'étape 3 a consisté à générer les connecteurs entre l'émetteur et le receveur d'un message. Lorsqu'un message passe par le connecteur, il peut être transformé afin d'être compréhensible par le broker ou le service (en utilisant un adaptateur). Cette étape consiste à définir une solution technique impliquant des descriptions plus formelles. Transformation des données Une transformation de données indique la transformation d'un document dans un autre format. Cette transformation intervient au moment de l'envoi ou de la réception d'un document par le gestionnaire de message. Pour définir dans quel format vous voulez que les données soient reçues par l'application réceptrice du message : 1. Dans la fenêtre de propriétés du connecteur, cliquez sur l'onglet Transformation de données. 2. Cliquez sur le dossier "Transformation de données" puis sur le bouton Nouveau 3. Dans la fenêtre qui apparaît, saisissez le nom de la transformation de données. 4. Affichez la fenêtre de propriétés de la transformation de données ainsi créée. 22 MEGA Designer - Integration

Créer un diagramme de broker Etape 4 : Paramétrer les connecteurs 5. Sous l'onglet Caractéristiques, indiquez la feuille de style dans le champ XSLT Map. Ressource connectée Le connecteur vous permet de préciser comment le message émis est connecté à la ressource qui implémente le service. Prenons l exemple du diagramme de broker "DB Comptes". Supposons que le service "InfCourant" soit implémenté par un processus applicatif, le "Processus applicatif-1". Dans la fenêtre de propriétés du service, vous pouvez voir apparaître le nom du processus applicatif qui l implémente. Pour indiquer que le message "Consultation Compte" est connecté au processus applicatif qui implémente le service "Infcourant" : 1. Cliquez avec le bouton droit sur le connecteur reliant le message "Consultation compte" au service "InfCourant" (en rouge). Vous pouvez également accéder au connecteur dans la fenêtre de propriétés du service, sous l onglet Connecteurs. 23

1 2. Sélectionnez Propriétés. 3. Dans la fenêtre de propriétés du connecteur, cliquez sur l onglet Ressource connectée. 4. Sélectionnez le dossier "Processus applicatif connecté" puis cliquez sur le bouton Relier Une fenêtre vous présente le processus applicatif qui implémente le service. Il s agit de "Processus applicatif-1". 5. Sélectionnez-le et cliquez sur OK. Sous le dossier "Message connecté", vous pouvez préciser quel message du processus applicatif en particulier vous souhaitez relier au message "consultation compte". Une fois que vous avez déterminé la ressource connectée, vous pouvez indiquer sous l onglet Adaptateur par quel moyen cette connexion est réalisée. Voir "Définir l'adaptateur", page 24. Définir l'adaptateur Il s'agit d'indiquer précisément quelles sont les adresses de départ et d'arrivée des documents échangés. Pour définir l adaptateur : 1. Cliquez avec le bouton droit sur le connecteur. 2. Sélectionnez Propriétés. 24 MEGA Designer - Integration

Créer un diagramme de broker Etape 4 : Paramétrer les connecteurs 3. Cliquez sur l'onglet Adaptateur. Adaptateur classe Sélectionnez un des types d'adaptateur suivants : Adaptateur Classe : qui correspond à une classe UML. Adaptateur Emplacement : qui utilise un fichier pour représenter l'emplacement du document. Adaptateur File de Messages : qui utilise une file de messages. L emplacement correspond à l emplacement du document envoyé ou reçu par le connecteur. Cet emplacement peut être une adresse électronique (protocole SMTP), une adresse Internet (protocoles HTTP et HTTPS) ou un fichier. Une file de messages est une file d'attente dans laquelle est envoyée ou d'où provient le document. L adaptateur désigne le point de contact entre le gestionnaire de messages et l'application, vu du point de vue de l'application. Lorsque l'application transmet le document au gestionnaire, l'adaptateur contient les informations nécessaires pour accéder au gestionnaire. Lorsque c'est le gestionnaire qui transmet le document à l'application, l'adaptateur contient les informations pour être appelé du gestionnaire. L'adaptateur est représenté dans MEGA par une classe UML. La classe UML représente la définition de l'adaptateur. Dans la fenêtre de Propriétés du connecteur, cliquez sur l'onglet Adaptateur. Faites un clic droit sur "Adaptateur classe". Deux cas se présentent : Soit la classe existe déjà dans la base MEGA. Dans ce cas, cliquez sur le bouton Relier et sélectionnez la classe dans la fenêtre de sélection. Soit la classe n'existe pas dans MEGA. Dans ce cas, cliquez sur le bouton Nouveau et donnez un nom à la classe. Vous pouvez spécifier quelle opération de l'adaptateur classe vous voulez utiliser : Cliquez sur l opération de l adaptateur classe et glissez-la sur le dossier Opération d adaptateur classe. 25

1 Adaptateur emplacement Pour créer un adaptateur de type emplacement : 1. Dans la fenêtre de propriétés du connecteur, faites un clic droit sur "Adaptateur emplacement" et cliquez sur Nouveau. 2. Indiquez le nom de l'adaptateur et cliquez sur OK. 3. Précisez les caractéristiques de l'adaptateur : cliquez avec le bouton droit sur l'adaptateur "emplacement" que vous avez créé et sélectionnez Propriétés. La fenêtre de propriétés de l adaptateur apparaît. 4. Sous l'onglet Caractéristiques, remplissez les champs appropriés. Par exemple, pour renseigner le type et le nom d'un fichier, indiquez le type d'emplacement (fichier) et l'adresse du fichier. Adaptateur file de messages Pour créer un adaptateur de type file de messages : 1. Dans la fenêtre de propriétés du connecteur, cliquez sur l'onglet Adaptateur. 2. Faites un clic droit sur "Adaptateur file de messages" et cliquez sur Nouveau. 3. Indiquez le nom de l'adaptateur et cliquez sur OK. 26 MEGA Designer - Integration

Créer un diagramme de broker Etape 4 : Paramétrer les connecteurs 4. Précisez les caractéristiques de l'adaptateur : sélectionnez Propriétés dans le menu contextuel de l'adaptateur file de messages créé et indiquez son adresse. 27

1 28 MEGA Designer - Integration

2 CONTRÔLER LE MODÈLE EAI Une fois votre modèle EAI construit, il convient de contrôler et de compléter le modèle avec des éléments techniques. Vous disposez de deux fonctions de contrôle : La Finition (Complete) : cette fonction permet de créer les éléments éventuellement manquants du modèle. Vous pouvez lancer une finition pendant que vous créez votre modèle à un niveau plus abstrait, afin de générer automatiquement les éléments plus techniques tels que les connecteurs. La Vérification (Check) : cette fonction contrôle le modèle et vérifie qu'il est correct. Vous pouvez lancer ces deux fonctions en même temps (Complete and Check) lorsque vous avez terminé votre modèle et que vous désirez effectuer un dernier contrôle avant de générer la configuration. 29

2 FINITION EAI La finition EAI consiste à ajouter les éléments indispensables au bon fonctionnement du modèle défini pour l'intégration d'applications. Cette finition consiste essentiellement à créer des connecteurs pour l'ensemble des messages échangés entre deux ressources. Pour lancer la finition : 1. Dans le menu contextuel du broker, sélectionnez Contrôler > Description de contrôle. 2. Dans la fenêtre qui apparaît, sélectionnez Complete Broker (suivi du nom du moteur que vous utilisez) et cliquez sur OK. Un rapport contenant la liste des éléments créés (s ils n existent pas) est généré. Les messages gérés par le broker L'ensemble des messages gérés par un broker particulier est analysé. Les ressources sources et cibles peuvent être des services ou des acteurs. Les vérifications portent donc sur les ressources sources services et acteurs, et les ressources cibles services et acteurs. Le schéma suivant illustre ces vérifications : Service source et message L'existence du connecteur entre le service source et le message est vérifiée. Si le connecteur est inexistant, il est créé automatiquement et a pour nom "Content_Ressource_I" où Ressource est le service émetteur reliée au message. Ce connecteur est relié au service en tant que connecteur émetteur et au message en tant que connecteur. Acteur source et message L'existence du connecteur entre l'acteur source et le message est vérifiée. 30 MEGA Designer - Integration

Contrôler le modèle EAI Finition EAI Si le connecteur est inexistant, il est créé automatiquement et a pour nom "Content_Ressource_I" où Ressource est l'acteur émetteur relié au message. Ce connecteur est relié à l'acteur en tant que connecteur émetteur et au message en tant que connecteur. Service cible et message L'existence du connecteur entre le service cible et le message est vérifiée. Si le connecteur est inexistant, il est créé automatiquement et a pour nom "Content_Ressource_O" où Ressource est le service récepteur relié au message. Ce connecteur est relié au service en tant que connecteur récepteur et au message en tant que connecteur. Acteur cible et message Dans cette étape, l'existence du connecteur entre l'acteur cible et le message est vérifiée. Si le connecteur est inexistant, il est créé. Il a pour nom "Content_Ressource_O" où Ressource est l'acteur récepteur relié au message. Il est relié à l'acteur en tant que connecteur récepteur et au message en tant que connecteur. Si aucun connecteur n'est créé, le message suivant apparaît : Problem: "This section consists in checking that all messages exchanged between 2 resources have a connector matching each resource." The resources concerned are: - Source Service - Target Service - Source Org-Unit - Target Org-Unit If the connectors do not exist, they are automatically created. If the matching resource is the source, the connector has the following name: "Content_Ressource_I". It is connected to the resource by the leg "Emitter Connector" and to the message by the leg "Connector". If the matching resource is the target, the connector has the following name: "Content_Ressource_O". It is connected to the resource by the leg "Receiver Connector" and to the message by the leg "Connector". The message connectors completion has succeeded. Your model was correctly parameterized. No connector has been created. Les événements gérés par le broker Un événement représente un fait ou une action se produisant dans le système, par exemple - modification de l'adresse client. Il est géré par un broker. Pour signaler qu'elle peut produire un événement, une application déclare qu'elle le publie. Si elle est intéressée par un événement, une application déclare qu'elle y souscrit. 31

2 L'ensemble des événements gérés par un broker particulier est analysé. Les ressources publish and subscribe "publication et abonnement" peuvent être des services ou des acteurs. L'analyse se fait en quatre étapes : Etude de la présence de connecteur entre le service publiant l'événement et l'événement. Etude de la présence de connecteur entre l'acteur publiant l'événement et l'événement. Etude de la présence de connecteur entre le service souscrivant à l'événement et l'événement. Etude de la présence de connecteur entre l'acteur souscrivant à l'événement et l'événement. Service publiant l événement et l'événement L'existence du connecteur entre le service publiant l'événement et l'événement luimême est vérifiée. Si le connecteur n'existe pas, il est créé automatiquement, et a pour nom : "Content_Service_P". Le connecteur est relié au service en tant que connecteur émetteur et à l'événement en tant que connecteur. Acteur publiant l événement et l'événement L'existence du connecteur entre l'acteur publiant l'événement et l'événement luimême est vérifiée. Si le connecteur n'existe pas, il est créé automatiquement, et a pour nom : "Content_Acteur_P". Il est relié à l'acteur en tant que connecteur émetteur et à l événement en tant que connecteur. Service souscrivant à l'événement et l'événement L'existence du connecteur entre le service souscrivant à l'événement et l'événement lui-même est vérifiée. Si le connecteur n'existe pas, il est automatiquement créé et a pour nom "Content_Service_S". 32 MEGA Designer - Integration

Contrôler le modèle EAI Finition EAI Il est relié au service en tant que connecteur récepteur et à l'événement en tant que connecteur. Acteur souscrivant à l'événement et l'événement Dans cette étape, l'existence du connecteur entre l'acteur souscrivant à l'événement et l'événement lui-même est vérifiée. Si le connecteur est inexistant, il est créé et a pour nom "Content_Acteur_S". Il est relié à l'acteur en tant que connecteur récepteur et à l'événement en tant que connecteur. Si aucun connecteur n'est créé, le message suivant apparaît : Problem:This part consists in checking that all events exchanged between 2 resources have a connector matching each resource. The resources concerned are: - Publishing Service - Subscribing Service - Publishing Org-Unit - Subscribing Org-Unit If the connectors do not exist, they are automatically created. If the matching resource is the publishing one, the connector has the following name: "Content_Resource_P". It is connected to the resource by the leg "Emitter Connector" and to the event by the leg "Connector". If the matching resource is the subscribing one, the connector has the following name: "Content_Resource_S". It is connected to the resource by the leg "Receiver Connector" and to the event by the leg "Connector". The event connectors completion has succeeded. Your model was correctly parametered. No connector has been created. Les interactions gérées par le broker L'ensemble des interactions gérées par un broker particulier est analysé. Les ressources sources et cibles sont alors soit des services soit des acteurs. 33

2 Les messages de l interaction sont parcourus et leur type (Request ou Response) est vérifé. Les éléments suivants sont analysés pour chaque message : Existence de connecteur entre le service source de l interaction et le message Existence de connecteur entre l'acteur source de l interaction et le message Existence de connecteur entre le service cible de l interaction et le message Existence de connecteur entre l'acteur cible de l interaction et le message Service source et message L'existence du connecteur entre le service source et le message est vérifiée. Si le connecteur n'existe pas, il est automatiquement créé et a pour nom : "CollaborationDefinition_Content_Service_I" si le message est de type request. Il est relié au service en tant que connecteur émetteur et au message en tant que connecteur. "CollaborationDefinition_Content_Service_O" si le message est de type response. Il est relié au service en tant que connecteur récepteur et au message en tant que connecteur. Le connecteur doit également être relié à l interaction instance qui contient le message. Acteur source et message L'existence du connecteur entre l'acteur source et le message est vérifiée. Si le connecteur est inexistant, il est automatiquement créé et a pour nom : "CollaborationDefinition_Content_Acteur_I " si le message est de type request. Il est relié à l'acteur en tant que connecteur émetteur et au message en tant que connecteur. "CollaborationDefinition_Content_Acteur_O" si le message est de type response. Il est relié à l'acteur en tant que connecteur récepteur et au message en tant que connecteur. 34 MEGA Designer - Integration

Contrôler le modèle EAI Finition EAI Le connecteur doit également être relié à l interaction instance qui contient le message. Service cible et message Dans cette étape, on vérifie l'existence du connecteur entre le service cible et le message. Si le connecteur est inexistant, on le crée. L'existence du connecteur entre le service cible et le message est vérifiée. Si le connecteur est inexistant, il est automatiquement créé et a pour nom : "CollaborationDefinition_Content_Service_I" si le message est de type response. Il est relié au service en tant que connecteur émetteur et au message en tant que connecteur. "CollaborationDefinition_Content_Service_O" si le message est de type request. Il est relié au service en tant que connecteur récepteur et au message en tant que connecteur. Le connecteur doit également être relié à l"interaction instance qui contient le message. Acteur cible et message Dans cette étape, on vérifie l'existence du connecteur entre l'acteur cible et le message. Si le connecteur est inexistant, on le crée. On distingue alors deux cas : Si le message est de type response, le connecteur a pour nom : "CollaborationDefinition_Content_Acteur_I ". Il est relié à l'acteur en tant que connecteur émetteur et au message en tant que connecteur. Si le message est de type request, le connecteur a pour nom : "CollaborationDefinition_Content_Acteur_O". Il est relié à l'acteur en tant que connecteur récepteur et au message en tant que connecteur. Le connecteur doit également être relié à l interaction instance qui contient le message. Si aucun connecteur n'est créé, le message suivant apparaît : Problem: This section consists in checking that all messages belonging to a broker's interaction have a connector matching each interaction's resources. The resources concerned are : - Source Service - Target Service - Source Org-Unit - Target Org-Unit If the connectors do not exist, they are automatically created. If the matching resource is the source, the connector has the following name: "CollaborationDefinition_Content_Ressource_I". It is connected to the resource by the leg "Emitter Connector", to the message by the leg "Connector" and to the interaction by the leg "Connector". If the matching resource is the target, the connector has the following name: "CollaborationDefinition_Content_Ressource_O ". It is connected to the resource by the leg "Receiver Connector", to the message by the leg "Connector" and to the interaction by the leg "Connector". 35

2 It is assumed that any message belonging to an interaction is either a Request or a Response. The completion of interaction message connectors has succeeded. Your model was correctly parameterized. No connector had to be created. No connector has been created. Contenu d'un message Cette partie consiste à vérifier l'existence d'un lien entre un schéma et un message. Si ce lien existe, il faut vérifier qu'il existe bien un contenu associé à ce schéma et ce message. Si le contenu n'existe pas, il est créé. On crée également les liens entre le contenu et le schéma et le contenu et le message. Les tests sont effectués sur les messages gérés par le broker et sur les messages des interactions gérés par le broker. Les messages associés à cette finition sont : Pour un message : Message: "MessageName" The content "content Name" has been created. It is linked to the schema "schema name". Pour une interaction : interaction: "InteractionName" Message : "MessageName" The content "content Name" has been created. It is linked to the schema "schema name". Si aucun lien entre le connecteur et l interaction n'est créé, le message suivant apparaît : This part consists in checking that if a message is linked to a schema, it must also be connected to a content. If the content does not exist, it is created and linked to the message and the schema. Pour un message : The completion of message contents has succeeded. Your model was correctly parameterized. No content had to be created. Pour une interaction : The completion of the interaction messages contents has succeeded. Your model was correctly parameterized. No content had to be created. 36 MEGA Designer - Integration

Contrôler le modèle EAI Vérification EAI VÉRIFICATION EAI Cette fonction consiste à vérifier que le modèle EAI que vous avez construit dans MEGA est correct. Lancer la vérification du modèle EAI Pour lancer la vérification : 1. Dans le menu contextuel du broker, sélectionnez Contrôler > Description de contrôle. 2. Dans la fenêtre qui apparaît, sélectionnez Check Broker (suivi du nom du moteur que vous utilisez). 3. Cliquez sur OK. 37

2 Le modèle est parcouru en vue d'éventuelles erreurs. A la fin de la recherche, une page décrivant les erreurs détectées s'affiche. Vous pouvez corriger les erreurs en cliquant sur le lien de l'erreur, et en vous aidant des explications dans ce document. Types d'analyse du modèle EAI Les contrôles s'effectuent à quatre niveaux : Méthodologie : ces contrôles s'appliquent au niveau général de l'implémentation d'une application EAI. Ils concernent les ressources, les messages échangés, et les données qui transitent. Implémentation : ce niveau analyse de manière plus précise comment le message est échangé et de quelle manière les données vont transiter. Il concerne les connecteurs, les événements, les transformations canoniques de données et leur structure. Avertissements : ces contrôles s'appliquent aux configurations non standard mais qui sont réalisables. Technique : ce niveau de contrôle définit les paramètres nécessaires pour configurer correctement l'outil d'intégration. Il s'agit de préciser la transformation et la destination du message. Cette partie est donc spécifique aux moteurs d'intégration utilisés. Voir la documentation spécifique de votre moteur d'intégration. Dans les sections suivantes, les erreurs sont expliquées en détail, selon leur type. Contrôles de la méthodologie d analyse Ces contrôles s'appliquent au niveau général de l'implémentation d'une application EAI. Ils concernent les ressources, les messages échangés, et les données qui transitent. 38 MEGA Designer - Integration

Contrôler le modèle EAI Vérification EAI Broker Il s'agit du routeur de message, appelé gestionnaire de flux, message broker ou encore serveur EAI. Il permet de préciser les informations nécessaires à la modélisation du mode d'échange de messages de type Publication et Abonnement (ou "Publish and Subscribe"). Le broker doit gérer au moins un message, une interaction ou un événement. Si ce n'est pas le cas, soit : Vous n'avez pas encore défini de configuration. Vous avez configuré tous les échanges de données sans spécifier le broker qui prend en charge le transfert de ces informations : vous devez associer au broker tous les messages, événements et interactions échangés. Le message d erreur qui s affiche alors est le suivant : The broker "broker name" has no message, event or interaction to manage. You must specify at least one message, event or interaction to validate your configuration. Ressources des messages, événements, interactions échangés Un événement représente un fait ou une action se produisant dans le système, par exemple - modification de l'adresse client. Il est géré par un broker. Pour signaler qu'elle peut produire un événement, une application déclare qu'elle le publie. Si elle est intéressée par un événement, une application déclare qu'elle y souscrit. Le contenu désigne le contenu d'un message ou d'un événement indépendamment de sa structure. Cette dernière peut être représentée par un schéma XML relié au contenu. Un contenu peut être utilisé par plusieurs messages puisqu'il n'est pas associé à un émetteur et à un destinataire. Il ne peut y avoir qu'un contenu par message ou par événement, mais un même contenu peut être utilisé par plusieurs messages ou événements. Une interaction représente un contrat conclu dans un contexte précis entre des entités autonomes à l'intérieur ou à l'extérieur d'une entreprise. Ces entités peuvent être des acteurs, des applications, des activités, des processus de l'entreprise, ou des acteurs externes à l'entreprise. Le contenu de ce contrat est décrit par un protocole d interaction. Chaque échange de données doit être associé à une ressource source et à une ressource cible. Les contraintes sur les ressources varient selon le type d'échange (message, événement ou interaction). Messages et émetteurs, récepteurs Cette vérification est associée à la partie "Message Emitter and Receiver" du site. Cette partie propose de vérifier que tout message intervenant dans un échange au sein d'un broker a un émetteur et un récepteur. Deux cas doivent être vérifiés : Si le message est relié à une application au lieu d'un service, on aura le message suivant : The broker 'broker Name' does not manage messages connected to applications. Messages must be exchanged between services belonging to applications. The messages below do not respect this rule. 39

2 Les messages ne respectant pas cette règle sont ensuite listés. Si le message n'a pas d'émetteur ou de récepteur, le message d'erreur généré est le suivant : A message must have one emitter and one receiver client. The messages below do not respect this rule. Evénement Cette vérification est associée au chapitre "Event publisher and subscriber". Il faut vérifier que l'événement a au moins une ressource qui publie l'événement et une ressource qui souscrit à cet événement. Cette ressource peut être : Un service Un acteur La ressource est obligatoire mais pas unique. Deux cas doivent être vérifiés : Si l'événement est relié à une application au lieu d'un service, on aura le message suivant : The broker 'broker Name' does not manage events connected to applications. Events must be exchanged between services belonging to applications. The events below do not respect this rule. La liste des événements concernés est alors affichée. Si l'événement n'a pas de publieur ou pas de souscriveur, le message d'erreur généré est le suivant : An event must have at least one emitter and one receiver client. The events below do not respect this rule. Interaction et émetteurs, récepteurs Cette vérification est associée au chapitre "Interaction triggering source and triggered target". Cette partie propose de vérifier que toute interaction intervenant dans un échange au sein d'un broker a un émetteur et un seul récepteur. Si ce n'est pas le cas, un message d'erreur apparaît. Deux cas doivent être vérifiés : Si l interaction est reliée à une application au lieu d'un service, on aura le message suivant : The broker 'broker Name' does not manage interactions connected to applications. Interactions must be exchanged between services belonging to applications. The interactions below do not respect this rule. S en suit la liste des interactions concernées. Si l interaction n'a pas de ressource déclenchante ou déclenchée, le message d'erreur généré est le suivant : An interaction must have one triggered and one triggering client. The interactions below do not respect this rule. 40 MEGA Designer - Integration

Contrôler le modèle EAI Vérification EAI Contenus associés aux messages et aux événements Chaque message doit avoir un seul contenu et chaque événement doit avoir un seul contenu. On distingue trois cas : les messages, les événements et les messages contenus dans les interactions. Contenu : désigne le contenu d'un message ou d'un événement indépendamment de sa structure. Celle ci est représentée par un schéma XML relié au contenu. Un contenu peut être utilisé par plusieurs messages puisqu'il n'est pas associé à un émetteur et à un destinataire. Il ne peut y avoir qu'un contenu par message ou par événement, mais un même contenu peut être utilisé par plusieurs messages ou événements. Message content Cette partie consiste à vérifier que le message géré par le broker a un seul contenu. Si cette règle n'est pas respectée, un message d'erreur apparaît. Problem : The message "message name" has more than one content. A message must only have one content. Le message géré par le broker doit obligatoirement avoir un contenu. Problem : The message "message name" has no content. A message must have one content. Event content L'événement géré par le broker doit avoir un et un seul contenu. Problem: The event "event name" has more than one content. Only one content is allowed for the event. L'événement géré par le broker doit obligatoirement avoir un contenu. Problem: The event "event name" has no content. One content is compulsory for the event. Interaction messages content Cette partie consiste à vérifier que l'ensemble des messages contenus dans l interaction gérée par le broker a un unique contenu. On considère donc chaque message appartenant à l interaction. Problem : The message "interaction message name" has more than one content. A message must only have one content. Problem : The message "interaction message name" has no content. A message must have one content. Contraintes de gestion Cette partie vérifie la cohérence de la gestion au sein du broker. Il existe deux cas : La relation de gestion entre événement et message La relation de gestion entre interaction et message Gestion de message-event Les événements gérés par un broker ne doivent pas être liés à un message géré par ce même broker. Si c'est le cas, une erreur apparaît. Problem: The event "event name" is managed by the broker "broker name". It cannot be associated with the message "message name". 41

2 Gestion de message-interaction Les messages gérés par un broker ne doivent pas être liés à une interaction gérée par ce même broker. Si c'est le cas, une erreur apparaît. Problem: The message "message name" is managed by the broker "broker name". It cannot be associated with the interaction "interaction name" which is also managed by the broker "broker name". Acteurs d'un message, événement ou interaction Cette partie vérifie la cohérence des ressources d'un échange d'informations. En effet, il n'est pas logique de définir à la fois un émetteur étranger à l'entreprise (acteur externe) et un récepteur étranger à l'entreprise (acteur externe). Ce type de cas montre un échange d'informations n'ayant aucun impact sur l'entreprise. Il faut donc vérifier la validité des ressources pour : Les messages du broker Les événements du broker Les interactions du broker Acteurs d'un message Si la ressource source et la ressource cible du message sont des acteurs, un des deux acteurs ne doit pas être de type externe. Si les deux acteurs sont externes, un message d'erreur s'affiche. Problem: The message "message name" has an external org-unit as an emitter and an external org-unit as a receiver. It is forbidden. You can have only one external org-unit as a resource. Acteurs d'un événement Si la ressource source et la ressource cible d'un événement sont des acteurs, un des deux acteurs ne doit pas être de type externe. Si les deux acteurs sont externes, un message d'erreur s'affiche. Problem: The event "event name" has an external org-unit as a publisher and an external org-unit as a subscriber. It is forbidden. You can have only one external org-unit as a resource. Acteurs d'une interaction Si la ressource source et la ressource cible d'une interaction sont des acteurs, un des deux acteurs ne doit pas être de type externe. Si les deux acteurs sont externes, un message d'erreur s'affiche. Problem: The interaction "interaction name" has an external org-unit as a triggering source and an external org-unit as a triggered target. It is forbidden. You can have only one external org-unit as a resource. Acteurs d'une application Cette partie vérifie que tout acteur (émetteur ou récepteur) intervenant dans un échange (message, événement ou interaction) au sein d'un broker et possédant une application de l'entreprise doit être un acteur interne. 42 MEGA Designer - Integration

Contrôler le modèle EAI Vérification EAI Problem: The org-unit "org-unit name" contains one of the company's applications. However this org-unit is of the "org-unit nature" type. It should be of the internal type. Services Cette partie vérifie que tout service (émetteur ou récepteur) intervenant dans un échange (message, événement ou interaction) au sein d'un broker doit être détenu par une application. Si ce n'est pas le cas, un message d'erreur s'affiche. Problem: The service "service name" is not defined by any application. It is compulsory to define its application. Acteurs internes et services Cette partie vérifie que tout acteur interne possédant une application et intervenant dans un échange (message, événement interaction) au sein d'un broker, n'a pas de service associé à son application qui interviendrait également dans des échanges au sein du même broker. Problem: The org-unit "org-unit name" has an application "application name" which defines services involved in the data exchange. The org-unit and the application are therefore not compatible in this context. Your org-unit must be independent of this application. Interaction et messages Cette vérification est associée au chapitre "Interaction Messages". Toute interaction intervenant dans un échange au sein d'un broker doit être associée à une interaction definition contenant des messages. Si le résultat de la vérification n'est pas valide, un message d'erreur apparaît. Problem: The interaction "interaction name" has no message. An interaction must have at least one message. Contrôles de l'implémentation Ce niveau présente de manière plus précise comment le message sera échangé et de quelle manière les données vont transiter. Il concerne les connecteurs, les événements, les transformations canoniques de données et leur structure. Connecteurs d'un message ou d'un événement Le connecteur désigne le point de contact entre le gestionnaire de messages et l'application, du point de vue du gestionnaire. Le document peut provenir ou être à destination d'un adaptateur, d'un emplacement ou d'une file de messages. Un connecteur ne peut avoir qu'une transformation de données. Tout message ou événement doit avoir exactement deux connecteurs. Ces deux connecteurs sont obligatoirement reliés à une source ou à une cible unique. La source peut être un acteur émetteur ou un service émetteur. La cible peut être un acteur receveur ou un service receveur. 43

2 Les contrôles portent sur les connecteurs d'un message, connecteurs d'un événement, connecteurs des messages d'une interaction. Connecteurs d'un message Tout message géré par un broker doit avoir exactement 2 connecteurs. L'un des 2 connecteurs a un service ou un acteur émetteur. L'autre connecteur a alors un service ou un acteur récepteur. Le connecteur n'est associé qu'à une seule ressource. Problem: The connector "connector name" belonging to the message "message name" has more than one resource. One resource only is allowed for a connector. Problem: The message "message name" has 2 connectors. However, both are receiver connectors. There must be one emitter and one receiver connector. Problem: The message "message name" has 2 connectors. However, both are emitter connectors. There must be one emitter and one receiver connector. Problem: The message "message name" has 2 connectors. One of the connectors is a receiver connector. The other one is not associated with any source. You must link this connector to an emitter source. Problem: The message "message name" has 2 connectors. One of the connectors is an emitter connector. The other one is not associated with any target. You must link this connector to a receiver source. Problem: The message "message name" has less than 2 connectors. Messages must have no more than 2 connectors. Problem: The message "message name" has more than 2 connectors. Messages must have no more than 2 connectors. Connecteurs d'un événement Tout événement géré par un broker doit avoir exactement 2 connecteurs. L'un des 2 connecteurs a un service ou un acteur émetteur. L'autre connecteur a alors un service ou un acteur récepteur. Le connecteur n'est associé qu'à une seule ressource. Problem: The connector "connector name" belonging to the event "event name" has more than one resource. One resource only is allowed for a connector. Problem: The event "event name" has connectors. However, there are no emitter connectors. There must be at least one emitter and one receiver connector. Problem: The event "event name" has connectors. However, there are no receiver connectors. There must be at least one emitter and one receiver connector. Problem: The event "event name" has less than 2 connectors. Events must have at least 2 connectors not less. Connecteurs des messages d'une interaction Cette vérification est associée au chapître "Interaction Messages Connectors". 44 MEGA Designer - Integration

Contrôler le modèle EAI Vérification EAI Cette partie vérifie que : Tout message appartenant à une interaction gérée par un broker a exactement 2 connecteurs. L un des 2 connecteurs a un service ou acteur émetteur. Son confrère a alors un service ou un acteur récepteur. Le connecteur n'est associé qu'à une seule ressource. Pour chaque interaction, si le résultat de la vérification n'est pas valide, suivant les cas, on génère les messages d'erreurs suivants : Problem : The connector "connector name" belonging to the message "message name" has more than one resource. only one resource is enabled for a connector. Problem : The message "message name" has no connector. Connectors are compulsory for interaction messages. Problem : The message "message name" has only one receiver connector. Emitter Connector is compulsory for interaction messages. Problem : The message "message name" has only one emitter connector. Receiver Connector is compulsory for interaction messages. Problem : The message "message name" has more than one emitter connector. Only one emitter connector is allowed for interaction messages. Problem : The message "message name" has more than one receiver connector. Only one receiver connector is allowed for interaction messages. Connecteurs Cette vérification est associée au chapitre "Connector Unicity". Cette partie vérifie que tout connecteur a un nom unique. Problem: The connector name "connector name" is used by more than one connector entity. The connector name must be unique. Transformation de données et connecteurs Cette partie vérifie qu'un connecteur ne peut être relié qu'à une seule transformation de données. Cette vérification est associée au chapitre "Connectors and Data Transform". Le but de cette vérification est de récupérer l'ensemble des connecteurs associés aux messages, événements et interactions du broker spécifié. Pour chacun de ces connecteurs, on vérifie qu'il a au plus une transformation de données. Problem : The connector "connector name" has more than one data transform. Connector must only have one data transform. Transformation de données et contenus Une transformation de données indique la transformation d'un document dans un autre format. Cette transformation intervient au moment de l'envoi ou de la réception d'un document par le gestionnaire de message. 45

2 Cette partie vérifie la validité des documents (ou contents) échangés au niveau d'un connecteur. On distingue deux cas : le connecteur émetteur et le connecteur récepteur. Connecteur émetteur Si le connecteur émetteur est associé à une transformation de données, le document en sortie de la transformation de données (outbound) doit être le même que celui du message ou de l'événement auquel le connecteur est relié. Si ce n'est pas le cas, un message d'erreur apparaît. Problem: The outbound content "content name" of the datatransform "datatransform name" linked with the connector "connector name" has no matching message or event content. Connecteur récepteur Si le connecteur récepteur est associé à une transformation de données, le document en entrée de la transformation de données (inbound) doit être le même que celui du message ou de l'événement auquel le connecteur est relié. Problem: The inbound content "content name" of the datatransform "datatransform name" linked with the connector "connector name" has no matching message or event content. Contenus et schémas XML Un contenu ne doit être associé qu'à un seul schéma XML (ou UML classe). En effet, un contenu ne peut être associé qu'à une seule définition de structure. Problem: The content "content name" has no schema. A schema is compulsory to validate the structure of your document. Services d'application publiant ou souscrivant à un même événement Cette vérification est associée au chapitre "Application services and events". Cette partie vérifie que les modules d'une même application ne peuvent souscrire ou publier un même événement. Le message d'erreur généré dépend s'il s'agit d'une souscription ou d'une publication. Pour la publication d'un événement : Problem: The application "nom de l'application" has more than one service publishing the event "nom de l'event". Only one service from the same application can publish a unique event. Pour la souscription d'un événement : Problem: The application "nom de l'application" has more than one service subscribing the event "nom de l'event". Only one service from the same application can subscribe to a unique event. Services récepteurs avec connecteurs portant des transformations de données Cette vérification est associée au chapître "Receiver Services and contents from Data Transform". 46 MEGA Designer - Integration

Contrôler le modèle EAI Vérification EAI Lorsqu un service en réception est lié à plusieurs connecteurs portant chacun une transformation de données, les contenus en sortie de la transformation de données doivent être les mêmes. Dans le cas contraire, le message d'erreur est le suivant : Problem: The Service "Service Name" has several contents as outbound contents of Data Transform. It must be the same content. Avertissements Ces contrôles s'appliquent aux configurations non standard mais qui sont réalisables. Contenus de part et d'autre de la transformation de données Cette partie vérifie la validité des documents (ou contents) échangés au niveau de la transformation de données d'un connecteur. On distingue deux cas : le connecteur émetteur et le connecteur récepteur. Connecteur émetteur Si le connecteur émetteur est associé à une transformation de données, si le document en sortie de la transformation de données (outbound) n'a pas de document en entrée associé (inbound), un message d'avertissement apparaît. Problem: The emitter connector "connector name" has no inbound content. It is recommended to define an inbound document for transformation. Connecteur récepteur Si le connecteur récepteur est associé à une transformation de données, si le document en entrée de la transformation de données (inbound) n'a pas de document en sortie associé (outbound), un message d'avertissement apparaît. Problem: The receiver connector "connector name" has no outbound content. It is advised to define an outbound document for the target resource. Connecteurs et interactions Cette partie vérifie que tout connecteur lié à une interaction est relié à un message de cette interaction. Sinon, le connecteur est inutile. Problem: The connector "connector name" is linked to the interaction "interaction name". However, none of the interaction messages is connected to this connector. It is useless. 47

2 48 MEGA Designer - Integration

3 DÉCRIRE LES INTERACTIONS Ce chapitre explique comment décrire les interactions entre les applications de l'entreprise et les applications de ses partenaires. Les points suivants sont abordés ci-après : "Contexte d'utilisation", page 50 "Description d'une interaction", page 58 "Description d'une bibliothèque", page 61 49

3 CONTEXTE D'UTILISATION L'utilisation des interactions permet de décrire en détail l'automatisation des échanges entre une entreprise et des acteurs externes. Ces échanges peuvent être décrits en utilisant des standards définis par des groupements internationaux tels que l'oag (Open Applications Group) ou par des fournisseurs de places de marché. Une entreprise peut également définir ses propres modes d interaction avec ses filiales, par exemple, ou avec ses sous-traitants. L'exemple qui suit va permettre de décrire les échanges entre une entreprise et ses fournisseurs. Pour cela, nous allons explorer les diagrammes qui décrivent le Broker "Achats". Depuis le navigateur, activez la commande Diagramme de Broker du menu contextuel du broker "Achats". Dans la liste qui vous est présentée, double-cliquez sur le diagramme "DB Achats (Flux)". Le diagramme s ouvre. 50 MEGA Designer - Integration

Décrire les interactions Contexte d'utilisation Carte des applications du processus des achats Voici une carte des principales applications qui interviennent dans le processus des achats. Elle permet de représenter les principaux flux échangés avec les fournisseurs dans le cadre de ce processus. Les achats de matériel pour entretenir les bateaux sont effectués directement par le bureau de représentation en utilisant l'application "Achats de matériel". Celle-ci fait appel à une application centralisée de "Gestion des achats" au siège. S'il s'agit d'un nouveau type de matériel ou d'un nouveau fournisseur, une demande de contrat est envoyée au fournisseur à l'aide de l'application du siège. Celui-ci renvoie en échange une proposition de contrat. Dans les autres cas, un agent du bureau de représentation envoie un ordre d'achat au fournisseur à l'aide de l'application "Achats de matériel". La réception des achats livrés par le fournisseur est réalisé à l'aide de l'application "Gestion des stocks bateaux" du bureau de représentation. La facture envoyée par le fournisseur est traitée par l'application "Facturation" du siège. Informatisation des échanges : les interactions La représentation des flux échangés par les applications de l'entreprise avec ses fournisseurs peut être suffisante pour une compréhension globale des relations entre l'entreprise et ses fournisseurs. 51

3 Elle n'est cependant pas assez précise pour permettre l'informatisation des échanges avec ces fournisseurs. Ouvrez le diagramme de broker "DB Achats (Interactions)" qui décrit également le broker "Achats". Dans ce diagramme, les flux échangés avec le fournisseur ont été remplacés par des interactions. Celles-ci vont permettre de décrire de manière précise l interaction effective entre les deux partenaires. Une interaction représente un contrat conclu dans un contexte précis entre des entités autonomes à l'intérieur ou à l'extérieur d'une entreprise. Ces entités peuvent être des acteurs, des applications, des activités, des processus de l'entreprise, ou des acteurs externes à l'entreprise. Le contenu de ce contrat est décrit par un protocole d interaction. Un protocole est un modèle de contrat entre des entités organisationnelles. Ce contrat est décrit par les messages échangés entre deux rôles (par exemple acheteur et vendeur). Interactions composites Une interaction complexe peut être décomposée en plusieurs sous-interactions élémentaires qui s'enchaînent. Ces sous-interactions sont affichées dans la forme de l interaction. Les enchaînements d interactions peuvent être définis à l'intérieur du processus de l'entreprise comme dans le premier exemple ci-dessous. Dans d'autres cas, ils peuvent être déterminés par les réponses du partenaire comme dans le deuxième exemple. 52 MEGA Designer - Integration

Décrire les interactions Contexte d'utilisation Les interactions élémentaires sont toujours composées d'une demande suivie d'une ou plusieurs réponses qui sont exclusives les unes des autres. Les demandes et les réponses sont représentées par des messages. Exemple d interaction composite Cliquez avec le bouton droit sur l interaction "Proposition de contrat". Dans le menu contextuel du protocole, cliquez sur Diagramme de Définition d interaction. Le diagramme correspondant s ouvre. Le message envoyé lors du déclenchement d'une interaction est représenté en bleu, les réponses sont représentées en rouge. La proposition de contrat se décompose en plusieurs sous-interactions élémentaires. Tout d'abord une demande de contrat est envoyée au fournisseur. 53

3 Après avoir reçu une proposition de contrat de la part du fournisseur, le demandeur peut répondre par : L'acceptation du contrat proposé Une modification du contrat proposé Un rejet définitif du contrat Dans le cas d'une modification du contrat, le demandeur peut de nouveau accepter, modifier ou refuser la contre-proposition du fournisseur. Les symboles suivants représentent : le début de l interaction un choix exclusif entre plusieurs interactions l'exécution en parallèle de plusieurs interactions la jonction de plusieurs interactions un enchaînement quelconque entre deux interactions, éventuellement conditionné par un message. Un enchaînement d interaction décrit la façon dont deux interactions se suivent. la fin de l interaction Autre exemple d interaction composite Retournez dans le diagramme "DAA Achats (Interactions)". Cliquez avec le bouton droit sur l interaction "Ordre d'achat". Dans le menu contextuel du protocole, cliquez sur Diagramme de Définition d interaction. 54 MEGA Designer - Integration

Décrire les interactions Contexte d'utilisation Le diagramme correspondant s ouvre. Lorsqu'un ordre d'achat est envoyé à un fournisseur, celui-ci peut : Accepter l'ordre d'achat par le message "Accusé de réception OA". Refuser l'ordre d'achat par le message "Rejet Ordre d achat". Proposer une modification de l'ordre d'achat par le message "Modification OA". Dans ce dernier cas, l interaction "Modification de l'ordre d'achat" est déclenchée. Il est possible de réitérer plusieurs fois l interaction "Modification de l'ordre d'achat". L interaction "Annulation de l'ordre d'achat" peut éventuellement être déclenchée à l'initiative du demandeur. Le fournisseur a la possibilité d'accepter ou de refuser cette demande d'annulation. PO est l'abbréviation de "Purchase Order" (Ordre d'achat). Message déclenchant un enchaînement d interactions Pour préciser le message qui conditionne l'enchaînement : 1. Cliquez avec le bouton droit sur l enchaînement "Modification OA". 55

3 2. Sélectionnez Relier > Message. La fenêtre Rechercher apparaît. 3. Choisissez "Réponses de l interaction précédente" et cliquez sur Chercher. Après l'exécution de la requête, la liste des messages susceptibles de déclencher l interaction vous est proposée. Pour afficher le message déclenchant l'enchaînement d interactions dans le diagramme, cliquez avec le bouton droit sur l'enchaînement d interactions puis cliquez sur Affichage. 4. Sélectionnez un message et cliquez sur OK. Ou cliquez sur Annuler pour fermer la fenêtre de résultat. Interactions élémentaires Une interaction élémentaire est composée d'une demande suivie d'une ou de plusieurs réponses qui sont exclusives les unes des autres. Les demandes et les réponses sont représentées par des messages. Cliquez avec le bouton droit sur l nteraction "Modification de l'ordre d'achat". Dans le menu contextuel du protocole, cliquez sur Diagramme de Définition d interaction. 56 MEGA Designer - Integration

Décrire les interactions Contexte d'utilisation Le diagramme correspondant s ouvre. Le message envoyé lors du déclenchement d'une interaction est précédé du signe "?", les réponses sont précédées du signe "=". Les messages échangés dans le cadre de chaque interaction élémentaire sont généralement normalisés par des organismes internationaux tels que l'oag (Open Applications Group) ou IFX (Interactive Financial Exchange). Ils peuvent également être définis à l'intérieur d'une entreprise ou d'un groupement d'entreprises voulant s'échanger électroniquement des informations. L'exemple ci-dessus présente des messages définis par l'oag pour la gestion des ordres d'achats (Purchase Order abrégé en PO). Le produit MEGA Process permet de préciser la façon dont les interactions avec les partenaires de l'entreprise sont mises en œuvre par les activités d'un processus. Le produit MEGA Architecture permet de préciser les applications qui vont prendre en charge les interactions et avec quels outils. Le produit MEGA System Blueprint permet de spécifier la structure de chacun des messages échangés et de générer le schéma correspondant au format XML. Fermez le diagramme. 57

3 DESCRIPTION D'UNE INTERACTION Créer une interaction Pour créer une interaction : 1. Cliquez sur le bouton Interaction dans la barre d'outils du diagramme. 2. Cliquez sur le plan de travail du diagramme. La fenêtre Ajout d'une interaction apparaît. 3. Saisissez le nom du protocole de cette interaction ou recherchez un protocole existant. Il n est pas nécessaire de renseigner le nom de l interaction. En effet, si celui-ci n est pas renseigné, l interaction hérite automatiquement du nom de sa définition. 4. Cliquez sur OK. L interaction apparaît dans le diagramme. Propriétés d une interaction Pour décrire en détail chacune des interactions de votre diagramme : 1. Ouvrez le menu contextuel de l interaction. 2. Cliquez sur Propriétés. 58 MEGA Designer - Integration

Décrire les interactions Description d'une interaction Une fenêtre indiquant le nom du protocole associé à l interaction apparaît. Propriétés d un protocole d interaction Un protocole est un modèle de contrat entre des entités organisationnelles. Ce contrat est décrit par les messages échangés entre deux rôles (par exemple acheteur et vendeur). Pour ouvrir la fenêtre de propriétés d un protocole d interaction : 1. Ouvrez le menu contextuel du protocole d interaction. 2. Sélectionnez Propriétés. La fenêtre des propriétés d'un protocole d interaction présente plusieurs onglets. Onglet Rôles L'onglet Rôles présente la liste des rôles intervenant dans l interaction 59

3 Onglet Sous-Interactions L'onglet Sous-Interactions présente la liste des sous-interactions de l interaction. Onglet Messages L'onglet Messages présente la liste des messages de l interaction. 60 MEGA Designer - Integration

Décrire les interactions Description d'une bibliothèque DESCRIPTION D'UNE BIBLIOTHÈQUE De nombreux protocoles d interactions peuvent être définis par l'entreprise ou par des organismes internationaux. Des bibliothèques permettent de regrouper ces protocoles par nature. Vous pouvez créer de nouvelles bibliothèques et leur rattacher des protocoles. Une bibliothèque permet de définir un espace de nommage pour les protocoles d interactions. Cela signifie que deux protocoles d interaction peuvent porter le même nom s ils appartiennent à des bibliothèques différentes. Par exemple, vous pouvez disposer du protocole d interaction "Demande de contrat" appartenant à la bibliothèque "Achats" et d'un protocole d interaction "Demande de contrat" appartenant à la bibiliothèque "Commercial". Si vous réutilisez des protocoles d interaction ou des messages proposés par des organismes internationaux (OAG, IFX, ), vous pourrez être amené à créer les bibliothèques correspondantes. Le même mécanisme est utilisé pour les messages d'un protocole d interaction ou pour les sous-protocoles d'un protocole d interaction composite. Vous pouvez également regrouper les protocoles d interaction par métiers. Créer une bibliothèque Pour créer une nouvelle bibliothèque : 1. Dans la fenêtre de navigation Accueil, cliquez avec le bouton droit sur le nom de la base et sélectionnez Nouveau > Bibliothèque. La fenêtre de création d'une bibliothèque apparaît. 2. Saisissez le nom de la bibliothèque et cliquez sur OK. La bibliothèque est créée et ajoutée dans la liste des bibliothèques. 61

3 MISE EN OEUVRE DES INTERACTIONS : LES SERVICES Mise en oeuvre d'une interaction L'exemple qui suit va permettre de détailler la mise en œuvre des interactions avec les fournisseurs pour l'achat de matériels. Cliquez sur la fenêtre de navigation Objets principaux. Ouvrez le dossier "Broker". Double-cliquez sur le broker "Achats" et ouvrez le diagramme "DB Achats de matériels". Les achats de matériel pour entretenir les bateaux sont effectués directement depuis le bureau de représentation en utilisant des services de l'application "Achats de matériel". Ces services font eux-mêmes appel à des services de l'application "Gestion des achats" qui est centralisée au siège. Ce sont ces derniers services qui mettent en œuvre les interactions avec les fournisseurs. Un service est l'élément de découpage d'une application qui est mis à la disposition de l'utilisateur final de cette application dans le cadre de son travail. La demande d'achat est saisie avec le service "Saisie Achat de matériel". 62 MEGA Designer - Integration

Décrire les interactions Mise en oeuvre des interactions : les services Interaction " Traitement de l'ordre d'achat " Le service "Saisie Achat de matériel" fait appel au service "Transmission ordre d'achat" qui lance l interaction "Traitement de l'ordre d'achat". Le service "Réception de l'ordre d'achat" enregistre la réponse de cette interaction dans le système. Le service "Traitement réponse ordre d'achat" permet ensuite à l'acheteur de consulter la réponse du fournisseur. Si le fournisseur a accepté ou refusé l'ordre d'achat, le traitement est terminé. Si le fournisseur a proposé une modification de l'ordre d'achat, l'acheteur peut : Annuler l'ordre d'achat à l'aide de le service "Annulation de l'ordre d'achat" Renvoyer l'ordre d'achat modifié, en incluant éventuellement de nouvelles modifications à l'aide de le service "Modification achat de matériel". Interaction " Modification de l'ordre d'achat " Le service "Modification achat de matériel" fait lui aussi appel à le service "Transmission des ordres d'achats" du siège pour lancer l interaction "Modification de l'ordre d'achat". La réponse de cette interaction est comme précédemment enregistrée par le service "Réception de l'ordre d'achat". Il peut arriver qu'une modification ou une annulation de l'ordre d'achat intervienne après que l'ordre d'achat a été accepté par les deux partenaires. En fonction du délai écoulé, cette modification pourra ou non être prise en compte par le fournisseur. Interaction " Annulation de l'ordre d'achat " L interaction "Annulation de l'ordre d'achat" est lancée par le service "Transmission annulation". La réponse est prise en compte par le service "Réception réponse annulation". Si l'annulation est rejetée par le fournisseur, on reboucle sur le service "Modification achat de matériel". 63

3 64 MEGA Designer - Integration

4 DÉCRIRE UN WORKFLOW Ce chapitre présente comment décrire un workflow par un processus applicatif dans MEGA. Les points suivants sont abordés ci-après : "Contexte d'utilisation", page 66 "Créer le diagramme du workflow", page 67 "Les variables", page 78 "Relier le workflow au service", page 82 65

4 CONTEXTE D'UTILISATION Un workflow permet d automatiser au maximum les échanges d informations entre différents intervenants. Il se charge de déterminer quel est le prochain intervenant pour chaque étape et d effectuer les transferts d information d un intervenant à l autre. Ces intervenants peuvent être des acteurs de l organisation ou des applications informatiques. Un workflow est la représentation exécutable d'un processus métier. Les éléments formalisant un workflow sont les suivants : le début et la fin du workflow, les opérations à accomplir durant le traitement, les éléments algorithmiques d enchaînement des opérations, les rôles interagissant avec les opérations et l allocation des ressources aux opérations. MEGA vous permet de réaliser la spécification d un workflow, réutilisable par n importe quel outil de BPM et de workflow. Un workflow est représenté dans MEGA par un processus applicatif. La modélisation d un workflow passe par : La description du workflow et de son algorithme La définition des variables utilisées dans le cadre du workflow 66 MEGA Designer - Integration

Décrire un Workflow Créer le diagramme du workflow CRÉER LE DIAGRAMME DU WORKFLOW Un workflow est représenté dans MEGA par un processus applicatif et il est décrit par un diagramme de workflow. Le diagramme de workflow donne une représentation générale d un service ou d un métier. Il décrit l enchaînement des opérations et les services avec lesquels il communique. Créer un workflow et son diagramme Pour créer un workflow : 1. Cliquez avec le bouton droit sur le dossier Processus applicatifs du navigateur. 2. Sélectionnez Nouveau > Processus applicatif. 3. Saisissez le nom du processus applicatif et cliquez sur OK. Vous pouvez ensuite créer le diagramme de workflow correspondant. Cette commande est disponible avec l option "Création de diagrammes de workflow". Pour activer cette option : 1. Cliquez sur le menu Outils > Options. 2. Dans la fenêtre qui apparaît, dépliez le dossier Compatibilité. 3. Cliquez sur Diagrammes. 4. Cochez l option en question. Une autre option vous permet de créer des diagrammes de worflow BPMN. Pour créer le diagramme de workflow : 1. Cliquez avec le bouton droit sur le processus applicatif et sélectionnez Nouveau > Diagramme. 2. Dans la fenêtre qui apparaît, sélectionnez "Diagramme de workflow" et cliquez sur le bouton Créer. Vous pouvez également créer un processus applicatif à partir d un service. Voir "Relier un workflow au service", page 82. Dessiner un diagramme de workflow Le diagramme de workflow permet de représenter graphiquement l'ordre des opérations et les services avec lesquels le workflow communique. 67

4 L'algorithme du workflow peut être exprimé via l'enchaînement des opérations mais aussi via des éléments comme des boucles, des jonctions ou des parallélismes. Diagramme du workflow Demande d achat Le diagramme ci-dessus présente le workflow utilisé pour la gestion de demande d achat. 68 MEGA Designer - Integration

Décrire un Workflow Créer le diagramme du workflow Après réception d une demande d achat, le moteur soumet cette demande à une vérification. Toute commande supérieure à 1000 euros nécessite l accord du responsable. Lorsque la demande est acceptée, le moteur vérifie qu il existe un prix de marché pour la marchandise demandée. S il n existe aucun marché en cours, le prix est négocié. Au dessus de 500 euros, le prix est fixé par le Négociateur Achats. Une fois le prix déterminé, la commande est envoyée au fournisseur. Les rôles Le rôle permet de représenter les interactions du workflow avec les autres services. On distingue deux types de rôle : Le rôle initiateur représentant celui qui demande un service. Les rôles 'simples' qui permettent de sous-traiter un traitement lorsque celui-ci ne fait pas partie intégrante du service. Les rôles émettent et reçoivent des messages. Dans l exemple ci-dessus, le rôle initiateur est "Demandeur". Un rôle est un participant à une interaction, un workflow ou une procédure. Il peut en être l'initiateur c'est à dire le demandeur du service ou représenter un sous-traitant réalisant un traitement extérieur au service. Un rôle fait partie intégrante de l'objet qu'il décrit et n'est pas réutilisable. Il peut par la suite être affecté à un acteur interne ou externe à l'organisation ou à un composant informatique. Exemples : Demandeur, voyageur. Les opérations Les opérations du workflow correspondent aux différents traitements réalisés. 69

4 On distingue trois types d'opérations dans le workflow, chacune ayant sa propre notation. Les opérations Début et Fin qui sont là pour indiquer au lecteur du diagramme où commence et où s'achève le workflow. Il y a un seul 'début' mais il peut y avoir plusieurs 'fin'. Les opérations de type Tâche qui représentent une tâche réalisée par un acteur, un groupe de personnes ou un programme informatique. Les opérations de type Tâche se divisent en deux groupes : Les opérations manuelles : qui nécessitent l intervention d un acteur. Les opérations automatiques : qui sont implémentées par une ressource informatique. Relier un sous-workflow à une opération Une opération d un workflow peut être réalisée par un sous-workflow. Pour associer une opération à un sous-workflow : 1. Cliquez avec le bouton droit sur l opération. 2. Sélectionnez Propriétés. 3. Cliquez sur l onglet Réalisation. 4. Cliquez avec le bouton droit sur le dossier "Workflow réalisateur" et sélectionnez Nouveau. 5. Dans la fenêtre qui apparaît, saisissez le nom du workflow et cliquez sur OK. Le sous-workflow apparaît dans la fenêtre de propriétés de l opération. 6. Pour créer le diagramme du sous-workflow, cliquez avec le bouton droit sur le sous-workflow et sélectionnez Nouveau > Diagramme de workflow. 70 MEGA Designer - Integration

Décrire un Workflow Créer le diagramme du workflow Les messages Pour représenter les échanges vers l'extérieur, lorsque les ressources n'appartiennent pas au workflow, des messages sont émis ou reçus par les opérations. Comme tous les messages, les messages de workflow portent des informations dans un 'contenu'. Un message représente un flux d'informations à l'intérieur de l'entreprise ou entre l'entreprise et ses partenaires. Il est échangé entre applications, acteurs internes et externes, et outils. Il porte un contenu décrivant les informations échangées. Pour plus de détails sur le nom des messages, voir le guide MEGA Common Features, chapitre "Manipuler les objets dans les diagrammes", "Noms des messages". Les boucles Une boucle exprime qu'une opération - ou une branche constituée de plusieurs opérations successives - est réalisée plusieurs fois, jusqu'à ce que la règle portée par la boucle soit réalisée. Une boucle est un ensemble d'instructions dont l'exécution est répétée jusqu'à la vérification d'un critère donné ou l'obtention d'un certain résultat. Pour spécifier les opérations impliquées dans une boucle : 1. Créez la boucle à l aide du bouton While de la barre d objets. 2. A l aide du bouton Lien, reliez la boucle à la première opération exécutée dans la boucle. Une fenêtre apparaît vous demandant de choisir le type de lien. 71

4 3. Choisissez le type de lien "Opération itérée". Le lien n apparaît pas si l opération est posée dans la boucle. Si l opération est cachée par la boucle, faites un clic droit sur la boucle et cliquez sur le bouton Arrière-plan de la barre de dessin. 4. Reliez entre elles les différentes opérations effectuées dans la boucle. Seule la première opération exécutée doit être reliée à la boucle. Les autres sont simplement reliées entre elles. 5. Reliez la boucle à la prochaine opération qui doit être exécutée une fois les itérations de la boucle terminées. Sélectionnez pour cela le lien "Opération suivante". 72 MEGA Designer - Integration

Décrire un Workflow Créer le diagramme du workflow La spécification de la boucle est alors complète. Il existe trois types de boucle : Une boucle de type "While" vérifie d'abord la condition avant de s'exécuter. Une boucle de type "Do While" s'exécute avant de vérifier la condition. Une boucle de type "For Each" parcourt chaque objet d une collection. While Do While For each Les conditions Il est possible de spécifier des conditions d enchaînement entre les différentes opérations du workflow. Une condition précise l'état dans lequel un objet doit se trouver pour qu'une action puisse être effectuée. 73

4 La fenêtre des propriétés d une condition permet de la spécifier en détail : 1. Dans le champ Logique en sortie, il est possible de préciser s il s agit d une condition alternative (par défaut) ou d un parallélisme. Un parallélisme est le traitement simultané de différentes parties d'un processus. 2. Il est également possible de spécifier en détail l expression à tester pour déterminer quelle branche de la condition va être activée. Il s'agit de spécifier une règle indiquant de manière non ambiguë les données à utiliser tout en assurant une traçabilité entre la règle et les données du workflow. La valeur de l'expression est stockée dans le texte Corps expression. Vous pouvez définir le corps de l expression en glissant/déplaçant les variables du workflow dans le texte de l expression. 3. Il reste à indiquer dans le cadre Objets suivants la valeur de l expression qui va déclencher l une ou l autre des opérations qui suivent la condition. La fenêtre des propriétés de la condition propose toutes les branches avec les prédicats, les opérateurs à appliquer et les valeurs que peut prendre l'expression. Prédicat Opérateur Valeur 1 Valeur 2 Oui Non Vraie Fausse = 10 Egal 10 74 MEGA Designer - Integration

Décrire un Workflow Créer le diagramme du workflow Prédicat Opérateur Valeur 1 Valeur 2 # 15 Différent 15 > 25 Supérieure à 25 >= 30 Supérieur ou égale à 30 < 35 Inférieure à 35 <= 45 Inférieure ou égale à 45 [50,100] Comprise entre 50 100 Les transactions Une transaction permet de réunir plusieurs traitements de données dans une seule unité de travail logique, afin d'assurer la validation de l'ensemble des tâches effectuées par ces traitements ou, au contraire, leur annulation. Il existe deux types de transaction : les transactions minutées et les transactions à exception. Transaction minutée Une transaction minutée doit être exécutée dans un espace de temps défini. Elle est utilisée dans le cas d une attente d une réponse. Exemple : la transaction suivante englobe les opérations "Proposer itinéraires" et "Traiter itinéraires". La transaction est tributaire de la réponse du demandeur, elle ne doit pas excéder 15 minutes. 75

4 Transaction à exception Une transaction à exception est utilisée dans le cadre de traitements informatisés, elle peut être réitérée en cas de panne d un des traitements. Exemple : la transaction suivante comprend les traitements bancaires automatiques "Débiter compte" et "Créditer compte". Si l un des traitements échoue pour une raison technique, il est possible de relancer la transaction. Pour préciser cela : Ouvrez la fenêtre de propriétés de la transaction. Dans l onglet Caractéristiques, précisez le nombre de tentatives et les intervalles entre chacune d elles. Créer une transaction Pour créer une transaction : 1. Dans le diagramme, cliquez sur le menu Affichage > Vues et détails. 2. Cochez la case "Transactions" et cliquez sur OK. Les boutons correspondant aux deux types de transaction apparaissent dans la barre d objets. 3. Cliquez sur l un des boutons puis cliquez dans le diagramme. 4. Dans la fenêtre qui apparaît, indiquez le nom de la transaction et cliquez sur OK. 5. Pour spécifier les opérations impliquées dans la transaction, faites-les glisser dans la transaction. Le lien est créé automatiquement. 6. Renseignez ensuite la fenêtre de propriétés de la transaction, selon qu il s agit d une transaction minutée ou d une transaction à exception. 76 MEGA Designer - Integration

Décrire un Workflow Créer le diagramme du workflow Echec de transaction Il est nécessaire d indiquer la marche à suivre en cas d échec d une transaction. Vous pouvez l indiquer en reliant la transaction à une opération marquant l interruption du workflow, à un message, une condition etc. 77

4 LES VARIABLES Dans la modélisation d un workflow, les données - ou variables - sont constituées : Des données transmises au workflow. Il s'agit des données véhiculées par les messages reçus par le workflow. Des données propres au workflow, nécessaires au stockage ou au calcul d'information. Définir les variables du workflow Les variables propres au workflow sont visibles dans l éditeur de schéma. Pour consulter les variables d un workflow: Dans le diagramme du workflow, cliquez sur le menu Diagramme > Objet décrit > Variables. Vous pouvez également consulter les variables à partir du menu contextuel du workflow. L éditeur s ouvre. Il contient l ensemble des variables du workflow. Les variables sont représentées par des schémas. Un schéma XML est un modèle permettant de décrire la structure de l'information contenue dans un document XML. 78 MEGA Designer - Integration

Décrire un Workflow Les variables Pour créer une nouvelle variable : Cliquez avec le bouton droit sur l élément racine du schéma et sélectionnez Nouveau. Vous pouvez créer un attribut, un élément ou un groupe. Définir les variables des opérations Les opérations du workflow correspondent aux différents traitements réalisés. Les opérations reçoivent et émettent des informations. Ces informations sont stockées dans des contenus. Les contenus sont construits à partir des différentes variables. Pour chaque opération sont automatiquement construits : Le contenu des variables en entrée de l opération Le contenu des variables en sortie de l opération Le contenu en entrée de l opération est automatiquement construit à partir des messages transmis au workflow et des variables propres au workflow. Le contenu en sortie est construit uniquement à partir des variables du workflow. Exemple : Prenons l opération "Approbation". Le contenu en entrée de l opération est "Approbation_In". Il est construit à partir des variables du message transmis 79

4 au workflow, "Demande d achat", et des variables du workflow, "Workflow Demande d achat". Le contenu en sortie est "Approbation_Out". Il est construit uniquement à partir des variables propres au workflow ("Workflow Demande d achat"). Par défaut, l ensemble des variables potentielles est affiché. Vous devez préciser celles que l opération utilise. Pour préciser quelles variables l opération utilise : 1. Dans l éditeur, cliquez sur le menu Outils > Mode restriction. 2. Cliquez avec le bouton droit sur la variable en question et sélectionnez Ajouter à la vue. Si vous voulez par exemple que l opération vous indique le motif du refus, faites un clic droit sur l attribut "Motif refus" et cliquez sur Ajouter à la vue. Une petite coche s ajoute devant l élément. 80 MEGA Designer - Integration

Décrire un Workflow Les variables Ici, l opération prend en entrée l ensemble des variables du contenu "Demande d achat" et délivre en sortie les informations "Approbation" et "Motif refus". Vous pouvez créer une nouvelle variable pour l opération. L élément créé pour cette opération vient s ajouter à la liste des variables du workflow. Variables d un sous-workflow Un workflow peut contenir un sous-workflow. Lorsque vous cliquez sur la commande Variables du sous-workflow, un nouveau contenu est attribué par défaut au sousworkflow. Vous avez la possibilité de reprendre le contenu du workflow détenteur. Pour spécifier que le sous-workflow a le même contenu que le workflow détenteur : 1. Ouvrez la fenêtre de propriétés du sous-workflow. 2. Cliquez sur l onglet Variables. 3. Sélectionnez le dossier Contenu et cliquez sur le bouton Relier. 4. Dans la fenêtre qui apparaît, sélectionnez "Contenu d un workflow détenteur" et cliquez sur OK. 5. Sélectionnez le contenu du workflow détenteur et cliquez sur OK. Vous pouvez également conserver le nouveau contenu du sousworkflow et ne reprendre que certaines variables du workflow détenteur. Vous pouvez transmettre ces variables par l intermédiaire des messages du sous-workflow. 81

4 RELIER LE WORKFLOW AU SERVICE Une fois le workflow créé, vous pouvez indiquer comment il s intègre aux flux du service. Cette connexion se fait par l intermédiaire des connecteurs du service. Relier un workflow au service Pour relier un workflow à un service : 1. Ouvrez la fenêtre de propriétés du service. 2. Cliquez sur l onglet Implémentation. 3. Sélectionnez le dossier Workflow implémentant. 4. Cliquez sur le bouton Relier. 5. Dans la fenêtre qui apparaît, sélectionnez le workflow en question et cliquez sur OK. Créer les connecteurs du service Dans le cadre de l'eai, vous pouvez définir des connecteurs associés au service. Ces connecteurs ont pour but de définir l'adaptateur qui va permettre de communiquer avec le service ou l'adaptateur que va utiliser le service pour envoyer un message ou un événement. La création des connecteurs du service et des liens associés est automatisée. Pour créer les connecteurs : Cliquez avec le bouton droit sur le service et sélectionnez Contrôler > Description de contrôle. Une fois le contrôle terminé, un rapport fait état des objets créés. Il faut ensuite indiquer comment les messages en entrée et en sortie du workflow communiquent avec les connecteurs en entrée et en sortie du service. Voir "Relier les connecteurs au workflow", page 83. 82 MEGA Designer - Integration

Décrire un Workflow Relier le workflow au service Relier les connecteurs au workflow Pour indiquer comment le workflow communique avec le service, vous allez relier les messages du workflow aux connecteurs du service : 1. Ouvrez la fenêtre de propriétés du service. 2. Cliquez sur l onglet Connecteurs puis sur le sous-onglet Emission. 3. Ouvrez la fenêtre de propriétés du connecteur en émission. La fenêtre de propriétés du connecteur apparaît. 4. Cliquez sur l onglet Ressource connectée : Dans le dossier Workflow connecté, indiquez le workflow à relier. Dans le dossier Message connecté, reliez le message en entrée du workflow. Une fois le connecteur en émission renseigné, allez dans la fenêtre de propriétés du connecteur en Réception et reliez-le de la même façon au message sortant du workflow. 83

4 84 MEGA Designer - Integration

5 LE DIAGRAMME DE WORKFLOW BPMN MEGA Designer - Integration vous permet de modéliser vos workflows en utilisant la notation BPMN (Business Process Modeling Notation). La spécification BPMN a été créée pour formaliser la représentation graphique des processus métiers, afin d offrir une notation facilement utilisable par l ensemble des acteurs concernés. Les points abordés ici sont : "Créer le diagramme de workflow BPMN", page 86 "Les opérations", page 88 "Les messages", page 89 "Les conditions", page 91 "Les synchronisations", page 92 "Les rôles", page 93 "Les transactions", page 94 "Ressources des opérations", page 95 "Les variables", page 96 85

5 CRÉER LE DIAGRAMME DE WORKFLOW BPMN Le diagramme de workflow BPMN utilise les mêmes concepts que le diagramme de workflow mais avec un jeu de formes différent. Créer un workflow et son diagramme de BPMN Pour créer un workflow : 1. Dans la fenêtre de navigation des Objets principaux, cliquez avec le bouton droit sur le dossier Processus applicatifs. 2. Sélectionnez Nouveau > Processus applicatif. 3. Saisissez un nom et cliquez sur OK. Vous pouvez créer le diagramme de workflow BPMN correspondant. Cette commande est disponible avec l option "Création de diagrammes de workflow BPMN 0.9". Pour activer cette option : 1. Cliquez sur le menu Outils > Options. 2. Dans la fenêtre qui apparaît, dépliez le dossier Compatibilité. 3. Cliquez sur Diagrammes. 4. Cochez l option en question. Pour créer un diagramme de workflow BPMN : 1. Cliquez avec le bouton droit sur le processus applicatif décrit et sélectionnez Nouveau > Diagramme. 2. Dans la fenêtre qui apparaît, sélectionnez "Diagramme de workflow (BPMN)" et cliquez sur le bouton Créer. Dessiner un diagramme de workflow BPMN L'algorithme du workflow peut être exprimé via l'enchaînement des opérations mais aussi via des éléments comme des conditions, des jonctions ou des parallélismes. Exemple Le diagramme ci-après représente la réservation en ligne de billet d avion. Après réception de la commande, une recherche de vol est effectuée puis une proposition est envoyée au client. Si le vol est refusé, la commande prend fin. Si le vol est accepté, une demande de réservation est envoyée à la compagnie aérienne. Cette demande est réitérée pour chaque compagnie. Si le vol n est pas confirmé, la commande prend fin. Si le vol est confirmé, le billet est confirmé au client. 86 MEGA Designer - Integration

Le diagramme de workflow BPMN Créer le diagramme de workflow BPMN S en suit une demande de facturation et la réception de l accusé de paiement. Le temps entre la demande de facturation et la réception de l accusé de paiement ne doit pas excéder 6 jours. Ces deux traitements sont représentés par une transaction dans le diagramme. Voir "Les transactions", page 94. Au delà de 6 jours, la réservation est annulée. En deça de 6 jours, le CRM (Customer Relationship Management) est mis à jour et le billet est émis. 87

5 LES OPÉRATIONS Les opérations correspondent aux traitements réalisés dans le workflow. La notation BPMN parle d activités. Vous pouvez décrire une opération par un sous-workflow BPMN. Les opérations décrites se différencient par leur forme. Pour créer une opération : 1. Dans la barre d objets du diagramme, cliquez sur l icône Opération puis cliquez dans le diagramme. 2. Nommez l opération et cliquez sur OK. Pour afficher la forme d une opération décrite : 1. Cliquez avec le bouton droit sur l opération et sélectionnez Formes et détails. 2. Sélectionnez la forme qui affiche un + et cliquez sur OK. Pour relier un sous-workflow à une opération, voir "Relier un sous-workflow à une opération", page 70. 88 MEGA Designer - Integration

Le diagramme de workflow BPMN Les messages LES MESSAGES Les messages représentent les flux circulant au sein du workflow. Il existe quatre types de messages : Type de message Description Forme graphique Message de début Marque le début du workflow. Message intermédiaire Définit un flux au sein du workflow. Message de fin Marque la fin du workflow. Message temporisé Est relié à un temporisateur qui précise à quel moment il est envoyé. Par défaut sont créés des messages de type intermédiaire. Pour représenter les autres types de messages, vous devez sélectionner la forme correspondante dans la fenêtre d affichage du message. Pour ouvrir cette fenêtre : Cliquez avec le bouton droit sur le message et sélectionnez Formes et détails. Contrairement au diagramme de workflow, ce ne sont pas des opérations qui marquent le début et la fin du diagramme mais des messages. Les types de flux Il existe deux types de flux principaux; les flux de communication et les flux de contrôle. Les flux de communication définissent des échanges de messages entre deux objets. Ils sont annexes au déroulement du workflow. Ils sont représentés par des traits en pointillé. 89

5 Les flux de contrôle définissent le séquencement des opérations et donc le déroulement du traitement. Ils sont représentés par des traits pleins. Pour afficher le style de ligne correspondant à un type de flux : 1. Cliquez avec le bouton droit sur le lien et sélectionnez Couleurs et traits. 2. Dans le cadre Trait de la fenêtre qui apparaît, sélectionnez le style de trait et cliquez sur OK. Les autres types de flux sont ceux qui relient des données aux objets du processus, telles que des notes ou des références externes. Ces données n ont pas d impact sur le flot mais fournissent des informations sur la façon dont fonctionne le processus. Le style de trait varie selon le type d objet attaché. Echange entre deux messages Dans un diagramme, il se peut que deux messages se suivent implicitement mais ne soient pas reliés. Par exemple, dans le diagramme de workflow BPMN "Réservation billet", le message "Itinéraires acceptés" est la réponse au message "Itinéraires proposés". Ils sont séparés par un traitement externe représenté par le rôle mais ils se suivent dans le déroulement du workflow. Pour indiquer que le message "Itinéraires acceptés" fait suite au message "Itinéraires proposés" : 1. Dans le diagramme, cliquez sur le bouton de la barre d objets. 2. Cliquez sur le message "Itinéraires proposés" et déplacez la souris jusqu au message "Itinéraires acceptés". L échange apparaît dans le diagramme entre les deux messages. 90 MEGA Designer - Integration

Le diagramme de workflow BPMN Les conditions LES CONDITIONS Les conditions du diagramme de workflow BPMN représentent les points de divergence des flux de contrôle. Dans la fenêtre de propriétés de la condition, vous pouvez indiquer s il s agit d une condition ou d un parallélisme. Dans le cas d une condition, seule une branche sortante peut être choisie parmi les différentes possibles. La notation BPMN parle de Exclusive Gateway (XOR). Dans le cas d un parallélisme, l ensemble des branches sortantes est traité simultanément. La notation BPMN parle de Parallel Gateway (AND). Voir : "Les conditions", page 73. 91

5 LES SYNCHRONISATIONS Les synchronisations représentent des points de convergence des flux de contrôle. La synchronisation peut prendre la forme d une synchronisation (appelée Parallel Gateway dans la notation BPMN) ou d une jonction (Exclusive Gateway). Une synchronisation est un point de regroupement de plusieurs branches du flot de traitement. Il spécifie que l'on attend la fin de tous les traitements regroupés pour passer à la suite. Une jonction est un point de regroupement de plusieurs branches du flot de traitement. Il spécifie que l'on attend la fin d'un des traitements regroupés pour passer à la suite. Pour créer une jonction : 1. Cliquez sur l icône Synchronisation de la barre d objets, puis cliquez dans le diagramme. 2. Nommez la synchronisation et cliquez sur OK. La synchronisation apparaît dans le diagramme. 3. Cliquez avec le bouton droit sur la synchronisation et sélectionnez Propriétés. 4. Cliquez sur l onglet Caractéristiques. 5. Dans le champ Logique en entrée, sélectionnez "Jonction". 92 MEGA Designer - Integration

Le diagramme de workflow BPMN Les rôles LES RÔLES Le rôle permet de représenter les interactions du workflow avec les autres services. Un rôle est un participant à une interaction, un workflow ou une procédure. Il peut en être l'initiateur c'est à dire le demandeur du service ou représenter un sous-traitant réalisant un traitement extérieur au service. Un rôle fait partie intégrante de l'objet qu'il décrit et n'est pas réutilisable. Il peut par la suite être affecté à un acteur interne ou externe à l'organisation ou à un composant informatique. Exemples : Demandeur, voyageur. Dans l exemple ci-dessous, la compagnie aérienne est le rôle qui sous-traite la réservation de billets. 93

5 LES TRANSACTIONS Vous pouvez grouper des opérations dans une transaction. Une transaction permet de réunir plusieurs traitements de données dans une seule unité de travail logique, afin d'assurer la validation de l'ensemble des tâches effectuées par ces traitements ou, au contraire, leur annulation. Ici, le temps entre la demande de facturation et la réception de l accusé de paiement ne doit pas excéder 6 jours : Voir "Les transactions", page 75. 94 MEGA Designer - Integration

Le diagramme de workflow BPMN Ressources des opérations RESSOURCES DES OPÉRATIONS Vous pouvez préciser les ressources affectées aux différentes opérations. Il peut s agir d un acteur ou d une ressource informatique (une application). Pour relier un acteur à une opération : 1. Cliquez sur le bouton Vues de la barre d outils du diagramme. 2. Cochez le champ Acteur et cliquez sur OK. L icône correspondant à cet objet apparaît dans la barre d objets du diagramme. 3. Sélectionnez cette icône puis cliquez dans le diagramme. 4. Dans la fenêtre qui apparaît, nommez l acteur et cliquez sur OK. L acteur apparaît dans le diagramme. 5. A l aide du bouton Lien, reliez l acteur à l opération. 95

5 LES VARIABLES Vous pouvez préciser les variables circulant au sein du workflow BPMN. Voir "Les variables", page 78. 96 MEGA Designer - Integration

6 EXPORT BPEL L outil d'export BPEL4WS de MEGA permet d'exprimer dans un fichier BPEL4WS (version 1.1) un workflow MEGA en en retenant les éléments pertinents pouvant être exprimés en BPEL4WS. Bien que l'échange de modèles ne soit pas la vocation première du langage BPEL4WS (il s'agit à l origine d'un langage d'exécution de processus), l'export BPEL4WS de MEGA peut remplir cette fonction pour satisfaire un usage de plus en plus répandu parmi les acteurs du marché du BPM. Les documents exportés peuvent servir de base à l'élaboration de scripts BPEL exécutables sur un outil moteur de workflow ou un orchestrateur de services Web. Mais les nombreux paramètres nécessaires à l'exécution d'un tel processus n étant pas gérés dans MEGA, ces documents nécessiteront par la suite des adaptations pour convenir à ces outils spécifiques d'exécution du BPEL. Il est vivement conseillé d'accompagner la lecture de ce document de la consultation des spécifications BPEL4WS version 1.1. De même, la connaissance du MétaModèle des workflows MEGA s'avère nécessaire à une bonne compréhension de l'interprétation des objets restitués par l'export en BPEL4WS. "Introduction à BPEL4WS", page 98 "Périmètre fonctionnel de l export BPEL", page 100 "Principes de l export BPEL", page 101 "Exécuter l export BPEL4WS", page 105 "Interprétation des différents éléments définissant la procédure ou le workflow", page 108 "Traitement des noms et valeurs d'objets", page 127 "Contraintes de modélisation - Cas non valides", page 128 "Export vers WebSphere Integration Developer", page 131 97

6 INTRODUCTION À BPEL4WS BPEL4WS L'export BPEL4WS de MEGA se base sur la version 1.1 des spécifications du langage BPEL4WS. BPEL4WS est l'acronyme de Business Process Execution Language for Web Services. C'est un langage XML de description des processus métiers (Business Processes) basé sur les standards WSDL, XML Schema, Xpath. La notion de "processus métier" introduite ici ne correspond pas à celle utilisée dans MEGA. Ici, le processus décrit une succession d'activités d'invocation de composants informatiques; on parle en général d'orchestration. Il s agit des processus de l'informatique, possiblement utilisés dans le cadre de la réalisation d'un "vrai" processus métier. Le langage BPEL4WS introduit deux formes de description des processus : Processus exécutable : modélise le comportement d'un participant dans les relations avec les intervenants du processus. Processus abstrait : décrit un protocole métier sur la base des messages publics échangés entre les différents participants sans montrer leur comportement interne Les processus décrits par BPEL4WS orchestrent les interactions entre chaque partenaire au travers de Services Web, sachant que les possibilités d'extension du langage permettent de prendre en compte d'autres types d'interaction. Le langage BPEL4WS permet de décrire l'état et la logique de déroulement d'un processus BPEL4WS ainsi que les interactions avec les Services Web qui peuvent être soit fournisseurs, soit demandeurs de services auprès du processus BPEL4WS. Dans le reste du document nous utiliserons l'acronyme BPEL comme raccourci de BPEL4WS. Vous pouvez trouver les spécifications 1.1 du langage BPEL4WS à l'adresse suivante : http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ Processus BPEL et Processus MEGA Le terme de processus a dans MEGA un sens bien particulier puisqu'il correspond à un concept du MétaModèle MEGA. Pour plus d informations sur les processus MEGA, voir le guide MEGA Process. Faire correspondre une procédure (processus organisationnel) ou un workflow à un processus BPEL peut prêter à confusion. Il convient que le lecteur connaisse les différences de nature entre les processus décrits dans un document BPEL et ceux définis par MEGA. 98 MEGA Designer - Integration

Export BPEL Introduction à BPEL4WS Ici, le terme "processus BPEL" désigne le concept exprimé dans un document BPEL et que l'on va faire correspondre à une procédure ou à un workflow MEGA. Ce concept est concrétisé dans un document BPEL par la balise <process>. 99

6 PÉRIMÈTRE FONCTIONNEL DE L EXPORT BPEL L'export BPEL de MEGA consiste à exprimer en BPEL les workflows et les procédures MEGA. L'outil assure la description des concepts communs aux workflows MEGA et au langage BPEL d'une part, et aux procédures MEGA et au langage BPEL d'autre part : logique de déroulement du processus BPEL à partir des "activités" BPEL identification des rôles des partenaires (du point de vue BPEL : Services Web) impliqués dans le processus BPEL au travers des appels à ces partenaires identification des messages échangés lors des interactions avec les partenaires au travers des appels L'export BPEL crée des documents conformes au schéma XSD du langage BPEL présent dans les spécifications BPEL4WS version 1.1. L'export BPEL couvre la définition des services (partner link types) et des messages (messages types) à l'aide du langage WSDL, en autorisant la génération d un document WSDL accompagnant le document BPEL créé. Ce document WSDL définit les services Web et les messages. L'export BPEL de MEGA n'a pas vocation à générer des documents BPEL directement exécutables dans un moteur de workflows ou un orchestrateur de services Web. Une adaptation préalable aux caractéristiques techniques de l'outil d'exécution devra être réalisée sur tout document BPEL exporté par MEGA. Dans le cas d une intégration avec le produit IBM Websphere Integration Developer (WID), le fichier BPEL généré contient les éléments nécessaires à l exécution du worflow. Voir "Export vers WebSphere Integration Developer", page 131. L'export BPEL MEGA ne gère pas : la mise en correspondance des partenaires avec des services Web la prise en compte des données utilisées et véhiculées par le processus le détail des variables d état du processus Un document BPEL exporté de MEGA contient uniquement la description du déroulement (l'algorithmique) de la procédure ou du workflow décrit dans MEGA. Les ressources (rôles, acteurs réalisateurs, applications réalisatrices) apparaissent dans le document lorsqu'elles sont utilisées dans le cadre des échanges entre le processus BPEL et les partenaires. 100 MEGA Designer - Integration

Export BPEL Principes de l export BPEL PRINCIPES DE L EXPORT BPEL Concepts MEGA pris en compte par l'export BPEL Parmi les concepts pris en compte par l'export BPEL, certains donnent lieu à des éléments du document BPEL exportés, d autres influent sur la manière dont des éléments connexes sont restitués. Voici la liste des concepts pris en compte ou influençant la génération BPEL : Workflow Procédure (processus organisationnel) Opération Message Rôle Acteur réalisateur Application réalisatrice Echange Condition Parallélisme Synchronisation Jonction Boucle Connecteurs Attente Objets restitués dans le document BPEL exporté Les objets considérés par l'export sont ceux qui font partie de la procédure ou du workflow exporté. La notion de "Faire partie de la procédure ou du workflow" est matérialisée dans le référentiel par l'existence d'un lien de type "Objet dans modèle de procédure" ou "Objet détenu par workflow". Exemple : "Opération dans modèle de procédure", "Opération détenue par workflow" Le fait que les objets apparaissent dans les diagrammes d'une procédure ou d'un workflow n'est pas pris en compte. 101

6 Objets du modèle d'une procédure Les objets suivants sont identifiés par l'export BPEL depuis la procédure par les MetaAssociationEnd indiquées : Opération par la MetaAssociationEnd "Opération détenue" Message par la MetaAssociationEnd "Message détenu" Echange par la MetaAssociationEnd "Echange détenu" Condition par la MetaAssociationEnd "Condition détenue" Parallélisme par la MetaAssociationEnd "Condition détenue" Synchronisation par la MetaAssociationEnd "Synchronisation détenue" Jonction par la MetaAssociationEnd "Synchronisation détenue" Boucle par la MetaAssociationEnd "Boucle détenue" Les objets suivants sont déterminants dans la façon d'interpréter les opérations et les messages mais ne sont pas identifiés par un lien depuis la procédure : Rôle Acteur réalisateur Application réalisatrice Objets du modèle d'un Workflow Les objets suivants sont identifiés par l'export BPEL depuis le workflow par les MetaAssociationEnd indiquées : Opération par la MetaAssociationEnd "Opération détenue" Message par la MetaAssociationEnd "Message détenu" Echange par la MetaAssociationEnd "Echange détenu" Condition par la MetaAssociationEnd "Condition détenue" Parallélisme par la MetaAssociationEnd "Condition détenue" Synchronisation par la MetaAssociationEnd "Synchronisation détenue" Jonction par la MetaAssociationEnd "Synchronisation détenue" Boucle par la MetaAssociationEnd "Boucle détenue" Attente par la MetaAssociationEnd "Attente détenue" Les objets suivants sont déterminants dans la façon d'interpréter les opérations et les messages mais ne sont pas identifiés par un lien depuis le workflow : Rôle Acteur réalisateur Application réalisatrice 102 MEGA Designer - Integration

Export BPEL Principes de l export BPEL Séquence du processus BPEL La séquence du processus BPEL est définie par : Les objets participant à la définition de la séquence : opération, message, échange, condition, parallélisme, synchronisation, jonction, boucle, attente Les liens définissant la séquence entre ces objets Objet de la séquence Objet suivant Par la MetaAssociationEnd Condition Condition Suivante Boucle Opération Synchronisation Boucle suivante Opération suivante Synchronisation suivante Loop Condition Condition itérée Condition Boucle Boucle Opération Opération Synchronisation Condition suivante Boucle itérée Boucle suivante Opération itérée Opération suivante Synchronisation suivante Message Opération Résultat Echange Echange déclenché Opération Condition Condition suivante Boucle Message Opération Synchronisation Attente Boucle suivante Résultat Suivante Synchronisation suivante Attente suivante Synchronisation Condition Condition suivante Boucle Opération Synchronisation Boucle suivante Opération suivante Synchronisation suivante 103

6 Début de la séquence du processus BPEL Le processus BPEL est constitué d'activités (appels d'opérations, branches conditionnelles, etc ) dont une seule constitue l'activité de début de la séquence. Afin de déterminer l'activité de début d'un processus BPEL, l'export recherche les objets sans prédécesseur de la procédure ou du workflow MEGA. Les messages sans prédécesseur sont écartés de l'ensemble des objets candidats à être interprétés comme début du processus BPEL. Dans le cas où un seul objet sans prédécesseur est trouvé, il est restitué dans le document BPEL comme début du processus BPEL : il est restitué par une balise XML contenant le reste de la séquence du processus BPEL. Dans le cas où plusieurs objets sans prédécesseurs sont trouvés, ils sont contenus dans une balise <flow> constituant le début de la séquence du processus BPEL. Ressources Parmi les ressources de la procédure ou du workflow, seules les ressources réalisatrices sont considérées. A partir d'une opération : Acteur par la MetaAssociationEnd "Acteur" Application par la MetaAssoCiationEnd "Application réalisatrice" 104 MEGA Designer - Integration

Export BPEL Exécuter l export BPEL4WS EXÉCUTER L EXPORT BPEL4WS L'export BPEL4WS peut être lancé soit à partir du menu Fichier, soit à partir du menu contextuel disponible sur les workflows ou les procédures MEGA. Pour afficher la fonctionnalité d export, vérifiez que l option correspondante est cochée : Dans MEGA, cliquez sur le menu Outils > Options. La fenêtre des options apparaît. Dépliez le dossier Echange de données > Export > Outils/Format tiers. Dans la partie droite de la fenêtre, cochez l option BPEL. Lancer l export BPEL4WS depuis le navigateur Pour lancer l export depuis le navigateur MEGA : 1. Dans l explorateur MEGA, cliquez sur le menu Fichier > Exporter > BPEL4WS (*.bpel). L assistant d export BPEL apparaît. 2. Dans le champ Objet exporté, indiquez si l objet exporté est une procédure ou un workflow puis cliquez sur le bouton de recherche 3. Dans le champ Nom du fichier créé, indiquez le chemin et le nom du fichier.bpel créé. Par défaut, le fichier porte le nom de l objet exporté. 4. Cliquez sur le bouton Suivant. 5. Déterminez les options d export et cliquez sur le bouton Exporter. 105

6 Une fois l export terminé, un rapport s affiche. Le bouton Rapport d export vous permet de visualiser le détail des objets exportés. Depuis l assistant, vous pouvez également ouvrir le fichier.bpel créé. Options de l export BPEL4WS Lors du lancement de l export, plusieurs options s offrent à vous. Nom du processus BPEL Espace de nommage L'option Nom du processus BPEL permet de spécifier la valeur de l'attribut "name" de la balise <process>. <process name="ncname"...> L'option Espace de nommage permet de spécifier la valeur de l'attribut "targetnamespace" de la balise <process>. <process targetnamespace="uri"...> Processus BPEL abstrait L'option Processus BPEL abstrait permet de spécifier la valeur de l'attribut "abstractprocess" de la balise <process>. Exemple si l option est cochée : <process abstractprocess="yes"> 106 MEGA Designer - Integration

Export BPEL Exécuter l export BPEL4WS Créer les balises <partnerlink> Lorsque l'option Créer les balises <partnerlink> est activée, une balise <partnerlink> est créée pour chaque rôle, acteur ou application MEGA interprétés comme un intervenant dans le processus BPEL décrit. Créer les balises <variable> Lorsque l'option Créer les balises <variable> est activée, une balise <variable> est créée pour chaque message donnant lieu à une variable : attributs "variable", "inputvariable" et "outputvariable" des balises <invoke>, <receive> ou <reply>. Créer le fichier WSDL complémentaire Lorsque cette option est activée, un document WSDL ad hoc est généré. Espace de nommage du WSDL Lorsqu'un document WSDL accompagne le document BPEL créé, cette option permet de préciser le "targetnamespace" du document WSDL. Alias de l'espace de nommage du WSDL Cette option permet de préciser l'alias utilisé dans le document BPEL pour faire référence aux éléments définis dans le document WSDL. <partnerlink name="ticket_booking_airline" partnerlinktype="ws:ticket_booking_airlinelt" partnerrole="airline"/> 107

6 INTERPRÉTATION DES DIFFÉRENTS ÉLÉMENTS DÉFINISSANT LA PROCÉDURE OU LE WORKFLOW Cette partie suppose des connaissances minimales : Du MétaModèle des procédures ou des workflows MEGA (et notamment la représentation graphique des modèles) Du langage BPEL : structure et utilisation des différentes balises définies par le langage Dans les points qui suivent, l interprétation des éléments définissant la procédure ou le workflow est illustrée par les différents cas supportés que l'on peut rencontrer. Ces cas sont présentés sous forme de tableaux. Chacun présente une portion de diagramme MEGA et le résultat correspondant. Les éléments de MEGA figurent dans la colonne de gauche tandis que les résultats se trouvent dans la colonne de droite. Les flèches sans nom correspondent aux liens prédécesseur/successeur : Les flèches avec un nom correspondent aux messages échangés : Il se peut que l'objet origine ou arrivée de la flèche ne figure pas dans la portion de diagramme représentée; cela ne signifie pas qu'il n'y a pas d'objet mais que cet objet n'entre pas en compte dans l'interprétation du cas représenté. Interprétation des procédures et des workflows L'interprétation d'une procédure ou d'un workflow MEGA, dans le cadre de sa restitution en BPEL, donne lieu à un processus BPEL exprimé par une balise <process>. Interfaces et intervenants Un processus BPEL peut être vu comme un service Web orchestrant d'autres services Web appelés "partners" en BPEL. Les interfaces entre le processus BPEL et les services Web intervenants sont appelés des "porttypes". Chaque couple {processus BPEL - partner} définit un "partnerlink" constitué de deux rôles dont chacun est associé à une interface ou "porttype". Au travers de ces interfaces, des services constitués d'opérations sont fournis. Un porttype est : Soit fourni par le processus BPEL (les appels d'opérations sont effectués par un Service Web au processus BPEL) Soit fourni par un service Web (les appels d'opérations sont effectués par le processus BPEL au service Web) L'export BPEL interprète les rôles, les acteurs réalisateurs et les applications réalisatrices comme des intervenants dans le processus BPEL et les fait correspondre aux "partners" BPEL. 108 MEGA Designer - Integration

Export BPEL Interprétation des différents éléments définissant la procédure ou le workflow A chaque rôle, acteur réalisateur ou application réalisatrice, l'export BPEL fait correspondre une interface ou "porttype" identifiée par le nom de l'objet rôle, acteur ou application concaténé au nom du processus BPEL. L'export BPEL prend en charge la restitution de la définition des porttypes et des partnerlinktypes qui s'exprime en WSDL lorsque l'option de création du WSDL est activée. Variables et messages Les données échangées entre le processus BPEL et les intervenants dans le processus sont exprimées à l'aide de variables BPEL. Les variables correspondent à des messages définis en WSDL. Les variables du processus BPEL sont déduites des messages MEGA échangés dans la procédure ou le workflow MEGA exportés. Les données composant les messages ne sont pas gérées par l'export BPEL. L'export BPEL prend en charge la restitution de la définition des messagetypes qui s'exprime en WSDL lorsque l'option de création du WSDL est activée. Interprétation des opérations Fourniture de service/appel de service Les opérations des procédures et des workflows sont interprétées comme des opérations de l'interface correspondant à la ressource réalisatrice de l'opération. Suivant les cas développés ci-dessous, les opérations sont restituées en balises <empty>, <invoke>, <receive> ou <reply>. Une opération MEGA est interprétée dans le cadre de sa restitution en BPEL soit : Comme une opération sollicitée par le processus BPEL auprès d'un service tiers Comme une opération d'un service fourni par le processus BPEL Ainsi, la restitution de l'opération MEGA donne lieu à : Une balise <invoke> dans le cas où l'opération est demandée par le processus BPEL Une balise <receive> ou <reply> dans le cas où l'opération est fournie par le processus BPEL Dans le cas où une opération n'est pas considérée comme réalisée ou utilisée par une ressource (rôle, acteur, application), elle est restituée sous la forme d'une balise <empty>. Dés que l'opération est associée à un acteur réalisateur ou une application réalisatrice, l'opération est interprétée comme une opération appelée par le processus BPEL. La restitution se fait alors sous la forme d'une balise <invoke>. Lorsque l'opération envoie un message vers un rôle ou reçoit un message d'un rôle, elle donne lieu à la fourniture d'une opération par le processus BPEL qui se concrétise par une balise <receive> ou <reply>. 109

6 Les éléments pris en compte pour déterminer la forme de restitution de l'opération en BPEL sont les suivants : Acteur réalisateur de l'opération Application réalisatrice de l'opération Messages déclenchant l'opération Messages résultant de l'opération Rôle intervenant dans un échange de message Opérations et acteurs/applications Une opération donne lieu à une balise <empty> ou <invoke> selon qu'elle est réalisée ou non par un acteur ou une application. <empty name="operation"/> <invoke name="operation" partnerlink="org-unit" porttype="workfloworg-unitpt" operation="operation"/> Les valeurs des différents attributs des balises <empty> et <invoke> sont déduites des éléments suivants : name = nom de l'opération partnerlink = nom de l'acteur ou de l'application porttype = nom du workflow (ou procédure) concaténé avec le nom de l'acteur ou de l'application et suffixé par "PT" operation = nom de l'opération Opérations et messages Les messages évènements (messages reçus et déclenchant l'opération) et les messages résultats (messages émis par l'opération) donnent lieu à l'ajout des attributs "inputvariable" et "outputvariable" dans la balise <invoke> correspondant à une opération. 110 MEGA Designer - Integration

Export BPEL Interprétation des différents éléments définissant la procédure ou le workflow Les messages ne sont pris en compte que sur les opérations réalisées par un acteur ou une application. Dans le cas où l'opération n'est pas associée à un acteur ou une application, celle-ci est restituée par une balise <empty>. <invoke name="operation" partnerlink="org-unit" porttype="workfloworg-unitpt" operation="operation" inputvariable="message1"/> <invoke name="operation" partnerlink="org-unit" porttype="workfloworg-unitpt" operation="operation" outputvariable="message2"/> <invoke name="operation" partnerlink="org-unit" porttype="workfloworg-unitpt" operation="operation" inputvariable="message1" outputvariable="message2"/> Les valeurs des attributs inputvariable et outputvariable sont déduites de la manière suivante : inputvariable = nom du premier message évènement outputvariable = nom du premier message résultat Cas de messages multiples arrivant ou sortant de l'opération Le langage BPEL ne permet pas d'associer à une opération plusieurs messages en entrée ou en sortie. Dans le cas où plusieurs messages résultent d'une opération ou plusieurs messages sont reçus par une opération, un seul de ceux-ci est pris en compte par l'export BPEL. Le message pris en compte est le premier qui apparaît par la MetaAssociationEnd "Résultat" pour les messages émis, et par la MetaAssociationEnd "Evènement" pour les messages reçus. 111

6 Exemple : <invoke name="operation1" partnerlink="org-unit" porttype="worg-unitpt" operation="operation1" outputvariable="message2"/> <flowname="operation1"> <sequence> <invoke name="operation3" partnerlink="org-unit" porttype="worg-unitpt" operation="operation3" inputvariable="message2" outputvariable="message4"/> </sequence> <sequence> <invoke name="operation2" partnerlink="org-unit" porttype="worg-unitpt" operation="operation2" inputvariable="message1" outputvariable="message3"/> </sequence> </flow> <invoke name="operation4" partnerlink="org-unit" porttype="worg-unitpt" operation="operation4" inputvariable="message3"/> Interprétation des messages depuis ou vers les rôles Messages d'opération sans réalisateur Lorsque les messages sont échangés entre un rôle et une opération qui n'est pas associée à un acteur réalisateur ou une application réalisatrice, l'opération exprime l'échange au cours duquel les messages sont adressés depuis ou vers le rôle. Les messages arrivant ou partant de l'opération vers une autre opération sont ignorés. 112 MEGA Designer - Integration

Export BPEL Interprétation des différents éléments définissant la procédure ou le workflow Il en résulte la restitution des cas suivants en BPEL : <receive name="operation" partnerlink="role" porttype="workflowrolept" operation="operation" Variable="m"/> <reply name="operation" partnerlink="role" porttype="workflowrolept" operation="operation" Variable="m"/> <invoke name="operation" partnerlink="role" porttype="workflowrolept" operation="operation" inputvariable="m1" outputvariable="m2"/> Les messages " m-a " et " m-b " sont ignorés. Les valeurs des différents attributs des balises <empty> et <invoke> sont déduites des éléments suivants : name = nom de l'opération partnerlink = nom du rôle porttype = nom du workflow (ou de la procédure) concaténé avec le nom du rôle et suffixé par "PT" operation = nom de l'opération inputvariable = nom du message arrivant vers le rôle outputvariable = nom du message partant du rôle Messages d'opération avec réalisateur Lorsque les messages sont échangés entre un rôle et une opération associée à un acteur réalisateur ou une application réalisatrice, l'opération exprime un service 113

6 rendu par l'acteur réalisateur ou l'application réalisatrice. Les cas correspondants d'échanges de messages entre le rôle et l'opération sont restitués comme suit : Ici, un message est reçu par l'opération en provenance du rôle, puis est traité par l'acteur. Cette situation est traduite en deux activités BPEL, <receive> puis <invoke>. L'attribut inputvariable de la balise <invoke> correspondant au message prend pour valeur le nom du message provenant du rôle. <receive name="message" partnerlink="role" porttype="workflowrolept" operation="message" variable="message"/> <invoke name="operation" partnerlink="org-unit" porttype="workfloworg-unitpt" operation="operation" inputvariable="message"> L'opération nécessite que le message "message" lui soit parvenu avant d'être réalisée. Une balise <receive> est insérée avant la balise <invoke> correspondant à l'opération. <receive name="message" partnerlink="role" porttype="workflowrolept" operation="message" variable="message"/> <invoke name="operation" partnerlink="org-unit" porttype="workfloworg-unitpt" operation="operation" inputvariable="messagea" outputvariable="messageb"/> 114 MEGA Designer - Integration

Export BPEL Interprétation des différents éléments définissant la procédure ou le workflow Le message allant de l'opération vers le rôle est restitué comme un message envoyé vers le rôle après la réalisation de l'opération. <invoke name="operation" partnerlink="org-unit" porttype="workfloworg-unitpt" operation="operation" inputvariable="begin_message" outputvariable="end_message"/> <reply name="m" partnerlink="role" porttype="workflowrolept" operation="message" variable="message"/> Le message 1 est considéré comme étant envoyé avant le message 2. L'opération est réalisée par l'acteur (ou l'application). Les messages "message 1" et "message 2" expriment une requête de la part de l'acteur et la réponse du rôle dans le cadre de l'opération. Les messages "message 1" et "message 2" ne sont pas gérés par le workflow car ils sont interprétés comme étant internes à l'opération : l'opération est déclenchée sur la réception du message "message a " puis envoie une requête via "message 1", attend la réponse puis renvoie un résultat "message b". L'opération est restituée sous forme d'une balise <invoke>. <invoke name="operation" partnerlink="org-unit" porttype="workfloworg-unitpt" operation="operation" inputvariable="messagea" outputvariable="messageb"/> Messages vers Rôle avec Echange Echange représentant la fourniture d'un service Lorsqu'un échange de messages entre des opérations et un rôle est explicitement formalisé par un objet "Echange" et que le message à l'origine de l'échange part du 115

6 rôle vers une opération, l'échange donne lieu à la fourniture d'un service au partenaire représenté par le rôle. Aucun nom n est attribué par défaut aux objets "Echange" ; il faut donc prêter une attention particulière à ces objets dans le cadre de l'export BPEL. L'objet "Echange" est alors restitué sous la forme d'une balise <receive> et d une balise <reply> : <receive name="operation1" createinstance="yes" partnerlink="workflow-3_role" porttype="ws:workflow-3pt" operation="exchange" variable="message_1"/> <empty name="operation_2"/> <reply name="operation_3" partnerlink="workflow-3_role" porttype="ws:workflow-3pt" operation="exchange" variable="message_2"/> Echange représentant l appel d'un service Lorsqu'un échange de messages entre des opérations et un rôle est explicitement formalisé par un objet "Echange" et que le message à l'origine de l'échange part d'une opération vers un rôle, l'échange donne lieu à un appel du service représenté par le rôle. L'objet "Echange" est alors restitué sous la forme d'une balise <invoke> : <invoke name="operation_1" partnerlink="workflow-2_role" porttype="ws:rolept" operation="exchange" inputvariable="message_1"/> <empty name="operation_2"/> 116 MEGA Designer - Integration

Export BPEL Interprétation des différents éléments définissant la procédure ou le workflow Restitution des éléments algorithmiques Conditions Une condition est restituée par une balise <switch>. Chaque branche de la condition est restituée dans une balise <case>. <empty name="operation1"/> <switch name="condition"> <case condition="predicate1"> <empty name="operation2"/> </case> <case condition="predicate2"> <empty name="operation3"/> </case></switch> Expression des conditions Pour chaque branche conditionnelle, la condition est exprimée dans l'attribut "condition" de la balise <case>. L'expression de la condition est déduite comme suit : Attributs MEGA renseignés L'attribut "Corps d'expression" de la condition et l'attribut " Prédicat " des liens de séquence sont spécifiés. Seul l'attribut "Corps d'expression" de la condition est spécifié. Seul l'attribut "Prédicat" du lien de séquence de l'élément suivant la condition est spécifié. Restitution de l'expression de la condition <case condition="expressionbody = Predicate"> <case condition="expressionbody"> <case condition="predicate"> Branches conditionnelles Lorsque toutes les branches conditionnées sont rassemblées, le bloc de condition est refermé. Les opérations suivantes sont en dehors de la condition. Dans ce cas, les balises correspondant aux éléments suivants sont restituées après la balise <switch>. 117

6 La réunion de deux branches conditionnelles est prise en compte quel que soit l'élément sur lequel ces branches se referment (synchronisation, opération, etc.). <empty name="operation0"/> <switch name="condition"> <case condition="predicate1"> <empty name="operation1"/> </case> <case condition="predicate2"> <empty name="operation2"/> </case> </switch> <empty name="operation3"/> 118 MEGA Designer - Integration

Export BPEL Interprétation des différents éléments définissant la procédure ou le workflow Tant que toutes les branches conditionnelles d'une condition ne sont pas réunies, les éléments inclus dans chaque branche sont restitués dans la balise <case> correspondante. Si la réunion de quelques branches conditionnelles ne correspond pas à la réunion de toutes les branches conditionnelles, les éléments suivants sont dupliqués dans les balises <case> correspondant à ces branches conditionnelles. <empty name="operation0"/> <switch name="condition"> <case condition="predicate1"> <empty name="operation1"/> </case> <case condition="predicate2"> <empty name="operation2"/> <empty name="operation4"/> </case> <case condition="predicate3"> <empty name="operation3"/> <empty name="operation4"/> </case> </switch> <empty name="operation5"/> Parallélismes Un parallélisme est restitué par une balise <flow>. Chaque branche du parallélisme est restituée dans une balise <sequence>. 119

6 L'export BPEL identifie des parallélismes dans les cas suivants : Une synchronisation dont l'attribut "Logique en sortie" à pour valeur "parallélisme" Une opération qui a plusieurs éléments suivants immédiats <empty name="operation0"/> <flow name="p"> <sequence> <empty name="operation2"/> </sequence> <sequence> <empty name="operation1"/> </sequence> </flow> Branches parallèles Chaque branche parallèle est restituée dans une balise <sequence>, enfant de la balise <flow>. 120 MEGA Designer - Integration

Export BPEL Interprétation des différents éléments définissant la procédure ou le workflow Les branches parallèles sont constituées des éléments suivant le parallélisme jusqu'à la réunion de deux ou plusieurs branches. <empty name="operation0"/> <flow name="p"> <sequence> <empty name="operation2"/> </sequence> <sequence> <empty name="operation1"/> </sequence> </flow> <empty name="operation3"/> <empty name="operation0"/> <flow name="p1"> <sequence> <empty name="operation1"/> </sequence> <sequence> <empty name="operation2"/> <flow name="p2"> <sequence> <empty name="operation3"/> </sequence> <sequence> <empty name="operation4"/> </sequence> </flow> </sequence> </flow> <empty name="operation5"/> Lorsque qu'une partie des branches parallèles est réunie sans que toutes les branches du parallélisme ne soient réunies, l'export BPEL identifie un parallélisme indépendant du parallélisme principal pour la réunion partielle des branches 121

6 parallèles. Le "sous-parallélisme" devient un élément d'une branche du parallélisme principal. <empty name="operation0"/> <flow name="p1"> <sequence> <empty name="operation1"/> </sequence> <sequence> <flow> <sequence> <empty name="operation2"/> </sequence> <sequence> <empty name="operation3"/> </sequence> </flow> <empty name="operation4"/> </sequence> </flow> <empty name="operation5"/> Une branche d'un parallélisme principal peut contenir un sous-parallélisme dont les branches se réunissent avec des ou les branches du parallélisme principal. <empty name="operation0"/> <flow name="p1"> <sequence> <empty name="operation1"/> </sequence> <sequence> <empty name="operation2"/> <flow name="p2"> <sequence> <empty name="operation3"/> </sequence> <sequence> <empty name="operation4"/> </sequence> </flow> </sequence> </flow> <empty name="operation5"/> Boucles Objets Boucles Les objets boucles sont restitués sous la forme d'une balise <while>. 122 MEGA Designer - Integration

Export BPEL Interprétation des différents éléments définissant la procédure ou le workflow Les éléments contenus dans la boucle sont ceux de la séquence commençant à l'élément itéré par la boucle. Cette séquence constitue la branche itérée de la boucle. Les éléments contenus dans la boucle sont restitués dans la balise <while>. Un seul élément itéré peut être associé à la boucle par les MetaAssociationEnd suivante : Elément itéré (élément initial de la séquence d'itération) Opération Condition Boucle MetaAssociationEnd Opération itérée Condition itérée Boucle itérée La condition de bouclage est exprimée dans l'attribut "condition" de la balise <while>. L'expression de la condition est déduite de l'attribut "Corps expression" de la boucle ou de l'attribut "Nom" si l'attribut "Corps expression" n'est pas renseigné. <empty name="operation0"/> <while name="while" condition="expressionbody"> <empty name="operation1"/> <empty name="operation2"/> </while> <empty name="operation3"/> Boucles déduites Lorsque l'export détecte un chemin d'exécution bouclant, celui-ci est restitué dans une balise <while>. Les boucles gérées, pour être cohérentes, doivent comporter un objet condition là où le chemin de la boucle s'écarte du chemin "séquentiel" d'exécution. 123

6 La condition d'exécution de la boucle est déduite de l'attribut "Corps expression" de l'objet condition et de l'attribut "Prédicat" du lien de séquence de l'élément suivant la condition : Attributs MEGA renseignés L'attribut "Corps d'expression" de la condition et l'attribut " Prédicat " du lien de séquence de l'élément suivant la condition sont spécifiés. Seul l'attribut "Corps d'expression "de la condition est spécifié. Seul l'attribut "Prédicat" du lien de séquence de l'élément suivant la condition est spécifié. Restitution de l'expression de la condition <while name="condition" condition="expressionbody = Predicate"> <while name="condition" condition="expressionbody"> <while name="condition" condition=" Predicate"> 124 MEGA Designer - Integration

Export BPEL Interprétation des différents éléments définissant la procédure ou le workflow <empty name="operation0"/> <empty name="operation1"/> <empty name="operation2"/> <while name="condition" condition="expressionbody = Predicate1"> <empty name="operation3"/> <empty name="operation1"/> <empty name="operation2"/> </while> <switch name="condition"> <case condition="expressionbody =Predicate2"> <empty name="operation4"/> </case> </switch> <empty name="operation0" /> <empty name="operation1" /> <empty name="operation2" /> <while name="condition" condition="expressionbody = Predicate1"> <empty name="operation3" /> <empty name="operation1" /> <empty name="operation2" /> </while> <empty name="operation4"/> 125

6 Attentes Un objet attente est restitué sous la forme d'une balise <wait>. Seul l'attribut "Nom" de l'objet Attente est exploité et est restitué dans l'attribut "name" de la balise <wait>. <empty name="operation0"/> <wait name="wait"/> <empty name="operation1"/> 126 MEGA Designer - Integration

Export BPEL Traitement des noms et valeurs d'objets TRAITEMENT DES NOMS ET VALEURS D'OBJETS Langue d'export L'export BPEL restitue les valeurs d'attributs traduisibles dans la langue courante. Il est donc nécessaire de spécifier la langue courante dans laquelle vous souhaitez extraire les valeurs des attributs à exporter ("Nom", "Corps d'expression", "Prédicat", etc). Pour définir la langue courante : Dans le navigateur MEGA, cliquez sur le menu Outils > Langue puis sélectionnez la langue en question. Filtrage des caractères Dans le langage BPEL, les types des valeurs des attributs de balises ne permettent pas de restituer telles quelles les valeurs des attributs des objets exportés. En effet, MEGA autorise dans les valeurs d'attributs l'utilisation de caractères qui ne sont pas admis dans les valeurs des attributs des balises du langage BPEL. Le filtrage des caractères est effectué pour que le document exporté se conforme au schéma XSD du langage BPEL. Les attributs restitués par l'export MEGA sont des types "NCName", "QName" ou "string" comme le précisent les spécifications "BPEL4WS" et "XSD Schema" : NCName ::= (Letter '_') (NCNameChar)* NCNameChar ::= Letter Digit '.' '-' '_' CombiningChar Extender QName ::= (Prefix ':')? LocalPart Prefix ::= NCName LocalPart ::= NCName Char::= #x9 #xa #xd [#x20-#xd7ff] [#xe000-#xfffd] [#x10000-#x10ffff] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ string ::= set of finite-length sequences of characters (as defined in [XML 1.0 (Second Edition)]) that match the Char production from [XML 1.0 (Second Edition)] Le filtrage s'effectue comme suit : pour les noms (NCName et QName) : tout caractère non alphanumérique est remplacé par un caractère '_' pour les chaînes (string) : tout caractère ne correspondant pas à la règle "Char" décrite ci-dessus est éliminé Ainsi, par exemple, le nom d'une opération se nommant "Vérifier les résultats (2)" sera restitué en "Vérifier_les_résultats 2_" car les caractères '(' et ')' sont interdits. 127

6 CONTRAINTES DE MODÉLISATION - CAS NON VALIDES Utilisation des boucles Si un élément d'une séquence itérée d'une boucle a pour élément suivant un élément qui fait également partie d'une séquence externe à la boucle, l'élément suivant est ignoré dans la séquence itérée. Dans l'exemple suivant, l'opération "o3-2" n'est pas restituée dans la balise <while> correspondant à la Boucle "c2". Détection des bouclages Un bouclage conduit à la détection d'une séquence itérée qui ne contient que les éléments contenus dans le bouclage. 128 MEGA Designer - Integration

Export BPEL Contraintes de modélisation - Cas non valides Dans l'exemple suivant, la balise <while> correspondant au bouclage ne contient pas la restitution de la balise correspondant à l'opération "o3" : Cohérence des bouclages La cohérence des bouclages est dépendante du type de l'élément détecté comme début du bouclage et des éléments intervenant dans la séquence bouclante. L'élément détecté comme origine du bouclage est le premier élément ayant plusieurs éléments suivants et dont une séquence des suivants revient sur un élément déjà parcouru. Cet élément doit être une Condition. 129

6 Une séquence bouclante doit éviter de contenir des éléments ayant plusieurs suivants. La présence d'un Parallélisme dans une séquence bouclante est fortement déconseillée. 130 MEGA Designer - Integration

Export BPEL Export vers WebSphere Integration Developer EXPORT VERS WEBSPHERE INTEGRATION DEVELOPER Avec l outil d export BPEL, vous pouvez exporter des workflows modélisés dans MEGA puis les importer dans WebSphere Integration Developer d IBM. Pour obtenir un workflow exécutable dans WID, il convient d exporter la description de ce workflow en BPEL ainsi que la définition des interfaces en WSDL. Pour cela : 1. Dans l explorateur MEGA, cliquez sur le menu Fichier > Exporter > BPEL4WS (*.bpel). L assistant d export BPEL apparaît. 2. Dans le champ Objet exporté, indiquez que l objet exporté est un workflow puis recherchez le workflow en question. Exemple de workflow dans MEGA : 3. Dans le champ Nom du fichier créé, indiquez le chemin et le nom du fichier.bpel créé. Par défaut, le fichier porte le nom de l objet exporté. 4. Cliquez sur le bouton Suivant. 131

6 5. Dans les options d export, cochez "Créer le fichier WSDL complémentaire" et "Créer les balises <variable>". L option "Créer les balises <partnerlink>" est cochée automatiquement. 132 MEGA Designer - Integration

Export BPEL Export vers WebSphere Integration Developer 6. Cliquez sur le bouton Exporter. Deux fichiers sont générés; un fichier BPEL et un fichier WSDL. Afin d obtenir le workflow complet, vous devez importer ces deux fichiers dans WID. Pour plus de détails, voir la documentation de WID. Exemple de workflow importé dans WID : 133

6 134 MEGA Designer - Integration

7 INTERFACE HOMME-MACHINE Il est possible de décrire les interfaces reliant les services ou les opérations avec l extérieur. Cette description s effectue dans un diagramme d IHM. Créer un diagramme D IHM Pour créer le diagramme d IHM d un service : 1. Cliquez avec le bouton droit sur le service en question. 2. Sélectionnez Nouveau > Interface Homme-Machine. Le diagramme d IHM s ouvre dans la fenêtre d édition. Ouvrir un diagramme d IHM Vous pouvez ouvrir un diagramme d IHM : A partir du menu contextuel du service ou de l opération décrit(e). A partir du navigateur MEGA, dans la fenêtre de navigation Diagrammes. Exemple d interface Prenons l exemple du service "Réservation Avion". Pour accéder à son diagramme d IHM : 1. A partir de la fenêtre de navigation Accueil, dépliez les bibliothèques "Alizés Grand Bleu", puis "Activités séjours et voyages" et "Réservation". 2. Dépliez le dossier "Application" et dépliez l application "Réservation en ligne Alizés". 135

7 3. Cliquez avec le bouton droit sur le service "Réservation Avion" et sélectionnez Interface Homme-Machine. Le diagramme d IHM s ouvre dans la fenêtre d édition. L interface se présente sous forme d une boîte de dialogue, dans laquelle doivent être renseignés différents champs : La ville de départ La ville d arrivée La date du vol Un bouton annule la demande, un autre ouvre une seconde interface. Dessiner l IHM Le diagramme d IHM vous permet de dessiner l interface de l opération ou du service. 136 MEGA Designer - Integration

Interface Homme-Machine Elément D IHM Un certain nombre de boutons vous permettent de définir l apparence de l interface : Champ de texte Liste Bouton radio Case à cocher Etc. Pour créer un élément : 1. Dans la barre d objets du diagramme, sélectionnez le bouton correspondant à l élément voulu puis cliquez dans le diagramme. 2. Dans la fenêtre qui apparaît, tapez le nom de l élément. 3. Cliquez sur OK. Vous pouvez également cliquer sur le bouton Elément d IHM type de l élément dans sa fenêtre de propriétés. et indiquer le Evénement d IHM Vous pouvez relier un événement à un élément d IHM. Dans notre exemple, le bouton "Proposer des vols" est relié à un événement, qui, lorsqu il est actionné, ouvre une autre interface. Un événement d IHM est une action effectuée par un utilisateur au moyen d'une touche de clavier ou d'un clic de souris, qui se définit par les renseignements associés à cette action. Créer un événement d IHM Pour créer un événement : 1. Cliquez sur le bouton Evénement d IHM puis cliquez dans le diagramme. 2. Saisissez le nom de l événement et cliquez sur OK. 137

7 Type d événement Il existe différents types d événement. Il peut s agir : D un clic sur un bouton D une entrée dans un champ Etc. Pour spécifier le type d un événement : 1. Ouvrez la fenêtre de propriétés de l événement. 2. Cliquez sur l onglet Caractéristiques. 3. Dans le champ Evénement type d IHM, cliquez sur la flèche puis sur Rechercher Evénément type d IHM. La fenêtre de sélection apparaît. 4. Cliquez sur Chercher. La liste des types d événement apparaît. 5. Sélectionnez le type voulu et cliquez sur OK. Relier l événement à un élément Pour relier l événement à un élément, deux possibilités s offrent à vous : Sélectionnez l événement dans le diagramme et faites-le glisser sur l élément. Ou ouvrez la fenêtre de propriétés de l événement et renseignez le champ Elément d IHM. 138 MEGA Designer - Integration

8 TRAITEMENTS EN CHAÎNE MEGA vous permet de décrire dans des diagrammes l enchaînement de traitements automatisés. Dessin de chaîne Le Dessin de chaîne permet de représenter l'organisation d'une chaîne en termes de steps (étapes du traitement). Un job est un ensemble de traitements informatiques exécutés par un ordinateur sans intervention humaine, généralement la nuit ou le week-end. Un step est une étape élémentaire d'exécution d'un job batch qui consiste à lancer l'exécution d'un programme avec les paramètres appropriés. Les éléments figurant sur un dessin de chaîne sont le step, le programme, le fichier logique, le fichier physique, la table et la base de données. Un fichier logique est la description des données permanentes nécessaires en lecture ou en écriture au fonctionnement d'un programme. Un fichier physique est l'ensemble des enregistrements des données effectivement lues ou écrites sur le disque dur de l'ordinateur lors d'une exécution d'un programme. La dissociation des fichiers logiques et physiques permet d'organiser les dessins de chaîne de différentes façons. 139

8 Ainsi dans l'exemple suivant, le job de prise en compte des mouvements de province dans la mise à jour du fichier des articles a été représenté de deux manières différentes. Planning d exploitation L enchaînement de traitements automatisés peut également être décrit dans un diagramme de planning d exploitation. Un planning d'exploitation définit l'ensemble des traitements informatiques à effectuer sur une ou plusieurs machines pendant une période de temps donnée. 140 MEGA Designer - Integration

Traitements en chaîne Les symboles graphiques associés au segment Job sont différenciés selon que les occurrences sont reliées ou non au planning décrit. 141

8 142 MEGA Designer - Integration

9 GLOSSAIRE Le glossaire présente les principaux concepts utilisés dans MEGA Designer - Integration. adaptateur L adaptateur désigne le point de contact entre le gestionnaire de messages et l'application, vu du point de vue de l'application. Lorsque l'application transmet le document au gestionnaire, l'adaptateur contient les informations nécessaires pour accéder au gestionnaire. Lorsque c'est le gestionnaire qui transmet le document à l'application, l'adaptateur contient les informations pour être appelé du gestionnaire. boucle Une boucle est un ensemble d'instructions dont l'exécution est répétée jusqu'à la vérification d'un critère donné ou l'obtention d'un certain résultat. broker Le broker est l'élément de regroupement et de classification des flux de données. Il permet de regrouper les événements, les messages et les interactions qui participent au même projet. broker manager condition connecteur Le Broker Manager est un outil d'importation de données de MEGA vers Biztalk. Il permet de visualiser la configuration Messaging Biztalk et de naviguer entre les différents concepts. Une condition précise l'état dans lequel un objet doit se trouver pour qu'une action puisse être effectuée. Le connecteur désigne le point de contact entre le gestionnaire de messages et l'application, du point de vue du gestionnaire. Le document peut provenir ou être à destination d'un adaptateur, d'un emplacement ou d'une file de messages. Un connecteur ne peut avoir qu'une transformation de données. 143

9 contenu Le contenu désigne le contenu d'un message ou d'un événement indépendamment de sa structure. Cette dernière peut être représentée par un schéma XML relié au contenu. Un contenu peut être utilisé par plusieurs messages puisqu'il n'est pas associé à un émetteur et à un destinataire. Il ne peut y avoir qu'un contenu par message ou par événement, mais un même contenu peut être utilisé par plusieurs messages ou événements. dépendance: La dépendance est une relation d utilisation unidirectionnelle entre des éléments. La relation de dépendance relie des éléments au sein d un même modèle. emplacement événement événement d IHM L emplacement correspond à l emplacement du document envoyé ou reçu par le connecteur. Cet emplacement peut être une adresse électronique (protocole SMTP), une adresse Internet (protocoles HTTP et HTTPS) ou un fichier. Un événement représente un fait ou une action se produisant dans le système, par exemple - modification de l'adresse client. Il est géré par un broker. Pour signaler qu'elle peut produire un événement, une application déclare qu'elle le publie. Si elle est intéressée par un événement, une application déclare qu'elle y souscrit. Un événement d IHM est une action effectuée par un utilisateur au moyen d'une touche de clavier ou d'un clic de souris, qui se définit par les renseignements associés à cette action. fichier logique Un fichier logique est la description des données permanentes nécessaires en lecture ou en écriture au fonctionnement d'un programme. fichier physique file de messages interaction job Un fichier physique est l'ensemble des enregistrements des données effectivement lues ou écrites sur le disque dur de l'ordinateur lors d'une exécution d'un programme. Une file de messages est une file d'attente dans laquelle est envoyée ou d'où provient le document. Une interaction représente un contrat conclu dans un contexte précis entre des entités autonomes à l'intérieur ou à l'extérieur d'une entreprise. Ces entités peuvent être des acteurs, des applications, des activités, des processus de l'entreprise, ou des acteurs externes à l'entreprise. Le contenu de ce contrat est décrit par un protocole d interaction. Un job est un ensemble de traitements informatiques exécutés par un ordinateur sans intervention humaine, généralement la nuit ou le week-end. 144 MEGA Designer - Integration

Glossaire jonction message parallélisme planning d exploitation protocole rôle schéma service step synchronisation Une jonction est un point de regroupement de plusieurs branches du flot de traitement. Il spécifie que l'on attend la fin d'un des traitements regroupés pour passer à la suite. Un message représente un flux d'informations à l'intérieur de l'entreprise ou entre l'entreprise et ses partenaires. Il est échangé entre applications, acteurs internes et externes, et outils. Il porte un contenu décrivant les informations échangées. Un parallélisme est le traitement simultané de différentes parties d'un processus. Un planning d'exploitation définit l'ensemble des traitements informatiques à effectuer sur une ou plusieurs machines pendant une période de temps donnée. Un protocole est un modèle de contrat entre des entités organisationnelles. Ce contrat est décrit par les messages échangés entre deux rôles (par exemple acheteur et vendeur). Un rôle est un participant à une interaction, un workflow ou une procédure. Il peut en être l'initiateur c'est à dire le demandeur du service ou représenter un sous-traitant réalisant un traitement extérieur au service. Un rôle fait partie intégrante de l'objet qu'il décrit et n'est pas réutilisable. Il peut par la suite être affecté à un acteur interne ou externe à l'organisation ou à un composant informatique. Exemples : Demandeur, voyageur. Un schéma XML est un modèle permettant de décrire la structure de l'information contenue dans un document XML. Un service est l'élément de découpage d'une application qui est mis à la disposition de l'utilisateur final de cette application dans le cadre de son travail. Un step est une étape élémentaire d'exécution d'un job batch qui consiste à lancer l'exécution d'un programme avec les paramètres appropriés. Une synchronisation est un point de regroupement de plusieurs branches du flot de traitement. Il spécifie que l'on attend la fin de tous les traitements regroupés pour passer à la suite. 145

9 transaction transformation de données (data transform) Une transaction permet de réunir plusieurs traitements de données dans une seule unité de travail logique, afin d'assurer la validation de l'ensemble des tâches effectuées par ces traitements ou, au contraire, leur annulation. Une transformation de données indique la transformation d'un document dans un autre format. Cette transformation intervient au moment de l'envoi ou de la réception d'un document par le gestionnaire de message. workflow Un workflow est la représentation exécutable d'un processus métier. Les éléments formalisant un workflow sont les suivants : le début et la fin du workflow, les opérations à accomplir durant le traitement, les éléments algorithmiques d enchaînement des opérations, les rôles interagissant avec les opérations et l allocation des ressources aux opérations. 146 MEGA Designer - Integration

INDEX A abonnement message.......................... 18 adaptateur classe............................ 25 définir............................ 24 emplacement....................... 26 file de messages..................... 26 adresse EAI arrivée......................... 24 départ 24 analyser modèle EAI......................... 38 application créer............................. 13 diagramme d environnement............ 13 rechercher......................... 13 arrivée EAI adresse......................... 24 B B2B.................................9 bibliothèque créer............................. 61 interaction......................... 61 protocole.......................... 61 boucle workflow.......................... 71 bouton radio IHM.............................137 BPMN.............................. 85 condition.......................... 91 diagramme de workflow............... 86 jonction.......................... 92 message.......................... 89 opération......................... 88 ressource....................... 95 parallélisme....................... 91 rôle............................. 93 synchronisation..................... 92 type de flux........................ 89 broker construire diagramme................ 16 créer............................ 18 diagramme de broker................. 11 événement........................ 31 interaction........................ 33 relier............................ 18 C chaîne dessin...........................139 classe adaptateur........................ 25 composite interaction........................ 52 condition workflow.......................... 73 workflow BPMN..................... 91 connecteur adaptateur........................ 24 créer............................ 20 paramétrer........................ 22 147

10 ressource connectée.................. 23 rôle.............................. 20 transformation des données............. 22 contenu message EAI............................ 36 message (MEGA Integration)............ 18 contrôle implémentation..................... 43 méthodologie....................... 38 contrôler modèle EAI........................ 29 F file messages..........................26 finition EAI.............................. 30 rapport............................ 30 flux BPMN.............................89 D I départ EAI adresse......................... 24 dessin de chaîne..................... 139 diagramme d environnement application......................... 13 diagramme d IHM.................... 135 diagramme de broker méthodologie....................... 12 diagramme de workflow créer.......................... 67, 86 données transformer........................ 22 E EAI................................. 9 finition............................ 30 moteur........................... 11 échange message.......................... 90 échec transaction workflow........................ 77 emplacement adaptateur......................... 26 espace de nommage................ 14, 71 événement broker............................ 31 IHM............................. 137 insérer............................ 14 exploitation planning......................... 140 IHM............................... 135 diagramme........................ 135 élément.......................... 137 événement........................ 137 interaction........................... 51 bibliothèque........................61 broker............................ 33 choix exclusif....................... 54 composite..........................52 créer.............................58 début.............................54 diagramme de broker.................14 fin...............................54 jonction........................... 54 parallèle........................... 54 propriétés..........................58 protocole..........................59 rôle.............................. 59 service............................ 62 sous-interaction..................... 60 interface homme-machine............. 135 J job dessin de chaîne.................... 139 planning d exploitation................ 140 jonction interaction......................... 54 workflow BPMN...................... 92 148 MEGA Designer - Integration

L workflow BPMN..................... 88 lien BPMN............................. 89 P M Message............................ 55 message abonnement........................ 18 broker............................ 30 contenu EAI............................ 36 contenu (MEGA Integration)............. 18 diagramme de broker................. 14 échange........................... 90 flux (MEGA Integration)................ 12 mode d échange..................... 18 mode question-réponse................ 18 publication......................... 18 structure.......................... 18 workflow.......................... 71 workflow BPMN...................... 89 modèle EAI contrôler.......................... 29 moteur EAI.......................... 11 N nom objet.......................... 14, 71 nommage espace......................... 14, 71 O objet nom........................... 14, 71 opération variable workflow........................ 79 workflow.......................... 69 parallélisme workflow BPMN..................... 91 planning exploitation........................140 protocole interaction............................. 59 publication message.......................... 18 R rapport finition........................... 30 ressource workflow BPMN..................... 95 ressource connectée connecteur........................ 23 rôle interaction........................ 59 workflow.......................... 69 workflow BPMN..................... 93 S service............................. 16 insérer........................... 17 sous-interaction...................... 60 sous-workflow variable.......................... 81 step dessin de chaîne....................139 structure message.......................... 18 synchronisation workflow BPMN..................... 92 149

10 T transaction workflow.......................... 75 créer.......................... 76 échec.......................... 77 exception....................... 76 minutée........................ 75 transformer données connecteur...................... 20 définition....................... 22 U un................................. 54 V variable sous-workflow...................... 81 workflow.......................... 78 vérifier modèle EAI........................ 37 W workflow boucle............................ 71 BPMN............................ 86 condition.......................... 73 contexte d utilisation.................. 66 diagramme..................... 67, 86 message.......................... 71 opération.......................... 69 relier au service..................... 82 rôle.............................. 69 transaction......................... 75 variable........................... 78 150 MEGA Designer - Integration