Dans un contexte IT, les applications communiquent entre elles des informations au travers d’échanges.
Nous allons voir dans cet article l’organisation, quelques concepts d’échange et l’importance de la cartographie des échanges d’un Système d’Information. 

Tout d’abord, un échange doit respecter des patterns d’architecture définis par les architectes d’entreprise.
Il doit être implémenté avec une technologie d’échange : ESB (webMethods, webLogic,…), API Manager (webMethods, Apigee,…) , Event and Streaming Platform (Kafka), File Transfer (Traffic, Transfiles,…).
Un autre point important est qu’un échange doit être lié à un objet d’échange (quel type de donnée est échangé? par exemple une commande, un produit, un fournisseur).
L’ensemble de ces éléments peuvent être référencés dans un référentiel unique au sein du Système d’Information et disponible à l’ensemble des collaborateurs (architectes d’entreprise, architectes d’échanges, product owner, développeurs, …).

Real-time ou batch?

• Echange real-time : Lorsqu’il y a une donnée à transférer, cela doit prendre un délai court entre l’entrée et la sortie de l’échange. La quantité de données à transférer par événement ne doit pas excéder quelques que Kbytes.
• Echange batch : il s’agit d’un échange déclenché une à deux fois par jour (par un scheduler par exemple). La quantité de données peut être grande pour une seule exécution (de 1 Mbytes à plusieurs GBytes).

Vue logique ? vue physique ?

• Vue logique d’un échange : Définition de l’échange souvent créé manuellement suite à la phase de cadrage d’un projet.
• Vue physique d’un échange : Instanciation d’un échange sur un environnement donné. Utilisé quand plusieurs environnements sont utilisés (Par exemple l’échange peut être installé sur un environnement de DEV, de TEST, de PRE-PRODUCTION et de PRODUCTION pour une ou plusieurs plateformes d’une Business Unit).

Un échange a donc par défaut une seule vue logique mais peut avoir N vues physiques en fonction du nombre d’environnements et de l’organisation IT.

Types d’échange

Plusieurs types d’échange sont disponibles :

• Type demi-flux : L’échange est composé de demi-flux logiques autorisés à transporter, transformer les données d’une applications vers un objet d’échange, appelé aussi pivot ou canonique (et vice versa).  Comme vu précédemment, ce demi-flux logique n’est pas une instance de demi-flux physique. Si un demi-flux est instancié pour deux Business Units, il n’y a qu’un seul demi-flux logique. Pour chaque demi-flux (entrant ou sortant) il est important de définir les connecteurs dans le cadre de demi-flux avec des processus de transformation (REST en entrée, SOAP en sortie par exemple). Ces connecteurs doivent être compatibles avec le type d’échange et les pattern d’architecture du SI.
• Type flux : Il est composé de flux sans transformation de la donnée et la plupart du temps en point à point (P2P Transfile, Traffic, …). 
• Type gateway : C’est un échange qui utilise une Proxy Gateway pour des APIs synchrone ou asynchrone au niveau du middleware (API Manager, Data Streaming Platform par exemple).

Nommage des échanges

Dans le cadre d’une identification efficace des échanges et pour conserver une cohérence globale dans les échanges, un nommage normé est conseillé. Par exemple, une mise en majuscule, sans caractères spéciaux, sans espace …

En plus de cela, le nom de l’échange doit faire référence aux informations transférées dans l’échange et le contexte d’utilisation (dans quel cas d’usage ou de process il est utilisé).

Exemple : CUSTOMERORDERCANCELED, l’échange concerne l’objet CUSTOMERORDER (la commande client) et le contexte est son annulation.

Un objet d’échange peut donc être contextualisé dans plusieurs échanges.

Gestion des versions

Concernant les versions des échanges (peu importe la technologie utilisée, ESB, API synchrone ou asynchrone), il est conseillé d’augmenter le chiffre de la version majeure lorsque le modèle de l’objet échangé ne peut assurer la compatibilité ascendante.

De plus, il est recommandé de ne pas garder plus de deux versions majeures en même temps sur les environnements de production. Pour cela, les consommateurs doivent être informés dès que la nouvelle version majeure est disponible afin de migrer au plus tôt vers celle-ci. Une deadline de fin de disponibilité de version peut aussi leur être communiquée pour qu’ils puissent synchroniser leur roadmap par exemple.

Périmètre de la cartographie des échanges

Le périmètre de la cartographie des échanges peut évoluer en fonction de la taille et de la complexité des applications et du Système d’Information. Celui-ci peut-être de type inter-applicatif (parfois intra-applicatif, mais de classe privée). Si le SI présente des grandes interactions, il est conseillé de plutôt privilégier la cartographie des échanges inter-applicatif pour ne pas noyer le référentiel d’échanges privés (on référence uniquement les échanges qui ont des données formatées et qui ont vocation à être partagées avec d’autres applications).

Avantages de la mise en place d’une bonne cartographie : 

• Maîtrise des échanges.
• Rapidité d’identification des échanges et donc de la réutilisabilité.
• Analyse d’impact simplifiée (pour les demi-flux mais aussi pour la structure des objets échangés).
• Validation du respect des patterns d’architecture de l’entreprise.

Enfin, afin de maintenir un bon niveau de qualité de la donnée, il est recommandé de maximiser l’automatisation de la cartographie notamment à partir des plateformes physiques.
Cela demande malgré tout un effort de mise en place au niveau des différentes technologies d’échanges et du référentiel pour améliorer leur inter-opérabilité (introspection des serveurs ESB, topic publique pour récupérer les mises à jour d’une API depuis l’API Manager et ainsi pouvoir mettre à jour automatiquement ces infos dans le référentiel).