Dans ce tutorial nous allons nous intéresser à l'architecture des ERP.
Les Entreprises Ressources Planning ou PRG ( Progiciel de gestion intégré )
ont en ce moment le vent en poupe dans le monde de l'entreprise.
C'est un progiciel de gestion des flux logistiques et financiers de l'entreprise.
Systèmes d'Information où les différents traitements (transactions et exécution)
et fonctions classiques d'une entreprise sont intégrés autour d'un référentiel de données et de processus unique.
Ils constituent une réponse générique est facilement adaptable ( en théorie )
à un pan complet de la gestion de l'entreprise.
Les ERP/PGI sont généralement opposées aux mondes des solutions dédiées
ou un développement complet est effectué pour répondre à une problématique.
Afin d'avoir une description complète des ERP/PGI je vous conseille de lire le descriptif des ERP.
Il existe différents éditeurs de solutions sur le marché en fonction de la segmentation de la clientèle. Cependant nous retiendrons 3 Grands éditeurs avec par ordre de grandeurs :
- SAP éditeurs allemands numéro 1 mondial notamment reconnus pour sa partie Supply chain.
- Oracle/PeopleSoft : depuis la dernière OPA hostile du géant de redwood est toujours localisé à la seconde place
- Microsoft qui avec son offre Navision est dans une situation de challenger.
Nous prendrons pour support l'offre PeopleSoft Enterprise.
Qui, à mon sens est une offre intéressante notamment pour la gestion de la partie ressource humaine et paye.
La solution est donc une version PeopleSoft (Module Finance 8.9), PeopleTools 8.47 et BEA WebLogic Server 8.1 Oracle 9.2 + Serveur d'application
Nous allons dans un premier temps exposer l'architecture complète, puis nous reviendrons sur chaque composante afin d'apporter un minimum de précision.
II. l'Architecture PeopleSoft
Comme vous pouvez le voir l'architecture se découpe en quatre composantes essentielles :
- Un client avec un navigateur Internet : Internet explorer, Firefox…
Attention ce navigateur internet se doit d'être mis à jour car PeopleSoft Enteprise utilise de nombreux servlets java, Oracle E-Buissiness a quant à lui besoin du Jinitiator.
- Un serveur Web : BEA Weblogic ou IBM Websphere ou Oracle application server.
- Un serveur d'application. ( Tuxédo, processus PeopleSoft )
- Un serveur de base de données ( ici nous retiendrons l'offre d'Oracle).
1. Le Client
1.1. Présentation
Un des avantages de PeopleSoft Enterprise est de pouvoir attaquer l'application en mode WEB. C'est à dire que l'utilisateur, qui peut être un gestionnaire de paye, peut saisir les informations concernant le dossier administratif d'un employé, saisir ces absences et calculer son salaire sans que ce dernier n'ait à installer un client lourd. Dans un réseau micro-informatique important cela permet d'intégrer l'ERP facilement sans à avoir à installer un nouveau client lourd sur le PC. De plus cela centralise les tâches d'administration sur les différents serveurs et non plus sur chaque machine cliente.
1.2. Administration
L'administration du client internet se fait logiquement à deux niveaux, soit au niveau de chaque client. Soit dans le cadre d'une politique micro informatique maîtrisé lors de la définition du MASTER qui équipera chaque PC. Afin de se servir correctement de PeopleSoft il faut avoir une solution internet explorer V5 et Mozilla FireFox 1.3 avec un encodage UTF-8
Chacun choisira son navigateur en fonction de ces préférences ou de choix plus … politiques.
Le protocole de communication est le protocole classique internet HTTP. Si on décide l'implémentation d'une solution plus sûre dans ce cas là on devra paramétrer le SSL : (Secure Sockets Layers : couche de sockets sécurisée) est un procédé de sécurisation des transactions effectuées via Internet.
Consultez la FAQ sécurité de developpez.
1.3. FailSafe Over
La seule solution est d'avoir installé sur son poste différents navigateurs
afin de pouvoir se servir de posséder une solution de secours
1.4. Solution Alternative
On peut choisir une solution alternative les autres navigateurs internet : Opéra, Netscape …
2. Le Web Server
2.1. Présentation
Le Web server est comme son nom l'indique le serveur Web qui va permettre d'assurer la communication entre les différents clients et le serveur d'applications. Nous avons privilégié cette solution afin d'avoir l'offre complète BEA ( Weblogic +Tuxedo). Ce qui nous assure l'offre la plus standard possible.
L'installation se fait en deux étapes. On commence par installer un serveur Web sur une machine. Puis nous mettrons en place la PIA : Peoplesoft Internet architecture.
Plus précisément, PIA installe des servlets spécifiques qui vont permettre de communiquer entre le serveur web et le serveur d'application (type J2EE, des services Web). Il va également permettre de synchroniser des bases via des passerelles permettant l'envoie et la réception de message XML. Ce n'est donc pas un simple serveur Web.
Pour information les composants installés avec les servlets sont :
- le portal Servlet (à partir de 8.4 ) permettant de formater sa page, accéder aux applications, il gère également touts les aspects de la visualisation de la page : personnalisation, recherche …
- Integration Gateway Servlet, qui logiquement permet d'envoyer/recevoir les messages comme les publish/suscribe message ( Processus PUB/SUB), ainsi que les messages en 4/3.
- Report Repository Servlet va permettre de voir le résultat, via internet, des sorties des traitements batchs, comme les SQR, Crystal. Les servlets vont retrouver les fichiers générés par ces traitements et vont les afficher dans le navigateur : bulletin de paye, report HR …
2.2. Administration
Donc vous l'aurez compris, la PIA n'est pas un simple pont Web entre le client et le serveur d'application, mais comporte également une composante JAVA qui via les servlets va pouvoir communiquer avec TUXEDO. D'ailleurs afin de pouvoir communiquer avec le serveur d'application, Weblogic doit savoir sur quel port il doit initier la communication avec le JSL.
Tout comme Apache qui possède un fichier de configuration httpd.conf, Weblogic dispose également de son fichier. Celui est généralement localisé dans :
Il s'appelle configuration.properties, c'est d'ailleurs dans ce fichier que l'on peut voir le port d'écoute et l'adresse du serveur web, qui va nous servir pour pouvoir nous connecter à l'application ( Attention à bien changer DOMAINE par le nom de domaine effectif ).
psserver=serveur:port
Ici le port est celui du JSL ( Jolt station listener ) via le protocole JOLT, par défaut le 9000. Si nous changeons le serveur d'application il faudra donc modifier ce fichier est relancé le serveur Web.
On peut connecter de 1 à plusieurs serveur d'application (laod balancing applicatif)
Ce dernier se relance via les commandes :
%PS_HOME%\webserv\peoplesoft\StartPIA.cmd
Et s'arrête via :
%PS_HOME%\webserv\peoplesoft\StopPIA.cmd
Avant de lancer le serveur Web, il faut parfois reconfigurer les variables d'environnement. Cela se fait via :
%PS_HOME%\webserv\peoplesoft\SetEnv.cmd
Un autre fichier de configuration est le config.xml présent dans le répertoire suivant :
$PS_HOME/webserv/peoplesoft/config.xml
Il va nous permettre de trouver des informations pertinentes comme le port d'écoute du serveur web ou l'utilisateur de la console d'administration du serveur Web. Il est visible avec un simple éditeur de texte.
Par exemple :
L'installation de la PIA se fait via l'application setup qui est présente dans le répertoire :
$PS_HOME/setup/mpinternet/
Attention cet exécutable doit se lancer directement sur le serveur et non pas à partir d'un poste client. Il lance une procédure d'installation via une interface graphique qui demande un certain nombre d'information tel que le PS_HOME, le WEB SERVER ROOT ( Home du Web server ),le type d'installation.
On a le choix d'installer une PIA sur trois types de serveur : BEA Weblogic, IBM Websphere et Oracle Application Server
Lors de l'installation, on va pouvoir entrer les différentes informations concernant le port du JSL, http et HTTPS, le nom du serveur d'application.
Pour le reconfigurer, il vous suffit de relancer le programme précèdent. De renseigner tous les champs et de demander non pas la création d'un domaine mais la configuration d'un domaine existant. Puis installer un site supplémentaire.
Ensuite une étape classique commence avec la demande d'information nécessaire à la création d'un domaine Web.
On a ensuite une fenêtre de récapitulation des différentes informations :
Jusqu'à obtenir l'écran final.
Un dossier avec le nom du projet est ajouté dans l'arborescence suivante :
Il existe également une console d'administration Web du serveur Weblogic. Cette console se trouve à l'URL suivant :
http://hostname:port/console
Elle est accessible lorsque le serveur Web est démarré et peut donc constituer une manière de valider la bonne installation et le démarrage de son serveur Web.
2.3. FailSafe Over
La solution que je conseille en règle générale afin d'avoir une configuration en binôme. On va configurer deux serveurs avec les mêmes caractéristiques. D'en activer un seul, balancer sur le second lorsque le premier est hors service par le biais d'une re-direction de nom vers adresse IP dans le DNS :
Par exemple, le serveur web est attaquable via le nom websrvprd.
Il existe deux machines avec les adresses IP suivantes : 10.0.0.1 et 10.0.0.2. Le serveur de production est le 10.0.0.1 et celui de secours est le 10.0.0.2.
Une re-direction de websrvprd de 10.0.0.1 à 10.0.0.2 ainsi que de " Flusher " le DNS sur les postes clients et la modification est transparente pour les clients.
Avec la nouvelle version de PIA une configuration en cluster est possible: c'est à dire 2 PIA sur 2 machine en même temps qui réceptionne les connections : si l'un tombe l'autre continue à fonctionner de façon transparente .
2.4. Solution Alternative
Pour l'instant l'autre solution standard est d'utiliser le serveur Web d'IBM : Websphere.
Le principe étant le même, installation du serveur et enfin de la PIA. Gageons qu'avec le projet FUSION Oracle intégrera certainement la possibilité de recourir à son propre serveur Web basé sur la technologie open-source Apache.
En 8.47 on a la possibilité d'installer un serveur Web déployé sous OAS.
3. Serveur d'application
3.1. Présentation
Le serveur d'application est la pierre angulaire de toute cette architecture. Elle se décompose deux sous couches TUXEDO et les processus PeopleSoft. Seule une connexion en 2 tiers via un client comme Sql*Plus ou Toad permet de passer outre cette couche. Elle se connecte au serveur web via le JSL, aux outils 3 tiers comme Application designer via le WSL. Sa communication à la base de données est soumise au protocole de communication du RDBMS. Dans notre cas (Oracle), Net*8.
Cette partie a donc pour objectif de traduire une demande d'un client et de l'envoyer à la base de données. Puis construit le résultat, provenant de la base de données, à afficher au client.
TUXEDO :
TUXEDO a été crée en 1984 par les laboratoires AT&T sur la base du client/serveur UNIX. Il fut racheté par BEA en 1996 ( Bill Coleman, Ed Scott et Alfred Chuang ). Il a été intégré à l'offre PeopleSoft Enterprise avec la version 6. Dans cette version il est un composant du serveur batch qui va permettre d'exécuter les Batch et de visionner le résultat.
Avec la version 7, il prend sa place centrale qu'il occupe aujourd'hui. Les programmes PeopleSoft ne fonctionne pas sans lui.
Finalement avec la version 8 il finit d'asseoir sa position centrale dans un environnement complexe.
Tuxedo est donc la partie qui va réceptionner les demandes et les partager à la bonne couche qui va traiter la demande. Il manage donc les transactions
Les différents processus TUXEDO :
BBL : ( Bulletin Bord Liaison ) il re-dirige les demandes sur les processus secondaires en fonction des demandes. Il augmente ou diminue le nombre de processus en fonction de la charge de travail ( c'est ce que l'on appelle faire du SPAWN ou DECAY ).
WSL : ( Workstation listener ) ici nous sommes dans un accès 3 tiers. Il effectue la connexion entre les postes et le serveur d'application puis passe le travail au WSH
WSH : ( Worstation handler ) il maintient une connexion persistante jusqu'à ce que la demande ait été satisfaite, pour les accès 3 tiers.
Arrêtons-nous pour comprendre tout cela. Une demande en 3 tiers parvient d'une workstation. Celle ci arrive sur le port 7000 ( par défaut ) et est réceptionné par le WSL ( listener ). Ce dernier l'a transmet au WSH, qui grâce au BBL va savoir lequel des processus contacter : PSAPPSRV, PSSAMSRV, PSQCKSRV.
Ensuite le bon processus entre en contact avec la base de données grâce au SQL.
Les différents processus JOLT :
Avant de commencer, rappelons que le JOLT n'est qu'une version java de TUXEDO. Il permet dans un monde 4 tiers de communiquer avec le serveur Web en lieu et place d'une seule workstation.
Il fait exactement la même chose que TUXEDO.
JSL : ( Jolt station listener ) établit la communication entre un processus java ( en règle générale le webserver ) et le serveur d'application
JSW : ( Jolt station Handler ) maintient une connexion persistante entre le webserver et la base jusqu'à satisfaction de la demande. C'est le BBL qui dit au JWS q'elle processus utilisé
JREPSRV : ( Jolt repository server ) Permet de transcrire les demandes du Jolt dans le Tuxedo par un langage compréhensible du BBL
Donc un client se connecte via son navigateur sur le serveur Web, celui ci via le JOLT contacte le JSL, qui l'à aussi sert de Listener. Il passe le relais au JSW qui grâce au JREPSRV va pouvoir présenter sa demande au BBL. Le BBL n'a donc plus qu'a orienter la demande vers le bon " interlocuteur ". Bien entendu celui ci passe déjà par la zone d'attente qui permet de servir les demandes selon le principe FIFO ( Firt In First Out ) : la queue.
PeopleSoft server :
Lorsque la communication a été établit vers les différents canaux. Les processus peopleSoft vont prendre le relais afin de résoudre la demande tout en communiquant avec la base de données. Ils vont interroger la base de données grâce au langage SQL qui est basé sur le protocole de communication propre à chaque base.
Les différents processus PeopleSoft :
PSAPPSRV : C'est un processus majeur. Son rôle consiste à construire et à sauver les pages HTML en fonction des droits de l'utilisateur. Il se charge également de la sécurité lors de l'accès. Gère les demandes des clients et s'occupe également des différents messages.
PSSAMSRV : C'est un processus qui gère les transactions SQL principalement pour le compte de l'outil Application Designer
PSQRYSRV : Ce processus gère toutes les transactions SQL issues des produits de développement PeopleSoft ( Data Mover …). Sa présence n'est pas indispensable pour que le serveur démarre, mais son absence génère fréquemment de nombreux problèmes de performance.
PSQCKSRV : Ce dernier traite quant à lui, les demandes de lecture de la part des clients. Il ne concerne pas les clients en quatre tiers. Sa présence est également facultative.
Ces processus peuvent être vus via le gestionnaire de tâches ou grâce à la commande ps -eaf | grep processus
Leur configuration se fait via le fichier appserv.cfg
Il existe d'autres processus qui sont optionnels et qui peuvent diminuer la charge de travail des processus principaux.
PSDBGSRV : Ce processus a une utilité lors de phase de debugging du PeopleCode.
PSOPTENG : Lors d'optimisation d'application : Supply chain planning …
PSPUBDSP - PSPUBHND : Publication Dispatcher ( DSP) et Publication Handler (HND) sont des processus qui vont permettre la publication et l'envoi des messages de l'environnement : Integration Broker. Ils permettent également un formatage du message et de l'envoie au bon interlocuteur.
PSSUBDSP - PSSUBHND : s'occupent des demandes de traitements et d'envoi de messages des systèmes externes à PS.
Dans une configuration internet, chaque domaine se doit donc d'avoir :
- une partie Tuxédo : comprenant un Listener, un Handler, Un BBL, un Jrepserver.
- Une partie PeopleSoft comprenant : PSAPPSRV, PSSAMSRV, PSQRYSRV autre processus …
3.2. Administration
Tout d'abord il faut savoir qu'il existe un TUXDIR qui est le répertoire racine d'installation de TUXEDO, tout comme il existe un PS_HOME et un WEB_HOME. Il faut s'assurer que le TUXDIR est bien compris dans le PATH.
Pour pouvoir administrer les deux composants TUXEDO et Processus peoplesoft, il existe un fichier de configuration psappserv.cfg, fichier qui se trouve dans le répertoire suivant :
$PS_HOME\appserv\<Domain>\
Et un programme : PSADMIN présent dans :
$PS_HOME\appserv\psadmin.exe
PSAPPSERV.CFG :
Ce fichier va recenser les différents paramètres ainsi que leur valeur minimale et maximale. C'est grâce à ce fichier que l'on va pouvoir interagir sur le nombre de processus et dire si on veut les activer ou pas.
Prenant le cas du PsAppSrv :
[PSAPPSRV]
;=========================================================================
;Settings for PSAPPSRV
;=========================================================================
;-------------------------------------------------------------------------
; UBBGEN settings
Min Instances=1
Max Instances=1
Service Timeout=500
;-------------------------------------------------------------------------
; Number of services after which PSAPPSRV will automatically restart.
; If the recycle count is set to zero, PSAPPSRV will never be recycled.
; The default value is 5000.
; Dynamic change allowed for Recycle Count
Recycle Count=5000
;-------------------------------------------------------------------------
; Number of consecutive service failures after which PSAPPSRV will; automatically restart.
; If this is set to zero, PSAPPSRV will never be recycled.
; The default value is zero.
; Dynamic change allowed for Allowed Consec Service Failures
Allowed Consec Service Failures=2
; Max Fetch Size -- max result set size in KB for a SELECT query
; Default is 5000KB. Use 0 for no limit.
Max Fetch Size=5000
; Automatically select prompt, 1 = yes, 0 = no
Auto Select Prompts=1
;-------------------------------------------------------------------------
; This parameter is used for Tuxedo Queue Thresold Determination (used forPub/Sub
; processing only). This parameter is the actual Tuxedo message queue size.
; This is a kernal parameter in Unix. For Window, look in BEA Tuxedo, IPC Resources.
; A value of 0 will disable Tuxedo Queue threshold Determination and usage.
; A value of -1 will use these defaults: Window = 65535, AIX = 4000000,
; Solaris = 65535, HP = 65535
Tuxedo Queue Size=65535
Nous voyons bel et bien que l'on peut agir sur les paramètres Min Instances et Max Instances, qui vont permettre au BBL de faire du SPAWN ou DECAY.
Cependant d'autres paramètres sont administrés via le PSADMIN.
Rappelons que le système ne lit pas le fichier psappserv.cfg, mais un fichier binaire PSTUXCFG présent dans le même répertoire. C'est pourquoi lors d'un changement de la valeur d'un paramètre il faut repasser par PSADMIN pour que ce dernier génère une nouvelle version du fichier binaire.
PSADMIN : Cet exécutable doit être impérativement lancé de son répertoire.
Il permet de gérer le serveur d'application ( arrêt -Démarrage - Configuration ) mais également le process Scheduler
Il se présente ainsi lors de son lancement :
PSADMIN -- Tools Release: 8.47
Copyright (c) 1988-2005 PeopleSoft, Inc. All Rights Reserved.
--------------------------------
PeopleSoft Server Administration
--------------------------------
1) Application Server
2) Process Scheduler
3) Service Setup
q) Quit
De là on va pouvoir administrer la partie serveur d'application ( TUXEDO et Processus PS ).
Command to execute (1-3, q): 1
-------------------------------------------
PeopleSoft Application Server Administration
-------------------------------------------
1) Administer a domain
2) Create a domain
3) Delete a domain
4) Import domain configuration
q) Quit
Grâce à la commande 4 on va pouvoir à nouveau reconfigurer et régénérer le fichier binaire.
Select domain number to administer: 1
--------------------------------
PeopleSoft Domain Administration
--------------------------------
Domain Name: F89DMO
1) Boot this domain
2) Domain shutdown menu
3) Domain status menu
4) Configure this domain
5) TUXEDO command line (tmadmin)
6) Edit configuration/log files menu
7) Messaging Server Administration menu
8) Purge Cache
q) Quit
Suite à l'installation du serveur d'application, on peut tester que l'installation de TUXEDO c'est faite de manière correcte grâce à l'aide en ligne.
Cependant avant de pouvoir lancer le TUXEDO en mode ligne de commande il faut auparavant fixer le TUXCONFIG, ce qui revient à initialiser le fichier binaire de configuration.
Le TUXEDO peut avoir un mot de passe, celui ci est présent dans :
%TUXDIR%\udataobj\tlisten.pw
Lors de l'installation de l'Application Server sous Windows, il convient de créer des services pour la partie TUXEDO, pour une bonne gestion TUXEDO-Windows.
Pour connaître la version sur laquelle on travaille :
SQL> Select * from psrelease
3.3. FailSafe Over
Avant de commencer je rappel que le fail Safe Over est un concept permettant une continuité du service d'une application même en mode dégradé
Cette configuration va nous permettre de gérer du load balancing en même temps que de faire du fail Safe Over . Nous configurons deux domaines sur deux serveurs différents que nous activons tout les deux.
Les deux domaines sont actifs et se partage les connexions de façon équilibré. Si l'un crash l'autre prend automatiquement en charge toutes les connexions. Il faut le mettre en place au moment de l'activation des domaines comme cela les crash sont transparents pour les utilisateurs .
Il n'existe pas de solution alternative au serveur d'application peopleSoft. Pas pour l'instant mais le projet fusion modifiera apportera certainement OAS en complément de l'offre.
4. Process Scheduler
4.1. Présentation
Ici nous sommes dans le monde des batch . En effet pour pouvoir de définir des processus programmées et différés on va paramétrer un ou des process scheduler qui sera géré via le TUXEDO pour pouvoir lancer les traitements Batch.
Un Process Scheduler est donc pour le serveur Batch, la même chose qu'un domaine pour un serveur d'application.
4.2. Administration
Un process Scheduler pour une base de données est géré via TUXEDO. A ce titre il est administré via le PSADMIN. Cette interface va nous servir à la création - suppression - configuration et paramétrage.
Lançons le PSADMIN :
PSADMIN -- Tools Release: 8.47
Copyright (c) 1988-2005 PeopleSoft, Inc. All Rights Reserved.
--------------------------------
PeopleSoft Server Administration
--------------------------------
1) Application Server
2) Process Scheduler
3) Service Setup
q) Quit
Command to execute (1-3, q): 2
On va donc lancer le Process Scheduler :
Command to execute (1-3, q): 2
-------------------------------------------
PeopleSoft Process Scheduler Administration
-------------------------------------------
1) Start a Process Scheduler Server
2) Stop a Process Scheduler Server
3) Configure a Process Scheduler Server
4) Create a Process Scheduler Server Configuration
5) Delete a Process Scheduler Server Configuration
6) Edit a Process Scheduler Configuration File
7) Import an existing Process Scheduler Configuration
8) Show Status of a Process Scheduler Server
9) Kill a Process Scheduler Server
q) Quit
Command to execute (1-9, q) :
De là tout comme pour l'application server, on a différents choix entre la création, l'administration, la suppression, la gestion…
Lorsque l'on crée un process scheduler pour une base de données, il existe un fichier de configuration qui est généré et qui se dénomme psprcs.cfg. Celui est présent dans le répertoire
$PS_HOME\ \appserv\prcs\DOMAINE
Il faut bien entendu remplacer le DOMAINE par le nom du domaine. Ce n'est pas ce fichier qui est lu lors du démarrage des Process mais PSTUXCFG ( fichier binaire). Il faut donc, lorsque l'on opère une modification sur le fichier de configuration relancer PSADMIN pour une prise en compte des différentes modifications et régénérer le fichier binaire.
Ce fichier de configuration centrale détermine la vie du process scheduler. Il va lui permettre de savoir ou se connecter, il lui fournit également les binaires de la BDD pour pouvoir communiquer avec cette dernière. Pour Oracle la variable DBBIN va lui indiquer la valeur de la variable $ORACLE_HOME/bin
Mais il va également permettre de configurer la section distribution des reports, la partie SMTP/server LOTUS et les crystal reports.
Autre domaine important de configuration, celui des SQR. On va pouvoir grâce à la variable SQRBIN lui indiquer la source des SQR
Print Log : Permet d'imprimer également les logs lorsqu'un report SQR est imprimé
Enhanced HTML : Permet d'avoir des Logs sous format HTML
PSSQR1 : Chemin de sortie des report SQR
Comme indiquer précédemment il est possible de démarrer le process scheduler par le biais de PSADMIN.
Celui va démarrer au moins deux processus : psprcsrv.exe et PSDSTSRV.exe
Le PSDSTSRV est le processus de agent qui distribue les batch.
Il est possible à tout moment de voir l'état du process Scheduler pour une base grâce à la table PSSERVERSTAT
select * from PSSERVERSTAT
La description des statut est possible via la table XLATTABLE :
select fieldvalue , xlatlongname
from xlattable
where fieldname = 'SERVERSTATUS'and language_cd ='FRA'
Attention à la langue sélectionnée .
Il est également de possible de lancer les Process Scheduler sans passer par le mode graphique de PSADMIN :
Tout d'abord il faut se placer dans le répertoire du PSADMIN
cd %PS_HOME%\appserv
Psadmin -h
psadmin -p start -d database (démarrer a Process Scheduler)
psadmin -p stop -d database (arrêter a Process Scheduler)
psadmin -p configure -d database (Configurer a Process Scheduler)
psadmin -p status -d database (Voir le statut du Process Scheduler)
psadmin -p kill -d database (tuer un Process Scheduler)
psadmin -p create -d database -t template -ps ps_set
(Créer un nouveau Process Scheduler)
Notons que grâce à ce mode on peut voir la version du serveur d'application :
%PS_HOME%\appserv>psadmin -v
Version 8.47
Voici quelques tables qui pourront nous aider dans l'administration des traitements Via le process schéduler PeopleSoft
--table des traitements batchs
select * from psprcsrqst
select * from PSPRCSQUE
-- Table des Run control/Batch
select * from PSPRCSRUNCNTL
-- Table des Locks du Process schéduler
select * from PSPRCSLOCK
--Table de paramétrage du process scheduler
select * from PSPRCSPARMS
-- table de status des batch en cours
select * from PSPRCSJOBSTATUS
Les logs générés par les traitements sont stockés dans : %PS_SERVDIR%\logs
On peut également tracer les traitements en vue du débugging et/ou de problème de performance
Psprcs.cfg
vvalues for config section - Trace
TraceFile=%PS_SERVDIR%\logs\PeopleTools.trc
TraceSQL=0
TracePC=0
TraceAE=0
Ici nous allons configurer le répertoire de sortie mais également le niveau de trace des ordres SQL, des Application Engine et du PeopleCode.
4.3. FailSafe Over
Afin d'assurer une politique de Fail Safe Over et de se prémunir contre les aléas dans un système sécurisé de production. Nous conseillerons d'avoir deux environnements distincts ( sur deux serveurs )ce qui nous permettra lors de la défaillance du premier de pouvoir basculer sur le second. Ici il s'agit donc d'avoir une solution de Fail Safe Over couplé à une solution de Load Balancing applicatif.
4.4. Solution Alternative
Il existe différentes solutions alternatives pour remplacer le scheduler de PeopleSoft. Notamment des produits tiers qui sont bien entendu payant : $Universe, Active Batch, Automation Suite … Voilà un site utile qui comporte une étude comparative intéressante ( en français ) http://ordonnanceurs.ordonnancement.org/
5. La Base de Données
5.1. Présentation
Ici nous abordons la solution que nous offre Oracle, nous avons choisis la dernière version d'Oracle : la 10G Release 2 qui va nous permettre de détailler les nouveautés de cette version.
En effet cette version est intéressante dans le sens ou elle va enfin répondre à une partie des attentes des DBA depuis quelques temps. Même si cette version est annoncé comme étant une version plus " IHM " le DBA demeure une clé importante de ce système. Celui devra simplement évoluer vers plus d'expertise.
Les nouveautés entre autres de la 10G sont :
- Datapump
- Console OEM en mode standalone
- Nouveau OMS
- Dbms_Scheduler
- Drop Database
- Renommer Un TBS
- Tablespace BigFile
- ASM ( Automatic storage Management )
- DBMS_FILE_TRANSFER
- AWR et ADDM
- Optimisation du code SQL (
- Fonctionnalité Flashback
- (…)
Base Oracle et base PeopleSoft :
Une base de donnée au sens Oracle est composé d'une ou plusieurs instances et de fichiers, le tout composant un ou plusieurs ORACLE_SID. Elle englobe donc un catalogue ou dictionnaire système. Le tout géré par un moteur Oracle ORACLE_HOME.
Une base de données au sens PeopleSoft est beaucoup plus logiques. En effet une base PS est un ensemble d'objets définit par le même schéma propriétaire. Une base de données Ps inclut donc les objets et les donnés d 'applications pour éventuellement un ou plusieurs produits. Cependant PeopleSoft recommande de n'avoir qu'un seul produit par instance Oracle ( Ici nous envisageons un seul instance = une seule base de données ). Cela "évidemment afin de faciliter l'administration et également les performances.
Comment gérer de multiple base PeopleSoft sur une Instance Oracle.
Connexion à la base de données :
Il existe un utilisateur un peu particulier sur PeopleSoft. Cet utilisateur que l'on peut retrouver dans la vue DBA_USERS. Cet utilisateur n'a aucun privilège système, il ne peut même pas ouvrir une session sous Sql*plus :
Cependant il possède deux objets qui sont important pour la connexion. La table PSDBOWNER et son index.
SQL> set linesize 250
SQL> col segment_name format a20
SQL> r
1* select segment_name, segment_type from dba_segments where owner ='PS'
SEGMENT_NAME SEGMENT_TYPE
-------------------- ------------------
PSDBOWNER TABLE
PS_PSDBOWNER INDEX
Lorsque Peoplesoft va se connecter à Oracle, la connexion est initialisé via le user déclaré comme CONNECT_ID PS qui grâce à la table PS.PSDBOWNER va donner pour chaque base de données PeopleSoft un schéma Oracle.
La sécurité PeopleSoft :
La sécurité est en grande partie géré par PeopleSoft et ces différentes tables de sécurité.
La table PSOPRDEFN est une table qui va détailler tous les utilisateurs applicatifs, ainsi que leur définition. Grâce à la sécurité PS on va pouvoir non seulement définir les accès aux différentes tables mais également aux traitements, donnés ..
Il existe une table par base PeopleSoft.
Voyons maintenant la gestion des ID sous PeopleSoft :
Connect Id : C'est l'utilisateur qui va assurer la connexion à la base. Son mot de passe est stocké en crypté dans la table DBA_USERS. le champ est password. Cet utilisateur n'a que le privilège Oracle de lecture (SELECT ) sur les tables suivantes : PSDBOWNER, PSSTATUS, PSOPRDEFN et PSACCESSPRFL. La création du Connect ID se fait via le script connect.sql présent dans le répertoire : $PS_HOME\scripts
En règle générale il s'agit de l'utilisateur PEOPLE.
User Id : C'est l'utilisateur applicatif dont les utilisateurs finaux vont se servir. Il est stocké comme décrit plus haut dans la table PSOPRDEFN.
Access ID : C'est ce qui va permettre de déterminer les droits d'accès à la base de données. Tout cela est géré dans les tables SGBDR.
Symbolic ID : C'est le lien entre les tables PSOPRDEFN et PSACCESSPRFL. Il va nous renseigner sur quelle Access Id utilisé
Dans ce document nous ne parlerons pas de l'installation, nous laissons ce soin à la documentation officielle.
PeopleSoft va nous livrer deux bases : SYS et DMO. La base SYS est une base qui dispose de tous les tables PeopleSoft, les objets de l'application. Cette base est vide de toutes les données que l'on peut trouver. On peut s'en servir comme base de production.
La base DMO est une base SYS avec en plus des données . D'ou le nom c'est une base de démonstration. Elle peut être utile à des fin de formation. Son autre dénomination est une base Vanille
Organisation de la base :
Une Base de données est constitué de trois strates bien distingues. Prenons le cas d'une base Oracle :
Catalogue système
PeopleTools
Données
Le catalogue système sont les tables système d'un SGBDR et lui sont donc propres. Ils vont contenir des informations sur la structure de la BDD. Sous Oracle ces tables commencent généralement par DBA_ , ALL_ , USER , V$_ , …
Elles sont recensés dans le dictionnaire Oracle :
SQL > select * from dict ;
Et appartiennent de facto à l'utilisateur SYS.
Les PeopleTools sont des tables qui commence par PS alors que les tables de données commence par PS_
Alors que le catalogue SGBDR va définir la DDL de tous les objets de la base de données. Les PeopleTools sont les tables qui vont définir l'application PeopleSoft.
Elle sont en règle générale stocké dans le tablespace PTTBL
select *
from user_tables
where table_name notlike 'PS@_%' escape '@'
and table_name like 'PS%'
Il existe deux traitements qui vont pouvoir vérifier l'intégrité de la base de données.
Le DDAUDIT.SQR est un traitement qui va vérifier l'intégrité du dictionnaire SGBDR par rapport aux tables PeopleTools.
Le SYSAUDIT.SQR va quand lui vérifier l'intégrité des tables de Tools. Il va notamment vérifier les références croisées.
5.2. Administration
L'administration de la base se fait de manière classique, sauf que depuis la version 10G il existe une console Web d'administration facilitant les tâches classiques du DBA. Oracle étant un domaine vaste je vous laisse le soin de consulter la documentation sur internet.
Vous pouvez également soit consulter le site de la rubrique Oracle ou alors poser une question sur le forum Oracle .
5.3. FailSafe Over
Les solutions de secours sont les solutions classiques tels que les StandBy database , la réplication …
5.4. Solution Alternative
Les concurrents habituels d'oracle présentent tous une solution adverse : Microsoft MS-SQLServer , Sybase Adapative server, IBM DB2, Informix
III. Conclusion
Vous comprendrez bien que ce document se veut plus comme une documentation d'introduction à l'architecture PeopleSoft plus que comme une documentation d'administration de cette plate-forme.
Je tiens également à remercier Chan Lima ainsi que Xavier Vlieghe
Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur.
La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
Dans ce tutorial nous allons nous intéresser à l'architecture des ERP.
Les Entreprises Ressources Planning ou PRG ( Progiciel de gestion intégré )
ont en ce moment le vent en poupe dans le monde de l'entreprise.
C'est un progiciel de gestion des flux logistiques et financiers de l'entreprise.
Systèmes d'Information où les différents traitements (transactions et exécution)
et fonctions classiques d'une entreprise sont intégrés autour d'un référentiel de données et de processus unique.
Tout comme Apache qui possède un fichier de configuration httpd.conf, Weblogic dispose également de son fichier. Celui est généralement localisé dans :
