SGE – Système de Gestion des Echanges - Portail

1. SGE – Système de Gestion des Echanges - Portail Proposition technique GSA/EUC/2003/091/CDM V1.1 Réponse à l'appel d'offres COL-SGE-DC-001-04du 01/08/2003.

2. Application GMEC - Solution V0.1 Solution fonctionnelle V0.1 Solution technique V0.1

3. Solution fonctionnelle V0.1 Architecture fonctionnelle Présentation de la solution

4. Solution fonctionnelle V0.1 Architecture fonctionnelle Système GMEC V0.1 Authentification Gérer les Modules Gérer les Processus Gestion des tâches Workflow - Relances Gestion des modules (DI, DR, PEE, REE, FDM, DES, Documents impactés, Ecarts et Réserves, DEM) Gérer les processus Workflow (DI, DR, Suivi des travaux, Gestion des Ecarts et Réserves, Gestion des modifications locales, Gestion des Contrats) Administration locale et nationale Partage de données entre les Equipes Communes Editions de Données et Requêtes Import de Données Export de Données Reporting sous BO Interfaces avec les différents sous-systèmes 25/09/03 – SGE - Portail – Proposition Technique / Page 4

5. INTERNET DMZ EXTERNE DMZ INTERNE INTRANET ETENDU Solution fonctionnelle V0.1 Architecture générale V0.1Schéma d’architecture des flux simplifié Composants hors périmètre HTTP Plate-forme Portail SGE V0.1 Serveur SMTP (messagerie) SMTP HTTP Serveur HTTP Apache HTTP WebLogic Portal Annuaire LDAP LDAP HTTP W4 Servlet RMI/IIOP RMI/IIOP W4 Engine EJB SGBD Oracle Métier SGBD W4 Oracle Acteurs internes 25/09/03 – SGE - Portail – Proposition Technique / Page 5

6. Solution fonctionnelle V0.1 Présentation de la solutionF : Gérer les Processus workflow • Les habilitations d’accès aux différents workflows sont gérées : • de façon générale au niveau de l’application ( en fonction du profil de l’acteur dans la base métier) pour l’affichage des menus en fonction du profil de l’utilisateur. Si l’utilisateur est habilité sur un ou plusieurs processus workflow, un lien dans le menu de l’application GMEC lui permet d’accéder à la gestion des processus (liste des tâches à réaliser – relances). • de façon fine au niveau d’un processus. Par exemple l’habilitation nécessaire à la création d’un processus défini est réalisée au sein même du module de workflow, au travers du rôle de cet utilisateur dans le processus de workflow. • La gestion des actions de type workflow d’un utilisateur au niveau d’un processus sera réalisée à partir de ses rôles définis dans la base W4 Gestion Processus Gestion des Modules Utilisateur Processus 1 Processus 2 Authentification W4 Processus 3 Gestion fine des actions de l’utilisateur en fonction de ses rôles dans W4 Liste des tâches 25/09/03 – SGE - Portail – Proposition Technique / Page 6

7. Présentation de la solutionF : Gérer les Modules • Les habilitations d’accès aux différents modules sont gérées : • de façon générale au niveau de l’application pour le droit d’accès à GMEC (authentification), aux différents modules (DI, DR, etc) et à l’administration locale et/ou nationale. Si l’utilisateur est habilité sur un processus workflow, un lien dans le menu de l’application lui permet d’accéder à la gestion des processus workflow. • De façon fine, au niveau de la gestion des modules, l’authentification de l’utilisateur permet de déterminer la base de donnée locale qui lui est rattachée, en fonction de son équipe commune de rattachement. Gestion des Modules Gestion des Processus Utilisateur Module 1 Gestion fine des habilitations de l’utilisateur (profils) Module 2 Authentification automatique Administration Gestion fine des rôles sur les processus Workflow au niveau W4 Accès Worflow 25/09/03 – SGE - Portail – Proposition Technique / Page 7

8. Solution fonctionnelle V0.1 Présentation de la solutionF6 : Administration locale / nationale • L’habilitation de l’utilisateur Cette fonctionnalité doit permettre à l’utilisateur de réaliser l’administration, de la base locale en fonction de son équipe commune de rattachement. • Une liste des événements à tracer est définie. Chaque événement déclenche une trace indiquant le type d’événement, l’utilisateur à l’origine de l’action, la date et l’heure, le détail éventuel de l’événement (par exemple : « consultation du message M00023 »). Evénements Utilisateur Evénement 1 Evénement 2 Evénement 3 25/09/03 – SGE - Portail – Proposition Technique / Page 8

9. Solution fonctionnelle V0.1 Présentation de la solutionF9 : • Les workflows métiers (processus) proprement-dits sont modélisés à partir de l’outil de modélisation W4 Studio, puis publiés sur le serveur W4. • Les acteurs ainsi que les rôles pour la gestion des processus sont définis dans la base de donnée du workflow. Les utilisateurs accédant à l’application GMEC doivent s’authentifier via la saisie d’un identifiant utilisateur et d’un mot de passe. Cette authentification est définie au sens LDAP et Workflow. • Une fois authentifié, le système définit l’espace local auquel l’utilisateur a accès : visualisation de ses données sur son espace local. L’utilisateur se connecte à GMEC 2 1 Les informations sur son profil permettent de déterminer l’espace local auquel il a accès Les informations concernant l’utilisateur (rôle workflow) permettent de définir les processus et tâches associées Page d’accueil personnalisée 25/09/03 – SGE - Portail – Proposition Technique / Page 9

10. Solution technique V0.1 Architecture générale Mécanismes applicatifs Architecture technique

11. Solution technique V0.1 Architecture générale Schéma d’architecture générale du portail V0.1 (*) Navigateur Web : Internet Explorer 5.0 à 6 Acteurs externes Acteurs internes INTERNET INTRANET HTTPS HTTP Plate-forme SGE V0.1 (Solaris 8) Serveur HTTP Apache 1.3.19 Plug-in WebLogic Sous-système WORKFLOW Annuaire d’authentification EDF Weblogic Server 6.1 SP2 HTTP Serveur de messagerie Sous-système EAI/B2B WebLogic Portal 4.0 SP2 SMTP RMI/IIOP LDAP Serveur d’EJB Weblogic Server  Système de fichiers Serveur de données Oracle 8.1.7 FTP Certificat Serveur 25/09/03 – SGE - Portail – Proposition Technique / Page 11

12. Solution technique V0.1 Mécanismes applicatifs Gestion de contenu V0.1 – 1/2 • La mise en place de Documentum n’est pas prévue dans le cadre de la V0.1 du portail SGE. • Une architecture temporaire est donc mise en place pour la gestion des contenus de cette version (Outils transverses, contenus éditoriaux, guides et autres documents). Cette architecture, qui vise à minimiser les impacts liés au passage à Documentum, est décrite page suivante. • Toutefois, CGE&Y recommande la mise en œuvre de Documentum dès la V0.1 du portail afin de l’intégrer dès le démarrage à l’architecture du projet : • Cette mise en œuvre permet d’intégrer dès la V0.1 les mécanismes d’accès à l’outil de gestion de contenu. Ces mécanismes sont réalisés au travers du contentSelector BEA et du eConnector Documentum. Ces composants, déjà utilisés sur d’autres projets EDF, sont complètement maîtrisés par CGE&Y. • L’intégration n’a pas d’impact en terme de délais sur le projet, la mise en place de Documentum pouvant être gérée de façon assez séparée du reste du système. • La mise en place prévue dans le cadre de la V0.1 vise essentiellement l’intégration de contenus statiques (pas de gabarits, utilisation du workflow standard du produit). Ces fonctions de base seront ensuite enrichies au fur et à mesure des versions : personnalisation fine des contenus, développement de gabarits, workflow de validation des documents… • Documentum permettra une première prise en main par les contributeurs et un retour d’expérience dès la V0.1. • La mise à jour du site pourra être réalisée de façon autonome par EDF, ce qui apporte une plus grande souplesse d’administration. • La modification graphique et/ou ergonomique de différents modèles de présentation des contenus est facilement impactée sur l'ensemble des contenus existants, ce qui peut faciliter l’application de la charte graphique SGE lors des développements de la V0.2. CGE&Y propose d’étudier avec EDF les conditions de mise en place de Documentum dès la V0.1. 25/09/03 – SGE - Portail – Proposition Technique / Page 12

13. Solution technique V0.1 Mécanismes applicatifs Gestion de contenu V0.1 – 2/2 • De la même façon qu’un système Documentum classique, la gestion de contenu en V0.1 repose sur : • une base Oracle dans laquelle sont stockées les informations liées aux documents : titre du document, chemin d’accès, propriétés liées à la personnalisation. • un système de fichier dans lequel sont placés les documents : fichiers HTML, documents Word… • L’affichage des documents aux utilisateurs est réalisé en deux étapes : • La sélection des documents est réalisée au travers d’une table de propriétés qui prend en compte les spécificités de l’utilisateur connecté. Il s’agira par exemple d’afficher à un utilisateur uniquement les guides d’implémentation des flux auxquels il a accès. • Une fois le ou les document(s) identifié(s), ils sont récupérés à partir du système de fichier via le eConnector Documentum. • Afin de minimiser l’impact de la mise en place de Documentum en V0.2, la sélection des contenus est réalisée de la même façon que pour un accès à une base Documentum Webcache : utilisation du contentSelector BEA et du eConnector Documentum. La base de données contenant les propriétés des documents a donc une structure identique à celle d’une base Webcache. • La mise à jour des contenus implique une re-livraison des fichiers impactés sur la plate-forme de production. L’ajout de documents requiert la mise à jour de la base via des ordres SQL classiques. Portail SGE V0.1 Portail SGE V0.2 1 Requête de sélection des documents à afficher Propriétés Webcache contentSelector BEA + eConnector Portail SGE 2 Récupération des fichiers à afficher 25/09/03 – SGE - Portail – Proposition Technique / Page 13

14. Solution technique V0.1 Mécanismes applicatifsPropagation de l’authentification aux sous-systèmes – Présentation • Ce mécanisme doit permettre l’intégration des sous-systèmes Workflow et EAI/B2B dans l’architecture SGE, le portail étant le point d’accès à ces deux sous-systèmes. • Chaque sous-système possède sa propre gestion des utilisateurs et des habilitations. Afin d’éviter une re-saisie par l’utilisateur du portail de ses identifiant et mot de passe, l’authentification est propagée par le portail vers ces applications via l’utilisation de l’identifiant (login) de l’utilisateur. • Suite à cette authentification automatique, chaque sous-système a en charge la gestion des habilitations de l’utilisateur connecté. • Les applications Workflow et EAI/B2B s’affichent dans les écrans du portail sous la forme de composants de type Portlet. Ce qui implique le respect de la charte du site par ces applications ainsi que d’un certain nombre de normes de développement qui sont à définir dans le cadre de la conception technique du Portail SGE V0.1 (réalisation du modèle d’application W4). Sous-système 1 Portail SGE Utilisateur Re-direction de l’appel vers le sous-système Le login utilisateur est envoyé au sous-système sous la forme d’un cookie dans le header HTTP Le cas échéant, le sous-système ouvre une session pour l’utilisateur à partir du login envoyé (lors du premier appel par exemple). Puis il renvoie la page demandée au portail. Appel d’un service sous-système 1 Le flux HTML est encapsulé sous la forme d’une portlet dans l’interface du portail et renvoyé à l’utilisateur Le service demandé est renvoyé au portail sous la forme d’un flux HTML 25/09/03 – SGE - Portail – Proposition Technique / Page 14

15. Solution technique V0.1 Mécanismes applicatifsPropagation de l’authentification aux sous-systèmes – Solution 1 • Une première solution, telle que décrite dans le dossier d’architecture SGE, consiste à utiliser un composant de type WebClipping qui re-dirige les appels aux différents sous-systèmes en mode HTTP : Composants hors périmètre INTERNET Serveur HTTP Apache Composants du module de re-direction DMZ EXTERNE HTTP WebClipping WebLogic Portal DMZ INTERNE RMI/IIOP EJB HTTP SGBD Oracle Filtre flux HTTP INTRANET ETENDU HTTP Sous-système EAI/B2B ou WORKFLOW 25/09/03 – SGE - Portail – Proposition Technique / Page 15

16. Solution technique V0.1 Mécanismes applicatifsPropagation de l’authentification aux sous-systèmes – Solution 2 • Dans cette seconde solution, un composant de type Servlet et un EJB de re-direction sont développés pour re-diriger les appels à ces sous-systèmes : Composants hors périmètre INTERNET Serveur HTTP Apache Composants du module de re-direction DMZ EXTERNE HTTP Servlet de re-direction WebLogic Portal DMZ INTERNE RMI/IIOP EJB RMI/IIOP SGBD Oracle INTRANET ETENDU Sous-système EAI/B2B ou WORKFLOW EJB HTTP 25/09/03 – SGE - Portail – Proposition Technique / Page 16

17. Solution technique V0.1 Mécanismes applicatifsPropagation de l’authentification aux sous-systèmes – Conclusion • La solution 1, à base d’un composant WebClipping impose l’ouverture d’un flux HTTP entre la DMZ Interne et l’Intranet RIN, et donc l’introduction d’un dispositif supplémentaire pour la sécurisation de ce flux. • La solution 2, à base d’une Servlet et d’un EJB de re-direction, est basée sur un flux autorisé (RMI/IIOP) mais nécessite l’installation d’une WebApplication au niveau de l’Intranet RIN pour la réception de l’EJB de re-direction. • Ces deux solutions ont déjà été mises en œuvre par CGE&Y sur des projets EDF. CGE&Y propose d’étudier avec EDF parmi ce deux solutions, celle qui est la mieux adaptée au contexte du portail SGE et des contraintes d’architecture EDF. La solution retenue sera ensuite implémentée par CGE&Y lors de la réalisation du portail SGE V0.1. 25/09/03 – SGE - Portail – Proposition Technique / Page 17

18. Solution technique V0.1 Mécanismes applicatifsModèle d’application W4 • Parallèlement à la réalisation du composant de re-direction vers les sous-systèmes SGE, un modèle d’application W4 est développé par l’équipe CGE&Y afin de : • valider le fonctionnement du composant de re-direction, notamment la propagation des informations de connexion vers W4 et la bonne intégration du sous-système au sein du portail ; • définir les règles de développement qui devront être respectées par le chantier Workflow. • Ce modèle d’application doit permettre de définir les règles de développement des processus W4 qui alimenteront le portail au fur et à mesure de la réalisation du chantier Workflow : • contraintes techniques liées à l’authentification à partir du portail : mode de réception des identifiants, paramètres de session… • contraintes de développement liées à l’intégration de l’application Workflow : gestion du multi-fenêtrage, intégration des appels de type MultipartRequest (upload et download de fichiers), JavaScript… • contraintes liées au respect de la charte graphique du portail : feuille de style, images… • Un cahier des charges technique est réalisé à destination des équipes de réalisation du chantier Workflow afin d’intégrer l’ensemble de ces contraintes et règles de développement. • Ce cahier des charges intègre également une notice d’installation et de paramétrage du composant de re-direction. 25/09/03 – SGE - Portail – Proposition Technique / Page 18

19. Solution technique V0.1 Mécanismes applicatifsInterface EAI/B2B • L’interface entre le portail SGE V0.1 et le sous-système EAI/B2B doit permettre aux utilisateurs de visualiser et télécharger les fichiers qui leur sont adressés (données de facturation, de consommation et bilans globaux). • Cette interface peut être réalisée de deux façons : Solution 1 : les fichiers et leur description (titre, utilisateur destinataire…) sont envoyés par l’EAI/B2B sur un serveur du portail (machine Weblogic située sur l’Intranet étendu). Un composant est développé au niveau du portail, qui accède à ces fichiers et restitue la liste de ceux destinés à l’utilisateur connecté. Solution 2 : le projet EAI/B2B développe sont propre composant de visualisation et de téléchargement des fichiers. Ce composant est alors présenté dans le portail SGE sous la forme d’une portlet via le composant de re-direction. Utilisateur Portail SGE Utilisateur Portail SGE  Sous-système EAI/B2B Sous-système EAI/B2B Composant de re-direction HTTP FTP HTTP HTTP  Le sous-système EAI/B2B dépose régulièrement les fichiers via FTP sur le serveur du portail. Un traitement permet l’intégration de ces fichiers dans la base du portail. Les fichiers sont ensuite restitués à l’utilisateur sous la forme d’un écran applicatif. La demande de l’utilisateur est re-dirigée vers le service de téléchargement de la brique EAI/B2B. Ce service apparaît dans l’interface du portail au sein d’une portlet. La solution retenue sera définie lors de la phase de conception technique du système. CGE&Y implémentera la solution choisie. 25/09/03 – SGE - Portail – Proposition Technique / Page 19

20. Mécanismes applicatifsSolutions choisies par EDF (*) • Suite à la production du cahier des charges du projet SGE et à l’oral du 27/08/2003, EDF a avancé sur un certain nombre de points techniques : • Concernant la solution de « Propagation de l’authentification aux sous-systèmes » : • La solution 2, basée sur un composant de type Servlet et un EJB de re-direction, requiert la localisation des sous-systèmes cibles (EAI/B2B et Workflow) au niveau de l’Intranet Etendu. En effet, le flux de type RMI/IIOP n’est pas autorisé entre l’Intranet Etendu et le RIN. Cette solution n’est donc pas envisageable puisque le sous-système EAI/B2B se situe au niveau du RIN. • La solution 1, à base d’un composant WebClipping et d’un filtre flux HTTP est donc la solution retenue. • Concernant l’ « Interface EAI/B2B » : • La solution 2, consistant à déléguer l’interface de consultation des fichiers mis à disposition au niveau du sous-système EAI/B2B n’est pas envisageable. • La solution 1 est donc retenue : le sous-système EAI/B2B dépose les fichiers au niveau du portail, ce dernier réalise l’ensemble des traitements nécessaire à l’intégration de ces fichiers et fournit l’interface de consultation. 25/09/03 – SGE - Portail – Proposition Technique / Page 20

21. Solution technique V0.1 Mécanismes applicatifsGénération des traces • Ce mécanisme a pour objectif de tracer un certain nombre d’événements réalisés dans l’interface du portail par les utilisateurs. La liste des événements à tracer est à définir au cours de la phase de conception du portail V0.1. • CGE&Y propose de s’appuyer sur le système de suivi comportemental standard de Weblogic Portal, qui permet : • de tracer des événements standards, par exemple la connexion ou la déconnexion d’un utilisateur ; • de définir des événements spécifiques à l’application, par exemple, tracer l’appel à un écran de consultation, tracer la visualisation d’un document (ex : guide d’implémentation), tracer l’appel à un service d’un sous-système… • L’ensemble des événements est enregistré en mode asynchrone afin de ne pas impacter les performances du système. • Les événements sont stockés dans un schéma Oracle spécifique, indépendant du schéma applicatif, ce qui facilitera l’évolution et l’interfaçage vers le futur sous-système « traces, supervision, archivage ». 25/09/03 – SGE - Portail – Proposition Technique / Page 21

22. LDAP Base de donnée Solution technique V0.1 Mécanismes applicatifsGestion des profils utilisateurs • Les profils utilisateurs sont gérés par Weblogic Portal au travers du module UUP (Unified User Profile). UUP permet de créer une vue uniforme et homogène des caractéristiques des utilisateurs issues de différentes sources hétérogènes. • L’ensemble des informations caractérisant un utilisateur est remonté en mémoire dans la session utilisateur lors de sa connexion. • La gestion via UUP permet d’assembler les informations utilisateurs provenant de différents sources hétérogènes (annuaire LDAP, base de données, différentes tables de données) et d’optimiser l’accès à ces données qui sont remontées en mémoire cache dans la session utilisateur à la connexion. Données de connexion Login Mot de passe Données utilisateur Nom, Prénom Coordonnées personnelles Adresse individuelle de travail Fonction, Question Profil de l’utilisateur (UUP) Données entreprise Raison sociale de l’entreprise Activité de l’entreprise 25/09/03 – SGE - Portail – Proposition Technique / Page 22

23. Solution technique V0.1 Architecture technique Weblogic Portal – Version utilisée • Les souches de développement Weblogic Portal version 8.0 sont en cours de validation au sein de la DIT EDF (projet IDP). • La date de mise à disposition de ces souches n’est aujourd’hui pas compatible avec le planning du projet SGE, aussi CGE&Y intègre dans sa proposition une architecture technique basée sur le framework Weblogic Portal 4.0. • Toutefois, dans le cas où les souches Weblogic Portal 8.0 seraient disponibles au cours du projet, CGE&Y propose de les intégrer dans des conditions identiques sous réserve qu’elles soient disponibles avant T0 + 2 semaines (début d’installation de la plate-forme de développement CGE&Y). 25/09/03 – SGE - Portail – Proposition Technique / Page 23

24. Solution technique V0.1 Architecture technique Weblogic Portal - Architecture du produit • Weblogic Portal est une infrastructure technologique pour le développement de portails d’entreprise. • Il se compose d’outils d’administration des utilisateurs et des ressources, de systèmes de personnalisation et de gestion des interactions, et de services d’intégration permettant d’associer les systèmes d’information existants et diverses ressources Internet. • Il comprend les modules applicatifs suivants : BEA Weblogic Portal Portlets BEA Partenaires Spécifique Personnalisation & gestion intéraction Services d’intégration Règles de personnalisation Suivi Comportemental Intéraction et gestion de campagnes Temps réel Evènements spécifiques Unified User Profile (UUP) Pipeline Components Web Services Client Portlet Builder WebLogic Integration Administration Intelligente Outils fonctionnels (interface) Administration Déléguée Gestion des accès par règles WebFlow – Conception de la navigation WebFlow – Intégration des process Services fondamentaux d’un Portail Services e-Commerce Intégration Solutions Contenu Moteurs de recherche Chartes graphiques et mises en pages Architecture déploiement Configuration mode déconnecté Portail multi-onglets Framework de portlets WebLogic Server 25/09/03 – SGE - Portail – Proposition Technique / Page 24

25. Page HTML Solution technique V0.1 Architecture technique Weblogic Portal -Principes de programmation • Les développements réalisés sur SGE sont conformes au modèle multicouches J2EE. • L’architecture logicielle préconisée est basée sur le modèle MVC (Modèle – Vue – Contrôleur). Elle s’organise autour des composants de type : • JSP pour la représentation graphique des informations, • Servlets ou Pipelines pour les contrôles et la navigation, • EJB pour la récupération des informations en provenance du modèle. Serveur d’application WebLogic Présentation Métier 1 Base de données (Contrôleur) Servlet ou Pipeline 2 Requête (EJB) Modèle Serveur Web Navigateur 3 5 (Vue) JSP 4 Réponse 25/09/03 – SGE - Portail – Proposition Technique / Page 25

26. Solution technique V0.1 Architecture techniqueOutils de développement • Les outils de développement utilisés sont les suivants : • DreamWeaver (MACROMEDIA) : éditeur HTML utilisé pour le maquettage des écrans. • JBuilder (BORLAND) : atelier de développement Java. • PowerAMC (SYBASE) : Outil de spécification de modèles de données et de processus. • WinCVS (CVS) : Outil client de gestion de configuration sous Windows. • Outils Portal : EBCC (E-Business Control Center) : interface d’administration du portail, utilisée pour le paramétrage. • Les postes de développement utilisent le système d’exploitation suivant Windows 2000. Ils sont équipés d’un navigateur Web de type Microsoft Internet Explorer ou Netscape Navigator, et du plug-in Acrobat Reader. 25/09/03 – SGE - Portail – Proposition Technique / Page 26