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
Top Related