Master Infrastructures applicatives et Génie Logiciel

Université de Lille

Evolution du modèle de la plateforme d’échanges

de données d’un groupe

Bastien Fauchart

2018 – 2019

Référent universitaire : Yves ROOS

Référent d’entreprise : François-Xavier RIVA

Sommaire

Remerciement ........................................................................................................................ 1

I. Zoom sur CGI et le CS échanges ...................................................................................... 2

1.2. CGI ................................................................................................................................ 2

1.2. Le CS échanges .......................................................................................................... 3

II. ABC, un groupe grandissant aux besoins multiples ...................................................... 4

2.1. Des besoins en solutions informatiques .................................................................... 4

2.2. Une solution basique pré-EAI ..................................................................................... 5

III. La solution EAI, début et fin .............................................................................................. 7

3.1. L’EAI, une solution temporaire ................................................................................... 7

3.2. Les problèmes de l’EAI ............................................................................................. 11

IV. Les objectifs des équipes du CS échanges ................................................................ 12

4.1. Appropriation et conception de l’ESB Webmethods .......................................... 12

4.2. Mise à disposition des outils transverses aux équipes .......................................... 15

4.3. Migration depuis l’EAI ............................................................................................... 16

4.4. Accompagnement du client .................................................................................. 16

V. Plan de mise en œuvre de l’évolution de l’ESB .......................................................... 18

5.1. Les équipes et leur rôle ............................................................................................. 18

5.2. Le modèle en V du projet ESB ................................................................................. 19

5.3. Cheminement d’un ticket au CS Build .................................................................. 20

VI. Où en sommes-nous aujourd’hui ? .............................................................................. 22

6.1. Les résultats de l’ESB.................................................................................................. 22

6.2. Vers l’ETL ? .................................................................................................................. 22

VII. Conclusion ...................................................................................................................... 23

1

Remerciements

Tout d’abord, un grand merci à François-Xavier Riva, mon tuteur durant

ces deux années, pour m’avoir enseigné les bonnes pratiques à appliquer au

sein d’un projet aussi vaste que celui-ci, ainsi qu’à Fabien Crespel, expert

technique, pour l’aide qu’il m’a apportée quant à la compréhension

technique et au retraçage de l’histoire du projet.

J’aimerais aussi remercier tous les membres du CS échanges pour

m’avoir intégré au sein de l’équipe et pour avoir toujours été présents pour

répondre à mes questions.

J’adresse également ma gratitude à tout le corps enseignant du Master

Informatique et IAGL qui m’a donné les clés pour devenir un bon

développeur.

Enfin, je remercie toutes les personnes qui ont relu ce mémoire afin de

m’aider à prendre du recul sur la rédaction de celui-ci.

2

I. Zoom sur CGI et le CS échanges

1.2. CGI

Fondée en 1976 par Serge Godin et André Imbeau à Québec, CGI

(Conseillers en Gestion et Informatique) est à l’époque une petite entreprise

de conseil en technologies de l’information.

Rapidement devenue un leader mondial dans l’offre de services et de

conseils en informatique, l’entreprise a grandi notamment grâce à ses

rachats.

A l’heure actuelle, CGI possède des bureaux sur les 6 continents ainsi

que de multiples clients. Elle est présente sur des domaines tels que l’industrie,

la distribution, les transports, les télécoms, etc., et offre des services comme le

conseil, l’intégration et l’outsourcing.

De 2017 à 2019, dans le cadre de ma formation en alternance, j’ai signé

un contrat de professionnalisation pour intégrer l’entreprise CGI dont

l’agence CGI Nord est spécialisée dans la distribution.

Ainsi, d’avril 2017 à septembre 2019, j’ai pu évoluer au sein de l’équipe

CS échanges (Centre Service échanges) qui travaille depuis 2011 sur un projet

d’intégration d’une plateforme ESB pour un client qui, dans un souci de

confidentialité, ne sera pas mentionné dans ce mémoire.

Nous appellerons donc ce client « groupe ABC».

L’ESB, ou Enterprise Service Bus, est un outil middleware qui sert à répartir le

travail entre les composants connectés d’une application. Grâce à cela, une

application a la capacité de se connecter au bus et de s’abonner aux

messages en fonction de certaines règles.

3

1.2. Le CS échanges

Le CS échanges a été fondé en 2016 suite à l’accumulation de projets

au sein du groupe ABC.

Les premiers intervenants de l’équipe sont arrivés vers 2011 pour mettre

en place l’ESB et tester sa fiabilité. Un des objectifs de l’ESB était de remplacer

la solution de l’époque devenue obsolète.

Chaque ressource naviguait entre les locaux des différents projets sur

lesquels elles étaient affectées et le siège régional du groupe ABC. Chaque

personne était donc habilitée à travailler sur un seul et même projet du groupe

afin de bien pouvoir répondre aux attentes de l’équipe interne à celui-ci.

Ce n’est donc qu’à partir de 2016 que les membres CGI qui travaillaient

sur ce projet ESB se sont réunis pour former le CS échanges au sein de

l’agence CGI Nord.

Durant toute la période d’avril 2017 à maintenant, j’ai donc travaillé au

sein de cette équipe sur le développement de flux de données à l’aide de

différentes technologies que nous étudierons dans une autre partie.

4

II. ABC, un groupe grandissant aux besoins

multiples

Le groupe pour lequel nous travaillons est un géant qui œuvre dans le

domaine de la distribution et qui a connu une grande croissance durant cette

dernière décennie. Il collabore désormais avec plusieurs sociétés de

distribution du même domaine et a ainsi pu s’étendre dans le monde.

2.1. Des besoins en solutions informatiques

Une telle structure requiert des solutions informatiques pour faire

communiquer les applications et les BU du groupe.

Une application est un logiciel possédé par une entreprise. Cela peut être,

par exemple, le site web de l’enseigne, le compte client ou le logiciel de

gestion des stocks.

Une BU (Business Unit) est représentée, dans le projet, comme une entité

propre à une entreprise du groupe et à un pays.

Sa dénomination se fait en fonction de l’enseigne et du pays dans laquelle

elle exerce son activité. (Par exemple, l’entreprise XY en RUssie sera la BU

RUXY.)

Une BU a ses propres environnements de recette, de pré-production et de

production ainsi que ses propres équipes.

Le groupe ABC a besoin de faire communiquer les applications de ses

entreprises entre elles, parfois même entre les BU. Pour cela, elle a besoin de

solution SOA.

La SOA (pour Service Oriented Architecture) est un concept d’échange et de

partage inter-application mis en œuvre à l’aide de services.

5

2.2. Une solution basique pré-EAI

Avant 2001, le groupe ABC était de taille raisonnable, sans concept de

BU. Elle n’avait pas besoin de solution complexe pour faire communiquer ses

applications.

Les entreprises du groupe devaient elles-mêmes développer des

interfaces spécifiques à chaque application et les connecter point-à-point.

Plusieurs problèmes se sont alors posés :

La complexité du modèle. En effet, à chaque ajout d’application, le

nombre de liens se multiplie. Sur un modèle où chaque application

doit se connecter à toutes les autres, le nombre total de liens est la

somme de 1 à n-1 avec n étant le nombre d’applications. En résulte

un réseau complexe appelé « modèle spaghetti » (cf fig 1).

Fig 1- le modèle « spaghetti »

La flexibilité du modèle. A chaque lien tracé, au moins deux

interfaces sont créées pour que l’application source et l’application

cible comprennent les données échangées. Lors d’une évolution

des données qu’une application du modèle utilise, il faut aussi faire

évoluer les interfaces impactées par ce changement. Tout cela rend

le modèle difficilement adaptable et résistant aux évolutions.

6

Le coût de maintenance. L’infrastructure étant complexe, les coûts

engendrés par sa maintenance augmentent de façon

exponentielle.

Cette solution était en place avant 2001 et donc adaptée à la croissance du

groupe à cette époque. Mais ABC a dû trouver une solution plus flexible et

moins coûteuse en terme de maintenance pour faire communiquer ses

applications.

7

III. La solution EAI, début et fin

Comme la solution de base était inadaptée à la croissance du groupe,

ABC a opté pour la construction d’un EAI.

3.1. L’EAI, une solution temporaire

Avant de posséder un ESB, ABC utilisait un EAI (Enterprise Application

Integration) pour que ses applications échangent leurs données.

Les éditeurs œuvrant dans le domaine de l’EAI proposent des logiciels

pour construire des échanges entre des applications n’ayant rien à voir

ensemble. L’éditeur choisi par ABC a été SeeBeyond.

L’appellation « EAI » désigne autant une offre logicielle que les projets

d’intégration d’applications.

Etabli en 2001, l’EAI du groupe ABC répondait au problème posé à

cette époque : intégrer les applications du groupe à une plateforme pour

qu’elles puissent communiquer entre elles. Le groupe étant de taille modérée,

l’EAI semblait être la solution : facilité à atteindre rapidement ses objectifs,

livraison garantie, simplification des traitements asynchrones, accès aux

sources de données, flexibilité, réutilisation des données dans d’autres

applications, etc.

Aussi, cette solution permet de résoudre un des plus grands problèmes

posés à l’époque : l’envoi de données à plusieurs applications de façon

synchrone.

Là où l’ancienne solution permettait d’envoyer des données depuis une

application vers une seule autre, l’EAI rend possible l’alimentation de plusieurs

applications de sortie avec seulement un envoi de données depuis une

application d’entrée.

8

Fig 2 – Fonctionnement de l’EAI

9

Comme nous pouvons le voir sur ce schéma (cf. fig 2 p.8), cette

technologie permet aux échanges de se décomposer en « demi-flux » : le

demi flux d’entrée connecte l’application d’entrée à l’EAI, et le demi-flux de

sortie connecte l’EAI aux applications de sortie.

L’EAI se charge de récupérer dans la table d’événement les nouvelles

lignes ainsi que les données qui lui sont associées dans la base (ou le serveur

FTP) de l’application d’entrée ; ces données sont appelées Objet Métier

Spécifique.

Un Objet Métier est un concept qui permet de décrire les entités manipulées

par les acteurs dans le cadre de la description d’un métier. Un Objet Métier

Spécifique, ou OMS, est un objet métier spécifique à une application.

Par exemple, l’OMS d’une application qui gère les stocks est un ensemble de

données qui décrit la mise à jour des stocks d’un article.

Ensuite, l’étape de la transformation débute : l’OMS est transformé en

Objet Métier Générique.

Un Objet Métier Générique, ou OMG, est un Objet Métier qui regroupe toutes

les données que les OMS qui pourraient en découler peuvent utiliser.

Cette transformation est exécutée grâce à un processus de mapping.

Ce mapping est commandé par le client qui fournit les informations au

développeur sur la manière de transformer les données d’un OMS vers un

OMG.

Cet OMG est ensuite copié et redirigé vers autant de mappings qu’il

existe d’applications de sortie, pour une fois de plus transformer les données

contenues dans l’OMG en un OMS propre à l’application de sortie. Ces

mappings sont, eux aussi, commandés par le client.

Ci-dessous (cf. fig 3 p.10), un schéma simplifié de l’EAI et de ses

applications : il permet de distinguer les demi-flux qui lient les applications à

l’EAI. Notons le fait qu’un demi-flux n’a pas de sens de transmission des

données, car une application d’entrée peut être une application de sortie, et

inversement.

10

fig 3 – EAI simplifié

Cependant, cette communication n’était effective qu’en batch avec

un traitement par jour.

Le traitement des données en batch est une manière de traiter des données

par « lot ». Les lignes/fichiers s’accumulent sur une table/serveur FTP jusqu’à ce

que le trigger capture un événement et que l’EAI se charge de récupérer ce

lot de données en rapport avec l’événement stocké.

De 2001 à 2010, l’EAI SeeBeyond n’intégrait que des flux FTP/S et BDD et

le groupe ABC voulait se diriger vers l’intégration de flux en temps réel ainsi

que vers des flux utilisant des web services (SOAP, REST). Cette solution n’était

donc plus adaptée. C’est à ce moment que ABC s’est rapproché de CGI pour

obtenir des conseils et former une équipe pour développer une solution.

11

3.2. Les problèmes de l’EAI

Comme dit plus tôt, l’EAI SeeBeyond n’était plus adapté à la structure

des échanges de données du groupe ABC, et cela pour plusieurs raisons.

Le fait que l’EAI ne supporte pas le temps réel est le principal problème

reproché à l’EAI vers 2011. L’EAI fonctionne en batch, avec un processus qui

vérifie toutes les X secondes (une fois par jour pour l’EAI de ABC) si la table des

événements a reçu des nouvelles données. Le lot détecté est traité et envoyé

aux applications de sortie par la suite. Le support du temps réel permettrait

notamment de répondre aux nouvelles attentes autour du cross-canal,

direction que le groupe ABC a pris récemment. Le fait de pouvoir implémenter

des échanges de type temps réel permettrait, par exemple, à un client de

commander sur le site et de retirer son article 2 heures après en magasin, puis

de retrouver sa facture sur le site Internet juste après son paiement.

L’EAI SeeBeyond était trop ancien car il ne supportait pas les

technologies Java Messaging Service, SOAP et REST, ce qui rendait impossible

la communication de certains échanges qui existaient déjà ou allaient exister.

Suite à ces constatations, ABC et CGI ont opté pour le remplacement

de l’EAI par un ESB qui, lui aussi, fonctionne avec des demi-flux.

12

IV. Les objectifs des équipes du CS échanges

Au départ, le groupe ABC a fixé des objectifs à atteindre à destination

de son équipe interne et du CS échanges.

4.1. Appropriation et conception de l’ESB

Webmethods

La première étape pour l’équipe CGI et ABC a été de s’approprier la

technologie utilisée par l’ESB : WebMethods de Software AG.

WebMethods est un logiciel permettant l’intégration des applications d’une

entreprise. Il se sert notamment de la technologie Java et utilise le format XML

pour la description de chaque service créé. Il a permis de développer la

solution ESB.

Il fallait donc comprendre cette technologie destinée seulement aux

entreprises, et cette compréhension collective engendrait un besoin de

conventions et de règles. Pour chaque demi-flux, un package webMethods

est créé, ce qui permet d’appliquer des conventions de nommage pour que

chaque membre de toutes les équipes puisse se repérer. Cela permet aussi

de pouvoir déposer ses packages sur un logiciel de gestion de version : un

SVN.

SVN (ou SubVersioN) est un logiciel de gestion de versions, il permet de

déposer les packages depuis un serveur d’intégration et ainsi de pouvoir les

versionner.

En 2011, seules deux ressources étaient présentes sur le projet pour

accompagner le client dans cette transformation. Cette étape requiert un

POC.

13

Un POC (ou Proof Of Concept) est une manière de prouver qu’une solution est

adaptée au besoin en implémentant de manière rapide une partie de ses

fonctionnalités.

Deux premiers demi-flux communiquant par dépôt de fichiers sont

implémentés autour d’un format pivot, une application d’entrée et une

application de sortie.

Fig 4 - POC

Un an plus tard, la solution est validée et une phase pilote commence :

deux BU vont devoir utiliser l’ESB pour leurs échanges, une de France et une

autre d’Espagne. A ce moment-là, quatre internes ABC et deux CGI mènent

ces projets de la conception jusqu’en production. Ce sont les premiers

véritables flux à utiliser l’ESB pour communiquer.

Les échanges de ces deux BU sont principalement en temps réel, ils

utilisent les technologies Java Messaging Service, REST, SOAP, ou demandent

un traitement de fichier immédiat. Cette demande a été le début de l’ESB tel

qu’on le connaît actuellement :

14

Fig 5 – L’ESB de ABC

15

Sur le schéma ci-dessus (cf fig 5 p14), nous pouvons remarquer que les

échanges par fichier en batch et en temps réel ne diffèrent pas

conceptuellement. En effet, seuls changent la fréquence d’activation de

l’échange ainsi que le volume de données traité.

Les échanges batch fichier découpent le lot de données en record, ce

qui permet de traiter les OMS unitairement, tandis que les échanges temps

réel fichier traitent le fichier en une seule fois.

A la manière de l’EAI, chaque application de sortie possède un

mapping qui lui est propre.

Les applications communiquent indirectement avec le Broker de l’ESB.

Un Broker est un intermédiaire entre deux processus. Dans le cas de notre ESB,

c’est une interface intermédiaire qui reçoit ou envoie des messages sous

format XML vers des processus.

Voyant le succès de l’ESB, plusieurs projets viendront demander leur

intégration.

Pour faciliter l’appropriation de la technologie webMethods et

industrialiser le processus de vie d’un demi-flux, des outils transversaux aux

équipes sont créés.

4.2. Mise à disposition des outils transversaux aux

équipes

Une des missions affectées par ABC était de fournir différents outils pour

pouvoir industrialiser et faciliter les processus de développement, de test, de

livraison et d’installation :

- ABC Utils (cf. annexe 1) est un outil qui permet de connaître quels packages

sont installés et quelles propriétés leur sont associées sur un serveur donné.

- Le monitor (cf. annexe 2) est un outil répertoriant, sur un serveur d’intégration,

tous les flux disponibles. Ils peuvent être exécutés à partir de l’interface web.

Nous y analysons les traces de toutes les exécutions qui ont eu lieu durant une

période donnée. Une première version a été développée avec GWT (Google

Web Toolkit) pour ensuite être refondue avec Angular JS et Bootstrap.

- Le SVN ABC, comme dit précédemment, est un outil de dépôt de packages

propre à chaque serveur et permet le versionning des demi-flux.

16

- Le Batch Repository (cf. annexe 3) est un outil qui permet de construire les

différents éléments dont un demi-flux batch aurait besoin : son connecteur

(FTP/SFTP/Oracle/etc.), la BU sur lequel il sera effectif, le pattern du fichier de

sortie s’il génère un fichier ainsi qui le dossier dans lequel il sera stocké, etc.

Ces éléments sont contenus dans ce qu’on appelle un Référentiel Batch qui

peut lui-même être soumis à un build dans l’optique de le livrer.

- CGICodeReview (cf. annexe 4) est un outil utilisé par les membres du CS

échanges. Il permet d’analyser le code contenu dans un package afin de

détecter les mauvaises pratiques et le non-respect de certaines conventions.

- Flow Unit (cf. annexe 5) est un outil permettant de tester automatiquement les

demi-flux. A chaque création/évolution d’un demi-flux batch, les cas de test

sont créés/mis-à-jour pour vérifier que le demi-flux génère effectivement les

données attendues par le client.

Tous les outils n’étaient pas disponibles au début du projet. Certains,

comme Flow Unit, sont apparus vers 2017. L’essentiel étant présent, la

migration des échanges depuis l’EAI pouvait commencer.

4.3. Migration depuis l’EAI

A partir de 2014, la migration des échanges depuis l’EAI démarre. La

charge de travail étant assez importante, le nombre de ressources sur le projet

a augmenté.

Etant donné que les échanges EAI sont des flux batch, le framework

batch a été le socle des développements de cette migration. Beaucoup

d’évolutions ont été demandées sur ce framework pour que toutes les

fonctionnalités soient implémentées.

Ce sont donc 700 demi-flux pour plus de 1500 échanges qui devaient

migrer sur l’ESB ; migration qui prit fin en février 2015. Par la suite, les équipes

du CS échanges ont quitté les bureaux d’ABC et se sont réunies à l’agence

CGI Nord sans pour autant perdre de vue un élément important de leur

mission : l’accompagnement du client.

4.4. Accompagnement du client

Un des objectifs fixés par le client est l’apport d’assistance de la part de

CGI. En effet, notre équipe doit avoir la capacité d’analyser les problèmes et

les besoins de l’équipe interne à ABC par le biais de tickets.

17

Un schéma de résolution des problèmes a été fixé.

Tout d’abord, il faut vérifier si le projet nous a bien fourni les outils

nécessaires à l’analyse (données qui provoquent une erreur, identité de la

trace qui pose problème, nom de l’application, etc.).

Ensuite, nous devons être capables de reproduire le problème sur nos

environnements de développement. Il est possible qu’il ne soit reproductible

que sur les environnements de recette, c’est pour cela que nous,

développeurs, y avons tout de même accès.

Si le problème vient de nous (non-respect de la spécification donnée

par le projet), nous sommes dans l’obligation de développer une nouvelle

version du package où le bug est localisé. Dans le cas contraire, nous

préconisons au projet de créer un nouveau ticket dans lequel il demandera

une évolution du demi-flux tout en nous fournissant une nouvelle spécification.

Mais l’accompagnement du client ne se limite pas qu’aux tickets de

bug, puisqu’une équipe au sein du CS échanges œuvre pour résoudre les

problèmes qui interviennent dans les environnements de production.

Elle dispose d’outils pour traquer sur chaque BU les défauts de

performance ou les traces tombées en erreur. Chaque problème est

répertorié et envoyé aux projets en question afin qu’ils puissent demander de

nouvelles versions des demi-flux incriminés.

Ces outils sont développés par une équipe au sein du CS échanges,

cette même équipe qui fait évoluer les frameworks et les outils mis à disposition

des développeurs et des équipes client.

Ce fonctionnement entre les équipes est le même que celui actuel, ce

qui permet d’assurer un plan de mise en œuvre de l’évolution de l’ESB.

18

V. Plan de mise en œuvre de l’évolution de l’ESB

Pour faciliter l’évolution de l’ESB ainsi que des outils, plusieurs équipes au

sein du CS échanges ont été formées.

5.1. Les équipes et leur rôle

L’intervention de CGI au sein du projet ESB du groupe ABC a plusieurs

aspects. Comme vu précédemment, il existe une équipe chargée d’observer

les différents comportements des échanges présents sur toutes les BU afin de

pouvoir signaler à ABC et aux équipes du projet possédant l’échange tout

problème potentiel (erreur, performances, etc.) ; cette équipe est nommée le

CS Run.

L’équipe responsable des outils qu’utilisent le CS échanges et les

équipes clients se nomme le CS EO (Expertise Outillage). Elle est en charge de

développer et de faire évoluer ces différents outils en accord avec ceux qui

l’utilisent et le client. Il est souvent demandé aux ressources à qui un outil est

adressé de soumettre des idées au CS EO afin de le faire évoluer. Cette

équipe ne peut travailler efficacement qu’avec la participation des

utilisateurs et non qu’avec les décisions du client.

L’équipe CS Build est l’équipe dans laquelle j’ai été intégré. Elle est en

charge de développer les demi-flux demandés par le client. Chaque

demande de création ou d’évolution d’un demi-flux est commandée via un

ticket Redmine (application web de ticketing). Elle est aussi responsable des

demandes de correction de bug ou d’assistance au client. Une autre partie

du CS Build est présente chez le client, cette partie réceptionne nos livraisons,

les installe en environnement UAT (User Acceptance Test) et teste leur bon

fonctionnement. Elle est souvent désignée comme la partie Front du CS Build.

Et pour finir, il nous faut compter sur l’équipe Flow Unit qui est en charge

de la création des campagnes de test Flow Unit.

19

5.2. Le modèle en V du projet ESB

Le projet ESB utilise un modèle bien connu des grandes entreprises de

services informatique, le modèle en « V » :

Fig 5 – modèle du projet ESB

Tout d’abord, les projets du groupe expriment un besoin (un demi-flux

par exemple). Leurs équipes internes se chargent de créer une spécification

fonctionnelle de leur besoin.

Cette spécification fonctionnelle est transmise aux équipes

d’architectes présentes sur le site ABC et rédigent une spécification technique

qui est elle-même soumise au CS Build.

C’est à ce moment que démarre le développement, et le CS Build

estime le coût en UO de la demande.

Une UO (ou Unité d’œuvre) est une unité utilisée pour déterminer l’effort et le

temps qu’une demande va coûter au centre de services mobilisé. Ce nombre

d’UO est ce que le client va devoir payer au centre de services.

20

Le nombre d’UO fixé, le développement suivi des tests est pris en charge

par le même développeur. Une fois ces phases terminées, le développeur livre

la demande au Front afin qu’ils puissent installer et tester le demi-flux sur les

environnements de recette.

La phase de recette terminée, le demi-flux est envoyé au architectes

pour que ces derniers puissent vérifier s’il correspond bien aux attentes

fonctionnelles du projet. Si c’est le cas, le demi-flux poursuit son chemin sur les

environnements de pré-production et de production avec l’accord des

équipes de l’enseigne concernée.

5.3. Parcours d’un ticket au CS Build

Lorsque le ticket est créé sur Redmine et affecté à notre équipe, un

ticket est créé sur notre outil de ticketing interne, Jira.

S’il s’agit d’une demande de création ou d’évolution d’un demi-flux,

nous devons analyser la spécification pour estimer le nombre d’UO. S’il s’agit

d’une demande de résolution de bug, nous devons déterminer s’il s’agit

véritablement d’une erreur de notre part, ou d’une erreur venant de la

spécification fournie, ; dans le deuxième cas, le ticket sera transformé en

demande d’évolution du demi-flux spécifié.

Une fois ce chiffre estimé, le développement du demi-flux peut

commencer, suivi des tests.

Avant de livrer la demande, nous devons tout d’abord passer des

étapes de vérification :

Le rapport de CGICodeReview est ajouté aux livrables du demi-flux,

s’il contient des erreurs, une justification est rédigée.

Une fiche de test est écrite afin de de décrire les tests que l’on a

effectué pour valider notre développement. Elle est ajoutée, elle

aussi, aux livrables.

Si le demi-flux est de type batch, la campagne Flow-Unit est mise à jour

ou créée en fonction du nombre d’entrées de l’application (si le demi-flux

traité est une sortie) et du nombre de BU sur lequel il va être installé. Des

captures d’écran du rapport d’exécution ainsi que du/des fichier(s) sorti(s)

sont joints aux livrables.

Une fois toutes ces étapes terminées, le développeur peut soumettre

(commit) son package WebMethods sur le SVN et tagguer la version créée.

21

Le package passe en build sur Jenkins afin de former un RPM (extension

du livrable) ; le plan de déploiement peut enfin être construit. Dans ce but,

nous avons un outil qui nous permet, grâce à un ID, d’identifier le demi-flux et

de sélectionner tous les RPM requis au bon fonctionnement de celui-ci.

Pour finir, le développeur indique sur le ticket Redmine qu’un plan de

déploiement a été créé sur la plateforme ATOM et clôt le ticket sur Jira.

Le fait que le développeur amène la demande du devis à la livraison

nous permet d’avoir un contrôle total sur le processus, et donc, en cas de

retour de la part du client, d’avoir plus de facilités d’analyser le problème.

22

VI. Où en sommes-nous aujourd’hui ?

6.1. Les résultats de l’ESB

L’ESB a parcouru du chemin depuis 2011 : il a accueilli de plus en plus

de BU comme celles de la Russie, de l’Italie, de l’Afrique du Sud ou encore du

Kazakhstan.

A la fin de la migration des échanges de l’EAI, l’ESB traitait 50 millions

d’objets métier par mois ; aujourd’hui, il en traite 4,5 milliards.

Le nombre d’applications et de demi-flux est en évolution constante

depuis la fin de la migration : environ 630 applications et 35 000 échanges y

sont présents.

Au niveau humain, les équipes du CS échanges accueillent une

trentaine membres dont 3 ressources se trouvant au Canada.

6.2. Vers l’ETL ?

Depuis quelques mois, Le CGI propose une offre ETL aux projets client.

L’ETL (ou Extract Transform Load) est une solution middleware permettant

d’effectuer des synchronisations massives d’informations d’une source de

données vers une autre. Comme son nom l’indique, cette solution extrait les

données d’une source, les transforme et les charge dans une cible (serveur

ou BDD cible si le demi-flux est une sortie, BDD pivot dans le cas contraire).

A l’origine, une seule ressource était responsable des développements

des demi-flux mais, cette dernière ayant récemment quitté CGI, j’ai été choisi

avec deux autres ressources pour un transfert de compétences.

J’ai donc été affecté, en plus du développement de demi-flux ESB, au

développement de demi-flux sur la technologie Stambia.

La demande venait principalement de Russie et d’Italie ; nous avons

donc pu collaborer sur le développement de cette solution récente et, par la

même occasion, expérimenter la mise en place d’une solution au sein d’un

projet qui a déjà de l’ancienneté.

23

VII. Conclusion

Depuis les débuts du groupe, le modèle de la plateforme d’échanges

de données a bien évolué.

Comme vu précédemment, le modèle « spaghettis » était le modèle de

base avant la construction d’un EAI : cette solution perdura une décennie

avant d’être remplacée, avec l’aide de CGI, par une plateforme ESB qui

répondit aux problèmes que l’EAI ne pouvait résoudre.

Les deux années que j’ai passées au sein des équipes du CS échanges

m’ont bien sûr permis de me familiariser avec les technologies telles que

WebMethods et Stambia. J’ai aussi pu comprendre le fonctionnement d’un

centre de services spécialisé dans l’intégration.

Cette alternance a été une expérience enrichissante et un véritable

complément à ma formation de Master.

24

Bibliographie

- « La SOA c’est pas sorcier », vidéo tournée par le CS échanges, pas de

lien web

- « définir L’objet métier »,

http://dictionnaire.sensagent.leparisien.fr/Objet%20m%C3%A9tier/fr-fr/

- « Objet métier », https://fr.wikipedia.org/wiki/Objet_m%C3%A9tier

- « Qu’est-ce que l’EAI ? Intégration et Urbanisation »,

https://www.piloter.org/techno/support/EAI.htm

- « EAI (Enterprise Application Integration) ou Intégration des

Applications d'Entreprise »,

https://www.guideinformatique.com/dossiers-actualites-informatiques-

entreprise-ressources-planning-1/eai-enterprise-application-

integration-ou-integration-des-applications-dentreprise-187.html

- « Intégration d'applications d'entreprise »,

https://fr.wikipedia.org/wiki/Int%C3%A9gration_d%27applications_d%2

7entreprise

- « Intégration d’applications : de l’EAI à l’ESB »,

https://www.axysweb.com/integration-applications-eai-esb/

- « EAI / ESB », https://gestsysinfo.wordpress.com/2013/01/14/eai-esb/

Annexes

Sommaire des annexes

Annexe 1 – ACB Utils ................................................................................................ I

Annexe 2 – Monitor ................................................................................................. II

Annexe 3 - Batch Repository ................................................................................. III

Annexe 4 – CgiCodeReview ................................................................................ IV

Annexe 5 - Flow Unit............................................................................................... V

I

Annexe 1 – ACB Utils

II

Annexe 2 – Monitor

III

Annexe 3 - Batch Repository

IV

Annexe 4 – CgiCodeReview

V

Annexe 5 - Flow Unit