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 sau- raient 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
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
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
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
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
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
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
I NTRODUCTION
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.
Introduction
C ONVENTIONS 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.
Les commandes sont présentées ainsi : Fichier > Ouvrir.
Les noms de produits et de modules techniques sont présentés ainsi : MEGA.
Remarque très importante à prendre en compte pour ne pas commettre d’erreurs durant une manipulation.
C RÉ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
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
E TAPE 1 : D IAGRAMME 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
1
Pour insérer les échanges entre les différentes applications, utilisez les boutons correspondants :
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".
Message
Interaction
Evénement
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.
1
E TAPE 2 : I NSÉ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.
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".
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
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.
1
E TAPE 3 : C RÉ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 et cochez le champ
"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.
1
E TAPE 4 : P ARAMÉ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.
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.
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.
3. Cliquez sur l'onglet Adaptateur.
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.
Adaptateur classe
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.
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.
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.
1
C ONTRÔ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.
2
F INITION 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
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.
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 lui- mê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 lui- mê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
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.
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
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".
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.
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.
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.
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.
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.
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".
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.
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.
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".
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.
