–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