Upload
ippon
View
1.505
Download
1
Embed Size (px)
Citation preview
–1–
– PROJET SOCLE
1. OBJECTIF DU PROJET SOCLE
2. ORGANISATION DU PROJET SOCLE
3. TRAJECTOIRE ET DATE CLÉS DU PROJET SOCLE
4. BÉNÉFICES DU PROJET SOCLE
5. ARCHITECTURE DU PROJET SOCLEa) OBJECTIFS DE LA REFONTEb) ARCHITECTURE APPLICATIVE DETAILLEEc) ZOOM SUR LES COMPOSANTS CLES d) RETOUR SUR EXPERIENCE
–2–
– OBJECTIF DU PROJET SOCLE
Core Renaissance
–3–
–OBJECTIFS DU PROJET SOCLE
RefonteISO-FONCTIONNELLE du site et des outils de back-office, autour d’un SOCLE DE DONNEES UNIFIE
Un périmètre touchantl’ensemble des applications Cœur de métier
Rénover et simplifier le SI, pour mieux servir les métiers
30 Mars 2015Bascule BB2
Socle : Une étape majeure
du SDSI
24 Juin 2015Bascule BB3
8 Déc. 2014Bascule BB1
Rationnaliser et homogénéiser les données au sein du SI
Rationnaliser l’organisation des fonctionnalités entre les différentes couches de l’architecture SI
Simplifier l’architecture globale du SI
–4–
– ORGANISATION DU PROJET SOCLE
–5–
– ZOOM SUR LA REPRISE DES DONNÉESORGANISATION PROJET SOCLE
Pour le projet Socle, l’APEC a fait le choix de s’appuyer avant tout sur ses collaborateurs, pour développer les savoir-faire internes
8 groupes de travail pilotés par les collaborateurs de l’Apec Moins de 10 personnes par GT (sauf GT2 avec quelques pointes à plus)
Piloté par les équipes de l’Apec
Comité de Pilotage Commanditaire
Chef de ProjetGT 1
Spécifications,
Paramétrages &
Recette
GT 2Développement &
Intégration
GT 3Homologatio
n
GT 4 Reprise
des données
Socle
GT 5Infrastructur
e
GT 6Connexion SI
GT 7Décisionnel &
Finance
GT8Accompagnement
Chaque GT est chargé d’organiser son intervention en fonction du périmètre global à traiter lot par lot, tout en se synchronisant avec les autres GT dont il dépend ou auxquels il contribue. Il est dirigé par un responsable qui répond de l’avancement des travaux qui lui sont confiés.
–6–
– TRAJECTOIRE ET DATES CLÉS
–7–
– TRAJECTOIREDans une perspective de minimisation des risques de déploiement, une trajectoire en « tâche d’huile » a été définie.
Le projet a procédé en trois cycles enchaînant chacun les étapes suivantes :- Développement de nouvelles briques applicatives- Bascule à blanc simulant en environnement de tests ou de pré-production la reprise des
données et la bascule des anciennes aux nouvelles applications- Recette technique et métier, et correction des anomalies rencontrées
Une fois la troisième bascule à blanc validée, les applications du socle étaient prêtes pour leur bascule réelle, c’est-à-dire leur mise en production dans les environnements utilisés par les métiers et les visiteurs du site APEC.fr
Cycle 1, ponctué par une bascule à blanc
Cycle 2, ponctué par une bascule à blanc
Cycle 3, ponctué par une bascule à blanc
Bascule réelle
–8–
– APPROCHE ET DATES CLÉS
2014 2015
T1 T2 T3 T1 T2 T3 (Juillet)
Front-Office (APEC.fr)
Back-Office et satellites
Reprise des données
Extractions pour SI décisionnel / Finance
Bascule à Blanc 1
BB1 BB2 BB3 BR
Bascule réelle
Bascule à Blanc 2
Bascule à Blanc 3
Fiabilisation de la chaîne de migration
Fiabilisation de la chaîne de migration
Web services, Connexion SI
Cette trajectoire en tâche d’huile s’est traduite par le déploiement graduel du périmètre en quatre étapes.
–9–
– BÉNÉFICES
–10–
–AUJOURD’HUI, UN NOUVEAU SOCLE
Un site rénové
Des évolutions métiers facilitées
Des données centralisées
l’APEC dispose d’un socle technique flambant neuf pour proposer de nouveaux services à ses clients
Socle : une innovation
technique au service des innovations
métiers
Un socle technique performant et de dernière génération qui permet:
Une meilleure production des contenus sur APEC.FR
Des fonctionnalités techniques natives au services des fonctionnalités métiers
Des développements de nouvelles fonctionnalités métiers plus agiles et moins couteux sur l’ensemble des applications
Des possibilités de développements nouvelles et innovantes
Une maintenance facilitée
Un délai optimisé
Une bascule réelle avancée de 4 mois
Fin prévue des travaux : Fin 2015
Fin réelle des travaux : Juillet 2015
–11–
– ARCHITECTURE SOCLE
PRÉSENTATION DE
L’ARCHITECTURE TECHNIQUE
DU SYSTÈME D’INFORMATION
–12–
– OBJECTIFS DE LA REFONTE
• Moderniser la pile logicielle :
- Anticiper la faisabilité technique des fonctionnalités de demain- Réduire les délais de maintenance, évolutions- Gagner en performance, fiabilité et en scalabilité
• Factoriser les composants logiciels pour simplifier l’architecture :
- Faciliter l’exploitation et la supervision de la plateforme- Réduire les couts
• Responsive design pour le web
• Ne pas impacter les partenaires externes
• Volonté forte de construire autour de la donnée
–13–
– OBJECTIFS DE LA REFONTEArchitecture applicative macroscopique avant refonte
–14–
– OBJECTIFS DE LA REFONTE
Echanges Externes
Front-Office
Services Métiers
Mise en place del’infrastructure cible sous Windows
Socle de Données
Back-Office
Extractions pour Décisionnel et Finance
/ Services RESTFul
Real Time
Avec Salesforce :
Connexion de Salesforce
Connexion des satellites et partenaires
Architecture applicative macroscopique cible
–15–
–• Particularités
- Serveur web jeune utilisé pour la 1ère fois en 2004- Robuste et très performant en cas de fort trafic- Gestionnaire de cache- Configuration très simple- 22% d’utilisation sur le million de sites les + visités au monde.
• Load balancer sur les frontaux web et affinité de session
• Mise en cache des pages ainsi que les appels rest pour le détail des offres
• Caches mis en RAM pour plus de performance
• Redirection pour les Urls du legacy
• Mise à disposition de ressources statiques (site https://histoiresdeliens.apec.fr )
NGINX
–16–
–• CMS JAVA
- Fournit une boite à outils technique java dense (Spring, tuckey, drools, OSGI…)- Création de pages et contribution aux articles- Représentation des données sous forme de nœud (via Jackrabbit)- Connectivité ( ExternalDataProvider, Intégration de briques Externes)- Exposition de points d’entrées rest via des Controller Spring- Bibliothèque de composants disponibles par défaut- Gestion des droits avancées pour la contribution- Mécanisme de modules pour la partie développement
• Avantages- Déploiement des modules à chaud grâce via OSGI- Architecture cluster- Multi-sites- Puissance et rapidité de Jackrabbit - Import / Export de sites, de pages, de bloc ou de noeud
JAHIA 7 – DIGITAL FACTORY
–17–
–JAHIA 7 – DIGITAL FACTORYArchitecture cluster mise en place
BD SOCLE SCHEMA JAHIA
MASTER SLAVE 1
LECTURE SEULE SYNCHRO JCR TOUTES LES 2 SEC
LECTURE/ECRITUREEDITION PAGES / BLOCSCONTRIBUTION EDITORIALE
MAJ CACHE NGINX
REQUETE CLIENTE
SLAVE 2 SLAVE 3
–18–
–
• AngularJS : Framework Javascript permettant de faire des applications web MVW entièrement éxécuté coté client.
• Utilisation d’AngularJS dans des blocs de pages via Jahia
- Rendu utilisateur dynamique – Pas de rechargement de page- Utilisation du cache Nginx pour les ressources JS et la page Jahia- Diminution de la charge serveur : fait uniquement passe plat pour les
services- Permet de supporter plus de trafic
• Malheureusement, Google ne sait pas encore exécuter le JS lors du crawling des pages
• Mise en place d’un serveur utilisant la librairie Phantom JS pour générer une version html des pages crawlable par Google.
ANGULAR JS ET PHANTOM JS
–19–
–
• PDS : Production de services
• Outils de Back Office (offres, cv, comptes cadres, comptes recruteurs)
• Entièrement réalisé en Angular JS
• Utilisation d’un serveur NodeJS pour la gestion des sessions
• Consommateur des services rest
PDS
–20–
–
• Services web REST ( Resin Tomcat, ORM : MyBatis)
• Point d’accès à la base de données pour tous les applicatifs
- Contient toutes les règles de gestion métiers- Mutualisation des développements entre le front et le back office- Garant de la sécurité « fonctionnelle » d’accès au données- Garant de l’intégrité des données du schéma SOCLE (Lecture /
Ecriture)
• Gestion de l’indexation avec SolR
• Envoi de mail transactionnel
• Gestion de l’upload des documents
SERVICES RESTFULL
–21–
–• CRM : Salesforce – Utilisé pour la gestion et le suivi des consommations de services
de l’APEC
• INFORMATICA : ETL (Extract-Transform-Load) partenaire avec Salesforce
• Processus métier planifier (batch sur les données)- Tous les batchs sont traités via Informatica (ex : suspension des offres)- Toutes opérations sur les données se font via les services REST
• Synchronisation des données en temps réel- De la base SOCLE vers le CRM (ex : comptes)- Du CRM vers le schéma de réplication
• Alimentation du décisionnel
INFORMATICA & CRM
–22–
–
• Oracle
• Réplication en temps réel sur une base de backup ( utilisée en cas de failover )
• Un schéma avec toutes les données métiers ( SOCLE )
• Sur la même base, une copie des informations du CRM dans un schéma spécifique pour centraliser l’information
• Un schéma est dédié au fonctionnement de JAHIA
• Seuls les services ont le droit d’écrire dans le schéma SOCLE afin de garantir l’intégrité des données
BASE DE DONNÉES
–23–
–
• Très satisfait de l’architecture en production
- Plateforme performante et stable- Maintenance et évolutions simplifiées- Objectifs sont atteints
• CMS Jahia
- Prise en main un peu complexe- Généraliser l’utilisation AngularJS- Effectuer les montées de version est préférable
• Utilisation de Jahia pour d’autres usages (ex : intranet)
RETOUR SUR EXPÉRIENCE
–24–
–
…Merci de votre attention !
Questions / réponses