dossier exploitation gdo psa

Documentation

DSIN Dossier d’exploitation de GDR ACProjet CUSCO

GENERALE

. Fiche identification document

Libellé : Dossier d’exploitation

auteur : Elise NAVARO état : niv. hiérasigle service : DSIN/SIDM/ITSA/ISRC visé par : Elise NAVARO visa :

date création : applicable le : 2007/07/17

Armoire Domaine Sous-Domaine Filière Sous-Filière Liens inter- documents

Mots clefs affectés

Remplace du

Dossier d’exploitation de l’application GDR – AC

édité le : 28/04/23 page: 1/ 37

Documentation


GENERALE

SOMMAIRE1. INFORMATIONS SUR LES INTERVENANTS................................................................................................4

1.1. UTILISATEURS...........................................................................................................................................41.2. ETUDES INFORMATIQUES......................................................................................................................41.3. INDUSTRIALISATION...............................................................................................................................4

2. PRESENTATION DE L’APPLICATION............................................................................................................52.1. DEFINITION DE L’APPLICATION...........................................................................................................52.2. CONTRAINTES ET INDICES DIC.............................................................................................................52.3. URL DE L’APPLICATION..........................................................................................................................52.4. SCHEMA D’ARCHITECTURE GENERAL...............................................................................................6

2.4.1. Schéma de l’application et liens avec l’extérieur.........................................................................62.4.2. Schéma du flux d’informations.....................................................................................................7

3. ENVIRONNEMENT INFORMATIQUE.............................................................................................................83.1. INFORMATIONS GENERALES................................................................................................................83.2. CONFIGURATION MATERIELLE............................................................................................................83.3. PROGICIEL / PRODUIT..............................................................................................................................8

4. CONFIGURATION APPLICATIVE.................................................................................................................104.1. CONFIGURATION WEBSPHERE...........................................................................................................10

4.1.1. Création du serveur d’application...............................................................................................104.1.2. Création de l’alias J2C et affectation à la datasource...............................................................104.1.3. Déploiement de l’application d’entreprise..................................................................................10

4.2. CONFIGURATION IHS.............................................................................................................................104.3. SCRIPT D’INDUSTRIALISATION USS..................................................................................................11

4.3.1. Initialisation des drivers DB2......................................................................................................114.3.2. Ajout du CLASSPATH................................................................................................................11

5. DESCRIPTION DES PROCESSUS « BATCH »..............................................................................................125.1. DEPENDANCE..........................................................................................................................................125.2. Enchaînement des interfaces.......................................................................................................................12

5.2.1. Traitements de nuit......................................................................................................................125.2.2. Traitements de jour......................................................................................................................145.2.3. Synthèse des traitements..............................................................................................................155.2.4. Gestion des opportunités provenant des sites web......................................................................185.2.5. Procédure d’installation d’un nouveau flux SFTP....................................................................18

5.3. SURVEILLANCE.......................................................................................................................................196. DESCRIPTION DES PROCEDURES DE PURGE...........................................................................................19

6.1. PURGE DES DONNÉES............................................................................................................................196.1.1. Organigramme de traitement......................................................................................................19

6.2. PURGE DES LOGS....................................................................................................................................207. DESCRIPTION DES FLUX EXTERNES.........................................................................................................21

7.1. FLUX EN EMISSION................................................................................................................................217.2. FLUX EN RECEPTION.............................................................................................................................22

8. DESCRIPTION DES BASES DE DONNEES...................................................................................................258.1. GENERALITES..........................................................................................................................................25

8.1.1. Sous-systemes...............................................................................................................................258.1.2. Initialisation.................................................................................................................................25

8.2. LISTE DES TABLESPACES.....................................................................................................................258.3. LISTE DES TABLES.................................................................................................................................268.4. LISTE DES INDEXS DE TABLE..............................................................................................................27

9. MAINTENANCE - EXPLOITATION...............................................................................................................299.1. SAUVEGARDES APPLICATIVES...........................................................................................................299.2. GESTION DES LOGS................................................................................................................................299.3. PURGE DES LOGS ET FICHIERS DE DONNEES.................................................................................299.4. SURVEILLANCE.......................................................................................................................................299.5. INCIDENTS ET CONSIGNES..................................................................................................................309.6. SERVEUR D’APPLICATIONS WEBSPHERE........................................................................................30

10. PRISE EN COMPTE DE LIVRAISON...........................................................................................................3010.1. DÉPLOIEMENT APPLICATION D’ENTREPRISE...............................................................................30

édité le : 28/04/23 page: 2/ 37

Documentation


GENERALE

10.2. DÉPLOIEMENT OBJETS APPLICATIFS..............................................................................................31

Historique de mise à jour

Date Version Référence Auteur Approbation Corrections effectuées

20/06/2006 1.0 ENA Création du document

21/11/2006 1.1 RBR Mise à jour V3

12/07/2007 1.2 ETA Mise à jour V3.2

17/07/2007 1.2 ENA Relecture pour validation

24/04/2008 1.4 ETA/RBR Mise à jour V3.4

11/08/2008 1.5 RBR Mise à jour V3.4.1 et déploiement lot3 2008

22/01/2009 3.5.1 RBR Mise à jour V3.5.1

01/04/2009 3.5.3 MAS Mise à jour V3.5.3 (Olive AC interface) Lot 5

04/09/2009 3.5.3 MAS Mise à jour V3.5.3 (New RRDI interface) Lot 6

21/04/2010 3.7 MAS Mise à jour V3.7 lot 7-8-9

édité le : 28/04/23 page: 3/ 37

Documentation


GENERALE

1. INFORMATIONS SUR LES INTERVENANTS

1.1. UTILISATEURSPFA : Jerome BOILLAUDPOA : Un par filiale

Les différents profils utilisateur sont les suivants : Super-administrateur Traducteur Administrateur central des fonctions opportunités Administrateur Pays des fonctions opportunités Administrateur central des fonctions réclamations Administrateur Pays des fonctions réclamations Utilisateur Pays des fonctions opportunités Utilisateur Pays des fonctions réclamations Accès aux réclamations du point de vente Chef des ventes / PRC Vendeur

L’ensemble des utilisateurs est connu de REUNIS. Les profils sont gérés par service applicatif. L’accès à l’application est assuré par l’intermédiaire d’interrogation du LDAP.

1.2. ETUDES INFORMATIQUESAntoine PUJOL DCSI/DSIN/SIDM/RCBM/SIRCFrédéric SAIS DCSI/DSIN/SIDM/RCBM/SIRCHamid INEZARENE DCSI/DSIN/SIDM/RCBM/SIRCStéphanie OUSSET DCSI/DSIN/SIDM/RCBM/SIRC

1.3. INDUSTRIALISATIONValery JAEGLE PDA/ICD/AGMariano SZUSTER PDA/ICD/AGMauro BIANCHI PDA/ICD/AG Guillermo BADII PDA/ICD/AG

édité le : 28/04/23 page: 4/ 37

Documentation


GENERALE

PRESENTATION DE L’APPLICATION

1.4. DEFINITION DE L’APPLICATION

Le système a pour objectif de fournir à la marque CITROEN une solution permettant de descendre aux réseaux les opportunités et les réclamations clients dont ils font l’objet.

1.5. CONTRAINTES ET INDICES DIC

L’indice DIC (Disponibilité, Intégrité, Confidentialité) est : 2.2.2

Pour les impacts résultants d’un dysfonctionnement, se référer aux Conditions Normales de Fonctionnement.

1.6. URL DE L’APPLICATION

Environnement URL AccèsMUD gdo.citroen.dev.inetpsa.com IntranetPréPROD gdo.citroen.preprod.inetpsa.com IntranetPROD gdo.citroen.com Internet

gdo.citroen.inetpsa.com Intranet

édité le : 28/04/23 page: 5/ 37

Documentation


GENERALE

1.7. SCHEMA D’ARCHITECTURE GENERAL

1.7.1. Schéma de l’application et liens avec l’extérieur

Les schémas à jour sont disponibles : \\pysn0601\SIDM\ITSA\ISRC\CD41\30 GRC AC AP\00 Suivi\Livrables GRC AC AP\Architecture\GDR GDO

édité le : 28/04/23 page: 6/ 37

Documentation


GENERALE

1.7.2. Schéma du flux d’informations

édité le : 28/04/23 page: 7/ 37

Documentation


GENERALE

2. ENVIRONNEMENT INFORMATIQUE

2.1. INFORMATIONS GENERALES

Nom de l’application dans Reflex : GDR Le code PRD : GDO/GDU CGS (Alias) : GDO

L’indice DIC (Disponibilité, Intégrité et Confidentialité) est : 2.2.2

2.2. CONFIGURATION MATERIELLE

Environnement : ProductionMachine : PYTSO3 (hostname PYDI12)Adresse ip : 10.82.215.17 (host PYDI12.INETPSA.COM)Model : OS/390Système d’exploitation : MVSComptes : RPI

Environnement : Pré-productionMachine : TSOPP21 (hostname PYAI41)Adresse ip : 10.82.215.133 (host py02sd1.INETPSA.COM)Model : OS/390Système d’exploitation : MVSComptes : RPI

2.3. PROGICIEL / PRODUIT

Toute la configuration logicielle des serveurs est indiquée sur le serveur le focalisation : http ://focalwfl.dtii.inetpsa.com

Machine : PYTSO3

Type de composant Produit CommentaireServeur http IBM HTTP Server Sous plate-forme Z/OSServeur d’application IBM WAS V5.1 Sous plate-forme Z/OSBase de données IBM DB2 v7 Sous plate-forme Z/OSStockage des fichiers USS Enveloppe ZFSAuthentification Annuaire d’entrepriseGestion des droits Annuaire d’entreprise Services applicatifsClient Internet Explorer V 5.5 et

supérieuresAucun plug-in, activeX ou applet

Batchs Java, ordonnancés par OPC sous Z/OS

Batchs développés en Java.

édité le : 28/04/23 page: 8/ 37

http://focalwfl.dtii.inetpsa.com/

Documentation


GENERALE

Type de composant Produit CommentaireTransferts de fichiers CFT Pour l’intégration et les

comptes-rendus d’intégration et l’envoi des alertes au portail FRC et à la Boite Patron.

édité le : 28/04/23 page: 9/ 37

Documentation


GENERALE

3. CONFIGURATION APPLICATIVE

3.1. CONFIGURATION WEBSPHERE

3.1.1. Création du serveur d’application

Sous environnement ZOS, la création du serveur d’application se fait par la cellule ETSO/DBDC (F. ROYER).Il n’appartient pas à l’industrialisateur de paramétrer le serveur d’application via la console d’administration.

Environnement Nom du serveur d’appli Console d’administrationPré-production BWE1BS3 http://py12dns.inetpsa.com:9664

BWE1BS8 http://py12dns.inetpsa.com:9664Production CWE1ASI http://pydi12.inetpsa.com:9625

CWE1AST http://pydi12.inetpsa.com:9625

3.1.2. Création de l’alias J2C et affectation à la datasource

Voir RDBAC20

Les job GDOZ0J2C et GDOZ3J2C permettent de mapper la datasource et de créer l’alias J2C sous WebSphere. Il n’est à exécuter qu’une seule fois par environnement après la création du serveur d’application.

Des logs complémentaires se trouvent dans /users/gdo00000/exploit/log et /users/gdu00000/exploit/log en fonction de l’ear concerné.

3.1.3. Déploiement de l’application d’entrepriseLe déploiement de l’EAR ainsi que du paramétrage properties doit se faire par un batch utilisant wsadmin.Voir §10.1

3.2. CONFIGURATION IHSLa configuration de l’IHS est gérée par la cellule ESO/MVS (Fabrice VALLET).La seule intervention de l’indus consiste à l’initialisation de fournir à ESO/MVS le mapping des ressources statiques (fourni par les Etudes) après la création du serveur d’application.

Pass /images/* /zWebSphere/V5R1M0/AppServerNodeE1/installedApps/cwe1asi/GDO00_ea.ear/BGCWeb.war/images/* gdo.citroen.inetpsa.comPass /config/* /zWebSphere/V5R1M0/AppServerNodeE1/installedApps/cwe1asi/GDO00_ea.ear/BGCWeb.war/config/* gdo.citroen.inetpsa.com

édité le : 28/04/23 page: 10/ 37

Documentation


GENERALE

Pass /script/* /zWebSphere/V5R1M0/AppServerNodeE1/installedApps/cwe1asi/GDO00_ea.ear/BGCWeb.war/script/* gdo.citroen.inetpsa.comPass /themes/* /zWebSphere/V5R1M0/AppServerNodeE1/installedApps/cwe1asi/GDO00_ea.ear/BGCWeb.war/themes/* gdo.citroen.inetpsa.com

3.3. SCRIPT D’INDUSTRIALISATION USS

3.3.1. Initialisation des drivers DB2Les drivers DB2 sont initialisés dans le start de l’application (Voir §5.2) sous la forme suivante :# ---------------------------------------------------# Initialisation des librairies pour les drivers DB2# pour les batchs (preco ESO/DBDC)# ---------------------------------------------------

export CLASSPATH=/soft/db2/db2710/jcc/classes/db2jcc.jar:/soft/db2/db2710/jcc/classes/db2jcc_javax.jar:/soft/db2/db2710/jcc/classes/db2jcc_license_cisuz.jar:$CLASSPATHexport LIBPATH=/soft/db2/db2710/jcc/lib/:$LIBPATHexport DB2JCCINI=/etc/dbdc/parms/jdbc/db2jcc.properties.CBA

Cette déclaration est identique en pré-production hormis le nom de l’instance DB2 qui n’est pas le même (CBA BBA).

3.3.2. Ajout du CLASSPATHLe bon fonctionnement des batchs USS (Voir §5.2) passe par l’enrichissement du CLASSPATH avec le programme JAR livré par les Etudes correspondant à chaque programme.

Exemple pour RRDI :export CLASSPATH=$UNXJAVALIB/GDONet.jar:$CLASSPATH

édité le : 28/04/23 page: 11/ 37

Documentation


GENERALE

4. DESCRIPTION DES PROCESSUS « BATCH »

4.1. DEPENDANCE

Les traitements sont indépendants les uns des autres. Il n’y a pas de chronologie particulière à respecter.

Le batch de nuit est déclenché tous les soirs de la semaine à 22H (hors traitement d’historisation des logs).Ce batch commence par les servitudes DB2 pour enchaîner ensuite sur les traitements batchs fonctionnels.

Les traitements suivants tourne tous les jours sans restriction à la réception d’un fichier :- Intégration et Extraction des Réclamations (CUSCO)- Intégration et Extraction des Réclamations (CUSCO Export)- Intégration et Extraction des Opportunités (CUSCO)- Intégration et Extraction des Opportunités (CUSCO Export)- Intégration des Opportunités (provenant de ITWEB) – Batch d’intégration déclenché

toutes les heures- Intégration des Opportunités (provenant de SFTP) – Batch d’intégration déclenché

toutes les heures- Intégration des Opportunités Connect Express (Tout pays)- RRDI- NOTD provenant de Cusco Export- Intégration des fichiers des clients et commandes issues (provenant de O’live).- Intégration des fichiers des Opportunités (O’live - connect Express) - Enchaînement des interfaces

4.1.1. Traitements de nuit

édité le : 28/04/23 page: 12/ 37

Documentation


GENERALE

édité le : 28/04/23 page: 13/ 37

Documentation


GENERALE

4.1.2. Traitements de Jour :

édité le : 28/04/23 page: 14/ 37

Documentation


GENERALE

4.1.3. Synthèse des traitements

Les batchs sont lancés via OPC. Ces batchs exécutent les scripts d’encapsulation sous USS via le « start » de l’application.

Le fichier start permet de charger les variables applicatives d’environnement. Il doit être utilisé systématiquement pour lancer les autres scripts d’exploitation.

Liste des traitements applicatifs :

GDOAW : Arrêt/relance du serveur d’application WAS.

GDOZ0 : Prise en compte de livraison du l’application d’entreprise (EAR).

GDOHL : Historisation et purges des logs et fichiers de données.Description : Ce traitement a pour but de transférer toutes les logs de $UNXLOG vers $UNXHISTO/log. De la même manière, les fichiers de données de plus de 30 jours sont transférés de $UNXDATA/out+<sous-répertoire pays> vers $UNXHISTO/envoi. Au bout de 120 jours les fichiers de log et de données sont virés de $UNXHISTO.

GDOBE : Batch PilotageDescription : Ce batch calcul et insert une fois par mois dans table de pilotage des informations de rapports de pilotage.

GDOCL : Batch de CloisonnementDescription : Ce batch traite les changements de code contrat des PDV (MAJ des codes contrat des PDV, duplication éventuelle des clients et rattachement des opportunités ou réclamations).

GDOIM : Récupération des indicateurs des tableaux de bords (sous forme de log dans WSF). GDOUV : Batch de sauvegarde USS + Pièces JointesDescription : Ce batch sauvegarde la partie USS de gdu et notamment les Pièces Jointes présentes dans /users/gdu00000/data/pj/courant.NB : Les pièces jointes présentes dans le répertoire /users/gdu00000/data/pj/archives sont sauvegardées par les GR (partie Baie Netapp).

GDOPU : Batch de purgeDescription : Ce batch purge les données obsolètes de la base de données DB2.

GDOON : Intégration des fichiers des opportunités de nuit (pour fichiers > 500 enr.)

édité le : 28/04/23 page: 15/ 37

Documentation


GENERALE

Description : Ce traitement a pour objectif d’insérer dans la base de données les opportunités présentes dans les fichiers supérieurs à 500 enregistrements.

GDOAN : Export d’alertes pour les réclamations (exécution à 22h)Description : Ce batch exporte des indicateurs dans un fichier ASCII formaté pour envoi via CFT vers un module d’importation des alertes « réclamations » au niveau du portail FRC et de la Boite Patron (pour AC France).

GDOBC : Batch d’export alerte NOTD Description : ce batch exporte toutes les nuits de la base DB2 les alertes NOTD avec laCréation d’un fichier en sortie au format ASCII pour un envoi CFT via un pilotage de la chaine GDOEH vers la boite patron.

GDOOA : Export d’alertes pour les opportunités (de 8h à 20h45 + 22h – toutes les 45mns)Description : Ce batch exporte des indicateurs dans un fichier ASCII formaté pour envoi via CFT vers un module d’importation des alertes « opportunités » au niveau du portail FRC et de la Boite Patron (pour AC France).

GDOBB : Batch d’export du référentiel réseau vers RVP Description : ce batch exporte toutes les nuits de la base DB2 le référentiel réseau . avecLa création d’un fichier en sortie au format XML pour un envoi CFT via un pilotage de la chaine GDOEG vers RPV.

GDOBA : Batch d’export des opportunités RPV Description : ce batch exporte des opportunités dans la base DB2 toutes les nuits et création d’un fichier en sortie au format UTF8 pour un envoi CFT via un pilotage de la chaine GDOEF vers RPV

GDOBO : Batch d’export des opportunités OPVDescription : Ce batch exporte les opportunités créées dans GDO pour envoi via CFT vers OPV

GDOBR : Export Mise à jour Réclamations CUSCO DB2Description : Ce batch exporte les réclamations MAJ par les PDV dans un fichier ASCII formaté pour envoi vers CUSCO DB2.

GDOCR : Export Mise à jour Réclamations CUSCO ExportDescription : Ce batch exporte les réclamations MAJ par les PDV dans un fichier ASCII formaté pour envoi vers CUSCO Export

GDODI : Intégration des fichiers généré pour GDOXX avec de points de vente RRDI pour les pays FR, GB, ES, IT, BE, DE, PT, AT, NL, SH, DK, NO, SE.Description : Ce traitement a pour objectif d’insérer dans la base de données les évolutions du référentiel réseau RRDI. Ce traitement est aussi valable pour la phase d’initialisation.

GDOD1 : Intégration des fichiers généré pour GDOXX avec de points de vente RRDI pour les pays HU, SI, SK, HR, CZ, PL, RODescription : Ce traitement a pour objectif d’insérer dans la base de données les évolutions du référentiel réseau RRDI. Ce traitement est aussi valable pour la phase d’initialisation

GDOD2 : Intégration des fichiers généré pour GDOXX avec de points de vente RRDI pour le pays RU.

édité le : 28/04/23 page: 16/ 37

Documentation


GENERALE

Description : Ce traitement a pour objectif d’insérer dans la base de données les évolutions du référentiel réseau RRDI. Ce traitement est aussi valable pour la phase d’initialisation

GDOTD : Intégration des fichiers de référentiel NOTD CUSCO DB2.Description : Ce traitement a pour objectif d’insérer dans la base de données les évolutions du référentiel NOTD de CUSCO DB2. Ce traitement est aussi valable pour la phase d’initialisation.

GDOTM : Intégration des fichiers de référentiel NOTD CUSCO Export.Description : Ce traitement a pour objectif d’insérer dans la base de données les évolutions du référentiel NOTD de CUSCO Export. Ce traitement est aussi valable pour la phase d’initialisation.

GDOOP : Intégration des fichiers des Opportunités Connect Express.Description : Ce traitement a pour objectif d’insérer en base de données, durant le batch de nuit, les fichiers des opportunités envoyés via Connect Express des différentes filiales.Une réception par filiale.

GDOBT : Intégration des fichiers des opportunités issus de l’OPV ITDescription : Ce traitement a pour objectif d’insérer dans la base de données les opportunités traitées dans l’OPV. GDOAJ : Export d’alertes pour les réclamations (exécution à 13h)Description : Ce batch exporte des indicateurs dans un fichier ASCII formaté pour envoi via CFT vers un module d’importation des alertes « réclamations » au niveau du portail FRC et de la Boite Patron (pour AC France).

GDOAR : Intégration des fichiers des réclamations et Extraction CR (CUSCO DB2).Description : Ce traitement a pour objectif d’insérer dans la base de données les réclamations clients présentes dans les fichiers issus de CUSCO DB2 et de renvoyer un compte-rendu.

GDOBU : Intégration des fichiers des réclamations et Extraction CR (CUSCO Export).Description : Ce traitement a pour objectif d’insérer dans la base de données les réclamations clients présentes dans les fichiers issus de CUSCO Export et de renvoyer un compte-rendu.

GDOAO : Intégration des fichiers des Opportunités et Extraction CR (CUSCO DB2).Description : Ce traitement a pour objectif d’insérer dans la base de données les Opportunités clients présentes dans les fichiers issus de CUSCO DB2 et de renvoyer un compte-rendu.

GDOBD : Intégration des fichiers des Opportunités et Extraction CR (CUSCO Export).Description : Ce traitement a pour objectif d’insérer dans la base de données les Opportunités clients présentes dans les fichiers issus de CUSCO Export et de renvoyer un compte-rendu.

GDOOS : Intégration des fichiers des Opportunités ITWEB 1.5Description : Ce traitement a pour objectif d’insérer en base de données les fichiers des opportunités envoyés, via SFTP, des Sites Web hébergés chez PSA.Les fichiers sont récupérés sur la machine ITWEB toutes les heures (xxh30).

édité le : 28/04/23 page: 17/ 37

Documentation


GENERALE

GDOOS : Intégration des fichiers des Opportunités ITWEB 2.0Description : Ce traitement a pour objectif d’insérer en base de données les fichiers des opportunités envoyés, via SFTP, des Sites Web hébergés chez PSA via ITWEB.L’interface n’est pas encore activée.

GDOOR : Intégration des fichiers des Opportunités SFTPDescription : Ce traitement a pour objectif d’insérer en base de données les fichiers des opportunités envoyés, via SFTP, des Sites Web hébergés chez PSA via SFTP.

GDOLM : Intégration des fichiers des clients et commandes issues O’live.Description : Ce traitement a pour objectif d’insérer dans la base de données les clients et commandes présentes dans les fichiers issus de O’live et de renvoyer un compte-rendu.

GDOLO : Intégration des fichiers des Opportunités Connect Express – O’liveDescription : Ce traitement a pour objectif d’insérer en base de données, durant le batch de nuit, les fichiers des opportunités envoyés via Connect Express Olive de France.

GDOXX : Séparation des données selon le pays d’origine.Description : Ce traitement a pour objectif fractionner les données envoyé pour RRDI, en 3 fichiers. Le premiere: FR, GB, ES, IT, BE, DE, PT, AT, NL, SH,DK, NO, SE.Le seconde : HU, SI, SK, HR, CZ, PL, ROLe troisiéme : RU

GDOPT : Intégration des fichiers des Opportunités (BAMAC).Description : Ce traitement a pour objectif d’insérer dans la base de données les Opportunités clients présentes dans les fichiers issus de BAMAC. Sans renvoyer un compte-rendu.

édité le : 28/04/23 page: 18/ 37

Documentation


GENERALE

4.1.4. Gestion des opportunités provenant des sites web

4.1.5. Procédure d’installation d’un nouveau flux SFTP

Extrait mail Antoine PUJOL (RCBM/SIRC) du 17/07/2008

Pour les environnements de pré-production AP et AC :- Un IDF par Marque est créé entre la passerelle SFTP et la machine de production PY03, sur laquelle un rebond est paramétré pour rediriger les fichiers reçus vers les environnements de pré-production (PY12). Les IDFs sont :

* PY3GDORB pour AC* PY3MACRB pour AP

- Les noms des fichiers à communiquer aux prestataires externes prennent en compte ces IDFs. Il s'agit de :

* RRMT0000PYN03XM2PY3GDORB pour AC* RRMT0000PYN03XM2PY3MACRB pour AP

- Pour ouvrir un nouveau flux, il faut :* Faire une demande de création de compte technique.* Demander l'attribution du service applicatif ZZ5B à ce nouveau compte.

Pour les environnements de production AP et AC :

édité le : 28/04/23 page: 19/ 37

Documentation


GENERALE

- Un IDF par Marque est créé entre la passerelle SFTP et la machine de production PY03. Les IDFs sont :

* PY3GDORK pour AC* PY3MACRI pour AP

- Les noms des fichiers à communiquer aux prestataires externes prennent en compte ces IDFs. Il s'agit de (seuls les IDFs changent) :

* RRMT0000PYN03XM2PY3GDORK pour AC* RRMT0000PYN03XM2PY3MACRI pour AP

- Pour basculer le nouveau flux en production, il n'y aura donc côté PSA rien à faire dès lors que les premiers flux auront été déclarés (après ACUK et AP Allemagne).

4.2. SURVEILLANCE

Voir §9.3 et §9.4

5. DESCRIPTION DES PROCEDURES DE PURGE

5.1. PURGE DES DONNÉES

La purge des données se fait hebdomadairement par le traitement GDOPU.

5.1.1. Organigramme de traitement

Ce batch est composé d’un seul programme java effectuant les opérations suivantes :

1. Récupération des paramètres de purge2. Connexion à la base de données GDO3. Purge des clients obsolètes (les opportunités associées sont ensuite purgées en

cascade).4. Purge des imports obsolètes5. Libération des ressources

édité le : 28/04/23 page: 20/ 37

Documentation


GENERALE

5.2. PURGE DES LOGSVoir §9.2

édité le : 28/04/23 page: 21/ 37

Documentation


GENERALE

6. DESCRIPTION DES FLUX EXTERNES

6.1. FLUX EN EMISSION

Traitement récepteur

Partenaire Taille d’un enregistrement

Nombre d’enregistrements

Fréquence Taille fixe / Variable

Impacts en cas de non réception

Export fichier d’alertes « réclamations »

Portail FRC

Pprod :PYASME

Prod :PYASMFPYASMG

Variable

(Max. = 50)

Variable

(Pour les filiales France, UK et Espagne max = 4700).

Bi journalier Variable Non bloquant.Pas d’alertes dans le portail jusqu’au prochain flux.

Export fichier d’alertes « réclamations »

Boite Patron

Pprod :PY0GDOE3

Prod :PY3GDOE3

Variable

(Max. = 50)

Variable

(Pour la filiale France max = 4700).

Bi journalier Variable Non bloquant.Pas de nouvelles alertes dans la Boite Patron jusqu’au prochain flux.

Export fichier d’alertes NOTD

Boite Patron

Pprod : pas de pré-prod

Prod :PYAIBK

Variable Variable

(Pour la filiale France max = 4700).

Bi journalier Variable Non bloquant.Pas de nouvelles alertes dans la Boite Patron jusqu’au prochain flux.

Export fichier référentiel Réseau

RPVPprod : YLAI0030Prod : YLAI1010

Variable XML

Variable QuotidienDans le batch de nuit

Variable

Export fichier Opportunité

RPVPprod : YLAI0030Prod : YLAI1010

Variable XML

Variable QuotidienDans le batch de nuit

Variable

Export fichier d’alertes « opportunités »

Portail FRC

Pprod :PYASME

Prod :PYASMFPYASMG

Variable

(Max. = 50)

Variable

(Pour les filiales France, UK et Espagne max = 4700).

toutes les 45 mn

Variable Non bloquant.Pas d’alertes dans le portail jusqu’au prochain flux.

Compte-rendu d’intégration des réclamations

CUSCO

Pprod :PY12

Prod :PY06

Variable.Max = 70

Variable Après chaque lancement de la chaine d’intégration des réclas

Variable Réémission par GDO.

édité le : 28/04/23 page: 22/ 37

Documentation


GENERALE






Compte-rendu d’intégration des opportunités

CUSCO

Pprod :PY12

Prod :PY06

Variable.Max = 70

Variable Après chaque lancement de la chaine d’intégration des opp.issues de Cusco


Export des MAJ sur les réclamations

CUSCO

Pprod :- PY12

Prod :- PY06

VariableMax =8000c

Variable(Max = 500)

QuotidienDans le batch de nuit

Variable Réémission par GRC.

Export opportunités

OPV AC IT/DE/PT/ES - BEN18

Variable Max 5000

Variable Quotidien durant le batch de nuit


Compte-rendu d’intégration des réclamations

CUSCO OraclePprod :- YLAI2020Prod :- PYAII6

Variable.Max = 70

Variable Après chaque lancement de la chaine d’intégration des réclas


Compte-rendu d’intégration des opportunités


Variable.Max = 70

Variable Après chaque lancement de la chaine d’intégration des opp.issues de Cusco Oracle


Export des MAJ sur les réclamations


VariableMax =8000c

Variable(Max = 500)

QuotidienDans le batch de nuit

Variable Réémission par GRC.

6.2. FLUX EN RECEPTION

édité le : 28/04/23 page: 23/ 37

Documentation


GENERALE






Intégration des réclamations

CUSCO

Pprod :- PY12

Prod :- PY06

Variable.Max = 62000.

Variable A réception d’un fichier Variable Réémission par CUSCO.

Intégration des réclamations




Intégration des opportunités

CUSCO

Pprod :- PY12

Prod :- PY06








Accessplus(SFTP)Prod : YLAS1070YLAS1060

Variable.Max = 4010c.

Variable A la réception d’un fichier Variable Réémission par Accessplus.


Poste client filiale (Connect Express)


Variable A la demande (transfert manuel déclenché par l’utilisateur)

Variable Réémission par l’utilisateur.

Intégration des opportunités CFT depuis la zone SGP (ITWEB 1.5)

Cible chaîne : UTF-8

Citroen.pl (site hébergé chez PSA)Prod : PYAQTP


Variable Récupération d’un fichier en SGP toutes les 30 min (citroen.pl génère un fichier par heure et le met à disposition, sauf dans le cas d’un fichier vide)

Variable Réémission par citroen.pl

Intégration des NOTD

CUSCO

Pprod :- PY12Prod :- PY06

Variable.Max = 82.

Variable Quotidien Variable Réémission par CUSCO.

édité le : 28/04/23 page: 24/ 37

Documentation


GENERALE






Intégration des NOTD


Variable.Max = 82.

Variable Quotidien Variable Réémission par CUSCO.

Intégration du référentiel réseau (RRDI)

RRDI

Prod :PY06

Fixe.2883c.

Variable Quotidien Fixe Réémission par RRDI.

Intégration des Opportunités

OPV AC IT/DE/PT/ES

Variable Max 2000

Variable Quotidien durant le batch de nuit

Variable Réémission par OPV

édité le : 28/04/23 page: 25/ 37

Documentation


GENERALE

7. DESCRIPTION DES BASES DE DONNEES

7.1. GENERALITES

7.1.1. Sous-systemesLes sous-systèmes DB2 utilisés pour l’application sont :

Environnement ServeurMUD (MVS2) NBB PréPROD (PY12) BBAPROD (PY03) CBA

7.1.2. InitialisationL’initialisation de l’application, dans l’ordre suivant :

- initialisation des référentiels de l’application,- initialisation des NOTD (REC36 fichier CUSCO),- initialisation du référentiel réseau (fichier RRDI).

L’initialisation des référentiels se fait par exécution d’une SYSIN d’init livrée sous Endevor : GDOSY001.

7.2. LISTE DES TABLESPACESNom Code PRIQTY (ko) SECQTY

(ko)GDOQDAL1

TS Canal GDOQDCAN 12 1TS Client GDOQDCLI 1760000 176000TS Contact GDOQDCON 22008 2200TS Demande GDOQDDEM 22008 2200TS GroupeReseau GDOQDGRP 16 1TS Libelle GroupeReseau

GDOQDGLI 52 5

TS des historiques GDOQDHIS 26 000 2600TS Import GDOQDIMP 572 57TS Locale GDOQDLNG 12 1TS MessageAccueil GDOQDMES 16 1TS Motifs GDOQDMOT 8472 847TS Nature GDOQDNAT 16 1TS Reseau GDOQDNET 2208 220TS NOTD GDOQDNTD 376 37TS Offre GDOQDOFR 22008 2200TS Opportunite GDOQDOP1 1760008 176000

édité le : 28/04/23 page: 26/ 37

Documentation


GENERALE

TS OpportuniteTraitee GDOQDOP2 22008 2200TS Pays GDOQDPAY 12 1TS Pilotage GDOQTPIL 1760008 176000TS Plaque GDOQDPLATS Reclamation GDOQDRCL 440008 44000TS Référentiel GDOQDREF 1108 110TS ResultatTraitement GDOQDRES 16 1TS Libelle Source GDOQDSLI 52 5TS suivi opportunités GDOQDSOP 26000 2600TS Source GDOQDSOU 16 1TS référentiel des suivis GDOQDSUI 500 50TS Transcodification GDOQDTRC 12 1TS Libelle GDOQDTRD 3920 392TS Libelle GDOQDTRT 12 1TS Type GDOQDTYP 12 1TS TypeClient GDOQDTCL 12 1TS utilisateurs GDOQDUSR 750 75TS Libellés volumineux GDOQDVOL 7040064 704006TS Travail GDOQDWRK 440008 44000

7.3. Liste des tablesCode Nom Texte de la description Nombre

de lignesGDOQTCAN Canal Référentiel des canaux de provenance des

opportunités20

GDOQTCON contact contact 100 000GDOQTDEM Demande Demande 100 000GDOQTCLI Client Clients 400 000GDOQTGLI GroupeReseauLi

bLibellés des regroupements de points de vente

120

GDOQTGRP GroupeReseau Regroupements de points de vente 100GDOQTHIS Histotique Historique des connections 400 000GDOQTIMP Import Historique des importations 1400GDOQTLNG Locale Langues 10GDOQTLOG Log log 10000GDOQTMES MessageAccueil Messages d’accueil des administrateurs 10GDOQTMOT Motif Motifs des réclamations 200000GDOQTNAT Nature Référentiel des natures d’opportunité 40GDOQTNET Reseau Référentiel des points de vente 10000GDOQTNTD NOTD Référentiel NOTD 1500GDOQTOFR Offres Offres 100 000GDOQTOP1 Opportunite Opportunités 400 000

édité le : 28/04/23 page: 27/ 37

Documentation


GENERALE

GDOQTOP2 OpportuniteTraitee

Opportunités Traitées 140 000

GDOQTPAY Pays Pays 10GDOQTPIL pilotage pilotage 200000GDOQTPLA Plaque Référentiel des plaques 100GDOQTRCL Reclamation Réclamations 100000GDOQTREF Référentiel Référentiel 10 000GDOQTRES ResultatTraiteme

ntRéférentiel des résultats du traitement des opportunités

30

GDOQTSLI SourceLib Libellé des sources d’opportunité 120GDOQTSOP Suivi opportunités Suivi opportunités 400 000GDOQTSOU Source Référentiel des sources d’opportunité 100GDOQTSUI Suivi Référentiel des suivis 10GDOQTTCL TypeClient Types de client 5GDOQTTRC Transcodification Référentiel de transcodification 10 000GDOQTTRD Libelle Libellés 8000GDOQTTRT Traitement Table des Traitements 10GDOQTTYP Type Référentiel des types d’opportunité 10GDOQTUSR Utilisateurs Table des utilisateurs issus de Réunis 50 000GDOQTVOL Libellés

volumineuxDescriptifs des réclamations 200000

GDOQTWRK Travail Table de travail pour l’import des opportunités

100 000

7.4. Liste des indexs de tableCode Primaire Cluster Etrangère Unique Code de colonne Table

GDOQCCAN X X X CODE_CANAL GDOQTCANGDOQXCA1 X CODE_PAYS GDOQTCANGDOQCCLI X X X ID_CLIENT GDOQTCLIGDOQXCL1 X CODE_PAYS GDOQTCLIGDOQXCL2 X ID_TYPE_CLIENT GDOQTCLIGDOQXCL3 NOM1 GDOQTCLIGDOQXCL4 CODE_POSTAL GDOQTCLIGDOQXCL5 VILLE GDOQTCLIGDOQCGLI X X X CODE_GROUPE_RESEA

UID_LOCALE

GDOQTGLI

GDOQCGRP X X X CODE_GROUPE_RESEAU

GDOQTGRP

GDOQCIMP X X X ID_IMPORT GDOQTIMPGDOQXIM1 X CODE_PAYS GDOQTIMPGDOQXIM2 DATE GDOQTIMPGDOQCLNG X X X ID_LOCALE GDOQTLNGGDOQCMES X X X ID_MESSAGE_ACCUEIL GDOQTME

SGDOQXME1 X CODE_PAYS GDOQTME

S

édité le : 28/04/23 page: 28/ 37

Documentation


GENERALE

Code Primaire Cluster Etrangère Unique Code de colonne TableGDOQXME2 X ID_LOCALE GDOQTME

SGDOQCMOT X X X ID_RECLAMATION

CODE_PAYSCODE_NATURE_CASCODE_OBJET_CASCODE_THEME_CASCODE_DETAIL_CAS

GDOQTMOT

GDOQCNAT X X X ID_NATURE GDOQTNATGDOQXNAT X CODE_PAYS GDOQTNATGDOQCNET X X X CODE_RRDI GDOQTNETGDOQXNE1 X ID_GROUPE_RESEAU GDOQTNETGDOQCNTD X X X CODE_PAYS

CODE_NATURE_CASCODE_OBJET_CASCODE_THEME_CASCODE_DETAIL_CAS

GDOQTNTD

GDOQCOP1 X X X ID_OPPORTUNITE GDOQTOP1GDOQXOP1 X DATE_MISE_A_DISPO

CODE_PAYSID_TYPE

GDOQTOP1

GDOQXOP2 X DATE_MISE_A_DISPOCODE_PAYS

STATUT

GDOQTOP1

GDOQXOP3 X CODE_RRDI GDOQTOP1GDOQXOP4 X DATE_CREATION GDOQTOP1GDOQXOP5 X ID_CLIENT GDOQTOP1GDOQXOP6 X CODE_MARKETING GDOQTOP1GDOQCOP2 X X X ID_OPPORTUNITE_TR GDOQTOP2GDOQXOT1 DATE_MISE_A_DISPO

CODE_PAYSID_TYPE

GDOQTOP2

GDOQXOT2 CODE_RRDI GDOQTOP2GDOQXOT3 ID_NATURE

CODE_PAYSGDOQTOP2

GDOQXOT4 ID_RESULTATCODE_PAYS

GDOQTOP2

GDOQXOT5 CODE_SOURCECODE_PAYS

GDOQTOP2

GDOQXOT6 ID_CANALCODE_PAYS

GDOQTOP2

GDOQCPAY X X X CODE_PAYS GDOQTPAYGDOQCRCL X X X ID_RECLAMATION GDOQTRCLGDOQXRC1 X ID_CAS

CODE_PAYSGDOQTRCL

GDOQCRES X X X ID_RESULTAT GDOQTRESGDOQXRE1 X CODE_PAYS GDOQTRESGDOQCSLI X X X CODE_SOURCE

CODE_PAYSID_LOCALE

GDOQTSLI

édité le : 28/04/23 page: 29/ 37

Documentation


GENERALE

Code Primaire Cluster Etrangère Unique Code de colonne TableGDOQCSOU X X X CODE_SOURCE GDOQTSO

UGDOQXSO1 X CODE_CANAL

CODE_PAYSGDOQTSO

UGDOQXSO2 X CODE_PAYS GDOQTSO

UGDOQCTCL X X X ID_TYPE_CLIENT GDOQTTCLGDOQCTRD X X X ID_LOCALE GDOQTTRDGDOQCTYP X X X ID_TYPE GDOQTTYPGDOQCVOL X X X ID_TEXTE_VOL GDOQTVOLGDOQXVO1 X ID_EXTERNE

ORDRETYPE

GDOQTVOL

GDOQCWRK X X X ID_WRK GDOQTWRK

8. MAINTENANCE - EXPLOITATION

8.1. SAUVEGARDES APPLICATIVESLa base de données est sauvegardée quotidiennement.La rétention est de 7 jours.

8.1.1. Sauvegarde/Restauration des Pièces Jointes

Cas général

Cas fonctionnel Localisation Etat ActionCas n°1 : Crash de la baie Netapp (en pleine journée)Réclas non clos USS USSOK Rien à faireRéclas clos depuis + de 3 jours Netapp NetappKO Restaurer la baie à la dernière sauvegardeRéclas clos depuis - de 3 jours(pointeurs vers Baie Netapp)

USS+Netapp USSOK ; NetappKO Les pointeurs désignant les fichiers sur la baie non encore sauvegardé (fichiers du jour par exemple), la base de données doit être mis à jour pour que les pointeurs désignent les fichiers encore présent sous USS

Cas n°2 : Crash des fichiers sous USS (en pleine journée)Réclas non clos USS USSKO Restaurer à la dernière sauvegarde USS. Mise

à jour de la base de données pour supprimer les pointeurs.

Réclas clos depuis + de 3 jours Netapp NetappOK Rien à faireRéclas clos depuis - de 3 jours USS+Netapp USSKO ; NetappOK Rien à faire car pointeurs vers Baie NetappCas n°3 : Restauration de la base de données à - de 3 jours (restauration le vendredi avec une sauvegarde du mardi soir)Réclas non clos USS USSOK Rien à faire : certaines PJ seront orphelines. Un

ménage sera à faire par les Indus avec l’aide des Etudes.

Réclas clos depuis + de 3 jours Netapp NetappOK Rien à faire : les pointeurs désignent les

édité le : 28/04/23 page: 30/ 37

Documentation


GENERALE

fichiers sur la baie et n’auront pas bougés en 3 jours

Réclas clos depuis - de 3 jours USS+Netapp USSOK ; NetappOK Rien à faire : Les pointeurs désignent les fichiers sur la baie. Après restauration, les pointeurs désigneront les fichiers sous USS.Q : que se passera-t-il lors du prochain passage de la purge, si les fichiers sont déjà sur la baie ? Vérifier si batch de purge écrase fichier existant

Cas n°4 : Restauration de la base de données à + de 3 jours (restauration le vendredi avec une sauvegarde du lundi soir)Réclas non clos USS USSKO Restaurer à la sauvegarde USS équivalenteRéclas clos depuis + de 3 jours Netapp NetappOK Rien à faire

Q : que se passera-t-il lors du prochain passage de la purge, si les fichiers sont déjà sur la baie ?

Réclas clos depuis - de 3 jours USS+Netapp USSOK ; NetappOK Restaurer à la sauvegarde USS équivalenteQ : que se passera-t-il lors du prochain passage de la purge, si les fichiers sont déjà sur la baie ?

Premier test de sauvegarde/restauration sur une Pièce Jointe (Exemple GRC Réseau AC)

Sauvegarde des Pièces Jointes stockées sous USS

L’application GDOUV exécutée tous les jours à 22h00 utilise le script /users/gdu00000/exploit/script/saveuss.shCe script sauvegarde tout le contenu des répertoires paramétrés dans la variable REPLISTE ainsi que les pièces jointes stockées dans /users/gdu00000/data/pj/courant ($REP_PJ/courant).Dans notre exemple, les Pièces Jointes sont stockées dans un fichier d’archive (.pax) zippé (.gz). Ce fichier est ensuite copié dans le répertoire de sauvegarde /users/gdu00000/montage/save/pUne fois récupéré par FDR UPDTREAM à 07h00, le fichier est visible dans l’interface du site intranet http://sssd.inetpsa.com/index_centralise.phpSuivi BU --> USS --> Suivi USS --> Cocher "Suivi Complet"

édité le : 28/04/23 page: 31/ 37

http://sssd.inetpsa.com/index_centralise.php

Documentation


GENERALE

Cas de la perte sur une Pièce Jointe

Le répertoire des Pièce Jointe actuel contient les fichiers suivants :

édité le : 28/04/23 page: 32/ 37

Documentation


GENERALE

Nous supprimons par exemple le fichier AC_50025238_20090116161407059.doc.Le test applicatif nous donne le résultat suivant « Le fichier est introuvable ».

édité le : 28/04/23 page: 33/ 37

Documentation


GENERALE

Restauration du fichier des Pièces Jointes

La restauration passe par le job xxxxxxxxxxxxIl faut y paramétrer …………………..Une fois exécuté le fichier se retrouve dans le répertoire /users/gdu00000/montage/restoreDéplacer le fichier dans un répertoire temporaire afin de ne pas prendre le risque d’écraser ou de modifier les répertoires viables. Une fois avoir dézippé (gzip –d <nom>) et desarchivé (pax –rf <nom>) le fichier dans votre répertoire temporaire, vous avez toutes les Pièces Jointes stockées dans un sous répertoire « courant ».Il ne reste plus qu’à copier le fichier – dans notre exemple – « AC_50025238_20090116161407059.doc » dans le répertoire /users/gdu00000/data/pj/courant

édité le : 28/04/23 page: 34/ 37

Documentation


GENERALE

Le fichier ne possède pas le même nom de propriétaire mais cela ne pose pas de problème applicativement parlant avec les droits par défaut (664).

8.2. GESTION DES LOGSLes logs applicatives sont nommées de la manière suivante :

<nom script indus> + « .log »

Dans le cas d’un lancement multi-journalier, les différentes logs sont ajoutées en fin de fichier.

L’historisation des logs se fait tous les jours à 21h.Traitement : GDOHL gdo_0hl0.shLes logs sont transférées du répertoire $UNXLOG vers $UNXHISTO/log. Elles sont renommées en <nom de log> + save + <date et heure de sauvegarde>.

8.3. PURGE DES LOGS ET FICHIERS DE DONNEESLa purge des logs se fait via également GDOHL. Elle ne conserve uniquement que les 120 derniers jours.Les fichiers de données, stockés dans $UNXHISTO/recept ou envoi, sont purgés au bout de 120 jours.

8.4. SURVEILLANCELa surveillance des jobs est automatiquement assurée par OPC.

édité le : 28/04/23 page: 35/ 37

Documentation


GENERALE

De plus, les J2EE Serveur et IHS sont enregistrés dans l’automate :- Incident remonté au pupitre si « crash »- Relance du processus

(source : DSIN-NM-WBS05 – Norme métier WebSphere)

Les arrêts/relances « normaux » par job OPC ne génère par d’incident.

8.5. INCIDENTS ET CONSIGNESLes instructions de reprise sont données via les OI (Opération Instruction).Les instructions définies pour cette application sont de « laisser en l’état, transfert de l’incident à l’indus ».

8.6. SERVEUR D’APPLICATIONS WEBSPHEREEn cas d’intervention sur la base de données pouvant rendre l’application indisponible, il est préconisé de faire au préalable un arrêt du serveur d’application Websphere.

Ces arrêts/relances se font par les jobs OPC utilisés également pour les chaînes de déploiement GDOZO et GDOZ3.

9. PRISE EN COMPTE DE LIVRAISON

Les livraisons se font par l’intermédiaire de packages livrés par les Etudes.

Le package pour l’application doit être nommé de la façon suivante : - L<Code Etude défini dans Endevor><PRD de l’application>XXX

Exemple : LGUGDO02R

Une fois récupéré, le mode de déploiement du package se fait en fonction du contenu du package.

9.1. DÉPLOIEMENT APPLICATION D’ENTREPRISESous ZOS, le déploiement de l’ear et des properties ne se fait pas par la console d’administration mais par une chaîne OPC, comme préconisée dans le document RDBAC20.

Traitement : GDOZO

Rappel des noms des répertoires des serveurs d’application :Pré-prod Prod

Serveur WAS BWE1BS3(C) CWE1ASI(S)

Localisation d’origine des objets : L’EAR est copié via Endevor dans un répertoire tampon sur la machine cible. Le répertoire est codifié de la manière suivante :/users/tampon/<Serveur WAS>/adeployer

Les fichiers properties sont quant à eux copiés dans les sous-répertoires de /users/tampon/bgc00000.

édité le : 28/04/23 page: 36/ 37

Documentation


GENERALE

La chaîne OPC est décomposée de la manière suivante :- Copie des properties TP et vidage du répertoire tampon (GDOZ0GDO)- Sauvegarde du dernier EAR déployé et celui qui va l’être dans

/users/gdo00000/<Serveur WAS>/saveXXX (GDOZ00CP)- Déploiement de l’EAR (GDOZ00DP)- Association de la bibliothèque partagée (GDOZ0PAT)- Destruction de l’EAR dans le tampon (GDOZ00DL)- Test des fichiers témoins de prise en compte d’EAR et properties pour

déclenchement de l’arrêt/relance du serveur d’application.- Arrêt/Relance du serveur d’application (postes NV00)- Mise à disposition (GDOZ0M00)

Des logs complémentaires sur la chaine de déploiement se trouvent dans /users/gdo00000/exploit/log.

Si à l’issue de la bonne exécution de la chaine de déploiement l’application est indisponible, les logs WebSphere concernant le serveur d’application concerné sont visibles dans la Sysview (en filtrant sur le nom du serveur d’application).

9.2. DÉPLOIEMENT OBJETS APPLICATIFSTraitement : GDOET

Cette chaîne OPC lance sous /users/gdo00000/exploit/outils ($UNXEXOUTILS), le script gdo_0liv.sh.

Ce script se base sur le fichier gdo_livr.dat situé dans /users/gdo00000/exploit/data ($UNXDATA).Chaque ligne est décomposée en deux colonnes : le répertoire source et le répertoire cible. Pour chaque composant trouvé dans un répertoire source, il est copié dans son répertoire cible correspondant.De plus, chaque fichier d’archive « .pax » est décompressé dans le répertoire cible.

Les livraisons sont historisées dans /users/gdo00000/histo/livraison et une log se trouve dans /users/gdo00000/exploit/data/outils ($GDO_RESULTAT).

édité le : 28/04/23 page: 37/ 37

dossier exploitation gdo psa

Documents