Plateformes d’échanges et d’intégration

Présentation au sujet: "Plateformes d’échanges et d’intégration"— Transcription de la présentation:

1 Plateformes d’échanges et d’intégration
Principes appliqués d’urbanisation A.Dewavrin - juin 2011

2 Sommaire Urbanisation des échanges Découplage des applications
Outils de découplage Intégration d’une nouvelle application : méthodes classiques ou découplées Typologies d’échanges Fichiers ou messages Interactif (WS) ou messages Grille de classification Exemples typiques Middleware Rôles respectifs de l’ETL, de l’ESB et du MOM Outils Middleware du marché Echanges par files de messages (MessageQueues) Files d’attente et scalabilité Files d’attente : alertes à mettre en place Files d’attente : traitement des rejets Implémentation Historiser les échanges Utiliser un sas d’entrée pour les intégrations en base bien nommer les files et répertoires Gérer les KO techniques : Middleware transactionnel Bonnnes pratiques et pièges à éviter

3 Urbanisation des échanges

4 Découplage des applications
Application A Application B Point à Point :  pour connecter 10 applications ensemble il faut 90 traductions Évolution d’une application = impact sur N autres applications Application C Application D Application A Application B Découplé :  pour connecter 10 applications ensemble il faut 10 mappings Evolution locale = moins d’impacts Apporte de l’agilité au SI ESB / ETL Application C Application D

5 Outils de découplage des applications
L’ESB et l’ETL permettent de s’affranchir des formats propriétaires Il font le mapping entre les formats des applications via un format pivot (typiquement un xml contenant les données métier de l’entreprise) Application A Application B ESB (Enterprise Service Bus) ou ETL (Extract Transform Load) Format PIVOT <Client> <nom>Dupont</nom> <prenom>Jean</prenom> </Client> Person = « Dupont, Jean » Nom: Dupont Prénom: Jean

6 Intégration d’une nouvelle application : méthodes classiques ou découplées
Méthode urbanisée : Découplage et composition Nouvelle appli A Appli A Appli B Nouvelle appli Middleware (ESB, ETL) BDD A BDD BDD B Nouvelle appli Appli A On doit faire une nouvelle application devant accéder aux données de A et B, et à une fonctionnalité de A A Appli B Appli A Appli B BDD A BDD B BDD A BDD B

7 Typologie d’échanges : Batchs, fil de l’eau, interactif

8 Fichiers ou messages ? Et aussi : le premier message est pris en compte instantanément

9 (MQSeries, JMS, activeMQ etc.)
WS ou messages ? Application A Application B Synchrone « interactif » WS WS Question et timeout Besoin info Information Réponse ou rien Application A événement asynchrone « fil de l’eau » messages File En WS, l’appli qui a la connaissance n’est pas à l’initiative de l’échange. C’est comme si elle répondait par téléphone En messages, l’appli qui a la connaissance est aussi à l’initiative de l’échange. C’est comme poster une lettre Application B Conséquence sur B MOM (MQSeries, JMS, activeMQ etc.)

10 Grille de classification
Mode Fichier Messages WS volume oui non propagation info différé instantané assurance de prise en compte non (timeout) attente d'un résultat

11 Exemples typiques d’échanges découplés
Cas 1 : Echange fichier + ETL ETL Application Source Application Destination Batch ordonnancé Fichier dans un répertoire transformation Fichier dans un répertoire Cas 2 : Echange base + ETL BDD Source ETL BDD Dest transformation Cas 3 : WS via ESB ESB Application Cliente Web service transformation Cas 4 : Messages avec transformation et/ou routage File aval de messages Application Destination 1 ½ Flux ESB … File amont de messages ½ Flux Application Source ½ Flux transformation File aval de messages Application Destination N Autres cas : Il y a beaucoup d’autres combinaisons moins fréquentes que les 4 cas présentés. Il y a par exemple des consommations de fichiers par l’ESB avec sortie en messages ou vice-versa, des accès en base, des WS…

12 Middleware

13 Rôles respectifs de l’ETL, de l’ESB et du MOM
ETL : validation et transformation BDD Source BDD Dest Partage Fichiers MOM (transport/persistance des messages applicatifs) Application Appelante / productrice Fichiers Application Appelée /consommatrice Messages Messages WS WS File Amont File Aval ESB : validation et transformation

14 Outils Middleware du marché
Pattern Middleware Noms Fichier / base / batchs ETL ODI (Oracle Sunopsis) Talend (Open Source) Synchrone Asynchrone rapide (= fil de l’eau = messages) ESB Tibco OSB (Oracle) webMethods Jboss ESB Talend Persistence du fil de l’eau MOM Apache Active MQ IBM MQ Series JMS (monde J2EE) MSMQ (monde .net / MS) Spécifique

15 Echanges par files de messages (« au fil de l’eau »)

16 Files d’attente et scalabilité
Application productrice Application productrice Messages SQL MOM sas thread conso Select for update thread conso Select for update thread conso Update flag=tid where in select limit 1 Puis conso where tid thread conso Update flag=tid where in select limit 1 Puis conso where tid thread conso thread conso thread conso bdd bdd

17 Files d’attentes : Alertes à mettre en place
Producteur Producteur Producteur file file file rejets Seuil Normal Dépassé : Le nb de messages dépasse les pics observés en temps normal (ex: 1000) capacité 70% Un nombre immense de message est en file Consommateur Consommateur Consommateur Alerte équipe infra (Alerte sur capacité, rare. Capacité = plusieurs jours On change la capacité et/ou on arrête le producteur) Alerte responsable application consommatrice (L’appli consommatrice ne consomme pas ou bien pas assez vite. On vérifie l’application, ses bases, ses MDB, ses services… et on surveille l’évolution) Alerte études Un message (ou plus) a été rejeté. Typiquement pas urgent, traité le lendemain

18 Fil de l’eau, traitement des rejets
Application productrice Infrastructure MOM (messages) (transport/persistance en base des messages applicatifs) Application consommatrice Messages Messages rejets File Amont File Rejets File Aval Infrastructure ESB (validation et transformation des formats des messages applicatifs) ESB

19 Bonnes pratiques

20 Historiser les échanges
ETL Infrastructure d’historisation ESB traces Visu File ou sas Base 31 tables

21 Utiliser un sas d’entrée pour les intégrations en base
Données entrantes Application IHM, batchs etc. Tables de l’application Sas sans contrainte (FK, unicité, etc.) Rejets Outil de réintégration

22 Bien nommer les files et répertoires
ESB ETL ... Application A Répertoire s ou files Pivot Application B Répertoires ou files Application N ½ Flux PRODUCTEUR.COMSOMMATEUR.CATEGORIE.OBJETMETIER Applications. PAIE STOCK ESB MDM COMPTA Domaine métier. Achats Offre Commercialisation Logistique: Marketing Order Management Référentiels Relation Cliente Support Entreprise Transverse Objet transporté. Commande client Facture Mouvement de stock MAJ offre

23 Gérer les KO techniques : Middleware transactionnel
Application source A Rejeu appliA.appliB.Marketting.MaJ_RJT appliA.appliB.Marketting.MaJ Application Destinataire B Check Formel (XSD…) Rejet Rollback Checks Fonctionnels Accès fichier traitements Accès BDD Accès WS Accès fichier Envoi Message Echec

24 Bonnes pratiques / pièges à éviter
Pattern Détail Risque à ne pas faire Inventorier les flux Renseigner leur volumétrie estimée, leur criticité, leur délai, l’attente d’une réponse… On choisira la mauvaise implémentation technique Documenter les flux Partager en un lieu unique la description métier, la version en production, les impacts en cas de blocage (qui prévenir) Le métier, les études et la production ne parlent pas le même langage Créer une équipe dédiée Une équipe flux fera -l’urba -la classification -le dev des flux -le support technique aux projets -des codes d’explemple Les projets négligent leurs échanges et travaillent en pensant « application, fichiers et batchs ». Pas de scalabilité, pas de reprise. Connaissance pointues impossibles à partager Versionner les flux Considérer un flux comme un application, avec ses compatibilités Les maj créent des pannes fonctionnelles Les projets gèrent leurs rejets Même si un flux entrant peut être considéré comme impropre du fait de l’envoyeur, le destinataire doit le prendre en charge : le mettre en rejet ou le supprimer Engorgement du système d’échanges Séparer les flux Une file par objet métier, REST plutôt que soap Confusion en cas de panne, adhérences empêchant les évols