Séminaire d’installation et d’exploitation technique Apogée.

Séminaire d’installation et d’exploitation technique Apogée.

SEMINAIRE TECHNIQUE APOGEE Introduction
Objectifs Comprendre techniquement Connaître précisément Etre opérationnel Prérequis DBA Oracle 10g/ Oracle 10g AS Administration OS : Unix/Linux /Windows Réseau

SEMINAIRE TECHNIQUE APOGEE Plan
Premier jour Architecture & Documentation Installation d’Apogée Deuxième jour Tests d ’installation Base de test Fin d ’installation, le Domaine Référentiel Habilitations Domaine exploitation Premier jour : A : Présentation de l’architecture globale d’Apogée et des documentations techniques indispensables (CCI, manuel install,exploit) B : Description de l’installation d’Apogée. Cette opération est détaillée dans le manuel d’installation. => installation complète d’une base de production Apogée Deuxième jour : C : Tests d ’installation : la base de donnée, architecture batch, poste client. D :Base de Test :Apprendre à créer une base de test (opération délicate et réalisée sous la responsabilité du site). Questions/Réponses => ing.système, visite salle machine E : Gestion des habilitations dans le logiciel (procédures de gestion des droits d’accès dans le logiciel) F : Tests de fonctionnement et gestion des batchs (opération délicate qui nécessite de suivre au plus près les manuels). G : Exploitation (gestion des sauvegardes, des purges, de batchs de la chaîne de nuit et de jour,...) N’hésitez surtout pas à poser des questions si un terme vous échappe ou si une explication ne vous semble pas claire. Vous serez responsable sur votre site.

Architecture et Documentation Technique
SEMINAIRE TECHNIQUE APOGEE Architecture et Documentation Technique

SEMINAIRE TECHNIQUE APOGEE Architecture & Documentation
Architecture 3 Tiers Serveur de bases de données Plates-formes validées: AIX 5L v 5.3 (64-bit) HP-UX 11i PA-RISC (64-bit) HP (Compaq) Tru64 5.1b (64-bit) Linux Red Hat Enterprise 4.x AS/ES (32 bits ou 64 bits) Dimensionnement Mémoire:système : entre 20 Mo et 50 Mo + Base Oracle : 500Mo + utilisateurs connectés : 8 Mo X nb utilisateurs + batchs Apogée : 1 Mo X nb utilisateurs Disque : système (1 Go) + Oracle 10g (4 Go) + Oracle Forms & Reports standalone (500 Mo) + Apogée (200 Mo / version) Serveur d’applications Windows XP, 2000, 2003 Linux RHEL 4 (et 3 sur certaines plates-formes) / SLES 9 (et 8 sur plate-forme Intel 32 bits) Dimensionnement: Disque : Système (1Go minimum) + Oracle (au moins 1.5 Go) + Apogée (500 Mo / version) Mémoire : système (100 Mo) + Oracle AS1g (1.5 Go) + 25 Mo * nombre maximum de sessions simultanées. Poste clients Windows XP, 2000, 2003, VISTA Disque : 2 Go Mémoire : 128 Mo minimum Réseau Liaison PC / serveur AS10g par réseau Ethernet à 10 Mbit/s via TCP/IP Liaison haut débit entre serveur AS10g et le serveur BDD

Site Local Streamer Réseau Ethernet 10/100 Mbits Serveur de fichiers (optionnel) Novell, Lan Manager, …) Sites Distants Pont vers l'extérieur : RENATER LS X25 Poste Isolé Un poste serveur BO XI R2 Windows 2000, XP SQL/Net V10 Business Object CMS Navigateur Internet Option Web Postes clients : Navigateur IE / Firefox Business Objects Client Serveur BDD UNIX Oracle Forms / Reports 10g stand alone Serveur LDAP (option) Serveur HTTP Serveur SMTP Serveur d ’application J2EE Internet Postes clients Impression A4 - A3 Impressions Synchrone et Asynchrone Editions Html et Pdf Firewall Serveur 10gAS SSO OID Forms / Reports 10gAS Serveur CAS

Cahier des Charges d’Implantation : CCI Plates-formes validées Versions de logiciels Dimensionnement , Volumétrie Manuel d’installation Procédures d’installation Procédures de test d’installation Dossier d’Exploitation Bible de l’exploitant Annexes exhaustives Il existe trois documents dont la maîtrise est absolument indispensable à une installation et une exploitation technique efficace d’Apogée. Le cahier des charges d’implantation : Il contient l’ensemble des pré-requis d’Apogée tant en terme de logiciels, que de versions ou d’architectures. Le Manuel d’installation : Il contient la description des procédures d’installation des différentes parties d’Apogée : base batchs client Le Dossier d’Exploitation et ses Annexes : Véritable «Bible» de l’exploitant. Ce dossier et ses annexes comportent une description complète des objets de la base, des procédures à suivre pour l’exploitation, etc. Ce document est à consulter avant tout appel au support.

Les documents clefs (1/2) Docsit_400\I_doc_version\v400\1_doc_tech NOT031InstallationOracle10gAS.pdf : Note d’installation du serveur d’application NOT035Migration10gAS-retourExperience.doc : Recueil d’informations concernant la mise en œuvre d’Apogee en 10GAS ConfigImpApogee.doc : Détail de la configuration des imprimantes Docsit_400\III_doc_technique\1_installation minstall.pdf : manuel d’installation Apogee apnscci2.pdf : CCI Apogee manuel_technique_iaprimo_web.pdf manuel_technique_iareins_web.pdf manuel_technique_ip_web.doc

Les documents clefs (2/2) Docsit_400\III_doc_technique\2_exploitation apanxde2.pdf : Annexe au dossier d’exploitation apdexp2.pdf : Dossier d’exploitation base de production apdform2.pdf : Dossier d’exploitation base de formation conv_opi.pdf : mise en œuvre interface OPI digc_site.xls : bible Apogee dossier_technique_ .doc: mise en œuvre de l’interface LDAP

Installation d’Apogée
SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée
Points fondamentaux : La base de données Le serveur d’applications Le module d’accès Web: FormWebAccess Business Objects Services Numériques et WebServices L’architecture Batch La base de formation Le préalable indispensable à l’intallation d’Apogée est l’installation complète des logiciels Oracle, y compris NET*9. - Patchs à passer et installation de report. L’installation de l’application Apogée comporte quatre composantes fondamentales. Trois sont relatives à la base de production : l’installation de la base l’installation du poste client l’installation de l’architecture batch L’installation d’une base de formation est plus spécifique.

La base de production a : La détermination du volume de la base (*) b : La préparation des File-Systems en fonction du volume c : Les points de montage d : La récupération d’une livraison e : Le script d’installation f : Le déroulement d’une installation g : Les retouches des scripts (*) h : La vérification d’une installation correcte i : La configuration de NET8 J : L’installation de report standalone Le serveur d’applications Le module d’accès Web: FormWebAccess Business Objects Services Numériques et WebServies L’architecture batch La base de formation La présentation de l’installation de la base de production a été segmentée en neuf parties : a : La détermination du volume de la base (*) b : La préparation des File-Systems en fonction du volume c : Les points de montage d : La récupération d’une livraison e : La présentation des scripts f : Le déroulement d’une installation g : Les retouches des scripts (*) h : La vérification d’une installation correcte i : Configuration de NET*9 Certaines étapes marquées avec un astérisque (‘*’) sont plus complexes et peuvent être envisagées après une première installation.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée La mise en place des filesystems Différents selon les systèmes UNIX Règles fondamentales : Choisir systématiquement un volume supérieur Sécuriser mais pas à outrance Surveiller l’état des disques Préférer la flexibilité à la facilité Attention résultats commande « df » La création des filesystems sous UNIX dépend du type d’UNIX utilisé. On peut cependant donner six points génériques. En premier lieu, il convient de prendre des marges. IBM a longtemps considéré qu’un disque plein à plus de 50% était un disque saturé. Cette marge est importante, cependant il faut se garder une marge d’au moins 15% d’espace libre sur vos filesystems. Il est nécessaire de sécuriser le fonctionnement mais aussi de veiller à ne pas brider les performances. Exemple : ne pas mettre les fichiers d ’archivelog sur une baie RAID 5. Avant de localiser les filesystems il peut être utile de déterminer quels disques sont les plus rapides (internes ou externes) et de choisir en fonction de la priorité donnée à l’application Apogée par rapport aux autres produits installés. Les disques doivent faire l’objet d’une attention particulière et notamment dans le cas de systèmes fonctionnant en mirroring où les opérations d’écriture sont démultipliées. Il peut être intéressant de disposer localement d’un disque de secours. Même si la création de certains types de filesystems sécurisés est plus difficile à mettre en œuvre, l’investissement s’est toujours révélé rentable. La commande df utilisée pour obtenir le volume disponible sur les filesystems retourne, selon les systèmes, la valeur en blocs ou en ko. Ceci peut induire de fausses conclusions sur le volume disponible : df -k

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Les points de montage
Six points de montage : Point 1 : Données IA, IP & Accès à distance Point 6 : Index autres Point 5 : Données autres Point 2 : Index IA, IP & Accès à distance Point 4 : Index Résultats Point 3 : Données Résultats La base de données Apogée est répartie sur six points de montages différents. Point 1 : Les données relatives à l’inscription administrative (IA), à l’inscription pédagogique et à l’option Accès à distance . Point 2 : Les index des données du point 1. Point 3 : Les données du domaine résultat. Point 4 : Les index des donnée du point 3 Point 5 : Les données relatives aux autres domaines. Point 6 : Les index des données du point 5. Il est recommandé de localiser ces points de montages sur des accès physiques séparés afin de prévenir les problèmes d’engorgement. Il ne s’agit pas uniquement de placer les points sur des disques différents car on peut saturer un contrôleur s’il gère tous les disques. Dans l’ordre de priorité il convient de séparer les points 3&4 puis 1&2 et enfin 5&6.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée La récupération d’une livraison Circuit de livraison : Livraison initiale Apogée : FTP Sur FTP Documentation : FTP Livraison des patchs L’annonce d’une livraison (patch) se fait par l’intermédiaire du courrier électronique ou d’un FAX à destination des responsables Apogée du site. Les fichiers sont récupérables sur le serveur via une connexion FTP en mode binaire. Actuellement le nom du serveur est ftp.amue.fr. La connexion se fait en utilisant le login aporead dont le mot de passe vous sera communiqué ultérieurement par téléphone. Toutes les livraisons se composent d’un certain nombre de fichiers dont la nature et les modalités d’exploitation sont précisées dans une note d’accompagnement au format Word 6.0/95, ainsi que dans le manuel d’installation. A la fin de la livraison, et avant de couper la connexion, il est recommandé de vérifier que les tailles des fichiers sont bien les mêmes entre le serveur de livraison et la copie locale. Avec le débit normal en sortie du serveur, le temps de récupération d’une livraison classique est de l’ordre de 30 minutes. Il est conseillé de lancer ces récupérations la nuit lorsque le réseau Renater n’est pas saturé.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Le script d’installation Exécution en APOINST Données indispensables : Le type de système UNIX (AIX, Tru64, HP-UX ou LINUX RH AS ES 4) : Le nom du groupe habilité DBA Le nom du groupe gérant les batchs d'Apogée (APOBATCH) Le nom de l'instance de production et les points de montage Le nom de l'instance de formation et les points de montage Le répertoire d ’installation des outils Developer 6i Pour créer l ’utilisateur APOINST il faut au préalable avoir créé le groupe APOBATCH. APOINST doit donc appartenir aux groupes DBA APOBATCH . Dans le .profile de APOINST (en ksh) doivent y figurer : - ORACLE_HOME - ORACLE_SID - ORACLE_HOME_OUTILS (Génération des batchs) - NLS_LANG=american.america.we8iso8859p1 - PATH = $ORACLE_HOME/bin Le script d’installation d’Apogée (install.sh) doit être lancé dans une session APOINST (telnet APOINST depuis une station plutôt que su pour récupérer les variables d’environnement) par la commande «sh install». Un certain nombre de données doivent être fournies au script d’installation afin qu’il puisse créer la base de production (ainsi que la base de formation et l’architecture batch). Ces données sont : le type de système UNIX qui conditionne l’utilisation du fichier «make» adapté à l’OS spécifié. le nom du groupe habilité DBA afin de vérifier les appartenances des utilisateurs et de positionner les droits sur la distribution. les noms et points de montage des instances de production et de formation.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Le script d’installation

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Le script d’installation Quelques principes des scripts : Commentés #================================================================= # MISE A JOUR DES VARIABLES GLOBALES # Recuperation du repertoire d'installation. repertoire_installation=`pwd` APOGEE_HOME=$repertoire_installation export APOGEE_HOME APOGEE_BATCH=$repertoire_installation/batch export APOGEE_BATCH # création du fichier log oracle.log. rm -f apo_oracle.log Les scripts sont rédigés en Bourne Shell et ne comportent pas d’options particulières aux systèmes d’exploitation. En effet certains systèmes UNIX n’interprètent pas de la même façon les options des commandes selon les versions. La variable LANG doit correctement être positionnée, en effet certains scripts peuvent tester des chaînes de caractères qui diffèrent selon les langues : par exemple ERROR et ERREUR.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Le script d’installation Quelques principes des scripts : Passage de paramètres explicités dans le header #! /bin/sh ######################################################################### # # # Script : apo_genere.sh # # Generation des executables batchs d'APOGEE # # Auteur : Pôle Livraison (FRN) # # Date : 20/11/ # # Parametres : $1 - plateforme d'installation (AIX, OSF1 ou HPUX) # # $2 - AUTO : generation lancee par script d'installation # # MANUEL : generation lancee manuellement # # Modif : 23/09/ # # Compilation avec les outils ORACLE DEVELOPPER # Le passage des paramètres aux scripts (ici apo_genere.sh) est réalisé d’une manière explicite et détaillée dans le header des scripts. Informations sur le script : auteur , date , mofication ... Les noms des variables sont aussi explicites : groupe, instance, disk1 ...

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Le script d’installation Quelques principes des scripts : Modification dynamique via le script apo_remplacer. Création des fichiers ~ # On remplace les références génériques à l’ORACLE_SID # et aux points de montage 1 et 2 par les valeurs saisies ./apo_remplacer INSTANCE $instance ${apo_init} ${apo_init0} apo_$instance.db~ apo_$instance.tsp~ apo_$instance.rbs~ ./apo_remplacer dsk1 $disk1 ${apo_init} ${apo_init0} apo_$instance.db~ apo_$instance.tsp~ ./apo_remplacer dsk2 $disk2 ${apo_init} ${apo_init0} apo_$instance.db~ apo_$instance.tsp~ # On remplace les références génériques aux points de montage 3,4,5 et 6 # par les valeurs saisies si la base à créer n’est pas de formation if [ ! "$domaine" = "FORMATION" ] then ./apo_remplacer dsk3 $disk3 apo_$instance.tsp~ ./apo_remplacer dsk4 $disk4 apo_$instance.tsp~ ./apo_remplacer dsk5 $disk5 apo_$instance.tsp~ ./apo_remplacer dsk6 $disk6 apo_$instance.tsp~ fi Il existe des situations où l’on ne peut pas exploiter facilement les paramètres, par exemple pour créer un fichier de la base (*.dbf) sur l’un des points de montage il est nécessaire d’exécuter un ordre SQL contenant le chemin physique et non une valeur de variable connue seulement du shell lançant la session svrmgrl Pour ce faire, les scripts d’installation utilisent un petit script (apo_remplacer) pour remplacer les références génériques par les valeurs contextuelles dans une copie du fichier contenant la requête. Cette copie est suffixée d’un signe ‘~‘. Par exemple le fichier apo_p.tsp contient la ligne suivante : CREATE TABLESPACE data_re DATAFILE 'dsk3/oracle/INSTANCE/data_re_1.dbf' Le script apo_base crée une copie du fichier apo_p.tsp qu’il nomme apo.tsp~ puis il remplace la chaîne «dsk3» par la valeur spécifiée comme troisième point de montage et la chaîne «INSTANCE» par le nom de la base donné lors du lancement d’install.sh (c.f. diapositive). Si l’on suppose que le troisième point de montage est «/ora2/APOGEE.pt3» et que l’instance a pour nom «APOGEE», à la fin de ces opérations, le fichier apo.tsp~ contient la ligne suivante : DATAFILE /ora2/APOGEE.pt3/oracle/APOGEE/data_re_1.dbf' Cette commande est alors exécutable sous SQLPLUS. Chaque script et chaque fichier temp ~ sont spécifique à l ’instance sous laquelle ils sont lancés.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Le déroulement de l’installation Architecture des appels du script install.sh install.sh creer_point.sh Création des points de montage de la base de production creer_base.sh apo_base.sh Création de la base de production. (3 scripts) apo_base_init.sh Création des rôles, utilisateurs, objets et données de référence (23 scripts) apo_genere.sh En résumé le déroulement du processus d’installation est le suivant : install.sh effectue des vérifications de configuration, puis saisie l’ensemble des paramètres indispensables à l’installation. Il fait alors appel au script creer_base, un script générique utilisé pour la création de la base de production et pour la création de la base de formation. creer_base effectue le contrôle de l’arborescence des points de montage et instancie les scripts SQL de création de la base, des tablespaces et des rollback segments. L’exécution de ces ordres est assurée par le script apo_base. install.sh reprend le contrôle et provoque la création des objets Oracle de la base de production puis initialise la base. apo_base_init : remplissage des tables du référentiel. L’étape suivante consiste à modifier le numéro de version dans la base de production afin de la rendre accessible uniquement aux clients compatibles. Ceci achève la création de la base de production. L’installation se termine par une édition de liens (32 ou 64 bits ) avec le script apo_genere.sh VISUALISER LES SCRIPTS ET EXPLIQUER ARBORESCENCE Verification de la base : complet.sql Création de l’architecture batch et reports asynchrones (1 script)

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Le déroulement de l’installation Architecture des appels du script formation.sh formation.sh creer_point.sh Création des points de montage de la base de formation initialiser_formation.sh Récupération ou mise à jour des données imprimante et université creer_base apo_base Création de la base de formation. (3 scripts) apo_base_formation.sh Création des rôles, utilisateurs, objets et données de référence (form.dmp) Déroulement identique à l ’installation de la base de production, ici 2 points de montage seulement En résumé le déroulement du processus d’installation est le suivant : formation.sh : effectue des vérifications de configuration, puis demande l’ensemble des paramètres indispensables à l’installation. Il fait alors appel au script initialiser_formation.sh, puis créer_base.sh un script générique utilisé pour la création de la base de production et pour la création de la base de formation. Le script creer_base effectue le contrôle de l’arborescence des points de montage et instancie les scripts SQL de création de la base, des tablespaces et des rollback segments. L’exécution de ces ordres du DDL est assurée par le script apo_base. Le script formation.sh reprend le contrôle et provoque la création des objets Oracle de la base de production, ainsi que le remplissage des tables du référentiel avec les données livrées. Cette tâche est remplie par le script apo_base_formation. L’installation se termine par une édition de liens (32 ou 64 bits ) . Creation des objets rôles users par import d ’un dump form.dmp apo_genere.sh Création de l’architecture batch et reports asynchrones (1 script)

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée La retouche des scripts Il est possible de retoucher les scripts : Tests Reprise sur incident Volumétrie ... L’étude minutieuse des scripts d’installation d’Apogée permet de progresser rapidement dans la connaissance des installations. Elle facilite la reprise sur incidents et permet au site d’adapter éventuellement les scripts à ses particularités. De plus il est recommandé aux exploitants de bien avoir lu et intégré le cahier des charges, le dossier d’exploitation et les annexes de ce dernier. Ces documents constituent une aide précieuse permettant de prévenir un grand nombre d’erreurs de manipulation. Il est possible de modifier les scripts à des fins d’études, pour reprendre une installation interrompue par des incidents ou pour mettre en place de nouvelles volumétries dans les scripts de création d’objets Oracle. Les opérations de modification des scripts, effectuées sans contrôle et archivage précis des modification, peuvent conduire à de sérieux problèmes.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée La vérification d’une installation correcte Les fichiers de log de l’installation initiale : localisations Les principaux fichiers LOG sont spécifiques à l ’instance sous laquelle est lancé le script : install.sh $APOGEE_HOME/install/log/install.[Instance].log formation.sh $APOGEE_HOME/install/log/formation.[Instance].log apo_base.sh $APOGEE_HOME/install/log/apo_base.[Instance].log Le fichier log du script de génération des exécutables est daté : apo_genere.sh $APOGEE_HOME/install/log/apo_genere.[Date].log Examen systématique de ces fichiers Recherche de la chaîne «ORA-» Lors de l’exécution des scripts de création, toutes les sorties sont dirigées vers des fichiers de journalisation de l’activité nommés ‘log’. Il existe deux fichiers de logs principaux qui sont install.log et apo_genere.log,situés dans le répertoire $APOGEE_HOME/install/log. Chaque log est spécifique à l ’instance sous laquelle le script est lancé. La variable $APOGEE_HOME, affectée dans le fichier exécutée lors de la connexion de l’utilisateur, pointe sur le répertoire où est située la distribution du serveur : par exemple /apogee/apo_2_50init. Il est nécessaire d’examiner tous ces fichiers de log en cherchant, par exemple sous l’éditeur vi , toutes les indications d’erreurs. On peut, par exemple chercher toutes les occurrences de la chaîne «ORA-» qui correspondent aux erreurs Oracle relatives au SGBDR. Cette opération est effectuée, par les scripts à la fin de l’installation. On utilise pour cela la commande Unix grep sur les fichiers de log. Cependant effectuer des grep dans des sessions interactives peut amener l’utilisateur à saisir des commandes du type >grep ORA- *.log ce qui peut induire de fausses alertes. Ne pas faire de recherche sur apo_oracle.log En cas d’erreur nécessitant la relance de l’installation penser à supprimer les fichiers de log.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée La vérification d’une installation correcte La réaction face aux erreurs d’installations Sauvegarder les log Localiser l'erreur apo_oracle.[Instance].log apo_genere.[Date].log Identifier la position dans le déroulement du script Identifier et analyser l’erreur En cas de doutes : Autres compétences locales Autres sites Apogée Correspondant technique Supports : constructeurs, Oracle ... Si jamais des erreurs sont détectées, la démarche à suivre est la suivante : Sauvegarder les log Sauvegarder les fichiers de log dans un répertoire situé en dehors de la distribution Apogée. Localiser l’erreur Il faut déterminer dans quel(s) fichier(s) se sont produites des erreurs. Il est parfaitement normal de trouver des erreurs lors du remplissage du tablespace system (sortie du script apo_base dans le fichier apo_oracle.log). De plus il convient de distinguer les erreurs (errors) des avertissements (warnings) sans conséquences dans le fichier (apo_genere.log). Lorsque l’erreur est repérée il faut la situer dans le déroulement du script (noter les indications de déroulement du script qui précèdent et suivent l’erreur). Identifier et analyser l’erreur Oracle fournit, dans son lot de documentation standard, un manuel des codes d’erreurs qui donne non seulement l’explication mais aussi des conseils pour la résolution du problème. En cas de doutes Si le problème n’est pas résolu par l’exploitant, la démarche doit être graduelle : autres compétences locales, autres sites, correspondant technique et enfin le support d’Apogée.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée. paramétrer NET
SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée paramétrer NET*8 serveur PAS EN ROOT ! LISTENER = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = ) (PORT = 1521) ) Le listener Trois parties Protocoles Services Paramêtres SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME =) (ORACLE_HOME=) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = APOGEE) (ORACLE_HOME=/oracle/products/ora9206) ) Ajout d’une base SID ORACLE_HOME TOUTES LES OPERATIONS SUR NET*9 SONT A EFFECTUER SOUS L’UTILISATEUR ORACLE. Le logiciel NET*9 est un outil Oracle qui permet la connexion d’une application s’exécutant sur une machine cliente à un noyau Oracle s’exécutant sur une machine serveur. Pour Apogée NET*9 est utilisé en surcouche de TCP/IP. Sur le serveur c’est un démon nommé lsnrctl qui assure cette fonction. Il est configuré par le fichier listener.ora situé dans le répertoire $TNS_ADMIN si cette variable est positionnée, ou, dans le cas contraire, d’abord dans le répertoire ORACLE_HOME/network/admin puis sous /etc. Le lecteur se référera à la documentation Oracle, les informations qui suivent ne sont données qu’à titre indicatif. Le fichier de configuration comporte trois parties : la définition des différents protocoles acceptés par la machine (ici TCP/IP), la définition des services (ici APOGEE) et divers paramètres. Pour ajouter un service, i.e. pour permettre au démon de prendre en compte les demandes arrivant pour une base de données il suffit de spécifier sa SID et le répertoire ORACLE_HOME relatif à la version de la base de données (celui correspondant à la version 7.3.x). Lorsque les modifications du fichier ont été effectuées et vérifiées, il est obligatoire d’arrêter puis relancer le démon par les commandes lsnrctl stop et lsnrctl start. Vérifier les services démarrés : lsnrctl stat <LISTE> Modif sous vi : non validé par Oracle (outil client nécessaire) TRACE_LEVEL_LISTENER = OFF STARTUP_WAIT_TIME_LISTENER = 0 CONNECT_TIMEOUT_LISTENER = 60 LOG_DIRECTORY_LISTENER=/oracle/products/ora9206/network/log LOG_FILE_LISTENER = lsn

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée paramétrer NET*8 serveur Fichier de configuration du client : tnsnames.ora Nom du service ... APOGEE.world = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = ORAPOGEETCP) (PROTOCOL = TCP) (HOST = ) (PORT = 1521) ) (CONNECT_DATA = (SID = APOGEE) Hôte Port SID Sur le client, NET*8 est configuré par le fichier tnsnames.ora situé dans le répertoire ORACLE_HOME/network/admin pour une distribution PC ou sur /etc si c’est un système UNIX. Le lecteur se référera à la documentation Oracle; les informations qui suivent ne sont données qu’à titre indicatif. Le fichier de configuration tnsnames.ora (situé dans le répertoire ORACLE_HOME/network/admin de la distribution Oracle du client) se compose d’une suite de déclarations de bases dont les points les plus importants sont : le nom donné au service l’adresse IP de l’hôte le numéro de référence du port la SID de la base de données. Si l’on utilise le logiciel de configuration de SQLNET V2 fourni par Oracle, il arrive parfois des incohérences entre le fichier sqlnet.ora et le fichier tnsnames.ora. Ceci se manifeste souvent par des suffixes .world manquant après le nom de la SID dans tnsnames.ora. La référence du port N est précisée dans /etc/services par la ligne : lsnrctl $N/tcp # ORACLE Il est recommandé de procéder régulièrement à des archivages de ces fichiers dont la reconstruction est difficile. Pour le fichier tnsnames.ora des postes clients, il est préférable d’en avoir une copie partagée par tous (lien), ce qui permet des évolutions rapides et globales.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée paramétrer NET*10 serveur Test du paramétrage listener.ora & tnsnames.ora sqlplus #sqlplus SQL*Plus: Release Production on Thu Jan 9 20:21: Copyright (c) 1982, 2006, Oracle Corporation. All rights reserved. Connected to: Oracle9i Enterprise Edition Release bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release Production SQL> Lorsque le paramétrage est achevé le listener peut être relancé la commande lsnrctl start. Le test d’installation de NET*9 peut alors se dérouler. Pour ce faire on utilise l’outil SQLPLUS situé dans la distribution Oracle du serveur en forçant le passage par NET*9. La syntaxe de la commande à lancer sous le compte Oracle est sqlplus où $SID est la SID de la base. Normalement, la connexion doit se dérouler comme présenté dans la diapositive. En cas de problème, les points suivants doivent être tout particulièrement contrôlés ! le nom du service le nom de la SID le port spécifié pour le listener l’état du listener par la commande lsnrctl stat. ... Une fois ces opérations achevées, l’installation d’un poste client peut débuter.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée report standalone
Permet la communication entre les batchs et le serveur de reports Décrit au chapitre 10 de la note d’installation Apogée sur AS10G Une distribution par type de plate forme Mise en œuvre dépendante de l’infrastructure établissement Installation nécessaire pour pouvoir lancer les éditions asynchrones Suivre scrupuleusement les indications fournies dans la documentation

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée report standalone : principe

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée report standalone : les étapes clef Créer un user dédié à l’installation de report standalone Installer la distribution oracle Vérifier les droits sur les répertoires Mise en œuvre de rwclient Mode multicast Mode Naming service Paramétrage du user batch

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée report standalone : en cas de problème Identifier le tiers cause du problème Console d’administration du report server Vérifier si la demande d’édition lui est parvenue Si oui activer les traces du report serveur pour analyser la cause du problème Log du batch Vérifier que le batch a bien été lancé avec les bons paramètres Contrôler qu’il n’y a pas d’erreur d’exécution Tracer le script apo_runreport.sh Modifier le script pour récupérer la commande générée dans un fichier Le lancer à la main pour obtenir l’erreur éventuelle lors de la demande faite au report server. La procédure à suivre est décrite en détail dans les fiches assistance.

Points fondamentaux : Serveur d’applications Installation d’Apogée
La base de production Le serveur d’applications Installation des produits Oracle Paramétrage d’Oracle AS10g Installation d’Apogée Authentification Module d’accès Web: FormWebAcces Business Objects Services Numériques + WebServices L’architecture batch La base de formation

Cf CCI Apogée pour le niveau de version d’Oracle AS10g (10.1.2.0.2)
Serveur d’applications Installation des produits Oracle Cf CCI Apogée pour le niveau de version d’Oracle AS10g ( ) Téléchargement: Documentations d’installation: Installation : 2 ORACLE_HOME: Infrastructure : <ORACLE_HOME_INFRA> : non concerné par le paramétrage Application Server: <ORACLE_HOME>

Serveur d’applications Installation des produits Oracle
URLs: Permettent de vérifier la bonne installation d’Oracle Infrastructure et d’Application Serveur : console d'administration (ASC) de l'Infrastructure : page d'accueil de l'Infrastructure : console web d'administration de l'OID (il y a aussi la console X11 oidadmin) : console d'administration (ASC) du Serveur d'Applications : page d'accueil du Serveur d'Applications : page d'accueil du Serveur d'Applications en passant pas le Web Cache (celui-ci est activé par défaut)

Serveur d’applications Paramétrage d’Oracle AS10g
Couche réseau d’Oracle: Mettre à jour le fichier <ORACLE_HOME>/network/admin/sqlnet.ora: NAMES.DIRECTORY_PATH= (TNSNAMES, LDAP, EZCONNECT, ONAMES, HOSTNAME) Mettre à jour le fichier <ORACLE_HOME>/network/admin/tnsname.ora: ... APOGEE.world = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = ORAPOGEETCP) (PROTOCOL = TCP) (HOST = ) (PORT = 1521) ) (CONNECT_DATA = (SID = APOGEE) Hôte Port SID

Imprimantes du serveur AS sous Linux : Déclarer l’imprimante dans le fichier <ORACLE_HOME>/guicommon/tk/admin/uiprint.txt Driver des imprimantes (*.ppd) Déposer dans le répertoire <ORACLE_HOME>/guicommon/tk/admin/PPD les drivers des imprimantes. Ajouter dans chaque .ppd la déclaration de la police Apogee Ajouter la déclaration de la police Apogée dans le fichier <ORACLE_HOME>/guicommon/tk/admin uifont.ali

Cas des imprimantes éditant un diplôme de docteur: Mise en place d’une procédure particulière pour les imprimantes qui éditent des diplômes de docteur (serveurs d’applications Oracle sous Linux): Ces diplômes utilisent la police Apogée (police comportant des caractères spéciaux notamment utilisés dans le cadre des titres de thèses). Procédure à suivre au choix: Installer la police sur l’imprimante : Procédure spécifique à chaque constructeur d’imprimantes. Cf documentation constructeur Incorporer la police dans le fichier PostScript généré par le serveur de reports Oracle. Modifier le script shell $ORACE_HOME/bin/rwlpr.sh

Définition de la police Apogee pour le serveur Forms La police Apogee doit être déclarée au niveau du service Forms du serveur Oracle AS. Console ASC >> Groupe d'instances >> Forms >> Forms >> Configuration : choisir Correspondance police-icône Forms (Registry.dat). Ajouter le mapping pour la police Apogée.

Serveur d’applications Installation d’Apogée
Préparation Créer un répertoire $ORACLE_HOME/forms/apogee/ Récupérer l’archive : Nom: apo{version}.as.{ext} Avec ext= gz pour Linux Zip pour Windows La copier dans ORACLE_HOME La dézipper/décompresser avec les outils OS: Arborescence obtenue: $ORACLE_HOME/forms/apogee/apo400/form/ $ORACLE_HOME/forms/apogee/apo400/lib/ $ORACLE_HOME/forms/apogee/apo400/menu/ $ORACLE_HOME/forms/apogee/apo400/report/ $ORACLE_HOME/forms/apogee/apo400/cfg/ $ORACLE_HOME/forms/apogee/apo400/javahelp/ $ORACLE_HOME/forms/apogee/apo400/devEtb/

Déploiement complémentaires (installation initiale ou relivraison ultérieure) (1/2) Aide en ligne: Répertoire $ORACLE_HOME/Apache/Apache/htdocs/aideApogee400 à créer (doit être accessible en lecture) Y copier le contenu du répertoire <ORACLE_HOME>/forms/apogee/apo400/javahelp/ Raccourcis claviers: Copier le fichier $ORACLE_HOME/forms/apogee/apo400/cfg/apogee.res dans $ORACLE_HOME/forms/admin/resource/US/ Icônes Apogée: Copier le fichier $ORACLE_HOME/forms/apogee/apo400/cfg/apogeeIcones.jar dans $ORACLE_HOME/forms/java. Utilitaires: Copier les fichiers $ORACLE_HOME/forms/apogee/apo400/cfg/apogee*.jar dans $ORACLE_HOME/forms/java. Macro Excel de saisie de notes: Copier le fichier $ORACLE_HOME/forms/apogee/apo400/cfg/imp_exp.xls dans $ORACLE_HOME/Apache/Apache/htdocs/.

Déploiement complémentaires (installation initiale ou relivraison ultérieure) (2/2) Police Apogee : Serveurs Linux: Copier le fichier apogee.afm dans le $ORACLE_HOME/guicommon/tk/admin/AFM La renommer en ApogeeMT. Serveurs Windows: Installer la police apogee.ttf sur le serveur à l’aide de l’utilitaire d’installation de police. Modification du fichier $ORACLE_HOME/bin/reports.sh (Linux) ou reports.bat (Windows) Mettre en commentaire la variable REPORTS_PATH Mise en commentaire de la variable NLS_LANG

Paramétrage du fichier formweb.cfg
Serveur d’applications Installation d’Apogée Paramétrage du fichier formweb.cfg Ajouter une nouvelle section (configuration) en fin du fichier $ORACLE_HOME/forms/server/formsweb.cfg (exemple : section [apo400]) à partir du contenu du fichier $ORACLE_HOME/forms/apogee/apo400/cfg/formsweb.cfg Vérifier la valeurs des variables de cette section Variables importantes: Pour activer le mode SSO: ssoMode=true ssoDynamicResourceCreate=true Choix de la JVM: Version JVM 1.4.2_06 imposée Pour accepter une autre versions de JVM: jpi_mimetype=application/x-java-applet

Paramétrage du fichier d’environnement des forms (1/2) Copier le fichier d’environnement $ORACLE_HOME/forms/apogee/apo400/cfg/apo400.env dans $ORACLE_HOME/forms/server Adapter le contenu du fichier d’environnement: Console d’administration ASC >> Groupe d'instances >> Forms >> Composant « Forms » >> Onglet « Environnement » : Sélectionner l’environnement, l’éditer

Paramétrage du fichier d’environnement des forms (2/2) Remplacer dans les valeurs des variables les références à /cheminInstallationOracleAS par la valeur de <ORACLE_HOME> Autres variables: # environnement Apogee (version, report, javahelp) APOGEE_VERSION= REPORT_ENVID=apo400 JAVAHELP_PATH=aideApogee400 SERVEUR_REPORTS=rep_dingo_oracleas

Paramétrage du fichier d’environnement des reports Modifier le fichier de configuration: Console d’administration ASC >> Groupe d'instances >> Forms >> Composant « Reports Server » >> Modifier le fichier de configuration: Y ajouter l’environnement des reports correspondant à la version Vérifier au final la syntaxe Redémarrer le Report Server

Mise à jour d’une installation : livraison d’un patch correctif Mettre à jour les composants modifiés livrés (fmx, plx, mmx, rdf, etc.) dans le répertoire de la version visée. Récupérer l’archive du patch correctif, la copier dans un répertoire temporaire /tmp ou c:\temp par exemple, la décompresser Arborescence obtenue: /tmp/patch_apogee/form/ /tmp/patch_apogee/lib/ /tmp/patch_apogee/menu/ /tmp/patch_apogee/report/ /tmp/patch_apogee/cfg/ /tmp/patch_apogee/javahelp/ Copier le contenu de chacun des sous-répertoires form, lib, menu et report dans le répertoire du même nom sous <ORACLE_HOME>forms/apogee/apo400 Exemple sous Linux : cp –f /tmp/patch_apogee/form/* $ORACLE_HOME/forms/apogee/apo400/form/.

Webutil En mode Web, l'application Forms s'exécute sur le serveur d'applications: Toutes les commandes d'interaction avec la machine (commande système, lecture/écriture de fichiers) s'exécutent donc sur le serveur d'applications. Webutil : librairie Oracle permettant d'exécuter ces commandes sur le poste client. Cette librairie permet d'exécuter les opérations suivantes sur le poste client: Lecture/écriture d'un fichier Lecture/écriture d'images (disque <-> BDD) … Installation : Récupérer les archives suivantes : webutil_106.zip : jacob_18.zip :

Test de l’installation Pré requis client : JVM 1.4.2 Avec Mozilla: problèmes si plusieurs versions de java sont installées! URL: Valider les 2 certificats Ouvertures de plusieurs fenêtres: Navigateur (à ne pas fermer) Applet JAVA (éxécution des forms)

Serveur d’applications Authentification
2 modes: Native : non SSO Configuration Forms: ssoMode=false ssoDynamicResourceCreate=false Server de Reports: Modification du fichier « <chemin d’installation Oracle AS>/reports/conf/rwservlet.properties »: DIAGNOSTIC=YES SINGLESIGNON=NO CASsification d’Oracle Pré requis: Librairies cas-java-client.jar (sur le site CAS de l'université de Yale) Librairie commons-logging.jar (du groupe jakarta). Développement spécifique casOracleSSO.jar Serveur CAS actif v2 ou v3 : Serveur d'infrastructure Oracle actif : L’intégration SSO / CAS se fait sur la partie Oracle Infrastructure

La base de production Le serveur d’applications Module d’accès Web: FormWebAcces Business Objects Services Numériques + WebServices L’architecture batch La base de formation

Application Web d’accès à différentes versions d’Apogée
Module d’accès Web Principe Application Web d’accès à différentes versions d’Apogée Pas de connaissance des URLs associées Raccourci vers une configuration 10gAS (application hébergée + ses paramètres) 2 modes de fonctionnement: SSO non SSO Déploiement sous Tomcat ou AS10g

Principe de fonctionnement en mode non SSO
Module d’accès Web Principe de fonctionnement en mode non SSO Liste de versions d’Apogée auxquelles l’utilisateur peut se connecter. Saisie du login/mot de passe à chaque connexion à l’applicatif

Module d’accès Web Paramétrage non SSO fichier à configurer:
application.properties: application.name=harpege Définition du mode non SSO sso.enabled=false Nombre total de configuration config.nb=2 #Configuration numéro 0 URL: adresse web d’accès à l’application. config.0.url= Nom de la configuration sur Oracle 10g AS. config.0.nom=hdev10g Label: dénomination de la version de l’application Apogée qui sera affichée au client config.0.label=Harpege Liste des « domaines » Apogée : Nombre total de domaine harpege.domaine.nb=2 label : intitulé du domaine affiché à l’utilisateur. harpege.domaine.0.label=Gestion form : nom de la form appelée en surchage dans l’url de la configuration choisie harpege.domaine.0.form=harpege.fmx

La base de production Le serveur d’applications Module d’accès Web: FormWebAcces Business Objects L’architecture batch La base de formation

Installation des produits Business Objects Documentation B.O. Installation CMC Installation client Versions impératives : voir CCI Univers Apogée livrés + états

La base de production Le serveur d’applications Module d’accès Web: FormWebAcces Business Objects Services Numériques + WebServices L’architecture batch La base de formation

Architecture matérielle
Les Services numériques IAREINS Application permettant la réinscription administrative des étudiants et la consultation des inscriptions Architecture matérielle

Les Services numériques
IAReins Pré requis: Pour le(s) serveur(s) Web (appelé frontal HTTP) : Un serveur HTTP (le serveur Web). Il n'y a aucune contrainte spécifique concernant l'OS ou le type de machine serveur. Pour le(s) serveur(s) d'application : Une machine virtuelle JAVA (la JVM). Le module SQLNET d’Oracle Java J2SE Development Kit version 1.4.2 Un moteur de servlets (le serveur d'application) respectant les spécifications Servlet 2.4 et Jsp 2.0 (norme J2EE 1.4). Il n'y a aucune contrainte spécifique concernant l'OS ou le type de machine serveur. Pour le serveur de bases de données : Une base de données Oracle avec un schéma Apogée. Pour la partie client : un navigateur pouvant interpréter du code HTML 4.0 (css 2.0 et javascript 1.1) Serveur(s) facultatif(s) : Un serveur SMTP Un serveur LDAP (si vous utilisez l'interface Apogée/LDAP)

IAReins Livrables: iareins-web : inscription administrative à distance des étudiants. iareins-conf : module de configuration de l’applicatif utilisable par les gestionnaire permet un paramétrage graphique des éléments suivants : Les libellés et les messages d'erreur L’aide contextuelle aux éléments pédagogiques Le contenu des pages d'aide Les coordonnées d'un contact

IAReins Possibilité de paiement extérieur: assurée par l’établissement. TEM_WEB_PMT_EXT = ‘N’ Stockage en base (table PAIEMENT) du N° CB pour un traitement ultérieur des données, pris en charge de l'établissement. déléguée à un tiers spécialisé TEM_WEB_PMT_EXT = ‘O’ Redirection vers un site spécialisé qui va gérer la saisie sécurisée des informations (PAYBOX).

Les autres Services Numériques Définition: applicatifs basés sur une architecture orientée services (SOA) à cinq couches et sur les technologies J2EE (Java 2 Entreprise Edition). Pré requis: Idem IAREINS Les SN: IP Web: service permettant l’inscription pédagogique à distance des étudiants ainsi que la modification et la consultation des inscriptions réalisées. IA Primo Web: IE Web : service permettant l’inscription aux épreuves de seconde session. 2 types d’identification : mire de connexion Identification SSO

IP Web Livrables: ip-web : inscription pédagogique à distance des étudiants ainsi que la modification et la consultation des inscriptions réalisées. ip-conf : module de configuration de l’applicatif utilisable par les gestionnaire permet un paramétrage graphique des éléments suivants : Les libellés et les messages d'erreur de l’IP Web L’aide contextuelle aux éléments pédagogiques Le contenu des pages d'aide Les coordonnées d'un contact Identification pour l’étudiant: idem IAPrimo

IA Primo Web Livrables: iaprimo-web : inscription administrative à distance des étudiants primo-entrant dans l’établissement. iaprimo-conf : module pour le gestionnaire de configuration des éléments suivants : libellés et messages d'erreur Le contenu des pages d'aide Les coordonnées du contact 3 types d’identification pour l’étudiant: Identification par mire de connexion Identification par paramètres d’appel: fourniture par l’applicatif externe appellant ce service des URLs d’appel des paramètres d’identification Identification SSO : lorsque la Web Application est intégrée au sein d’un environnement SSO de type CAS, l’identification est laissée à la charge du serveur CAS

IA Primo Web (idem IAReins) Possibilité de paiement extérieur: assurée par l’établissement. TEM_WEB_PMT_EXT = ‘N’ Stockage en base (table PAIEMENT) du N° CB pour un traitement ultérieur des données, pris en charge de l'établissement. déléguée à un tiers spécialisé TEM_WEB_PMT_EXT = ‘O’ Redirection vers un site spécialisé qui va gérer la saisie sécurisée des informations (PAYBOX).

Les WebServices Permettent d’ouvrir l’application Apogée au sein du système d’information Basés sur une architecture orientée services (SOA) multicouches et sur les technologies J2EE (Java 2 Entreprise Edition). Pré requis: Pour le(s) serveur(s) d'application : Java J2SE Development Kit version 1.4.2 Un moteur de servlets (le serveur d'application) respectant les spécifications Servlet 2.4 et Jsp 2.0 (norme J2EE 1.4). Il n'y a aucune contrainte spécifique concernant l'OS ou le type de machine serveur. Pour le serveur de bases de données : Une base de données Oracle avec un schéma Apogée.

Les WebServices Livrables: apo-webservices : webservices Apogée.
apo-webservicesclient : librairies java d’appels aux Web Services (stubs et proxy). apo-testwsclient : exemple de projet Java utilisant la libraire apo-webservicesclient.jar d’appels aux Web Services Apogée. apo-opi-webservices : webservies OPI. apo-opi-webservicesclient : librairies java d’appels aux Web Services (stubs et proxy). apo-opi-testwsclient : exemple de projet Java utilisant la libraire apo-opi-webservicesclient.jar d’appels aux Web Services OPI.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch
Points fondamentaux : La base de production Le serveur d’applications Module d’accès Web: FormWebAcces Business Objects Services Numériques + WebServices L’architecture batch La base de formation

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch
L’architecture batch Principes Utilisateur BATCH (Unix) Utilisateur Oracle Protocole BEQ Activation Arrêt Logs Les informations contenues dans ces transparents résument celles contenues dans le Dossier d’Exploitation dont la lecture est un préalable impératif à l’installation. L’architecture batch est le nom donné à un ensemble de programmes écrits en Pro*C. Ces programmes exécutent des opérations lourdes qui ne peuvent être effectuées pendant les heures de travail (risques de verrous, de pertes de puissance ou de dégradation des temps de réponse). La description de cette architecture comporte cinq phases : le mode de connexion à la base Oracle, la création de l’utilisateur UNIX, la création de l’utilisateur ORACLE, l’activation d’une architecture, le test de l’installation de l’architecture.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch : Principe Etape 3 : Le batch effectue son travail et produit son résultat : impression de report, écriture dans des fichiers, mises à jour de tables de la base. Table_A Table_B Fichier de sortie Serveur UNIX : Table FILE_BATCH Batch X à heure I Batch Z à heure J Batch X à heure H Etape 1 : Suite à la demande sous Apogée, écriture d’une ligne dans FILE_BATCH. Etape 1 : Etape 2 : A l’heure H le programme parcourant régulièrement la table FILE_BATCH provoque l’exécution du batch X sur le serveur. L'exécution des batchs est lancée depuis Unix, par un process démon qui scrute la table FILE_BATCH. A l’heure demandée pour l’exécution du batch X, il le lance. Les utilisateurs habilités à lancer les batchs doivent disposer d'un compte Unix et d'une connexion sur la base de données. De plus, ils ne peuvent être déclarés sous Apogée, car ils ont des droits différents : la déclaration des utilisateurs batch est nécessairement faite par l'exploitant. Ces utilisateurs ont des droits importants sur la base de données. Ils peuvent en particulier modifier ou supprimer des enregistrements. Les mots de passe de ces utilisateurs sont aussi importants que ceux des utilisateurs root d’Unix, ou apogee ou admin d’Oracle.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch : Utilisateur BATCH (Unix) Utilisateur BATCH (Unix) Un par base Variables ORACLE_HOME ORACLE_HOME_SERVEUR ORACLE_HOME_OUTILS LD_LIBRARY_PATH ORA_CLIENT_LIB TNS_ADMIN TWO_TASK_BATCH NLS_LANG ORA_NLS33 APOGEE_HOME APOGEE_TYPE_CONNEXION APOGEE_DIR_BATCH APOGEE_DIR_LOG APOGEE_DIR_FIC APOGEE_LOG_SYS APOGEE_NBR_MAX_BATCH APOGEE_NBR_ERR_BATCH Répertoires La déclaration de l’unique utilisateur batch par base est effectuée par l’utilisateur Unix root. Si plusieurs bases => plusieurs utilisateurs batch Tous les utilisateurs batchs des différentes bases doivent appartenir au même groupe Unix, celui passé en paramètre lors de l’installation. L'exécution du process démon sous Unix nécessite que différentes variables soient positionnées correctement dans l'environnement Unix de l'utilisateur.(.profile) => fichier prod.profile dans le répertoire batch/cfg. APOGEE_DIR_LOG = $APOGEE_DIR_BATCH/log/$ORACLE_SID => rep des logs d ’execution APOGEE_DIR_FIC=$APOGEE_DIR_BATCH/fic/$ORACLE_SID => rep des fichiers de données gérés par les batchs. APOGEE_LOG_SYS = log système APOGEE_NBR_MAX_BATCH=nbre max de batchs effectués simultanément APOGEE_NBR_ERR_BATCH=nbre max d ’erreur arretant le traitement Ces répertoires (LOG et FIC) devront être créés par l'exploitant (groupe "batch", droits 755). => VISUALISER LES VARIABLES ET EXPLIQUER sous batch/cfg

Noyau Oracle User OPS$ Système UNIX
SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch : Utilisateur Oracle : Mode OPS$ MODE OPS$ (OpeRating System) Identification UNIX script creer_user_batch Recommandé pour batchs Noyau Oracle User OPS$ Système UNIX Le mode OPS$ repose sur l’identification des utilisateurs par le système d’exploitation du serveur. Il permet à un utilisateur Unix de se connecter sans mot de passe à l'instance sur laquelle il a été défini. Pour créer l’utilisateur (dont le nom commence par la chaîne OPS$) il faut exécuter les commandes spécifiées dans le Dossier d’Exploitation. Un script Unix existe qui facilite cette création : créer_user_batch : Identified by externally. VOIR ET EXPLIQUER LE SCRIPT La connexion à la base n’est protégée que par le mot de passe Unix de l'utilisateur, puisqu'il faut être connecté sous ce nom Unix pour lancer sqlplus sans mot de passe Oracle. Le lancement de l'architecture batch se fait alors par l'appel du script apo_batch, sans paramètre, dans le cron Unix du compte root : Il est aussi possible de lancer apo_batch depuis le cron de l ’utilisateur batch : (cron.allow , $HOME/.profile, PATH=.)

Noyau Oracle Système UNIX User non OPS$
SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch : Utilisateur Oracle : Mode non OPS$ MODE NON OPS$ Identification UNIX Identification Oracle Sécurité des batchs ? Noyau Oracle User non OPS$ Système UNIX Le mode standard (non OPS$) impose une double identification : par le système d’exploitation par Oracle. La connexion à la base est protégée par le mot de passe Unix puis par celui d’Oracle. Le lancement de l'architecture batch se fait alors par l'appel du script apo_batch, avec les paramètres <compte oracle> / <mot de passe>, dans le cron Unix du compte root. Ces paramètres seront utilisés pour initialiser les variables $APOGEE_CODE et $APOGEE_PASSE. Ainsi le mot de passe est spécifié au lancement de apo_batch. Ceci est dangereux car un utilisateur malveillant peut essayer d’avoir accès au fichier .profile qu’il convient de protéger.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch : Protocole BEQ Paramétrage du Protocole BEQ Rajout d ’un service dans tnsnames.ora APOGEEbeq.world = (DESCRIPTION = (ADDRESS = (PROTOCOL = BEQ) (PROGRAM = /oracle/products/ora9206/bin/oracle) (ARGV0 = oracleAPOGEE) (ARGS=‘ (DECRIPTION=(LOCAL=YES) (ADRESS=(PROTOCOL=beq)) ) ’) (ENVS=‘ ORACLE_SID=APOGEE,ORACLE_HOME=/oracle/products/ora9206 ’) ) (CONNECT_DATA = (SID = APOGEE)) ) Le protocole BEQ évite de surcharger les couches réseaux du serveur UNIX Protocole BEQ => protocole par défaut Oracle (ne nécessite pas de listener) Attention à la syntaxe dans le fichier tnsnames.ora La variable TWO_TASK est prioritaire sur la variable ORACLE_SID Après insertion du nouveau service : arreter et relancer le listener : lsnrctl stop lsnrctl start Remarque : il est important de mettre toutes les variables d ’environnement (ENVS) sur une même ligne

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch : Protocole BEQ Test du protocole BEQ Positionnement de la Variable TWO_TASK : TWO_TASK=APOGEEbeq Vérification de la variable TNS_ADMIN (emplacement du fichier tnsnames.ora) Test de connexion à la base Pour Apogée on utilise TWO_TASK_BATCH (report asynchrone uniquement) Test de connexion à la base : si connexion OPS$ : sqlplus FAIRE LE TEST SUR LA BASE HP FAIRE APPARTE SUR SQL*NET : sqlnet.ora, tns_admin, listener : les LISTES

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch : Activation Activation Root ou Utilisateur autorisé (cron) crontab script apo_batch OPS$ / Non OPS$ Batch_user apo_lancer_batch apo_batch, est lancé par le cron Unix de l'utilisateur root, toutes les minutes. Ce process crée, si elle n'existe pas déjà, puis exécute, une copie du programme baat_sqc. La copie créée a pour nom baat_sqc_$ORACLE_SID, en type de connexion OPS, ou baat_sqc_$ORACLE_SID_$APOGEE_CODE, en type de connexion non OPS. L'utilisateur lançant ce process doit posséder des variables d'environnement particulières. Voir le chapitre Gestion des utilisateurs pour les batchs. Afin de démarrer l’architecture il est nécessaire de créer le fichier baat_sqc_$ORACLE_SID.start (apo_lancer_batch) dans le répertoire $APOGEE_DIR_BATCH/cfg. La présence de ce fichier est testée par le script apo_batch et permet le lancement du traitement baat_sqc_$ORACLE_SID. Ce travail est effectué par le script apo_lancer_batch lancé sous le compte de l’utilisateur batch. Avant d’activer l’architecture il faut, au préalable, vérifier manuellement son bon fonctionnement : su - $BATCH_USER lancer apo_lancer_batch lancer apo_batch vérifier les logs

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch : Arrêt Arrêt fichier /cfg/baat_sqc_$SID.start script /exe/apo_arreter_batch L'architecture batch ne peut pas démarrer si le fichier baat_sqc_$ORACLE_SID.start est absent du répertoire $APOGEE_DIR_BATCH/cfg. On arrête donc l’architecture par le script apo_arreter_batch lancé sous le compte de l’utilisateur batch. Le fichier baat_sqc_$ORACLE_SID.start est alors renommé en baat_sqc_$ORACLE_SID.stop dans le répertoire $APOGEE_DIR_BATCH/cfg. Le script apo_batch ne lance plus le traitement baat_sqc_$ORACLE_SID.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Architecture Batch : Logs Fichers de compte-rendus >>> babajou1 ADMIN >>> Execution : NORMALE Fin d'execution a :06:04 >>> Lancement le :07: >>> babaheb1 ADMIN 00001 batchs APOGEE Log Système Logs Spécifiques >>> babanui1 ADMIN >>> Debut d'execution a :30:08 [INF-3] Parametres d'exécution : CIP A. >>> babatest1 ADMIN >>> Execution : NORMALE Fin d'execution a :31:58 Les logs sont des fichiers plats Unix contenant les informations relatives à l'exécution des traitements. Ces fichiers sont créés dans le répertoire stocké dans la variable d'environnement Unix $APOGEE_DIR_LOG. Les logs ne sont visualisables qu'à partir d'un terminal connecté à Unix, mais elles peuvent être éditées, à partir de l'écran Liste des travaux différés du domaine Exploitation, sur une imprimante déclarée sous Unix. Il existe deux types de log : la log système et la log spécifique. La log système est un journal recensant le début et la fin de chaque traitement batch. Ce fichier est ouvert en mode partagé afin de permettre l'accès en écriture à tous les traitements batch s'exécutant en parallèle. Ce parallélisme se manifeste par l'entrelacement des messages de début/fin de chaque traitement. Chaque message est identifié par le nom de l'utilisateur demandeur, le batch lancé, la date et l'heure de lancement. Le nom de la log système est paramétré par la variable d'environnement $APOGEE_SYS_LOG. Une log spécifique est créée à chaque exécution de batch. Son nom est constitué par la concaténation : du code du batch, du code utilisateur, du numéro d'ordre de lancement (ce numéro fait partie de la clé de FILE_BATCH), du jour et du mois. L'utilisateur peut retrouver, à partir des informations présentes dans la table FILE_BATCH, la log d'un traitement qui ne s'est pas effectué correctement.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Base de formation
Points fondamentaux : La base de production Le serveur d’applications Module d’accès Web: FormWebAcces Business Objects Services Numériques + WebServices L’architecture batch La base de formation

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Base de formation
La base de formation Structure Installation Rafraîchissement Exploitation La base de formation est livrée avec le logiciel Apogée. Cette base contient les données permettant d'effectuer les scénarios de démonstration et les exercices présentés dans les manuels de formation. Elle est également utilisable pour vérifier que le logiciel installé est opérationnel. Sa présentation s’effectue en quatre étapes : Structure Installation Rafraîchissement Exploitation

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Base de formation : Structure Structure de la base FORM 5 FORM 3 FORM 1 FORM 6 FORM 4 FORM 2 Spécifique Sept environnements Form : BO La base de formation est composée de 7 environnements identiques. Chaque environnement est composé d'un jeu de tables Apogée complet, appartenant à l'un des sept utilisateurs : form, form1, form2, form3, form4, form5, form6. Ces utilisateurs sont créés sous Oracle à l'installation de la base. Les mots de passe sont identiques au code utilisateur. Exemple : form/form, form1/form1. Si l'on se connecte sous l'utilisateur X, seules les tables de l'utilisateur X sont accessibles. Aucun synonyme n'est créé sur les tables, empêchant un utilisateur autre que X de voir les tables appartenant à X : les différents environnements sont totalement indépendants et identiques à l’exception de FORM. Seul FORM est utilisable pour la formation au domaine pilotage : ce domaine n’effectuant aucune écriture dans la base, il n’y a aucun risque de conflit. B.O. FORM

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Base de formation : Installation Formation.sh Installation Printer& Data Script formation.sh /install/sql/form.dmp Données locales : Imprimantes Université FORM.DMP FORM 4 FORM 5 FORM 6 FORM 2 FORM 3 FORM 1 FORM Import sous sept utilisateurs L'installation de la base de formation est réalisée à l'aide du script formation.sh . L’exécution complète de cette opération nécessite de trois à sept heures selon les machines et le nombre d’utilisateurs connectés. Ce script effectue l’import d’un fichier de dump (/install/sql/form.dmp) , spécifique à la version d’Apogée, sous chacun des sept environnements. Le nom de l'université et la file de l'imprimante Unix ne sont pas obligatoires. Ils permettent de mettre à jour automatiquement certaines données de la base de formation, évitant à l'exploitant de le faire ultérieurement, via l'application Apogée, sur chacun des environnements. Penser a faire une sauvegarde physique de la base à l’issu de l’installation.

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée rafraîchissement
script rafraichir_formation.sh Données nécessaires Outils Oracle Nom de l’instance Nom de l’université file UNIX Durée & Volume La base de formation doit être rafraîchie régulièrement par l'exploitant pour réinitialiser les données. Le script rafraichir_formation.sh permet cette opération. Il réalise les opérations suivantes : suppression des données existant pour les sept utilisateurs création des sept utilisateurs Oracle chargement des données pour les sept utilisateurs facultatif : nom de l'université et imprimante. Les informations suivantes sont nécessaires pour l'exécution de la procédure : chemin d'accès à Oracle, à saisir sous la forme /xxx/.../yyy nom de l'instance de la base de formation nom de l'université (*) file de l'imprimante Unix (*) (*) Le nom de l'université et la file de l'imprimante Unix ne sont pas demandés à l'exploitant s'ils sont déjà présents dans les fichiers universite.dat et imprimante.dat dans ce répertoire. L'opération de rafraîchissement des sept environnements de formation prend entre trois et sept heures selon les machines. Il est donc préférable d'effectuer le rafraîchissement de la base en fin de journée. Il peut être judicieux de ne pas rafraîchir la base de formation mais de relancer une création complète en ayant détruit la précédente (le délai peut être inférieur). Remarque : Il est aussi possible de créer une sauvegarde sur bande (ou sur disque si le site dispose de la place suffisante) et d’exploiter cette sauvegarde pour écraser la base à rafraîchir

SEMINAIRE TECHNIQUE APOGEE Installation d’Apogée Exploitation
Mise à jour imprimantes libellé établissement Lancement des batchs Paris IX La base de formation livrée doit être mise à jour après installation pour être opérationnelle. Les opérations suivantes doivent être réalisées : choix de la base accédée par défaut par les postes clients déclaration d'au moins une imprimante pour les éditions et nom de l ’établissement lancement des batchs Base par défaut : Sur chacun des postes de travail utilisés pour la formation, la variable LOCAL doit être mise à jour dans la base de registre , section ORACLE. Se reporter à la documentation Oracle pour le paramétrage de SQLNET V2 sur le poste client et sur le serveur. Données spécifiques Deux données doivent être mises à jour dans la base de formation, pour les éditions à réaliser pendant les sessions : La variable applicative ETB_LIB (libellé de l'établissement) et l'imprimante de code «UNIX» (imprimante rattachée par défaut aux utilisateurs) peuvent être mises à jour automatiquement. Pour de plus amples renseignements le lecteur se reportera au dossier d’exploitation.

Batchs Utilisateur Lancement Arrêt L'exécution des programmes batch se fait à partir du serveur Unix en lançant un process cron. Il est nécessaire de lancer un cron pour chaque environnement de formation. Cela nécessite les opérations suivantes : déclaration d'un utilisateur Unix avec les variables correctes lancement des cron Déclaration d’utilisateur La déclaration de l'utilisateur Unix pour la formation nécessite des variables d'environnement spécifiques et particulièrement : APOGEE_TYPE_CONNEXION : FORM (différent de OPS et non vide). Le fichier /cfg/batch.profile.form, rappelle ces données. Lancement du cron Le lancement de l'architecture batch sur la base de formation est automatisé par des scripts Unix, livrés dans le répertoire <chemin d'installation d'Apogée>/batch/exe. Ils doivent être lancés par l'utilisateur Unix défini pour la base de formation, dont les variables d'environnement sont correctement positionnées pour lui permettre d'accéder au jeu de tables voulu. Cette commande exécute toutes les minutes le script apo_batch_form, qui exécute à son tour le script apo_batch, pour chacun des environnements existant sur la base de formation.

Batchs Utilisateur Lancement Arrêt Arrêt de la base L'arrêt de l'architecture batch sur la base de formation est automatisé par un script Unix, livré dans le répertoire <chemin d'installation d'Apogée>/batch/exe. Il doit être lancé par l'utilisateur Unix défini pour la base de formation, dont les variables d'environnement sont correctement positionnées. 1) Se connecter avec le compte Unix <utilisateur>, correspondant à la base de formation. 2) Se placer dans le répertoire d'exécution des batchs <chemin d'installation d'Apogée>/batch/exe 3) Arrêter l'architecture batch sur la base de formation en exécutant la commande suivante : apo_arreter_form Cette commande renomme en *.stop les fichiers *.start nécessaires pour l'exécution des batchs sur la base de formation dans le répertoire <chemin d'installation d'Apogée>/batch/cfg. Les fichiers *.start ne figurant plus dans le répertoire, le programme baat_sqc n'est plus exécuté.

SEMINAIRE TECHNIQUE APOGEE
Tests d’Installation

SEMINAIRE TECHNIQUE APOGEE Tests d’Installation
Plan : Vérifications sur la base Vérifications sur les batchs Vérifications sur le serveur d’application Vérifications sur le client Les tests d’installation portent sur les quatres parties fondamentales de l’architecture Apogée : la base de données Oracle, l’architecture Batch et le serveur d’application. Il est donc nécessaire de posséder un minimum de connaissances dans les domaines suivants : Administration Oracle Administration UNIX Administration Windows

SEMINAIRE TECHNIQUE APOGEE Tests d’Installation Vérification base
Vérifications sur la base La base est-elle montée ? UNIX : ps -ef | grep pmon Quelle est la version d’Oracle ? UNIX : echo $ORACLE_HOME Quelle est la version de la base ? SQL : select * from version_apo Combien d’objets en base ? SQL :select distinct object_type,count(object_id) from user_objects group by object_type; Quels est l’état de ces objets ? SQL : select distinct object_type, status, count(object_id) from user_objects group by object_type, status; Les vérifications que l’on peut effectuer sur les bases de production et de formation sont nombreuses. Parmi celles-ci on peut citer : Vérifier que la SID spécifiée est la bonne (couple ORACLE_HOME/SID) Vérifier que la base est montée Vérifier le numéro de version d’Apogée de la base Vérifier le nombre d’objets de l’utilisateur Apogee Vérifier le nombre d’objets des utilisateurs Formsi Vérifier l’état de ces objets, particulièrement : tables vues packages Vérifier la connexion par NET*8 sur les deux bases Vérifier le nombre de tablespaces Vérifier la disposition des fichiers sur les points de montage Vérifier le contenu de la table FILE_BATCH ... Comment recompiler un package ? Utiliser le script : ../admin/recompil.sql ...

SEMINAIRE TECHNIQUE APOGEE Tests d’Installation Vérification batchs
Vérifications Architecture Batchs droits sur /batch variables d’environnement le bon fichier de profil utilisateur la table FILE_BATCH la distribution du CRON La vérification de l’architecture batch peut être délicate. Les points précisés dans la diapositive sont les sources des problèmes les plus fréquemment rencontrés : Les droits sur les répertoires /batch ne sont pas conformes à ceux spécifiés dans le Dossier d’Exploitation. Les variables d’environnement ne sont pas correctes ou ne sont pas toutes à jour. Le fichier de profil utilisateur modifié n’est pas celui du shell définit pour l’utilisateur batch. Le contenue de la table FILE_BATCH, d’une base arrêtée brusquement, empêche les déclenchements aux dates et heures demandées La distribution Apogée sur laquelle pointe le CRON n’est pas correcte. Les réponses à une immense majorité de questions se trouvent dans le Dossier d’Exploitation d’Apogée. Si PB fonctionnement des batchs : Vérifier droits sur CFG/EXE/LOG/FIC les fichiers de log

SEMINAIRE TECHNIQUE APOGEE Tests d’Installation
SEMINAIRE TECHNIQUE APOGEE Tests d’Installation Vérification serveur d’application Console d’administration pour vérifier l’état des composants Les sessions actives Les traces sqlnet Les reports en cours, terminés (OK/NOK) Les traces reports server

SEMINAIRE TECHNIQUE APOGEE Tests d’Installation Vérification client
Vérifications Client Espace disque suffisant Résolution Navigateur Plug in Java Police Apogee Le poste client n’est pas nécessairement, contrairement à l'opinion généralement répandue, la partie la plus simple de l’application. La structure logicielle en strates, en provenance de divers constructeurs, ne favorise pas la recherche des causes premières d’incidents. Cependant un certain nombre de vérifications simples peuvent être effectuées avant de devoir se plonger dans les arcanes de Windows : Vérifier que l’espace disque sur le PC est suffisant pour accueillir des reports importants (plus 100 Mo parfois). Vérifier que la résolution est supérieure ou égale à 1024X768 et que le pilote vidéo est bien compatible avec la version de Windows. Vérifier que la couche TCP/IP est bien compatible avec Oracle. Vérifier que les différents serveurs sont bien visibles depuis le poste client (PING), que le débit est satisfaisant (FTP) et que la connexion au serveur d’application fonctionne correctement (http ou https).

Base de test

SEMINAIRE TECHNIQUE APOGEE Base de test
Intérêt Méthodes : Import / Export Duplication Cette partie traite de la base de test. Elle en expose les intérêts et les méthodes de création. Elle peut sembler coûteuse en terme de volume de stockage, mais l’expérience montre qu’une base de test est extrêmement utile lors du démarrage de l’application.

? SEMINAIRE TECHNIQUE APOGEE Base de test Intérêt
Intérêt d’une base de test Tests d’Installation Tests d’Exploitation Il existe trois utilisations fondamentales de la base de test. Les tests d’installation. La base de test permet de vérifier que des contraintes locales ne viendront pas perturber l’installation des correctifs livrés. Pour ce faire, on utilise la base de test comme plate-forme d’essai avant de dérouler les correctifs sur la base de production du site. Les tests d’exploitation. En cas d’incident d’exploitation la base de test permet, à condition qu’elle soit régulièrement mise à jour , d’essayer de trouver des solutions aux problèmes sans risques, ce travail pouvant être effectué avec l’aide du département Support. Les tests fonctionnels. Enfin, avant de saisir directement des données dans la base de production, ou pour finir de vérifier la cohérence des travaux préliminaires, la base de test est le support privilégié. ? Tests Fonctionnels

SEMINAIRE TECHNIQUE APOGEE Base de test Import /Export
Plan Principe Export de la base de production Reconstruction de la base Import des données Cette partie de la présentation a pour but de vous présenter la solution utilisée par Rennes 1 pour : Réorganiser sa base de production Créer sa base de test Remarques : Il existe sur le marché des outils de réorganisation, actuellement en test pour ne pas être obligé de faire un Import/Export complet pour ne réorganiser que certains objets Oracle. Rennes 1 utilise la méthode par duplibase (exposée plus loin) pour créer la base de test à partir de la base de production. Il y a un plus gros volume de données à copier, mais l’opération est plus rapide. Le plan suivi est le suivant : Le principe utilisé pour l'Import/Export Présentation de l'Export La reconstruction d'une base Apogée sans données Présentation de l'Import

Principe Exporter la base de production Création d’une base vide point de montage Tablespaces FICHIER.DMP Importer les données Le principe est le suivant : Exporter quotidiennement la base de production afin d'avoir un point de reprise. Créer une base de données vide avec des tablespaces bien taillés et bien positionnés. Importer ensuite l'intégralité des données dans la nouvelle base. La nouvelle base de données est réorganisée et opérationnelle. Il faut, le cas échéant, prévoir la création de l'utilisateur batch pour la nouvelle base dans le cas du passage de la production au test.

Export de la base FICHIER.DMP Utilité Sauvegarde logique de la base Point de reprise possible Facile à archiver Permet de reconstruire une base Permet de défragmenter les objets Permet de créer une base de test Permet de déplacer les données sur d'autres disques Méthode Mode restrict Fichier de paramétrage Redémarrage L’exportation fournit une réponse adéquate à un grand nombre de problèmes de sureté de fonctionnement des bases Apogée : Sauvegarde logique de la base Point de reprise possible Facile à archiver Permet de reconstruire une base Permet de défragmenter les objets Permet de créer une base de test Permet de déplacer les données sur d'autres disques La méthode à suivre tous les soirs est la suivante: Arrêt de la base de production par un shutdown immediate. Redémarrage de la base en mode restreint "startup restrict". Lancement de l’export par «exp parfile=fichier.par» où fichier.par est le suivant : system/mot_de _passe buffer= full=y file=/ou_vous_voulez/fichier log= /ou_vous_voulez/fichier.log CONSISTENT=y constraints=y Redémarrage de la base en mode normal.

Construction d’une base vide Création d’une base de données Dimensionnement des tablespaces scripts Apogée installer.sh A modifier creer_base apo_base apo.db A modifier apo_g.tsp A modifier apo_p.rbs L’opération de création d’une base vide consiste à créer physiquement une base de données Apogée mais complètement vide. La méthode suivie par Rennes 1 a été de copier le contenu du répertoire admin ainsi que le script installer.sh dans un répertoire nommé admin_R1 (pour Rennes 1) et dans lequel certains scripts ont été modifiés. installer.sh : Suppression des appels à apo_base_initiale et maj_version. creer_base Pas de modification apo_base (script lançant la création de la base) apo.db (ordres SQL de création de la base) Préciser ici la taille et l'emplacement des fichiers de redo.log apo_p.tsp (création des Tablespaces) Préciser ici la taille et l'emplacement des fichiers .dbf des tablespaces apo_p.rbs (création des Rollback Segments)

Chargement des données Import du DUMP SQL/Loader d'Oracle Objets Invalides à recompiler On lance l'import par le commande imp parfile=fichier.par, où fichier.par est le suivant : system/mot_de_passe buffer= full=y file=/ou_vous_avez_votre_export/fichier.dmp log=fichier.log COMMIT=y IGNORE=y INDEXES=y Penser à vérifier si les objets sont tous valides et particulièrement les vues. Il suffit de lancer un "alter view xxxx compile" et les grants sur les vues (Cf. le fichier de log engendré).

SEMINAIRE TECHNIQUE APOGEE Base de test Duplication
Duplication physique d’une base Shutdown normal Copie physique des points Source-> Cible Destruction fichiers de contrôles Cible Copie init.ora & init0.ora Source-> Cible Modification init.ora & init0.ora Cible Nom de base Chemins Lancer dans l’ordre duplibase.sql controlf.sql startbase.sql LES OPERATION DECRITES DANS CETTE PAGE NE SONT SUPPORTEES NI PAR ORACLE NI PAR LE SUPPORT APOGEE. La duplication d’une base source nommée SRC vers une base de destination nommée DEST peut être réalisée de la manière suivante : Fermer la base SRC par un "shutdown" sans paramètre "abort" ou "immediate". Copier tous les fichiers des différents points de montages de la base SRC vers les points de montage de DEST. Détruire les fichiers de contrôle control.ctl présents dans les points de montage de la base DEST. Copier les deux fichiers initSRC.ora et initSRC_0.ora de la base SRC dans le $ORACLE_HOME/dbs respectivement sous les noms initDEST.ora et initDEST_0.ora. Modifier les fichiers initDEST.ora et initDEST_0.ora en changeant le nom de la base ainsi que les différents chemins des fichiers. Passer les scripts situés dans le répertoire /admin/outils_dba dans l'ordre sans oublier de les modifier en fonction de l'arborescence des différents points de montages ainsi que la taille des différents fichiers .dbf : duplibase.sql controlf.sql startbase.sql

Fichier duplibase.sql Recréer le fichier duplibase.sql Sous sqlplus « /as sysdba » alter database backup controlfile to trace Récupération du fichier trace dans user_dump_dest (cf init.ora) Recopier dans le fichier duplibase la section : LOGFILE DATAFILE Pour être sur d’avoir l’ensemble des df

Le Domaine Référentiel
SEMINAIRE TECHNIQUE APOGEE Le Domaine Référentiel

SEMINAIRE TECHNIQUE APOGEE Fin d’installation
Plan Introduction au référentiel Principales fonctions Prise en compte des modifications Paramétrage initial Introduction Opérations de paramétrage Paramétrage technique Déclaration des utilisateurs Cette partie a pour but de présenter, rapidement, les actions à mener dans le référentiel pour rendre utilisable une première installation d'Apogée. L’exposé présente, d’une manière synthétique et non exhaustive, des informations contenues dans le dossier de paramétrage, dans le dossier d’exploitation et dans le manuel utilisateur référentiel d'Apogée. Le plan suivi est le suivant : Introduction au référentiel. La position du domaine référentiel, ses principales fonctions et la propagation dynamique ou non des modifications apportées. Paramétrages Les opérations de paramétrage permettent de rendre opérationnel Apogée dans l'établissement. Il existe un paramétrage technique destiné à personnaliser le fonctionnement d'Apogée, ainsi que des opérations de déclaration des utilisateurs avec des profils bien définis. Autres traitements Ne fait pas partie à proprement parler des opérations préalables à l’exploitation mais se situe malgré tout dans le domaine référentiel, car la paramétrage en est particulier. Reprise de données La repris e de données se situe dans le temps après le paramétrage et avant la mise en exploitation Il est conseillé de reprendre au minimum les informations sur les individus. Cette partie sera développée lors du séminaire de Janvier Reprise de données Autres traitements

SEMINAIRE TECHNIQUE APOGEE Fin d’installation
SEMINAIRE TECHNIQUE APOGEE Fin d’installation Introduction au Référentiel Principales fonctions Gestion des utilisateurs et des habilitations Règles de gestion Mise en place des données Principe des témoins « En service » Prise en compte des modifications Immédiate Nouvelle session / changement de domaine Le domaine Référentiel est fondamental pour l’exploitation technique d’Apogée. Ses principales fonctions sont les suivantes : Gestions des habilitations pour dire qui a le droit de faire quoi dans Apogée Règles de gestion qui influent directement sur le comportement de l'application Mise en place des données de références La prise en compte des modifications apportées par le biais de ce domaine est immédiate dans une majorité de cas. Cependant les opérations suivantes nécessitent impérativement l’ouverture d’une nouvelle session pour être prises en compte (ou un changement de domaine) : Les habilitations utilisateur Mise à jour d'années universitaire (cgmt domaine) Mise à jour variables applicatives et règles de gestion Mise à jour CIP , CIE et CGE d'un utilisateur (cgmt domaine)

SEMINAIRE TECHNIQUE APOGEE Fin d’installation Paramétrage initial
Introduction Prérequis Connaître les informations à saisir Savoir utiliser Apogée Différentes natures de tables figées renseignées Le premier préalable à l’utilisation du domaine référentiel est la connaissance des manipulations basiques à effectuer dans Apogée (navigation dans les menus, utilisation des touches de fonction spécifiques, ...). Le deuxième est constitué par la préparation et la saisie, par l’intervenant en charge de l’exploitation du domaine référentiel, des données composant les entités de l’établissement : CGE CIP Composantes ... La base initiale comporte déjà un certain nombre de données nommées «Données de Références» (insérées par la procédure exploitant le fichier livref.dmp lors de l’installation). Les tables contenant ces données peuvent être de trois types : Figé : impossible d'ajouter, de modifier ou de supprimer des informations Renseigné : possible de modifier et/ou ajouter des informations Vide : Aucune information n'est présente initialement. vides

Opérations de paramétrage Connexion admin/admin Paramétrages (le menu Etablissement) mises à jour des données d’établissement déclaration des années universitaires déclarations des modes de paiements ... Le lecteur est invité à se réferer au Dossier de Paramétrage du domaine Référentiel qui décrit par le détail les opérations à mener. La première connexion au domaine référentiel se fait sous l’utilisateur admin avec le mot de passe admin. Ce mot de passe, ainsi que ceux des utilisateurs Oracle apogee, system et sys doivent être modifiés. Des messages d’erreurs informant de l'absence d’une année universitaire ouverte sont normaux. Lors de cette connexion il est nécessaire de procéder à toutes les opérations décrites dans le Dossier de Paramétrage et tout particulièrment : La vérification du contenu des tables livrées La mise à jour de l’établissement de référence La mise à jour des autres tables d’environnement La déclaration des années universitaires La déclaration des modes de paiements La mise à jour des entités organisationnelles CGE CIP Composantes ...

Paramètrage technique Règles de gestion (ne pas toucher) Messages applicatifs (ne pas toucher) Déclaration des imprimantes (à modifier) Mise à jour des variables applicatives (à modifier) La deuxième phase consiste à établir le paramétrage technique. Les règles de gestion et les messages applicatifs ne doivent être modifiés qu’en parfaite connaissance des tenants et aboutissants : ils ne doivent pas être touchés lors de la toute première connexion après installation. Deux opérations doivent cependant être effectuées : la mise à jour des variables applicatives et la déclaration des imprimantes. Les principales variables à mettre à jour sont rappellées dans la liste suivante : ETB_COD : Code de l'établissement de référence ETB_COD_UNIV : Code en base 36 pour les numéros INE. ETB_DEP : Département ETB_NUM_SERIE : Numéro de série de l'établissement pour INE ETB_TYP : Type de l'établissement

Déclaration des utilisateurs Connexion en admin Pas d’apostrophes, ni de % ni de _ dans les noms et les codes Un compte Oracle par utilisateur Fonctionnement des utilisateurs Apogée propriétaire des objets Synonymes public sur les objets d ’Apogée Droits d ’accès, rôle pour chaque utilisateur Attention l’utilisateur ADMIN ne sert qu’à l ’administration La déclaration des utilisateurs se fait dans le domaine référentiel. La modification des droits d’accès s’effectue via l’écran d’habilitation et sous tout utilisateur autorisé à le faire. Cependant seul admin peut créer ou supprimer un compte Oracle. Ainsi la suppression d’un utilisateur Apogée doit comprendre trois étapes : décocher la case "en service" de l'écran habilitation utilisateur supprimer le compte Oracle en étant connecté admin. Supprimer l ’utilisateur (poubelle via l ’écran Apogée) Il n'est pas possible d'effacer l'utilisateur de la base car des contraintes d'intégrité ne le permettent pas. Attention aux habilitations données : un utilisateur peut changer son propre mot de passe en ayant un accès en visualisation sur l'écran habilitation. Cette fonctionnalité n’est pas toujours utilisée en parfaite connaissance des conséquences. ==> solution : ne pas donner accès au référentiel

SEMINAIRE TECHNIQUE APOGEE Fin d’installation Autres traitements
Administration / Traitements personnalisés Ajouter dans Apogée vos traitements Forms Reports Cet écran, accessible par le menu "administration/ traitements personnalisés", vous permet d'ajouter vos propres reports et forms. Ils seront accessibles par le menu "administration/autres traitements" des autres domaines.

SEMINAIRE TECHNIQUE APOGEE Fin d’installation Reprise de données
Conversion / Reprise de données Récupérer des données pour faciliter le changement d’outils (individu) Récupérer l’historique de gestion de la scolarité (inscriptions, résultats)

Habilitations

SEMINAIRE TECHNIQUE APOGEE Habilitations
Plan Gestion des utilisateurs Gestion des accès aux traitements Sécurité Les habilitations des utilisateurs consituent un domaine particulièrement sensible : elles conditionnent les droits des utilisateurs à accéder, à consulter ou à modifier des données dans la base de données Apogée. Cette présentation est construite autour de trois points : La description de la gestion des utilisateurs La description de la gestion des accès aux traitements Quelques remarques sur la sécurité

Gestion des utilisateurs Création & Modification d’un utilisateur Modification du mot de passe Oracle par l’utilisateur Suppression d’un utilisateur La gestion des utilisateurs Apogée est effectuée, par l'administrateur de données ou un utilisateur habilité, au sein de la conversation référentiel Habilitation/Utilisateur du domaine Référentiel. La création d'un nouvel utilisateur se fait en saisissant le nom utilisateur et le type utilisateur. L'utilisateur est alors créé dans la base Apogée. Il est également possible de le rattacher à un centre de gestion, à un centre d'inscription pédagogique et à une ou plusieurs composantes. Pour autoriser la connexion de l'utilisateur à l'application, le témoin "En service" doit être activé, ce qui impose la création du compte Oracle de l'utilisateur. Seul l'administrateur de données est habilité à créer un compte Oracle. Cette opération est effectuée en cliquant sur le bouton "Création", qui entraîne l’apparition d’ une fenêtre de saisie du mot de passe : Pour autoriser un utilisateur à modifier lui-même son mot de passe, il suffit de lui donner ,via le type d'utilisateur auquel il appartient, les accès aux fonctions suivantes, en mode visualisation uniquement : accès au référentiel et accès à l'écran Utilisateur. Attention, car certains utilisateurs perdent régulièrement leurs mots de passe !. La suppression s’effectue en deux étapes : suppression sous Oracle de l’utilisateur Oracle, puis suppression sous Apogée de l’utilisateur Apogée. Il faut gérer aussi sérieusement les utilisateurs Apogée que les utilisateurs UNIX.

Gestion des accès aux traitements (Habilitation / accès) USER 1 OBJET 1 R OBJET 2 V OBJET 3 M OBJET 4 R Type UTILISATEUR USER 2 USER 3 Par type d’utilisateur R : Refusé V : Visualisation M : Modification Par exe : Ecran de purge des OPI Objet = «fonction» = 1 objet Oracle La gestion des accès aux traitements se fait par l’intermédiaire de l’écran : Habilitation/Accès du domaine Référentiel. Cette gestion repose sur la notion de ‘Type Utilisateur’ que l’on peut considérer comme un ensemble d’objets affecté des qualificatifs R (accès Refusé), V(accès seulement en Visualisation) et M (accès en modification). Dans l’exemple les trois utilisateurs ayant ce type utilisateur possèdent les droits en modification sur l’objet 3, les droits de visualisation sur l’objet 2 et n’ont pas accès aux objets 1 et 4. Ces objets sont des objets Oracle de type écran. Par exemple l’objet 4 peut être l’écran de purge des Opérations Préalables à l’Inscription, l’objet 2 celui des éditions de stages, etc. Afin de faciliter la création de ces profils d’utilsateurs, l’application Apogée est livrée avec un certain nombre de types pré-définis.

VIGILANCE SEMINAIRE TECHNIQUE APOGEE Habilitations Sécurité :
Réseau = DANGER SQLPLUS = DANGER Confiance = DANGER Protection des comptes Unix apoinst, oracle et apobatch La sécurité des données doit être un soucis constant. En effet, la distribution des traitements et la répartition des tâches dans différents services multiplient les risques. Le réseau est souvent le maillon faible : les sniffers existent et sont en distribution libre sur Internet. De plus, un certain nombre de sites ne sont pas encore dotés de Firwalls mais sont accessibles depuis le Net ... Localement, il convient de limiter la disponibilité des outils de type Q+E ou SQLPLUS sur les postes clients. En effet, un utilisateur connaisseur et débrouillard peut parfaitement exploité ces logiciels pour récupérer des informations auxquelles il ne devrait pas avoir accès. Il ne faut pas avoir confiance dans une situation établie. Il existe de plus en plus d’attaques possibles, même si elles demandent de plus en plus de connaissances. Il faut rendre la tâche la plus difficile possible aux éventuels ‘petits malins’. Ceci est particulièrement critique dans les établissement qui assurent des enseignements dans le domaine de l’informatique.

Domaine Exploitation

SEMINAIRE TECHNIQUE APOGEE Exploitation
Plan Utilisateur spécifique Exploitation fonctionnelle - Traitements occasionnels et différés Exploitation technique - Architecture batch Distribution automatique du client Cette partie a pour but de vous présenter, rapidement, les différentes possibilités offertes par le domaine exploitation. Ce domaine est réservé aux responsables informatiques de l’application. Pour une information complète et précise sur le sujet, il est conseillé de lire le dossier d'exploitation d'Apogée + Annexes. Les services disponibles dans le domaine exploitation sont de deux types : Le lancement de traitements différés : traitements batchs Apogée, purge dans certaines tables,… L'administration : tous les traitements liés à l'exploitation technique d'Apogée.

Utilisateur spécifique Accès réservé et restreint Admin / admin Utilisateur TYP_APO Utilisateurs spécifiques (avec un type utilisateur ayant les droits sur tous ou certains des écrans du domaine exploitation) Il est important de restreinte l’accès au domaine Exploitation. Il s’agit d’une icône séparée qui n’est pas accessible par les autres domaines. Il est recommandé de ne pas installer cette icône sur tous les postes. Par ailleurs l’accès doit être réservé : admin/admin Voir les utilisateurs de typ_apo : ce type utilisateur devant lui même être réduit dans sa propagation

Exploitation fonctionnelle Traitements occasionnels et différés Les purges Les enquêtes Sise Le traitement des OPI Exploitation des étudiants affiliés Le changement d’année universitaire Mise à jour des séquences Oracle

Exploitation fonctionnelle Les purges Purge des individus et enseignements Purge des objets et liens fermés Purge pour les étudiants sans notes et résultats Purge des étudiants dans les groupes Purge des tableaux d’incompatibilité et des calendriers Purge ou restauration des cartes étudiants Purge des individus et enseignements Purge l'individu et les informations associées, pour les étudiants qui : N'ont pas effectué d’IA depuis un certain nombre d'années N'ont pas contracté d’IP pour l'année en cours N'ont effectué aucune opération préalable à l'inscription Structure des enseignements des éléments et listes qui ne sont pas : pré-recquis conditions d ’accès liés à une inscription, à un résultat ou à un étudiant Pour ce traitement il faut prévoir : La durée de conservation des données en nombre d'années (paramètre d'exploitation : Table "Regle_Gestion", Colonne "Par1_Rgg" pour Cod_Rgg = "BA01"), Le délai maximum entre l'archivage et la purge, en nombre de jours (paramètre d'exploitation : Table "Regle_Gestion", Colonne "Par2_Rgg" pour Cod-Rgg = "BA01"), Sa politique d'archivage et les procédures associées, La période de l'année universitaire la plus appropriée pour lancer les purges. Attention si vous avez converti vos données étudiants et pas encore les Inscriptions Administratives correspondantes. vous risqueriez de perdre le résultat de votre travail. Purge pour les étudiants sans notes et résultats Purge des tables résultats resultat_xxx et grp_resultat_xxx Version de diplôme Version d'étape Elément pédagogique Epreuve Ce programme permet la purge des résultats inutilisés pour une année donnée pour les 4 objets (VDI, VET, ELP et EPR). Il purge aussi les groupes résultats. Il opère en supprimant les enregistrements des tables RESULTAT_XXX pour une année donnée pour lesquels il n'y a pas de note, de note de substitution et de résultat. On purge ensuite les tables GRP_RESULTAT_XXX pour une année donnée qui ne possèdent pas d'enregistrement fils dans les tables RESULTAT_XXX. Purge des étudiants dans les groupes Purger les étudiants qui appartiennent Aux collections choisies À tous les groupes d’une année Purge des tableaux d’incompatibilité et des calendriers Purge des tables du domaine épreuve : suite à des erreurs à la génération des tableaux d’incompatibilité pour l ’année universitaire écoulée (calendrier) Ces deux purges (tableaux d’incompatibilités et calendriers) permettent aux utilisateurs de purger les tables du domaine épreuves, lors d’erreurs, lors de la génération des tableaux d’incompatibilité ou lorsque l’année universitaire est écoulée. Si l’année choisie dans l’écran de purge est égale à l’année maximum Résultat, l’utilisateur peut choisir indifféremment l’une des deux purges. Si l’année choisie dans l’écran de purge est inférieure à l’année maximum Résultat , l’utilisateur ne peut choisir que la purge des calendriers (la purge des tableaux d’incompatibilités ayant déjà été effectuée par la génération des tableaux de l’année suivante). Cette contrainte est due au fait que l’utilisateur ne doit pas avoir la possibilité de purger des tableaux d’incompatibilité pour des périodes qui peuvent être utilisées durant l’année courante Résultat. Purge ou restauration des cartes étudiants Restauration des cartes Lorsque l'édition d'un lot ne s'est pas effectuée correctement (bourrage de l'imprimante, panne d’un serveur d’impression, ...) Purge des cartes Lorsque l'édition d'un lot de cartes s'est correctement effectuée, l'exploitant peut purger ce lot de la table CARTE_ETU La méthode à suivre est la suivante : Cocher Restauration des cartes d'étudiant. Cocher le ou les lots à restaurer. Cliquer sur le bouton Accepter Les enregistrements de la table CARTE_ETU relatifs au centre de gestion choisi et dont le champ DAT_IMP_CTE a comme valeur la date choisie sont restaurés : les champs DAT_IMP_CTE et ETA_EDT_CTE sont remis à vide. Cocher le ou les lots à purger. Cliquer sur le bouton "Accepter" Tous les enregistrements, du centre de gestion choisi, dont le champ DAT_IMP_CTE a comme valeur la date choisie sont supprimés.

SEMINAIRE TECHNIQUE APOGEE Exploitation Exploitation fonctionnelle
Lancement des résultats et enquêtes SISE SISE: Système d’Information sur le Suivi de l’Etudiant Sélection de (ou des) l'enquête(s) du ministère Exécution du (ou des) batch(s) associé(s) Des fichiers sont créés sur le serveur ($APOGEE_DIR_LOG $APOGEE_DIR_FIC) Cette chaîne est planifiée par l'utilisateur, depuis l'écran FORMS "Enquêtes SISE" du domaine "Exploitation". Les paramètres à saisir sont indiqués sur cet écran. Elle se décompose en deux étapes : La sélection de (ou des) l'enquête(s) et autres paramètres d'exécution, et la création d'un nouvel enregistrement dans FILE_BATCH, pour cette nouvelle demande d'exécution d'un batch, l'exécution du (ou des) batch(s) associé(s) à l'exécution de cette (ces) enquête(s). Chaque batch permet de construire 2 fichiers ASCII (un fichier d'identification et un fichier de données), ainsi qu'un compte-rendu permettant d'indiquer les anomalies du traitement, les différents compteurs décrits dans le traitement et les informations transmises à SISE. Le traitement est effectué suivant un calendrier diffusé par SISE (concerne domaines IA et RE). Attention aux variables $APOGEE_DIR_LOG et $APOGEE_DIR_FIC

Purge et chargement OPI Fichiers d’interface OPI Tables APOGEE Cinq étapes : Purge des tables de chargement des deux fichiers d'interface, Chargement de ces tables à partir des deux fichiers d'interface, Traitements de vérification de cohérence et de ventilation des données, Edition du compte rendu, (Report), du chargement des fichiers, Purge des tables de chargement des deux fichiers d'interface. Utilisation Six fichiers sont concernés par cet archivage (s'il est important de conserver une trace des résultats du précédent chargement) : les fichiers de données baiadvi1.dat et baiadvi2.dat, situés dans le répertoire décrit par la variable d'environnement $APOGEE_DIR_FIC sur le serveur UNIX, Les fichiers de log baiaxvi1.log baiaxvi2.log propres à SQL*Loader, situés dans le répertoire décrit par la variable d'environnement $APOGEE_DIR_LOG sur le serveur UNIX, Les fichiers de rejet des enregistrements, non conformes aux contrôles effectués par SQL*Loader, baiadvi1.bad et baiadvi2.bad situés dans le répertoire décrit par la variable d'environnement $APOGEE_DIR_FIC sur le serveur UNIX. Si des problèmes surviennent lors du load on renomme les .bad en .dat après correction. Si des problèmes surviennent lors du compte rendu on modifie directement BATCH_IND_OPI et BATCH_VOEUX_INS Ne pas oublier de mettre à zéro ind_chg_bio et ind_chg_bvi et supprimer les .dat pour pouvoir relancer.

Extraction des étudiants affiliés Extraction des étudiants affiliés à la sécurité sociale Création de la table BATCH_ETU_AFL_SSO Elaboration par chaque site à partir de la table BATCH_ETU_AFL_SSO du support magnétique à envoyé à la CPAM Penser à purger la table BATCH_ETU_AFL_SSO lors du changement d’année universitaire

Changement d'année universitaire cf Dossier de paramétrage / Dossier d ’exploitation 1 seule année IA ouverte Modification des séquences Modification des quittances Permet de modifier l’année des dates de début et de fin d’inscription pédagogique aux éléments pédagogiques pour les écrans de Structure des enseignements où cette information est saisie.

Modification des séquences Les séquences Oracle suivantes doivent être mises à jour : seq_cod_ind : suite à la conversion des individus seq_cod_adr : suite à la conversion des adresses seq_cod_etu : suite à la conversion des individus et en début d'année universitaire seq_num_ord_etu : suite à la conversion des individus et en début d'année universitaire seq_cod_ind_opi : après avoir effectué la purge des OPI Les autres séquences d'Apogée ne doivent pas êtres mises à jour. Voir le script maj_sequence.sh sous /admin

Exploitation technique Architecture batch Planning d’exploitation Liste des travaux différés Purge des logs Administration

SEMINAIRE TECHNIQUE APOGEE Exploitation Exploitation technique
Planning d'exploitation gestion des traitements différés Définir le jour et l ’heure de lancement d’un batch par défaut Autoriser ou non, la modification de cette valeur par défaut 0 heure 0 minute suspend le passage d ’un batch Les tâches concernées par ce planning sont : certains traitements transactionnels. les éditions mixtes et asynchrones. les traitements par lot (batchs). Parrallélisme des batchs

Liste des travaux différés pour tous les utilisateurs Liste des codes statuts des traitements D demandé P pris en compte X en exécution O fin normale N interrompu Détail des statuts possibles pour les traitements Code Statut* Signification D T le traitement n’a pas encore été pris en compte par le process baat_sqc P T le process baat_sqc se prépare à lancer l'exécution du traitement X T le traitement est en cours d'exécution O D le traitement est terminé et aucune erreur ne s'est produite W D le traitement s’est interrompu sur des erreurs techniques N D le traitement a signalé des anomalies n’ayant pas empêché son accomplissement * le statut précise si cet état est temporaire (T) ou définitif (D). W anomalies détectées

Purge des logs Table FILE_BATCH Traitement X USER Traitement X USER B Traitement Y USER C Traitement X USER D Traitement Z USER B Traitement Y USER D Purger la table FILE_BATCH Tous les traitements sélectionnés Pour tous les demandeurs Suppression des fichiers logs sur le serveur La Purge des logs permet de supprimer de la table FILE_BATCH les demandes de traitement, qu'elles aient ou non été prises en compte. Les fichiers log associés à ces traitements sont également supprimés. L'exploitant doit avoir au préalable vérifié le contenu de ces fichiers. Choisir les statuts (ou états) des demandes à supprimer. Saisir la date ou le nombre de jours antérieurs à la date du jour pour déterminer les demandes qui seront purgées. Cliquer sur le bouton "Accepter" pour lancer la demande de traitement. Les traitements répondant aux critères sont supprimés de la table, quel que soit l'utilisateur ayant demandé le traitement. Critères de lancement : état du batch, date Cette purge ne concerne pas babajou, babanui et babaheb

Purge de la table file_batch Un traitement ne s ’exécute pas. Un traitement est terminé en anomalie. Purge des logs pour tous les traitemenst applicatifs Purge manuelle pour babajou1, babanui1, babaheb1 delete file_batch where cod_bad = babajou1

Merci de votre attention.
SEMINAIRE TECHNIQUE APOGEE Questions Merci de votre attention. Des questions ?

Séminaire d’installation et d’exploitation technique Apogée.

Présentations similaires

Présentation au sujet: "Séminaire d’installation et d’exploitation technique Apogée."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Séminaire d’installation et d’exploitation technique Apogée.

Présentations similaires

Présentation au sujet: "Séminaire d’installation et d’exploitation technique Apogée."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back