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

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

Urbanisation des échanges

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

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

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

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

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

(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.)

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

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…

Middleware

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

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

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

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

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

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

Bonnes pratiques

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

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

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

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

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