Offre Socle Technique OFL by CGI

1. Offre Socle Technique OFL by CGI

2. Pourquoi cette offre ? Les modules & fonctionnalités Architecture logicielle Les enjeux et principes de la solution Notre démarche Quelques écrans Démo et outils en ligne Références 1 3 2 6 7 4 8 5 Agenda

3. Pourquoi cette offre ? La grande majorité des solutions de mise en œuvre de plateforme d’échange n’embarque pas de brique de supervision fonctionnelle permettant un suivi des instances avec indicateurs de bout-en-bout et au-delà de leurs périmètres d’actions. L’Open Framework Logica (OFL) est une solution autonome qui permet de compléter une solution échanges en proposant ce suivi détaillé ainsi que différents tableaux statistiques. Il s'inscrit dans une démarche de suivi fonctionnel des échanges, temps réel, avec une vision bout-en-bout et transverse. Il permet une première approche d’urbanisation en proposant différents modules structurants (référentiels, SLA, indicateurs de plateforme, etc.). Cette offre existe déjà depuis plus de 9 ans et bénéficie donc d’un retour d’expérience unique.

4. Les enjeux la solution Supervision / audit des instances des échanges, des processus ou des services par son approche indépendante de la vision éditeur. Gestion des erreurs. Traitement d’indicateurs métiers paramétrables dynamiquement et issus du contenu ou de manière statique (personnalisation métier). Problématique de transcodification de données. Gestion de tâches planifiées (ex : purge, émission de rapport statistique …). Supervision de composant technique applicatif (ex : webMethods Broker, TIBCO EMS, self). Gestion de domaine métier via un gestionnaire d’habilitation (filtrage par profil, domaine). Suite d’outils d’exploitation.

5. Les enjeux la solution • Enjeux principaux: • Industrialisation plateforme EAI/SOA • Connaître à tout moment l’état d’un flux, d’un process, le respect des SLA fixés. • Etre alerté au plus tôt: être proactif. • Avoir une vision globale et statistique de la plateforme ESB.

6. Les principes de la solution

7. Les principes de la solution BUILD 1 OFL RUN OFL 2 CARTO 3

8. Les modules & fonctionnalités Export • Rapport-Alertes Administrateur Responsable applicatif Développeur Roles Supervision applicative Supervision technique Emails Web services Flux RSS Logs Test unitaire Modules BUILD RUN Référentiel Adit Référentiel de paramètres Données

9. Matrice détaillée

10. API clientes Exemple d’utilisation des API TIBCO: UseCases, Patterns, Templates, Toolbox, Bonnes pratiques, etc.

11. API clientes Les autres API spécifiques disponibles : Les API génériques :

12. Implémentation E.T.L/E.A.I : BW

13. TIBCO BW : Rationalisation

14. Déclencheur Polling Déclencheur EMS Socle TIBCO BW: Rationalisation Supervision Supervision applicative Supervision technique Hawk Audit Q TIBCO EMS Queues et/ou F.S. délivrance réception scrutation transform Connecteur output CommonLib Connecteur Input Persistance réception délivrance transformation Implémentation spécifique : à développer BNP-Paribas Personal Finance - Projet ARTEMIS No. 14

15. Automatisation : Packaging / déploiement STCM Extraction source + génération doc Réalisation Mise à jour outil de ticketting avec version technique Test Unitaire et NR bouchonné action Back CSB COMMIT manuel Liste de distribution 1 action Release Note 2 Front Logica RepoDev Repo Livraison action IPS/PSM Référentiel Flux/Version Checkout auto STCM generate Référentiel Params 5 Intégration Légende 3 Tests package Dépot STCM Deploy STCM package STCM Deploy STCM release 4 Mise à jour outil de ticketting avec version technique 6 Référentiel Params Production / Recette Repo Prod Run Package 7 8

16. Automatisation : Générateur de flux

17. Automatisation : Référentiel flux, source du générateur de flux

18. Automatisation : Référentiel de packaging

19. Automatisation : Référentiel de paramétrage

20. Etat des services du serveurs getServerStatus.sh ARTPRD01 Démarrage des services du serveurs TIBCO startAllServices.sh ARTPRD01 Démarrage des services et applications TIBCO startAllApps.sh ARTPRD01 Arrêt des services TIBCO stopAll.sh ARTPRD01 Arrêt / démarrage du service CFT cftstop | cftstart Automatisation : Administration en ligne de commande

21. Administration des applications BW Arrêt, démarrage, arrêt immédiat, état d’une application BW /projects/artemis/scripts/flows/<Package>_ARTPRD01.sh (stop | start | kill | status) Exemple : BNP_PF_01_ARTPRD01.sh status Exploitation en ligne de commande • Le signe « + » ou « - » permet de visualiser le statut

22. Déploiement d’une livraison Import des paramètres dans le référentiel de paramètrage ImportSingleAppParameter –app <package> -version <version> -domain ARTPRD01 Déploiement de l’application DeploySingleApp –app <package> -version <version> -domain ARTPRD01 Vérificationsvia la ligne de commande : /projects/artemis/scripts/flows/<Package>_ARTPRD01.sh status Monitoring technique : log OFL centralisé Exploitation Simplifié

23. Console de supervision applicative

24. Console de supervision applicative

25. Console de supervision applicative

26. Console de supervision applicative

27. Console de supervision applicative

28. Moteur de collecte Technologies à adapter aux besoins

29. Quelques notions ESB Métier Niveau d’agrégation Technique

30. Quelques écrans

31. Quelques écrans

32. Quelques écrans

33. Quelques écrans

34. Quelques écrans

35. Quelques écrans

36. Quelques écrans

37. Quelques écrans

38. Quelques écrans Référentiel des échanges: Codification Paramétrage audit Etapes associées Application source/cible Spécifique échange Domaine métier Critères métiers Notificateurs

39. Administration des flux Technologies à adapter aux besoins

40. Notre démarche Une démarche générale Un cadre méthodologique expliquant les différentes étapes et les concepts pour la mise en œuvre d’une supervision de plateforme d’échange. Une bibliothèque d’outils Les sources et binaires de la solution, les différentes API d’interfaçage (Java, WebService, Tibco, WebMethods, etc.), des outils en ligne de commande (bench, configuration) et une base documentaire classique. Accompagnement à la mise en œuvre Prise en compte de l’existant, étude de faisabilité, aide à la mise en œuvre. Une équipe et un socle Une équipe d’experts techniques de proximité surles technologies SOA/ESB. Un support accessible (bug tracker, wiki, forum, etc.) pour plus d’agilité. Un support réactif Sous la forme de contrat de maintenance avec tickets (corrections, évolution, conseils). Pas de licence Aucune licence n’est nécessaire pour l’usage du produit.

41. Notre démarche A C C O M P A G N E M E N T M A I T R I S E Phase 1 : Analyse de l’existant et proposition personnalisée Cartographie des besoins et des moyens disponibles Proposition adaptée aux besoins Mise au point de la démarche d’accompagnement Présentation générale de l’offre Photo des chantiers à un instant T Phase 2 : Mise en œuvre Démarche d’amélioration et d’ajustement Accompagnement des utilisateurs finaux, des exploitants et de l’ingénierie (ateliers et formations) Définition et exécution des chantiers de migration Socle méthodologique pour les activités futures Phase 3: Contrat de maintenance Rétablir le service suite à une anomalie Ajouter des fonctionnalités au produit Rôle de conseil sur le périmètre de la solution Accès à la plateforme support et à la base de connaissances

43. Ministère de l’IntérieurGendarmerie Nationale Sur les projets ARIANE & FOVES : Supervision des procédures judiciaires, des photos d’objets / personnes et des objets volés intra applications.

44. AG2R La Mondiale En place sur le projet BUS Groupe,en cours de migration sur le projet GPS: élément de supervision, référentiel & transcodification. Migration FREESBI

45. AG2R La Mondiale Migration FREESBI

46. REXEL Sur le projet HUB : Grosse cartographie mais patterns identiques.

47. REXEL Supervision technique et applicative de la totalité des flux synchrones, asynchrones et batchs de la plateforme d’échange HUB . Le HUB France Rexel ,héberge en production plus de 200 types de flux différents et alimente l’ensemble des domaines métiers de Rexel (Logistique, R.H, Référentiel, EDI, CRM). 749 instances de flux batch par nuit dont la plupart s’exécutent entre 21 h et 23 h : • Répartis sur 106 types de flux différents • Déployé sur 16 applications BW (JVM distinctes) 1397 instances de flux batch par jour • Répartis sur 100 types de flux différents • Déployé sur 10 applications BW (JVM distinctes) 2 Types de flux synchrone • Plusieurs milliers de requêtes par jour d’ici fin d’année Plus gros fichiers traités • Articles : 600 Mo une fois par jour • Signalétiques : 100 Mo une fois par jour Volumétrie traitée avec transformation • 2 Go / jour :flux fichier/fichier • 3 Go / jour de données mixtes DB/Fichier traitées • 300 Mo/jour véhiculés sur le BUS EMS Tibco compressés avec un facteur 10 (natif produit)

48. Orange France Telecom Sur le projet PROMISE & B-USE: Unification des flux de provisionnement des plateformes de service Orange Mobile et Internet. Problématiques: Flux synchrone, asynchrone, batch Supervision de bout en bout sur plateforme hétérogène Forte volumétrie (2 à 3 Millions / jour) -> 10M dans la base d’audit multi cible dynamique (i.e. éligibilité au Runtime)

49. Orange France Telecom

50. Auchan Sur le projet MOSAIC : Supervision de la totalité des flux synchrones, asynchrones et batchs de la plateforme d’échange (plus d'une centaine de flux, une volumétrie cible à 10 millions d’instances par jour).