Dossier d’Architecture Technique...• Un serveur SSO pour l’authentification et la protection des accès aux IHM EBX : il s’agit d’un simple paramétrage d’un module au

1 / 28

DEM-05-DAT

GUIDE TECHNIQUE

Dossier d’Architecture Technique

TABLE DES MATIERES 1. LISTE DES FIGURES .................................................................................................................................................3

2. LISTE DES TABLEAUX ..............................................................................................................................................3

3. INTRODUCTION .....................................................................................................................................................4

3.1. PERIMETRE ...................................................................................................................................................................... 4

3.2. ARCHITECTURE GENERALE DE LA SOLUTION ............................................................................................................................ 4

4. ARCHITECTURE APPLICATIVE ..................................................................................................................................6

4.1. APERÇU ........................................................................................................................................................................... 6 4.1.1. Flux de données .............................................................................................................................................. 7 4.1.2. Interopérabilité ............................................................................................................................................... 9

4.3. LISTE DES COMPOSANTS ................................................................................................................................................... 11 4.3.1. OS/SGBD ....................................................................................................................................................... 11 4.3.2. Composants communs ................................................................................................................................. 11 4.3.3. Composants EBX ........................................................................................................................................... 12 4.3.4. Composants iWay ......................................................................................................................................... 12

4.4. DISPONIBILITE ................................................................................................................................................................ 12

4.5. PARAMETRAGE ............................................................................................................................................................... 13

4.6. SECURITE ....................................................................................................................................................................... 14 4.6.1. Accès à l'application ...................................................................................................................................... 14 4.6.2. Données ........................................................................................................................................................ 15 4.6.3. Chiffrement des flux ..................................................................................................................................... 16

4.7. PERFORMANCES ............................................................................................................................................................. 16

4.8. SCALABILITE ................................................................................................................................................................... 16 4.8.1. Scalabilité SGBDR ......................................................................................................................................... 16 4.8.2. Scalabilité EBX ............................................................................................................................................... 16 4.8.3. Scalabilité Iway ............................................................................................................................................. 17 4.8.4. Synthèse Scalabilité et Disponibilité ............................................................................................................. 17

4.9. PRE REQUIS DES POSTES UTILISATEURS ................................................................................................................................ 18 4.9.1. SINAPS-MDM ................................................................................................................................................ 18

ARCHITECTURE PHYSIQUE (INFRASTRUCTURE) ......................................................................................................... 20

4.10. DIMENSIONNEMENT ...................................................................................................................................................... 20 4.10.1. Systèmes ....................................................................................................................................................... 20 4.10.2. Sauvegarde ................................................................................................................................................... 21 4.10.3. Réseau ........................................................................................................................................................... 21

4.11. CONTRAINTES / ENVIRONNEMENTS .................................................................................................................................. 21

4.12. DISPONIBILITE .............................................................................................................................................................. 22

2 / 28

DEM-05-DAT

4.13. MODELE D’ARCHITECTURE .............................................................................................................................................. 22 4.13.1. Modèle d’architecture simple....................................................................................................................... 22 4.13.2. Modèle d’architecture recommandé ............................................................................................................ 23

4.14. RESEAU (LAN / WAN) .................................................................................................................................................. 24

5. DESCRIPTION DES ENVIRONNEMENTS .................................................................................................................. 26

6. ABREVIATIONS ET GLOSSAIRE .............................................................................................................................. 26

6.1. GLOSSAIRE DES TERMES ................................................................................................................................................... 26

6.2. ABREVIATIONS ................................................................................................................................................................ 26

7. DOCUMENTS DE REFERENCE ................................................................................................................................ 26

8. ANNEXES ............................................................................................................................................................. 26

3 / 28

DEM-05-DAT

1. LISTE DES FIGURES Figure 2 : Architecture Générale Sinaps ................................................................................................................................. 4 Figure 3 : Architecture applicative .......................................................................................................................................... 6 Figure 4 : HA EBX................................................................................................................................................................... 13 Figure 5 : HA iWay................................................................................................................................................................. 13 Figure 6 : Mécanismes d’authentification Sinaps ................................................................................................................. 14 Figure 7 : Scalabilité horizontale pour iWay ......................................................................................................................... 17 Figure 8 : Modèle d'architecture simple ............................................................................................................................... 23 Figure 9 : Modèle Sinaps recommandé ................................................................................................................................ 24 Figure 10 : Organisation réseau optimale ............................................................................................................................ 25 Figure 11 : Organisation réseau simplifiée ........................................................................................................................... 25

2. LISTE DES TABLEAUX Tableau 1 : Inventaire des flux ................................................................................................................................................ 7 Tableau 2 : Liste des services exposés (détail des flux ESB-EXT-1, ESB-EXT-2) ....................................................................... 8 Tableau 3 : Liste des protocoles et ports utilisés entre Sinaps et produit Amue ................................................................... 9 Tableau 4 : Services communs du SI établissement nécessaires pour Sinaps ...................................................................... 10 Tableau 5 : Connecteurs Sinaps standard ............................................................................................................................. 10 Tableau 6: Versions OS/SGBD ............................................................................................................................................... 11 Tableau 7: Versions OS/SGBD anticipées ............................................................................................................................. 11 Tableau 8 : Composants communs ....................................................................................................................................... 11 Tableau 9 : Composants EBX ................................................................................................................................................ 12 Tableau 10 : Composants iWay ............................................................................................................................................ 12 Tableau 11 : Rôles Sinaps ...................................................................................................................................................... 15 Tableau 12: Synthèse scalabilité et disponibilité .................................................................................................................. 18 Tableau 13: Dimensionnement de l'environnement de production pour un établissement petit ...................................... 20 Tableau 14: Dimensionnement de l'environnement de production pour un établissement moyen ................................... 20 Tableau 15: Dimensionnement de l'environnement de production pour un établissement grand .................................... 20 Tableau 16 : Dimensionnement des environnements hors production ............................................................................... 21 Tableau 17 : Contraintes/environnements ........................................................................................................................... 22

4 / 28

DEM-05-DAT

3. INTRODUCTION Dans le cadre de sa mission de contribution à l’élaboration du SI des Etablissements, l’Amue a pour objectif de proposer une solution de référentiel partagé des données de référence (ou Master Data) intégrable, non seulement dans le SI Amue mais plus généralement dans n’importe quel SI d’Etablissement : Sinaps. De plus, Sinaps adresse la problématique de la gestion des processus métier critiques des établissements. Les principaux objectifs que se fixe l’Amue sont les suivants :

• Fabriquer la version initiale du référentiel partagé Sinaps sur la base des outils choisis (Orchestra Networks EBX et Information Builders iWay),

• Accompagner techniquement les établissements dans l’implantation de Sinaps dans leur SI et en particulier dans un contexte de déploiement massif

• Apporter l’assistance nécessaire aux établissements dans l’exploitation et la maintenance de la solution, • Accroître par étapes le périmètre des données de référence gérées dans Sinaps ainsi que des échanges intra ou

inter systèmes d'informations • Ouvrir la solution à la co-construction (construction collaborative). Fournir aux établissements un outillage pour

faciliter les échanges et travaux entre les établissements. • Sinaps prend en charge des processus et échanges internes au SI de l'Etablissement mais aussi des processus et

échanges entre l'Etablissement et des partenaires externes

3.1. Périmètre La version 1 de Sinaps a pour périmètre :

• Les référentiels : o Structure o Personne o Nomenclature

3.2. Architecture générale de la solution

Figure 1 : Architecture Générale Sinaps

5 / 28

DEM-05-DAT

Sinaps gère les données de référence du Système d’Information des Etablissements. On entend par « données de référence », les données partagées et utilisées par plusieurs applications du Système d’Information. Ces référentiels peuvent être de différentes natures et être pilotés par des modèles de gouvernance divers:

• Référentiel des Personnes incluant les Personnes Ressources, les Etudiants, les Usagers… • Référentiel des Structures Organisationnelles • Référentiel des Nomenclatures

6 / 28

DEM-05-DAT

4. ARCHITECTURE APPLICATIVE

4.1. Aperçu

SINAPS-INTERMEDIATIONSINAPS-MDM

Apache Tomcat

Spécifique

< DOMAINE >

< DOMAINE >

Natif

Match & Cleanse

Information Search

Moteur standardBAM

Natif

Moteur standard

ou

MDM-SQL-1

ESB-MDMMDM-ESB

ESB-SQL-2

ESB-SQL-1

Utilisateur

MDM-IHM

ESB-IHM-2

SI Etablissement

Serveur mailMDM-Mail ESB-Mail

Application tierce

Application tierce ESB-EXT-1

ESB-EXT-2

MDM-SQL-2SQL Connect

Serveur SSOApache-SSO

Applications

< Application >

< Application >

Serveur BO

BO-SQL-1

ESB-SQL-3ESB-SQL-4

BO-IHM

BO-Mail

ESB-IHM-1

Figure 2 : Architecture applicative

L’application Sinaps se décompose en deux sous-parties : Sinaps MDM et Sinaps Intermédiation. Deux composants sont transverses à ces sous-parties : le serveur web Apache qui centralise les flux à destination des IHM Sinaps, il permet de gérer l’authentification de type SSO lors de l’accès aux IHM EBX, et la base de données, permettant le stockage et l’échange de données.

7 / 28

DEM-05-DAT

La sous-partie Sinaps MDM est composée d’un serveur d’application Apache Tomcat permettant l’exécution de l’outil MDM EBX. La librairie EhCache est installée sur ce serveur pour donner accès à un gestionnaire de cache. L’application EBX se décompose en deux parties :

• Une partie native, avec le moteur natif de l’outil, ainsi que deux add-ons développés par le même éditeur : o « Information Search » : permet les recherches sur le contenu du MDM. o « Match & Clease » : permet la recherche et le traitement automatique des doublons.

• Une partie « développement spécifique », comprenant l’ensemble des binaires issus des différents chantiers. La sous-partie Sinaps Intermédiation est composée d’un serveur d’application autonome (ISM) qui est une sorte de conteneur d’application iWay. L’application iWay se décompose en trois parties :

• Une partie native qui correspond au moteur du Bus d’entreprise (ISM). Il permet une gestion des configurations et applications iWay.

• Une partie « BAM (Business Activity Monitor) ». Ce processus de supervision doté d’une IHM pour la consultation est fourni par l’éditeur. Sinaps fournit seulement son packaging en temps qu’application iWay. Elle est ainsi déployée dans ISM sous la forme d’une IIA (iWay Integration application).

• Une partie « applications », comprenant un ensemble d’application iWay (IIA) qui permet de mettre en œuvre les processus de médiations génériques (logiques d’intermédiation) et spécifiques établissements (connecteurs applicatifs)

4.1.1. FLUX DE DONNEES

Tableau 1 : Inventaire des flux

Flux Emetteur Receveur Protocole Port * Description Apache-SSO Frontal Apache Serveur SSO HTTP 443 Validation du jeton SSO

MDM-IHM Navigateur

Frontal Apache

HTTP 80 Authentification et consultation des IHM EBX

MDM-IHM (suite) Frontal Apache EBX AJP 8009 Consultation des IHM EBX

MDM-SQL-1 EBX

BDD JDBC

1521 ou 1433

Persistance des données EBX en base

MDM-SQL-2 EBX (SQL Connect) BDD JDBC 1521 ou 1433

Réplication de certaines données fréquemment consultées

MDM-Mail EBX Mail SMTP 25 Envois de courriels

MDM-ESB EBX

iWay TCP 14000 Echanges depuis EBX vers iWay par Web

services SOAP (service exposé par iWay)

ESB-IHM-1 Navigateur ISM (iWay) HTTP 9999 Consultation de la console web d’administration de l’ESB (ISM)

ESB-IHM-2 Navigateur BAM (iWay) HTTP 8087 Consultation de la console web de supervision des flux (BAM)

ESB-SQL-1 iWay BDD JDBC 1521 ou 1433

Persistance et lecture des données de supervision des flux en base


Lecture des données fréquemment consultées (back-end EBX de réplication)


Alimentation de la base de données de supervision BO depuis les données contenues dans la base de données BAM

8 / 28

DEM-05-DAT


Mise à jour dans la base de données de supervision BO du statut des transactions

ESB-Mail iWay Mail SMTP 25 Envois de courriels

ESB-MDM iWay EBX HTTP 8080 Echanges depuis iWay vers EBX par Web services SOAP (service exposé par EBX)

ESB-EXT-1 App. tierce

iWay HTTP 9005 Acquisition de messages XML au format

pivot

ESB-EXT-2 App. tierce iWay FTP 21 et 20000-30000

Acquisition et consommation asynchrone de messages XML au format pivot

BO-IHM Navigateur BO HTTP 8080 Consultation du rapport de supervision BO

BO-SQL-1 BO BDD JDBC 1521 ou 1433

Lecture des données de la base de données de supervision BO

BO-Mail BO Mail SMTP 25 Envois de courriels

* Les ports indiqués sont ceux inscrits par défaut dans la configuration Sinaps.

Tableau 2 : Liste des services exposés (détail des flux ESB-EXT-1, ESB-EXT-2)

Description Domaines Adresse (Endpoint) Protocole

Port (par défaut)

Méthode d’authentification

Service d'acquisition unitaire Personne Nomenclature Structure

http://ipServeur:port HTTP 9005 Basic Auth

Service d'acquisition unitaire Personne Nomenclature Structure

- FTP 9051 Basic Auth

Service d'acquisition par liste Personne Nomenclature Structure

http://ipServeur:port HTTP 9017 Basic Auth

Service d'acquisition par liste Personne Nomenclature Structure

- FTP 9054 Basic Auth

Service de Recherche de personne - http://ipServeur:port/personne/recherche HTTP 9055 Basic Auth

Service de Recherche de références croisées - http://ipServeur:port/refcroisee/recherche HTTP 9055 Basic Auth

Service de Création de références croisées - http://ipServeur:port/refcroisee/creation HTTP 9055 Basic Auth

Service de transcodification - http://ipServeur:port/transcodification HTTP 9055 Basic Auth

Service d’acquittement fonctionnel - http://ipServeur:port HTTP 9058 Basic Auth

Connecteur Sifac (nomenclature) - - FTP 9052 Basic Auth

9 / 28

DEM-05-DAT

Tableau 3 : Liste des protocoles et ports utilisés entre Sinaps et produit Amue

Au niveau des ouvertures de flux à réaliser dans le cadre de Sinaps, si la politique de sécurité le permet, le plus simple est d’ouvrir entre les applications Amue connectées et Sinaps la plage de ports de 9000 à 10000 sur les protocoles FTP et HTTP. Pour les flux, dans le sens Sinaps vers les applications Amue, il faut s’en référer au tableau ci-dessus.

4.1.2. INTEROPERABILITE Comme illustré en bas de la figure 2, l’intégration de l’application Sinaps au sein du SI d’un établissement consiste à permettre son interaction avec un ensemble de service : Sinaps s’appuie sur des services existants dans le SI établissement :

• Un serveur SSO pour l’authentification et la protection des accès aux IHM EBX : il s’agit d’un simple paramétrage d’un module au niveau du serveur web Apache.

• Un serveur SMTP pour l’envoi de mail : il s’agit d’un simple paramétrage au sein de chaque outil (EBX + ISM) pour référencer l’adresse du service SMTP.

• Un serveur BO pour la mise en œuvre du journal de supervision. Sinaps propose des connecteurs pour le SI établissement :

• Sinaps expose un serveur FTP qui permet à toute application du SI établissement, inscrite dans le processus d’acquisition et/ou de publication-souscription, respectivement, de déposer ou de consommer des messages au format pivot.

• Sinaps offre également une intégration avec la suite applicative Amue. Les applicatifs Harpège, Siham, Sinchro et Sifac sont intégrés.

Les tableaux des sous chapitres suivants exposent les interfaces de communications avec les applications des SI établissements.

Application (de) Application (vers) Protocole Port Méthode d’authentification

Sinaps (iWay) Harpège (serveur web service) http 80 Basic Authentification

Sinaps (iWay) Harpège (serveur web service) * * *

Sinaps (iWay) Apogée (serveur web service) http 8085 N/A

Sinaps (iWay) Apogée (serveur web service) http 8215 N/A

Sinaps (iWay) Sifac http 80 Basic Authentification

Harpège (serveur BDD) Sinaps (iWay) http 9005 / 9017 / 9058

Basic Authentification

Siham Sinaps (iWay) ftp 9051 / 9054 Basic Authentification

Apogée (serveur BDD) Sinaps (iWay) http 9005 / 9017 / 9058

Basic Authentification

Sifac Sinaps (iWay) http 9017 Basic Authentification

10 / 28

DEM-05-DAT

Services du SI établissement Quel que soit le référentiel, Sinaps s’appuie sur des services de l’établissement.

Tableau 4 : Services communs du SI établissement nécessaires pour Sinaps

Service Description

DNS Service permettant de traduire un nom de domaine en adresse IP. Ce serveur est utilisé par Sinaps pour les résolutions de nom.

SMTP

Un serveur de messagerie électronique est un logiciel serveur de courrier électronique (courriel). Il a pour vocation de transférer les messages électroniques d'un serveur à un autre. Ce serveur est utilisé par Sinaps pour les envois de courriel.

Reverse Proxy Le reverse proxy permet aux utilisateurs d'Internet d'accéder aux serveurs internes Sinaps.

SSO

Single Sign On (SSO) : Authentification unique. Permet à un utilisateur d'accéder à plusieurs services en ayant à effectuer qu'une seule opération d'authentification. Pour gérer l’authentification SSO, Sinaps s’appuie sur le serveur SSO présent en établissement.

BO Plate-forme Business Objects qui intègre un rapport BO sous Web Intelligence matérialisant le journal de supervision de Sinaps.

Connecteurs Sinaps standard Quel que soit le référentiel, Sinaps offre des interfaces de communication au format pivot.

Tableau 5 : Connecteurs Sinaps standard

Flux (de vers) Connecteur Traitement Description

Application Sinaps XML/RPC Acquisition de messages XML au format pivot

iWay analyse le format pivot et procède à une acquisition de nomenclature, structure ou de personne. Un message XML doit contenir un seul objet métier.

Application Sinaps FTP Acquisition de fichiers XML au format pivot

iWay analyse le fichier déposé sur l’espace FTP et procède à une acquisition de nomenclature, structure ou de personne. Un fichier doit contenir un seul objet métier.

Sinaps Application XML/RPC Diffusion de messages XML au format pivot

iWay emploie les informations du point d’accès de l’abonné (l’application) pour créer une connexion XML/RPC et diffuser un message XML au format pivot

Application Sinaps FTP Diffusion de fichiers XML au format pivot

L’application accède à un service FTP pour récupérer les fichiers XML au format pivot.

11 / 28

DEM-05-DAT

4.3. Liste des composants L’ensemble des composants hors OS et SGBD seront fournis par l’Amue.

4.3.1. OS/SGBD Pour octobre 2016, il y a 2 scénarios possibles :

• Versions de construction Sinaps V1.0.0

Tableau 6: Versions OS/SGBD

Nom du composant Version Description OS Windows Server 2008 R2 OS uniquement couplé avec SQL Server RHEL 6.5 OS uniquement couplé avec Oracle SGBD Microsoft SQL Server 2012 Moteur de base de données. Oracle database 11g R2 - 11.2.0.4 Moteur de base de données.

• Versions anticipées de Sinaps V1.1.0 (02/2017)

Tableau 7: Versions OS/SGBD anticipées

Nom du composant Version Description OS Windows Server 2012 R2 OS uniquement couplé avec SQL Server RHEL 7.2 OS uniquement couplé avec Oracle SGBD Microsoft SQL Server 2014 SP1

V2014.120.4100.1 Moteur de base de données.

Oracle database 12c R2 - 12.2.0.1* Moteur de base de données.

* ou à défaut 12c R1 - 12.1.0.2 si la dite version n’est pas disponible au moment de l’opération.

4.3.2. COMPOSANTS COMMUNS

Tableau 8 : Composants communs

Nom du composant Version Description JAVA 1.7 JVM Java BO 4.1 SP5 BO Apache HTTP server 2.2.15 Reverse proxy et client SSO mod_deflate - Module Apache de compression des flux mod_proxy, mod_proxy_ajp, mod_proxy_http - Module permettant la mise en œuvre de proxy pour

les protocoles HTTP et AJP

mod_proxy_balancer - Module d’équilibrage de charge (optionnel, dépend de l’architecture choisie)

mod_ssl - Chiffrement des flux

12 / 28

DEM-05-DAT

4.3.3. COMPOSANTS EBX

Tableau 9 : Composants EBX

Nom du composant Version Description Apache Tomcat 7.0 Serveur d’applications web Java EBX 5.6 MDM

Information Search 1.5 Add-on EBX de recherche sur les données Match & Cleanse 1.7 Add-on EBX de traitement de la qualité des données

SQL Connect - Fonctionnalité native de synchronisation de base de données

< DOMAINE > - Développement spécifique EBX concernant un domaine métier particulier

EhCache 2.10 Librairie Java de gestion de cache

4.3.4. COMPOSANTS IWAY

Tableau 10 : Composants iWay

Nom du composant Version Description ISM 7.0.3 Moteur ESB

< Application SINAPS_STD > - Application souche Sinaps standard (demi-flux au format pivot et transcodification)

< Application SINAPS_ETAB > -

Application pour l’établissement qui permet l’extension locale du format pivot. Cette application contiendra les développements spécifiques établissement dans iWay, c’est à dire l’ensemble des demi-flux des applications non-Amue développés par les établissements

<Archive sources SINAPS_ETAB> -

Cette archive contient le code source de l’application SINAPS_ETAB livrée à l’établissement. Il contient des exemples d’implémentation de demi-flux spécifiques. L’établissement peut s’en appuyer pour réaliser ces propres développements dans iWay

< Application BAM > - Application de supervision des flux qui transitent sur l’ESB

4.4. Disponibilité Sinaps ne nécessite aucun redémarrage de maintenance pour fonctionner dans la durée. Il ne présente donc aucune contre-indication à une utilisation en haute disponibilité. Il est possible d’opter pour une haute disponibilité applicative pour Sinaps EBX :

• Sinaps EBX dispose d’un mécanisme d’activation à distance permettant de mettre en place une architecture de « fail-over » si besoin : un second serveur EBX est installé en mode passif (inactif), de préférence sur un autre serveur physique, et branché sur la même base de données que le serveur EBX initial (actif). Un système de surveillance vérifie à intervalles réguliers l’accessibilité du serveur actif et peut, en cas de défaillance constatée, ‘réveiller’ le serveur passif à l’aide d’une simple URL, serveur qui peut alors prendre le relai des appels vers le MDM. Ce système de surveillance n’est pas proposé par Sinaps et doit être mis en place par l’établissement le souhaitant. Il s’agit d’un outil de surveillance / monitoring système et réseau. L’outil NAGIOS (par exemple) propose un mécanisme simple de vérification par appel d’URL appelé « check_http » permettant de savoir si un site est accessible. Il peut être utilisé dans le cadre de Sinaps.

13 / 28

DEM-05-DAT

Serveur actif Serveur passif

Système de surveillance (à développer) Interrogation à intervalle régulier du

serveur actif pour tester son état.

Légende

Activation du serveur passif en cas d’indisponibilité du serveur actif.

Accès à la même base de données.

Figure 3 : HA EBX

• Sinaps iWay dispose d’un mécanisme de HA de type backup par channel qui ne répond pas aux besoins de

Sinaps. En effet, l’hôte de backup contient en cas d’incident seulement les channels inopérants sur le serveur principal, les applications devraient donc elles-mêmes orienter les requêtes sur le serveur en bonne santé. Pour cette raison, ce mécanisme n’est pas retenu pour Sinaps.

Serveur ISM Actif

Point de montage réseau (Configuration,

Espace FTP, etc.)

Serveur ISM Actif

Channel B

Channel A

Backup Channel

Channel A

Channel B

Channel Actif dans ISM

Légende

Channel arrêté dans ISM

Accès à un système de fichier réseau.

Moteur de backupnatif

Channel à développer

SignalHeath check

Communication de l’état de santé du serveur principal

Instance principale Instance backup

Figure 4 : HA iWay

4.5. Paramétrage Sinaps est conçu pour pouvoir s’intégrer à n’importe quel SI d’établissement. Le paramétrage technique (ports d’écoute paramétrable, etc.) est décrit dans le dossier d’installation de Sinaps. Cela passe par l’usage de fichiers de propriétés. Le paramétrage fonctionnel est décrit dans le dossier de paramétrage. Le référentiel de paramétrage concerne quatre catégories de paramètres : identifiant de connexion, publication / souscription, identifiants fonctionnels et annuaire spécifique. La liste des exhaustives des paramètres liés à ces catégories se trouve dans le dossier de paramétrage.

14 / 28

DEM-05-DAT

4.6. Sécurité

4.6.1. ACCES A L'APPLICATION

Authentification Sinaps authentifie les accès humains, ainsi, si nécessaire les accès par flux (demi-flux spécifique établissement et applicatifs Amue).

IHM BAM

« Flux » interne Apache (ou exlusif)

Légende

Flux entre le reverseproxy et EBX/iWay

IHM ISM

« Flux » interne ISM de contrôle du compte dans le référentiel interne

Flux en relation avec une base de données

Mod_proxy

Mod_proxy_HTTP Mod_proxy_AJP

Référentiel de compte ISM

Channels

Mod_auth_shib

Mod_auth_cas

IHM EBX

Ajout du Remote_userdans le header fournit

par les clients SSO Apache

Contrôle de l’existence du compte

Contrôle du compte

Machine virtuelle ou physique

Navigateur client

« Frontière » entre Sinaps et le SI établissement

Applications SI établissement

FTP : Auth. native protocolaire

Flux entre le navigateur et le reverseproxy (HTTP)Flux entre les Applications établissements et les interfaces standard iWay FTP

SOAP

Flux entre EBX/iWay

Passe-platHTTP : Auth. HTTP Basic

Passe-platAuth. par formulaire

Passe-platAuth. HTTP Basic

Mod_SSL

Flux XML/RPC entre les App. établissements et reverseproxy

Dans la version cible de Sinaps, Le SSL sera positionné sur les flux

Figure 5 : Mécanismes d’authentification Sinaps

Les IHM Sinaps sont protégées par des mécanismes d’authentification :

• Sinaps-MDM pour ses IHM délègue à un tiers la responsabilité de l’authentification, un frontal d’accès Apache (client SSO) qui a la responsabilité de protéger les ressources et de les authentifier. Sinaps-MDM vérifie simplement que cette authentification a bien été faite. Techniquement, l’authentification pour les utilisateurs humains est assurée par un service SSO externe à Sinaps qui est en relation avec le client SSO afin qu’il renseigne un attribut particulier de l’entête http. La valeur de cet attribut (Remote_user) correspond à un vecteur d’identité qui permet d’effectuer un rapprochement d’identité fiable vis-à-vis de l’annuaire de compte de Sinaps-MDM.

15 / 28

DEM-05-DAT

La mise en place du frontal web avec une intégration au SSO est à la charge des établissements. Il est possible de mettre en place le serveur Apache et le module « mod_auth_cas » ou « mod_auth_shib » afin d’interfacer Apache et le SSO CAS. Ce module est capable d’ajouter dans l’entête http l’identité de l’utilisateur.

• Sinaps-ESB pour ses IHM fournit un mécanisme d’authentification standard qui s’appuie sur son référentiel de compte interne pour ISM et sur son référentiel en base de données pour la BAM.

Les flux Sinaps sont protégés en fonction de leur provenance par des mécanismes d’authentification :

• Tous les flux exposées aux formats pivots sont protégés par un mode d’authentification protocolaire « http basic ou FTP ». Sinaps-ESB, seul habilité à accéder aux web services exposés par Sinaps-MDM renseigne les entêtes SOAP que vérifie Sinaps-MDM.

• Les flux exposés par des tiers, en relation avec Sinaps, ont la responsabilité d’authentifier le flux.

Autorisation (gestion des droits) Tout utilisateur authentifié peut accéder à Sinaps, les droits étant gérés via les interfaces de ces derniers. Ci-après, les rôles gérés par EBX.

Tableau 11 : Rôles Sinaps

Remarque : iWay ne gère pas de rôle à proprement dit pour l’accès à ces IHM, il associe directement un ensemble de droit à un compte utilisateur.

4.6.2. DONNEES

Intégrité Les données présentes dans les différents points de vérité d’EBX ne sont pas modifiables directement, conformément au besoin exprimé par l’Amue, grâce à un développement spécifique. Leur manipulation nécessite la création d’espaces de données enfants de travail et la validation des données de ces espaces avant fusion avec les points de vérité (option native de fusion prévalidante sur les points de vérité), ce qui assure que toutes les données de ces points de vérité sont conformes aux règles métier.

Rôle Réf. Nomenc.

Conf. Nomenc.

Réf. Structures

Conf. Structures

Réf. Personnes

Doublons Personnes

Transco-difications Annuaire Para-

métrage Publication / Diffusion

Règles de gestion

Références croisées

LECT_NOMENC Lecteur nomenclature ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ GEST_APP_NOMENC Gestionnaire nomenclature ✔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ INT_REF_NOMENC Intendant nomenclature ✔ ✔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ INT_TRANSCO Intendant des transco. ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ✔ ⛔ ⛔ ✔ ⛔ ⛔ LECT_STR Lecteur structure ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ DEM_STR Demandeur structure ⛔ ⛔ ✎ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ INT_REF_STR Intendant structure ⛔ ⛔ ✔ ✔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ LECT_PER Lecteur personne ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ GEST_PER Gestionnaire personne ⛔ ⛔ ⛔ ⛔ ✔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ INT_PER Intendant personne ⛔ ⛔ ⛔ ⛔ ✔ ✔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ LECT_ANN Lecteur annuaire ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ INT_ANN Intendant de l’annuaire ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ✔ ⛔ ⛔ ⛔ ⛔ INT_PUB Intendant publication / sousc. ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ✔ ⛔ ⛔ INT_REF_CROIS Intendant références croisées ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ✔ INT_RG Intendant règles de gestion ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ✔ ⛔ INT_SOCLE Intendant Socle ⛔ ⛔ ⛔ ⛔ ⛔ ⛔ ✔ ✔ ✔ ✔ ✔ ✔

⛔ Aucun droit

Droit en lectureuniquement

✎ Droit en écritureuniquement dansun espace de travai

✔ Droit en écriture

16 / 28

DEM-05-DAT

4.6.3. CHIFFREMENT DES FLUX La solution Sinaps dans sa première version ne chiffre pas les flux. Dans une version cible de l’architecture, la totalité des flux opérationnels en correspondances directes avec l’utilisateur final ou l’applicatif sera chiffré. Cette évolution est prévue dans le cadre du projet Amue “Sinaps échange”. Pour ce faire, Il suffit d’ajouter le module SSL sur le frontal Apache et configurer le connecteur FTP fourni par iWay en SSL. Cette mise en œuvre garantit un chiffrement des flux entre les navigateurs clients et le frontal IHM Sinaps, ainsi qu’un chiffrement des communications entre les applicatifs et le frontal Sinaps ou le service FTP. Comme le présente la figure 6, seuls les flux opérationnels sont chiffrés, dès lors qu’un flux est dans « l’intranet Sinaps », une rupture protocolaire est assurée par le frontal Apache. Cette mise en œuvre facilite les configurations et déclare « l’intranet Sinaps » comme une zone de confiance. Cependant, le choix de l’usage de protocole sécurisé de bout en bout dans les échanges avec le SI ne peut être à la responsabilité de Sinaps. Les PSSI (Politique de Sécurité du SI) influent énormément sur la mise en œuvre ou non de ce système de sécurisation. Sinaps ne peut en effet aucunement garantir une sécurisation des flux de bout en bout sans une compatibilité protocolaire assurée par les tiers en relation.

4.7. Performances Une grande partie des performances de Sinaps-MDM repose sur les performances de la base de données. Il est donc impératif de respecter les bonnes pratiques recommandées en termes d’administration et de maintenance pour chaque type de moteur de bases de données utilisé. En particulier, Orchestra Networks recommande un calcul quotidien des indexes de la base de données à l’issue de la purge des espaces enfants fermés (cf. document intitulé kit d’exploitation de Sinaps). L’éditeur recommande également l’usage de la compression des flux http entre les postes clients et le serveur. Cela est assuré par la mise en place du module « mod_deflate » sur le serveur frontal Apache. Par ailleurs, les développements spécifiques mettent en œuvre l’usage d’un cache afin d’améliorer l’expérience des utilisateurs.

4.8. Scalabilité

4.8.1. SCALABILITE SGBDR Les scalabilités verticales (upgrade d’un serveur) ou horizontales (ajout de serveurs) sont possibles pour la base de données quel que soit le moteur choisi.

4.8.2. SCALABILITE EBX Seule une scalabilité verticale est possible avec EBX pour un référentiel donné en écriture, ce qui peut être rendu nécessaire par l’accroissement des règles métier et / ou l’augmentation du volume des données à traiter. EBX propose un mécanisme de scalabilité horizontale, basé sur la fonctionnalité D3 (Distributed Data Delivery), qui offre une répartition de charge sur les référentiels en lecture seulement. L’accès en écriture à un référentiel n’est possible qu’à partir d’un unique serveur. Pour cette raison la mise en œuvre de ce mécanisme pour Sinaps-MDM n’est pas retenue.

17 / 28

DEM-05-DAT

4.8.3. SCALABILITE IWAY iWay supporte la scalabilité horizontale, cependant cela dépend fortement des implémentations des connecteurs. En effet, à titre d’exemple, si l’usage de polling est réalisé dans le cadre de mise en œuvre d’acquisitions, ceux-ci ne sont pas scalables horizontalement. Seuls les listeners HTTP (écouteurs) d’iWay sont scalables horizontalement. Le connecteur FTP ne supporte pas la scalabilité Horizontale, il est par contre possible de répartir la charge en configurant un ensemble d’application pour interagir avec le nœud 1 et d’autres avec le nœud 2. Le schéma suivant présente une solution de scalabilité horizontale pour iWay-Sinaps :

Noeud1

IHM BAM

Légende

Flux HTTP entre le reverseproxy et iWay

IHM ISM


Mod_proxymod_proxy_balancer

(Round-robin)

Channels

SGBDR

JDBC


Navigateur client



FTP

Flux entre le navigateur et le reverseproxy (HTTP)

Flux entre les Applications établissements et les interfaces standard iWay FTP

XML/RPC



Mod_proxy_HTTP

Noeud2

IHM BAM

IHM ISM

Channels

XML/RPC

JDBC

Flux en relation avec un point de montage NFS ou CIFS pour les données iWay (Fichier de configuration, système de fichier FTP)

Stockage Réseau

Référentiel de compte ISM,

Système de fichier FTP

NFS ou CIFS

NFS ou CIFS

FTP

Figure 6 : Scalabilité horizontale pour iWay

4.8.4. SYNTHESE SCALABILITE ET DISPONIBILITE Les propositions d’architecture ci-dessous sont la déclinaison des préconisations des éditeurs. Ces architectures doivent être adaptées au contexte SI de chaque établissement. Nous préconisons la mise en œuvre d’une étape de prototype validant la solution dans son contexte cible.

18 / 28

DEM-05-DAT

Tableau 12: Synthèse scalabilité et disponibilité

iWay EBX BDD

HA

Non supporté Préconisation d’usage des infrastructures (CF. 6.2 Disponibilité)

Supporté par deux procédés : • Applicatif : Demande

la mise en œuvre d’un mécanisme de contrôle de la disponibilité du serveur maître tel que Nagios. (cf. 5.3 Disponibilité)

• Infra : Cf. 6.2 Disponibilité

Supporté, cf. recommandation des éditeurs Oracle et Microsoft.

Scalabilité verticale

Supporté cf.6.1 Dimensionnement Supporté cf.6.1 Dimensionnement Supporté cf.6.1

Dimensionnement

Scalabilité horizontale

Supporté mais avec certaines limitations (cf. 5.7.3)

Non supporté en écriture. Nous préconisons de ne pas mettre en place le mécanisme.

Supporté, cf. recommandation des éditeurs Oracle et Microsoft.

4.9. Pré requis des postes utilisateurs

4.9.1. SINAPS-MDM

Navigateurs supportés Sinaps-MDM est accessible à travers un navigateur, seuls les navigateurs suivants sont supportés: Microsoft Internet Explorer 8, 9, 10, 11:

• Le mode compatibilité n’est pas supporté. • Limitations de performance : le chargement d’une page sous IE8 est généralement 20 fois plus lent qu’avec les

autres navigateurs ; sous IE9, IE10 et IE11, le chargement des pages est 2 fois plus lent. Ce problème est principalement observé lors de l’affichage de formulaires avec plusieurs champs à renseigner.

Mozilla Firefox 3.6 et supérieur

• En raison de la fréquence des mises à jour de Mozilla Firefox, seule la version 3.6 est pleinement supportée. Orchestra Networks et le titulaire ciblent leurs efforts de tests pour supporter les dernières versions disponibles.

Google Chrome

• En raison de la fréquence des mises à jour et de l’impossibilité de désactiver les mises à jour automatiques, Orchestra Networks et le titulaire ciblent leurs efforts de tests pour supporter les dernières versions disponibles.

Résolution d’écran La résolution d’écran minimale est 1024x768 pixels, seul le zoom par défaut (100%) du navigateur est supporté.

Rafraîchissement des pages Le rafraîchissement forcé (F5 ou fonction « Actualiser la page ») des pages dans le navigateur n’est pas supporté. Quand un rafraichissement forcé a lieu la dernière action de l’utilisateur est ré-exécutée, ce qui peut entrainer un comportement non souhaité. Il est impératif d’utiliser les boutons d’action et les liens présents dans l’interface au lieu d’utiliser un rafraîchissement forcé.

19 / 28

DEM-05-DAT

Configuration du navigateur Les fonctionnalités suivantes doivent être activées dans le navigateur afin de permettre à l’application de fonctionner correctement :

• JavaScript • Ajax • Pop-ups.

20 / 28

DEM-05-DAT

ARCHITECTURE PHYSIQUE (INFRASTRUCTURE)

4.10. Dimensionnement

4.10.1. SYSTEMES

Production Les dimensionnements présentés sont catégorisés suivant la règle suivante :

• Etablissement petit : moins de 10 000 étudiants

Tableau 13: Dimensionnement de l'environnement de production pour un établissement petit

iWay EBX* BDD**

Processeur Intel x64/x86 4 cores

Intel x64/x86 4 cores


RAM 6 GB Ram 8 GB 12 GB Ram

HDD 72 GB HDD RAID 100 GB (de préférence en SAN) 250 GB *** (de préférence en SAN)

• Etablissement moyen : 10 001 à 30 000 étudiants

Tableau 14: Dimensionnement de l'environnement de production pour un établissement moyen

iWay EBX* BDD**




RAM 8 GB Ram 16 GB Ram extensible à 128 16 GB Ram


• Etablissement grand : 30 001 à N étudiants

Tableau 15: Dimensionnement de l'environnement de production pour un établissement grand

iWay EBX* BDD**




RAM 12 GB Ram 16 GB Ram extensible à 128 32 GB Ram


* EBX ne disposant pas de possibilité de scalabilité horizontale, il est impératif de prévoir un serveur extensible dans les échelles fournies afin de pouvoir s’adapter aux évolutions des différents chantiers (nombre de règles métier supplémentaires, espace de données supplémentaires essentiellement). ** Le nombre de CPU doit être extensible pour pouvoir s’adapter aux opérations multiples sur la table des pointeurs (impacts sur la table et les index associés). Par ailleurs, le serveur de BDD doit être un serveur dédié (pas de serveur mutualisé) et il ne doit y avoir qu’un seul schéma par base de données (i.e. par instance EBX). L’estimation en terme de « d’espace de stockage disque » est propre à chaque contexte établissement, certains ayant une volumétrie plus importante que d’autres. Cette valeur est donc à ajuster en fonction des établissements en se basant sur les informations fournies dans le dossier d’exploitation. *** Il est préconisé un dimensionnement à 250 GB pour l’espace disque alloué aux bases de données. Ce dimensionnement permet de prévenir la volumétrie importante de données stockées lors des phases de mise en qualité et de pic d’utilisation de la solution Sinaps.

21 / 28

DEM-05-DAT

Dimensionnement des environnements hors production

Tableau 16 : Dimensionnement des environnements hors production

EBX iWay BDD


Intel x64/x86 1 core


RAM 8 GB Ram 8 GB Ram 16 GB Ram HDD 50 GB 50 GB 250 GB

En ce qui concerne l’environnement de pré production, dans l’idéal il doit être identique à celui de production (CF. 4.1.1 Systèmes). En fonction des politiques internes du SI, il possible de dimensionner l’environnement de pré production à l’identique du développement.

4.10.2. SAUVEGARDE EBX doit pouvoir sauvegarder 30 jours de logs et d’historique de transactions, soit environ 100 Go de données. Les 30 jours de logs permettent de pouvoir investiguer sur l’origine d’un problème. L’exécution d’un workflow peut durer plusieurs jours en fonction de la disponibilité des personnes. Il est donc important d’avoir accès aux logs sur une période importante. Ces logs sont parfois demandés par l’éditeur Orchestra Network s’il est sollicité. La taille des logs dépend de l’activité qu’aura l’établissement sur Sinaps. Elle est donnée à titre indicative et devra être affinée par chaque établissement en fonction de l’activité Sinaps. Pour cette raison, une estimation est possible seulement en réalisant des calculs entre le poids d’un enregistrement métier et le nombre d’enregistrement potentiellement candidat. Cette opération est à effectuer sur chaque référentiel, la somme des résultats obtenus apporte une approximation valable de l’espace à prévoir. CF. Le dossier d’exploitation pour plus de précision sur les calculs d’estimation.

4.10.3. RESEAU La bande passante réseau intranet minimale conseillée est le Giga bit/s. Elle concerne l’ensemble des flux internes Sinaps et les flux inter Sinaps /application établissement. Il est également recommandé comme spécifié dans le chapitre sur les performances, d’activer la compression des flux http entre les postes clients et le serveur.

4.11. Contraintes / environnements

22 / 28

DEM-05-DAT

Sinaps repose sur quatre environnements pour garantir le bon cycle de vie de ses livrables en SI établissement. Certaines contraintes sont à prendre en compte pour éviter d’altérer leur intégrité.

Tableau 17 : Contraintes/environnements

Contraintes Description

Machine

Il est fortement conseillé de dédier des machines virtuelles ou physique à chaque environnement. Quatre machines par environnement doivent être attribuées. Il est ainsi interdit pour un environnement donné de mutualiser les services entre eux sur une machine qu’elle soit virtuelle ou physique. On ne doit donc pas disposer par exemple du service iWay sur la même machine que le serveur EBX. Il est également interdit de mutualiser les environnements. On ne doit donc pas par exemple héberger le service iWay de développement sur la même machine que le service iWay de production. Le seul cas particulier où l’on peut réduire le nombre de machine dédié à un environnement concerne la machine du moteur de base de données. Il est autorisé, bien que non recommandé, de mutualiser l’ensemble des bases de données Sinaps des environnements non opérationnels (hors production) sur le même serveur.

Réseau

Dans l’idéal, les environnements sont sur des VLAN dédiés. Cet isolement garantie qu’une erreur de configuration de type « employer une ressource d’un autre environnement » pour un environnement donné ne passe pas inaperçu. L’erreur est ainsi identifiée au plus tôt sans remettre en cause l’intégrité des données.

Utilisateur BDD Dédier des utilisateurs pour chaque schéma de base de données (BAM et EBX). Cela permet de réduire le risque d’usage d’un schéma inapproprié.

4.12. Disponibilité En fonction des infrastructures établissements de virtualisation, il est possible de faire supporter par l’infrastructure la haute disponibilité de Sinaps (Ex. HA VMware). Ce mode de haute disponibilité répond à des fonctions de fail-over par l’intermédiaire de machines virtuelles passives configurées à l’identique des actives et qui prennent le relai en cas de défaillance. Nous préconisons particulièrement l’emploi de ce mécanisme pour le service. 4.13. Modèle d’architecture Deux modèles d’architectures sont présentés ci-après. Le premier permet de mettre en œuvre Sinaps d’une manière simple avec une « haute disponibilité » assuré par l’infrastructure (HA fournie par l’hyperviseur). Le second modèle est plus robuste et emploi toutes nos recommandations pour Sinaps.

4.13.1. MODELE D’ARCHITECTURE SIMPLE

23 / 28

DEM-05-DAT

VM iWay (HA)

IHM BAM

Légende

Flux HTTP entre le reverseproxy et iWay/Ebx

IHM ISM


VM Apache (HA)

Mod_proxy

Channels

SGBDR (HA)

JDBC

Machine virtuelle ou physiqueNavigateur client



FTP



XML/RPC



Mod_proxy_HTTP

JDBC

VM Ebx (HA)

IHM EBXSOAP

Nagios

ContrôlesAlertes

Haute disponibilité assurée par l’infrastructureHA

Figure 7 : Modèle d'architecture simple

4.13.2. MODELE D’ARCHITECTURE RECOMMANDE

24 / 28

DEM-05-DAT

VM iWay 1

IHM BAM

Légende

Flux HTTP entre le reverseproxy et iWay/Ebx

IHM ISM


VM Apache (HA)

Mod_proxy

Channels

SGBDR

JDBC


Navigateur client



FTP



XML/RPC



Mod_proxy_HTTP

VM iWay2

IHM BAM

IHM ISM

Channels

XML/RPC

JDBC

Flux en relation avec un point de montage NFS ou CIFS pour les données iWay (Fichier de configuration, système de fichier FTP)

Stockage Réseau

Référentiel de compte ISM,

Système de fichier FTP

NFS ou CIFS

NFS ou CIFS

FTP

VM Ebx Maître

IHM EBX

mod_proxy_balancer (Round-robin)

SOAP SOAP

JDBC

VM Ebx Backup

IHM EBX

Nagios

ContrôlesAlertes

Figure 8 : Modèle Sinaps recommandé

4.14. Réseau (LAN / WAN) Ce chapitre présente deux solutions d’organisation réseau de Sinaps dans le SI établissement. La première solution est une proposition d’un découpage en VLAN par composant applicatif pour mieux identifier et protéger les ressources en fonction de leur niveau d’exposition :

25 / 28

DEM-05-DAT

Poste utilisateurVLAN Frontoffice Sinaps

VM MDM

VM ESBPare-feu

VLAN utilisateurs

8009

443,99080,21

VM frontal Apache

44380

VM Base de données 15211433

VLAN Applicatifs établissements

VLAN Middleware Sinaps

Pare-feu

VLAN Backoffice Sinaps

Pare-feu

Pare-feu

Vlan (réseau local virtuel)

Machine virtuelle

Légende

Figure 9 : Organisation réseau optimale

La seconde solution correspond à une solution simplifiée qui fait appel à un découpage logique sur un nombre limité de VLAN :

Poste utilisateur

VLAN Frontoffice

VM MDM

VM ESB

Pare-feu VLAN utilisateurs

8009

443,99080,21

VM frontal Apache 44380

VM Base de données 15211433

VLAN Backoffice

Pare-feu

Pare-feu

Vlan (réseau local virtuel)

Machine virtuelle ou physique Sinaps

Légende

VM(s) applications établissements backend

VM(s) applications établissements frontend

Machine virtuelle ou physique existante dans le SI

Figure 10 : Organisation réseau simplifiée

26 / 28

DEM-05-DAT

5. DESCRIPTION DES ENVIRONNEMENTS Trois environnements sont nécessaires pour assurer le cycle de vie du produit Sinaps :

• L’environnement de mise en qualité (MEQ), permet au branchement d’une nouvelle d’une application métier à Sinaps de :

o mettre en qualité les données de l’application o initialiser le paramétrage Sinaps avant de le déverser sur les environnements de PPD et PRD

• L’environnement de pré production (PPD) permet de vérifier le bon fonctionnement d’une version de Sinaps avant son passage en production

o Sinaps PPD doit pouvoir être rafraichis régulièrement à partir de Sinaps PRD o Sinaps PPD doit être connecté aux applications métiers de PPD ou PRD

• L’environnement de production (PRD) exécute une version opérationnelle de Sinaps en connexion avec les applications métiers de production

6. ABREVIATIONS ET GLOSSAIRE

6.1. Glossaire des termes Scalabilité : en informatique la scalabilité désigne la capacité d'un environnement à s'adapter à un changement d'ordre de grandeur de la demande, en particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande (source Wikipédia). Utilisabilité : l’utilisabilité ou aptitude à l'utilisation est définie par la norme ISO 9241-11 comme « le degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte d’utilisation spécifié ». C'est une notion proche de celle d'affordance, ou même d’ergonomie qui est cependant plus large. Les critères de l’utilisabilité sont :

• l’efficacité : le produit permet à ses utilisateurs d’atteindre le résultat prévu. • l’efficience : atteint le résultat avec un effort moindre ou requiert un temps minimal. • la satisfaction : confort et évaluation subjective de l’interaction pour l’utilisateur.

6.2. Abréviations DFD : Diagramme de Flux de Données ESB : Enterprise Service Bus ISM : iWay Service Manager BAM : Business Activity Monitor IIA : iWay Integration Application ITA : iWay Template Application

7. DOCUMENTS DE REFERENCE ISO/IEC/IEEE 42010 : Systems and software engineering - Architecture description (Ingénierie des systèmes et des logiciels — Description de l'architecture). ISO 9241-11:1998 : Exigences ergonomiques pour travail de bureau avec terminaux à écrans de visualisation (TEV) - Partie 11 : Lignes directrices relatives à l'utilisabilité.

8. ANNEXES Sans objet.

27 / 28

DEM-05-DAT

SUIVI DOCUMENTAIRE Information sur le document

Nom du document DAT – Dossier d’Architecture Technique

Base documentaire Spécifique projet Sinaps

Validation du document

Version Date Nom Fonction / Service

1.0 24/11/2016 Amue – Renaud THEY Consultant Sinaps



Diffusion du document

Nom Fonction / Service

Tous les établissements n/a

Historique des versions

Version Date Rédacteur Description

1.0 11/08/2015 ATOS – Gilles COUDERT ATOS – Patrick VINCENTI Création du document

1.2 12/09/2016 ATOS – Gilles COUDERT ATOS – Patrick VINCENTI

Ajout des prérequis des postes utilisateurs de SINAPS MDM. Ajout de la liste des services exposés dans le chapitre Flux de données.

1.5 19/09/2016 Amue – Renaud THEY

Correction du chapitre sur les versions OS/SGBD. Anticipation montée de version 2017 Suppression du frontal apache et modification des versions OS et SGBD Ajout du détail des flux entre SINAPS et produits AMUE Modification de la description des environnements

1.6 13/10/2016 ATOS – Charles MANCUSO Mise à jour du dimensionnement des HDD pour les serveurs de BDD

1.7 27/10/2016 ATOS – Charles MANCUSO Ajout d’un commentaire sur le dimensionnement des HDD pour les serveurs de BDD

1.8 25/11/2016 Amue – Valérie SIMONNET Mise en forme

1.9 02/11/2016 Amue – Renaud THEY Mise en forme et corrections mineures suite à la relecture de la MIRE

28 / 28

DEM-05-DAT

Modifications depuis la dernière version

Paragraphe Page Nature de la modification

Documents

Dossier d’Architecture Technique...• Un serveur SSO pour l’authentification et la protection des accès aux IHM EBX : il s’agit d’un simple paramétrage d’un module au