Une fois connecté avec un compte HR Access sous HRaSpace, il est possible d'avoir une vue sur les droits de ce compte grâce à la servlet "Check".
L'URL d'accès à cette fonction est (adapter l'adresse et le port IP) :
http://1.2.3.4:5678/hra-space/check
30 novembre 2011
29 novembre 2011
Accéder à la console d'administration du Self Service de HRaSpace
Le Self Service de HRaSpace possède sa propre "console" d'administration. Cette dernière permet de lancer à chaud des actions de rafraîchissement des Processus Guidés ou du cache des données (listes de codes réglementaires) :
L'URL d'accès à cette console est (adaptez l'adresse et le port IP) :
http://1.2.3.4:5678/hr-self-service/selfadmin
Pour rendre cette console disponible, vous devrez auparavant arrêter HRaSpace, puis redémarrer après avoir décommentariser les deux balises suivantes dans le fichier /hra***/hraspace/webapps/hr-self-service/WEB-INF/web.xml :
<servlet>
<servlet-name>selfadmin</servlet-name>
<servlet-class>com.hraccess.selfservice.servlets.HRSelfAdminServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
et
<servlet-mapping>
<servlet-name>selfadmin</servlet-name>
<url-pattern>/selfadmin</url-pattern>
</servlet-mapping>
En production, complétez le fichier web.xml pour sécuriser l'accès à cette console (<security-constraint>).
- Refresh GP
- Refresh all GPs
- Refresh session
- Clear cache
L'URL d'accès à cette console est (adaptez l'adresse et le port IP) :
http://1.2.3.4:5678/hr-self-service/selfadmin
Pour rendre cette console disponible, vous devrez auparavant arrêter HRaSpace, puis redémarrer après avoir décommentariser les deux balises suivantes dans le fichier /hra***/hraspace/webapps/hr-self-service/WEB-INF/web.xml :
<servlet>
<servlet-name>selfadmin</servlet-name>
<servlet-class>com.hraccess.selfservice.servlets.HRSelfAdminServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
et
<servlet-mapping>
<servlet-name>selfadmin</servlet-name>
<url-pattern>/selfadmin</url-pattern>
</servlet-mapping>
En production, complétez le fichier web.xml pour sécuriser l'accès à cette console (<security-constraint>).
21 novembre 2011
ERREUR D'ACCES (TABLE RELATIONNELLE) : PP10/SELECT/9X/DF/000000000000805
Ce genre de message (erreur SQL 805) se produit sous DB2 quand le "Bind" de certains Cobols n'a pas été joué.
db2 -x "select pkgname from syscat.packages, ${HRSCHEMA}.pg15 where pkgschema='${HRSCHEMA}' and pkgname=rtrim(rdprog)||cdprog" | while read BND
do
[ ! -f $SIGACS/prod/bnd/${BND}.bnd ] && echo "<W> Fichier ${BND}.bnd inexistant" && continue
if ! db2 "bind $SIGACS/prod/bnd/${BND}.bnd collection ${HRSCHEMA} datetime iso isolation UR qualifier ${HRSCHEMA}" ; then
echo "<W> Bind Ko pour ${BND}.bnd"
else
echo "<I> Bind Ok pour ${BND}.bnd"
fi
done > ${LOG}/ReBind.log 2>&1
ls $SIGACS/prod/bnd | grep '\.bnd$' | while read F
do
BND=$(basename $F .bnd)
EXIST=$(db2 -x "select count(*) from syscat.packages where pkgschema='${HRSCHEMA}' and pkgname='${BND}'")
if [ ${EXIST} -eq 0 ]; then
if ! db2 "bind $SIGACS/prod/bnd/${BND}.bnd collection ${HRSCHEMA} datetime iso isolation UR qualifier ${HRSCHEMA}" ; then
echo "<W> Bind Ko pour ${BND}.bnd"
else
echo "<I> Bind Ok pour ${BND}.bnd"
fi
fi
done > ${LOG}/NewBind.log 2>&1
FYI : la liste des packages générés par DB2 lors d'un bind est accessible à travers la vue "syscat.packages".
SQL0805N Package "<package-name>" was not found
- Si l'environnement était propre jusqu'alors, on pourra se contenter de refaire le bind du programme concerné.
- Si le contexte est défavorable (environnement instable), il vaut mieux rejouer la totalité des binds de la totalité des programmes. Cela rendra la situation plus claire.
Re-Exécution des Bind pour les programmes référencés en table PG15
db2 -x "select pkgname from syscat.packages, ${HRSCHEMA}.pg15 where pkgschema='${HRSCHEMA}' and pkgname=rtrim(rdprog)||cdprog" | while read BND
do
[ ! -f $SIGACS/prod/bnd/${BND}.bnd ] && echo "<W> Fichier ${BND}.bnd inexistant" && continue
if ! db2 "bind $SIGACS/prod/bnd/${BND}.bnd collection ${HRSCHEMA} datetime iso isolation UR qualifier ${HRSCHEMA}" ; then
echo "<W> Bind Ko pour ${BND}.bnd"
else
echo "<I> Bind Ok pour ${BND}.bnd"
fi
done > ${LOG}/ReBind.log 2>&1
Exécution du Bind pour les programmes présents dans $SIGACS/prod/bnd mais absents en base de données
ls $SIGACS/prod/bnd | grep '\.bnd$' | while read F
do
BND=$(basename $F .bnd)
EXIST=$(db2 -x "select count(*) from syscat.packages where pkgschema='${HRSCHEMA}' and pkgname='${BND}'")
if [ ${EXIST} -eq 0 ]; then
if ! db2 "bind $SIGACS/prod/bnd/${BND}.bnd collection ${HRSCHEMA} datetime iso isolation UR qualifier ${HRSCHEMA}" ; then
echo "<W> Bind Ko pour ${BND}.bnd"
else
echo "<I> Bind Ok pour ${BND}.bnd"
fi
fi
done > ${LOG}/NewBind.log 2>&1
FYI : la liste des packages générés par DB2 lors d'un bind est accessible à travers la vue "syscat.packages".
17 novembre 2011
Topologie HRS : Connecteur FTP et Diagramme de Query avec un serveur Web distant
Pour éviter des accès FTP inutiles, j'ai décrit sous HRD Studio (HR v7.17.5) une topologie HRS
Ca ne marche pas !
En fait HRaSpace v7.17.5 prend le "diagramme compilé" - une version simplifiée du diagramme de query - qui ne contient que les propriétés par défaut ... Donc ... sans les "surcharges" !
echo "set lines 4000
select ZONXML from EN30 where TYENTI='SI' and CDENTI='HRS' and CDROLE='CPSITE' order by NOLIGN;" | sqlplus -s hr/password | sed 's/^.*base64//' | perl -MMIME::Base64 -ne 'print decode_base64($_)'
<?xml version="1.0"?>
<SITE_COMPILE XmlVersion="7.1.7">
<QUERYCHAIN Name="DIAGQRY">
<QUERY_URL>1.2.3.4</QUERY_URL>
<QUERY_PORT>21</QUERY_PORT>
<QUERY_USER>hradev</QUERY_USER>
<QUERY_PASSWORD>pFre7%34</QUERY_PASSWORD>
<QUERY_DIRECTORY>/hradev/hraccess/query/work</QUERY_DIRECTORY>
<QUERY_LOCALISATION>L</QUERY_LOCALISATION>
<QUERY_LISTENER>5678</QUERY_LISTENER>
<QUERY_COMMUNICATION>D</QUERY_COMMUNICATION>
<EDITION_URL>1.2.3.4</EDITION_URL>
<EDITION_PORT>21</EDITION_PORT>
<EDITION_USER>hradev</EDITION_USER>
<EDITION_PASSWORD>pFre7%34</EDITION_PASSWORD>
<EDITION_DIRECTORY>/hradev/hraccess/query/work</EDITION_DIRECTORY>
<EDITION_LOCALISATION>L</EDITION_LOCALISATION>
<IMPORT_URL>1.2.3.4</IMPORT_URL>
<IMPORT_PORT>novalue</IMPORT_PORT>
<IMPORT_USER>novalue</IMPORT_USER>
<IMPORT_PASSWORD>novalue</IMPORT_PASSWORD>
<IMPORT_DIRECTORY>/hradev/hraccess/txt/arc/import</IMPORT_DIRECTORY>
<IMPORT_ARCHI>/hradev/hraccess/txt/arc</IMPORT_ARCHI>
<IMPORT_LOCALISATION>L</IMPORT_LOCALISATION>
<IMPORT_COMMUNICATION>novalue</IMPORT_COMMUNICATION>
</QUERYCHAIN>
</SITE_COMPILE>
(NB: LOCALISATION = L pour Local)
Donc dans ma configuration (tous les modules locaux, le serveur Web distant), pour faire fonctionner les liens FTP entre HRaSpace et le volume d'archivage, il vaut mieux :
Pourquoi chercher à éviter des accès FTP inutiles ?
- où tous les modules sont locaux,
- puis dans le diagramme de query j'ai surchargé les paramètres de la connexion HRWeb au volume d'archivage pour spécifier un accès FTP
Ca ne marche pas !
En fait HRaSpace v7.17.5 prend le "diagramme compilé" - une version simplifiée du diagramme de query - qui ne contient que les propriétés par défaut ... Donc ... sans les "surcharges" !
echo "set lines 4000
select ZONXML from EN30 where TYENTI='SI' and CDENTI='HRS' and CDROLE='CPSITE' order by NOLIGN;" | sqlplus -s hr/password | sed 's/^.*base64//' | perl -MMIME::Base64 -ne 'print decode_base64($_)'
<?xml version="1.0"?>
<SITE_COMPILE XmlVersion="7.1.7">
<QUERYCHAIN Name="DIAGQRY">
<QUERY_URL>1.2.3.4</QUERY_URL>
<QUERY_PORT>21</QUERY_PORT>
<QUERY_USER>hradev</QUERY_USER>
<QUERY_PASSWORD>pFre7%34</QUERY_PASSWORD>
<QUERY_DIRECTORY>/hradev/hraccess/query/work</QUERY_DIRECTORY>
<QUERY_LOCALISATION>L</QUERY_LOCALISATION>
<QUERY_LISTENER>5678</QUERY_LISTENER>
<QUERY_COMMUNICATION>D</QUERY_COMMUNICATION>
<EDITION_URL>1.2.3.4</EDITION_URL>
<EDITION_PORT>21</EDITION_PORT>
<EDITION_USER>hradev</EDITION_USER>
<EDITION_PASSWORD>pFre7%34</EDITION_PASSWORD>
<EDITION_DIRECTORY>/hradev/hraccess/query/work</EDITION_DIRECTORY>
<EDITION_LOCALISATION>L</EDITION_LOCALISATION>
<IMPORT_URL>1.2.3.4</IMPORT_URL>
<IMPORT_PORT>novalue</IMPORT_PORT>
<IMPORT_USER>novalue</IMPORT_USER>
<IMPORT_PASSWORD>novalue</IMPORT_PASSWORD>
<IMPORT_DIRECTORY>/hradev/hraccess/txt/arc/import</IMPORT_DIRECTORY>
<IMPORT_ARCHI>/hradev/hraccess/txt/arc</IMPORT_ARCHI>
<IMPORT_LOCALISATION>L</IMPORT_LOCALISATION>
<IMPORT_COMMUNICATION>novalue</IMPORT_COMMUNICATION>
</QUERYCHAIN>
</SITE_COMPILE>
(NB: LOCALISATION = L pour Local)
Donc dans ma configuration (tous les modules locaux, le serveur Web distant), pour faire fonctionner les liens FTP entre HRaSpace et le volume d'archivage, il vaut mieux :
- Mettre une connexion distante au niveau du connecteur FTP du module du volume d'archivage.
- Puis - pour éviter des accès FTP inutiles - surcharger la connexion du Query au volume d'archivage pour l'indiquer locale.
Pourquoi chercher à éviter des accès FTP inutiles ?
- Car certaines versions de HR laissent des fichiers temporaires contenant le user/password,
- Car si le mot de passe évolue et que l'objet Topologie n'est pas corrigé très vite, cela provoque des échecs de connexions, et avec certaines politique sécurité le blocage du compte.
7 novembre 2011
Message d'erreur SORT(EXTSM) failed - sort engine status = 9/065
Le problème
Sur un de mes environnements HRv5, certaines chaines parallélisées sortent en erreur lors de tris Cobol avec un statut 9/065.Le status 9/065 signifie "File locked". Si des traitements batch ont lieu en parallèle; c'est probablement que deux opération de tri ont eu lieu en même temps sur l'environnement, avec des noms de fichiers de travail identiques.
Une solution
Pour sécuriser les MFSort, le support microfocus dit nécessaire de positionner une variable $TMPDIR sur un répertoire différent pour chaque tri... une gageure. Ma proposition est d'utiliser un répertoire $TMP/$$ créé à chaque appel de "mfsort" ($$=Pid Unix du shell en cours),Pour ceci, l'option la plus simple et la moins impactante pour l'application est :
- de surcharger la commande MicroFocus "mfsort"
- par une "fonction exportée" spécifique nommée "mfsort"
- déclarée et exportée via le script $ENV de chaque environnement.
Extrait du script $ENV
# Fonction mfsort
# Description :
# Créer un repertoire temporaires dedie avant chaque appel a mfsort.
# Syntaxe : mfsort take ...
function mfsort
{
echo "mfsort Spécifique 20110620 : redefinition TMPDIR=${TMP}/$$"
export TMPDIR=${TMP}/$$
mkdir -p ${TMPDIR}
trap 'rm -rf ${TMPDIR}' 0
# Adapter le chemin en fonction du site
/logi/cobol/bin/mfsort "$@"
}
typset -fx mfsort
A noter
Avec HRv7 les chaînes HR intègrent en début de script :TMPDIR=$TMP/T"$nupro"
export TMPDIR
Brainstorming
A- Ma proposition est d'utiliser un répertoire $TMP/$$ créé à chaque appel de "mfsort" ($$=Pid Unix du shell en cours),B- Surcharger la variable TMPDIR au moment de l'exécution du shell n'est pas suffisant car il faut gérer la création et la purge dudit répertoire $TMP/$$.
C- L'appel à la commande "msfort" est présent dans les chaines standard HR. Remplacer les "mfsort" par des appels à une commande d'un autre nom est contraignant : ceci implique de patcher la macro A39MT de PVBAMC00, de regénérer et relivrer toutes les chaînes HR.
D- Ceci implique de créer une fonction ou un script Unix "mfsort" spécifique de MEME NOM et qui soit PRIORITAIRE sur la commande "msfort" de /logi/cobol/bin. Pour ceci,
E1- Créer un shell "mfsort Spécifique" n'est pas suffisant. Pour être prioritaire l'ordre des répertoires du "PATH" Unix peut devoir être adapté. Si tel est le cas, ceci peut être source d'effets de bords. Un autre moyen est de créer et d'exporter un alias "mfsort" pointant sur ce script "mfsort Spécifique"
E2- Créer une fonction "mfsort Spécifique" et la référencer dans le "FPATH" n'aura pas d'effet car le FPATH est pris en compte APRES le PATH. le "mfsort" de MicroFocus serait donc trouvé AVANT la fonction "mfsort Spécifique". Un autre moyen est de créer et d'exporter cette fonction.
F- Déclarer l'alias ou la fonction dans le .profile est gênant car ces scripts sont spécifiques à chaque environnement et exclus de la livraison. De plus ces alias et fonctions - exportées ou non - sont "perdus" lors de l'ouverture d'un sous-shell !
G- Déclarer l'alias ou la fonction dans un script de "fonctions communes" fonctionnerait, à condition que ce dernier soit bien appelé par TOUS les scripts, ce qui est peu probable.
H- Déclarer l'alias ou la fonction dans le script $ENV de l'environnement permet d'en disposer dans chaque session. L'y exporter permet d'en disposer dans les sous shells.
...
Ouf !
4 novembre 2011
Message "Adress already in use" au démarrage du AP0
En cas de "The server failed to start !" / "Adress already in use" lors d'un csadmin start cs, impossible de démarrer le processus AP0.
ps -ef | grep AP0
Avec la commande lsof :
lsof -Pni | head -1; lsof -Pni | grep :2222
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
AP0 4456554 hradev 3u IPv4 0xf1000e00006783b0 0t0 TCP *:2222 (LISTEN)
AP0 4456554 hradev 4u IPv4 0xf1000e000a3f73b0 0t0 TCP 1.2.3.4:2222->9.9.1.7:38103 (ESTABLISHED)
BNR 30146592 hradev 0u IPv4 0xf1000e000a3f73b0 0t0 TCP 1.2.3.4:2222->9.9.1.7:38103 (ESTABLISHED)
BNR 30146592 hradev 3u IPv4 0xf1000e000a3f73b0 0t0 TCP 1.2.3.4:2222->9.9.1.7:38103 (ESTABLISHED)
Sous Linux il serait aussi possible d'utiliser la commande fuser (package psmisc) - a tester :
fuser -n tcp 2222
NB : pour connaitre ne n° de port, rechercher l'item SERVICE dans le fichier $SIGACS/adm/cfg/initserver, puis faire la correspondance avec les numéros de port du fichier /etc/services.
Si le port est utilisé légitimement par un applicatif (numéro paramétré dans ses fichiers de configuration) ... il faut se mettre d'accord avec l'administrateur intéressé, reparamétrer, redémarrer.
Si le port est utilisé par hasard par un applicatif (numéro attribué dynamiquement) ... il faut demander à l'administrateur système de paramétrer la plage de ports dynamiques pour ne plus entrer en conflit. En attendant, fermer l'applicatif concerné, ouvrir le AP0, redémarrer l'applicatif.
Il est toutefois possible de forcer son redémarrage :
Le transactionnel est déjà démarré
Vérifiez dans un premier temps qu'il n'est pas déjà actif !ps -ef | grep AP0
Quels processus utilisent le port
Dans le cas contraire, pour savoir quels processus utilisent encore le port de communication, et connaissant son numéro (ici exemple avec le port 2222),Avec la commande lsof :
lsof -Pni | head -1; lsof -Pni | grep :2222
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
AP0 4456554 hradev 3u IPv4 0xf1000e00006783b0 0t0 TCP *:2222 (LISTEN)
AP0 4456554 hradev 4u IPv4 0xf1000e000a3f73b0 0t0 TCP 1.2.3.4:2222->9.9.1.7:38103 (ESTABLISHED)
BNR 30146592 hradev 0u IPv4 0xf1000e000a3f73b0 0t0 TCP 1.2.3.4:2222->9.9.1.7:38103 (ESTABLISHED)
BNR 30146592 hradev 3u IPv4 0xf1000e000a3f73b0 0t0 TCP 1.2.3.4:2222->9.9.1.7:38103 (ESTABLISHED)
Sous Linux il serait aussi possible d'utiliser la commande fuser (package psmisc) - a tester :
fuser -n tcp 2222
NB : pour connaitre ne n° de port, rechercher l'item SERVICE dans le fichier $SIGACS/adm/cfg/initserver, puis faire la correspondance avec les numéros de port du fichier /etc/services.
Corriger les paramétrages
Si le port est utilisé par un applicatif zombie (ex : BNR en boucle infinie), tuer le processus avec la commande "kill n°PID" (puis "kill -9 n°PID" si le kill normal est sans effet)Si le port est utilisé légitimement par un applicatif (numéro paramétré dans ses fichiers de configuration) ... il faut se mettre d'accord avec l'administrateur intéressé, reparamétrer, redémarrer.
Si le port est utilisé par hasard par un applicatif (numéro attribué dynamiquement) ... il faut demander à l'administrateur système de paramétrer la plage de ports dynamiques pour ne plus entrer en conflit. En attendant, fermer l'applicatif concerné, ouvrir le AP0, redémarrer l'applicatif.
Forcer le redémarrage
Il peut arriver que ce soit le AP0 lui même qui ait mal libéré le port. En général ce dernier est libéré après un certain TIME OUT ...Il est toutefois possible de forcer son redémarrage :
- dans le fichier $SIGACS/adm/cfg/initserver, ajouter le paramètre RECONNECT=ON dans le chapitre [AP0] (NB : syntaxe RECONNECTE=ON pour les V2 et V3. Cet item est supprimé après le démarrage de AP0.)
- redémarrer avec un "csadmin start cs"
18 octobre 2011
Impossible d'écrire le fichier TA0FR.zip - Reprendre manuellement le FTP de la publication HR Studio
La phase de publication est relativement longue, HR Studio ramenant de la base la description complète de l'arbre et faisant un contrôle exhaustif de la validité des composants et de leurs dépendances.
Suite à ces contrôles, HR Studio construit en local une arborescence HTML qu'il va zipper pour l'envoyer par FTP sur le serveur Web pour demander son déploiement (le SFTP n'est pas disponible à ce jour, malgré de nombreuses demandes). Quand cette étape de FTP sort en erreur ... on se dit que l'on a perdu 1 à 3h de travail !
Message d'erreur HR Studio :
Dans un premier temps, contrôlez l'éventuelle présence d'un problème sur le serveur, ou sur votre connexion au serveur.
Une fois ces points écartés ou corrigés, dans la plupart des cas, HR Studio vous permettra de "reprendre la publication" (cf. le choix de menu correspondant - par clic droit sur l'arbre concerné).
Sinon, pour éviter de tout refaire, il est possible de déposer manuellement le zip (qui est conservé sur le poste PC) et déclencher son déploiement avec IE :
Retrouvez le fichier zip dans
C:\Program Files\HR Access Solutions\Design Center\{MonEnvironnement}\EXP\700\{MonCdplph}\{MonUser}\CURRENT_700\OBJECT\TRP\
Transférez le fichier zip avec un client FTP (FileZilla ou autre) sous webapps/hr-rich-client/services/{MonUser} (utilisez de préférence le compte hra***, cela vous évitera les problématiques de droits Unix).
Assurez vous que l’application Web est ouverte, sinon ouvrez OpenHR, HRQuery, HRWeb.
Pour déployer le ZIP de l’arbre, sous IE tapez l'URL
Si le déploiement est correct, l’écran affichera :
Puis pour rafraichir le dictionnaire des arbres, sous IE tapez l'URL :
http://.../hr-rich-client/HRAdmin?ACTION=RELOAD_TREES&USERLANG=F&VERIFYDICO=TRUE
Suite à ces contrôles, HR Studio construit en local une arborescence HTML qu'il va zipper pour l'envoyer par FTP sur le serveur Web pour demander son déploiement (le SFTP n'est pas disponible à ce jour, malgré de nombreuses demandes). Quand cette étape de FTP sort en erreur ... on se dit que l'on a perdu 1 à 3h de travail !
Message d'erreur HR Studio :
Envoi des fichiers
Impossible d'écrire le fichier TA0FR.zip. Les causes possibles sont:
- L'utilisateur Ftp n'a pas les droits d'écriture de fichiers dans le répertoire /hra***/hraspace/webapps/hr-rich-client/services et ses sous-répertoires
- Il n'y a pas suffisamment d'espace disque disponible sur le serveur HRa Space
Dans un premier temps, contrôlez l'éventuelle présence d'un problème sur le serveur, ou sur votre connexion au serveur.
- user/mdp ou chemin altéré dans l'objet topologie HRS,
- dans l'objet topologie HRS, la connexion FTP au serveur Web est-elle bien en mode "passif" ?
- connexion ftp impossible suite a changement de politique des firewall,
- obsolescence du mot de passe dépassée ou compte Unix verrouillé,
- espace disque disponible dans l'arborescence insuffisant,
- droits Unix sur le répertoire, sur le fichier trop restrictifs ...
Une fois ces points écartés ou corrigés, dans la plupart des cas, HR Studio vous permettra de "reprendre la publication" (cf. le choix de menu correspondant - par clic droit sur l'arbre concerné).
Sinon, pour éviter de tout refaire, il est possible de déposer manuellement le zip (qui est conservé sur le poste PC) et déclencher son déploiement avec IE :
Retrouvez le fichier zip dans
C:\Program Files\HR Access Solutions\Design Center\{MonEnvironnement}\EXP\700\{MonCdplph}\{MonUser}\CURRENT_700\OBJECT\TRP\
Transférez le fichier zip avec un client FTP (FileZilla ou autre) sous webapps/hr-rich-client/services/{MonUser} (utilisez de préférence le compte hra***, cela vous évitera les problématiques de droits Unix).
Assurez vous que l’application Web est ouverte, sinon ouvrez OpenHR, HRQuery, HRWeb.
Pour déployer le ZIP de l’arbre, sous IE tapez l'URL
- en HRv5
- en HRv7
- à compter de la version HR 7.20 il faut rajouter TREE et USERLANG
Si le déploiement est correct, l’écran affichera :
<HRRESULT Error="0">
<!\[CDATA\[ controls Ok \]\]>
</HRRESULT>
Puis pour rafraichir le dictionnaire des arbres, sous IE tapez l'URL :
http://.../hr-rich-client/HRAdmin?ACTION=RELOAD_TREES&USERLANG=F&VERIFYDICO=TRUE
7 octobre 2011
MF-LMF: License Key database unusable due to copying, restoration or tampering
Suite à installation d'un patch AIX, le gestionnaire Microfocus Cobol a perdu les clefs de licence (compilation et runtime). Ci dessous la procédure utilisée pour les rétablir ...
Configuration du site : HRv7 Unix Oracle avec Cobol Server Express 5.1 sur AIX 6.1
Début des opérations :
(chemin à adapter en fonction du site - il s'agit du chemin vers MF Cobol)
export COBDIR=/opt/microfocus/cobol
cd $COBDIR/aslmf
./aslmdbrecover
Avec root, installation de la licence
cd $COBDIR/aslmf
./apptrack
You must set an access password, before proceeding. Enter 6 characters as the password (6 spaces removes password)
-> ******
Server License Administration System - AppTrack
-----------------------------------------------------------
1. License List
2. License Summary
3. License Install
4. License Uninstall
5. Change/Set Password
6. Reinitialize Licensing
7. Current Users
9. Quit
Enter the Menu Selection
=> choix 3 (License Install)
Serial=***********AI+
License=************************
License installed ok
=> choix 9 (Quit)
Avec un des comptes hra***, test d'un batch :
subbn
select NUDOSS from ZE00
Contrôle du log.
Si tout est correct, avec chacun des comptes hra***, redémarrage des applications (la base étant active, démarrer AP0 avec csadmin, OpenHR, puis HRQuery et HRaSpace)
(chemin à adapter en fonction du site - il s'agit du chemin vers le gestionnaire de licences MF Cobol)
export COBDIR=/opt/microfocus/mflmf
cd $COBDIR
./lmfdbrecover
This script will remove the existing LMF license database
and prompt you to install your LMF licenses to a new database.
Do you wish to continue? (y/n)
y
Empty database created ok
License db recovery utility (lmfdbrecover) starting.
1. Text Mode license install
2. Screen Mode license install
3. Exit with no license install
=> choix 1
Micro Focus License Manager Command Line Interface
--------------------------------------------------
Select the function you require from the list:
License Install - Enter 'I'
License Uninstall - Enter 'U'
=> choix I
installer la licence de compilation
Serial=************AI+
License=************************
License added ok
Install another license? (y/n)
n
Avec root, redémarrage du démon
cd /etc
./mflmrcscript
Starting MFLM License Manager
MF-LMF:Wed Oct 12 23:15:30 2011: LMF Starting
Avec un des comptes hra***, test d'une compilation
subbz
processus et radical : AS800
module : BOT
Contrôle du log
Configuration du site : HRv7 Unix Oracle avec Cobol Server Express 5.1 sur AIX 6.1
Début des opérations :
- Arrêt complet des applicatifs (dont listener oracle)
- Arrêt et mise à jour système AIX + reboot
- Redémarrage du listener Oracle (cas où le listener n'est pas démarré au boot)
- Ouverture des bases de chaque environnement
Pour la licence d'usage
Avec root, reinitialisation de la base de licence(chemin à adapter en fonction du site - il s'agit du chemin vers MF Cobol)
export COBDIR=/opt/microfocus/cobol
cd $COBDIR/aslmf
./aslmdbrecover
Avec root, installation de la licence
cd $COBDIR/aslmf
./apptrack
You must set an access password, before proceeding. Enter 6 characters as the password (6 spaces removes password)
-> ******
Server License Administration System - AppTrack
-----------------------------------------------------------
1. License List
2. License Summary
3. License Install
4. License Uninstall
5. Change/Set Password
6. Reinitialize Licensing
7. Current Users
9. Quit
Enter the Menu Selection
=> choix 3 (License Install)
Serial=***********AI+
License=************************
License installed ok
=> choix 9 (Quit)
Avec un des comptes hra***, test d'un batch :
subbn
select NUDOSS from ZE00
Contrôle du log.
Si tout est correct, avec chacun des comptes hra***, redémarrage des applications (la base étant active, démarrer AP0 avec csadmin, OpenHR, puis HRQuery et HRaSpace)
Opération a prévoir pour la licence de compilation
Reinitialisation de la base de licence, installation de la licence(chemin à adapter en fonction du site - il s'agit du chemin vers le gestionnaire de licences MF Cobol)
export COBDIR=/opt/microfocus/mflmf
cd $COBDIR
./lmfdbrecover
This script will remove the existing LMF license database
and prompt you to install your LMF licenses to a new database.
Do you wish to continue? (y/n)
y
Empty database created ok
License db recovery utility (lmfdbrecover) starting.
1. Text Mode license install
2. Screen Mode license install
3. Exit with no license install
=> choix 1
Micro Focus License Manager Command Line Interface
--------------------------------------------------
Select the function you require from the list:
License Install - Enter 'I'
License Uninstall - Enter 'U'
=> choix I
installer la licence de compilation
Serial=************AI+
License=************************
License added ok
Install another license? (y/n)
n
Avec root, redémarrage du démon
cd /etc
./mflmrcscript
Starting MFLM License Manager
MF-LMF:Wed Oct 12 23:15:30 2011: LMF Starting
Avec un des comptes hra***, test d'une compilation
subbz
processus et radical : AS800
module : BOT
Contrôle du log
29 septembre 2011
ORA-28002: the password will expire within 6 days / ORA-28011: the account will expire soon / ORA-28000: the account is locked
Profil des comptes Oracle
A compter de Oracle v10, les comptes utilisent un profil par défaut avec les propriétés suivantes :
select * from dba_profiles where resource_type='PASSWORD' order by profile;
PROFILE RESOURCE_NAME RESOURCE LIMIT
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10
DEFAULT PASSWORD_LIFE_TIME PASSWORD 180
DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED
DEFAULT PASSWORD_GRACE_TIME PASSWORD 7
DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD NULL
DEFAULT PASSWORD_LOCK_TIME PASSWORD 1
DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED
Un mot de passe est donc valide 6 mois, et le compte est verrouillé après 10 tentatives de connexion infructueuses (ce qui va très vite si on démarre HR Access avec un objet Topologie HRS mal renseigné).
On aura alors blocage du compte :
select username, profile, account_status from dba_users where username='HR';
USERNAME PROFILE ACCOUNT_STATUS
- - - - - - - - - - - - - - - - - - - - - - - - -
HR DEFAULT LOCKED
Attribuer à HR un profil spécifique
Ci dessous on crée un profil différent du profil par défaut, sans limitations.
CREATE PROFILE HR
LIMIT
SESSIONS_PER_USER UNLIMITED
CPU_PER_SESSION UNLIMITED
CPU_PER_CALL UNLIMITED
CONNECT_TIME UNLIMITED
IDLE_TIME UNLIMITED
LOGICAL_READS_PER_SESSION UNLIMITED
LOGICAL_READS_PER_CALL UNLIMITED
PRIVATE_SGA UNLIMITED
COMPOSITE_LIMIT UNLIMITED
FAILED_LOGIN_ATTEMPTS UNLIMITED
PASSWORD_LIFE_TIME UNLIMITED
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
PASSWORD_LOCK_TIME UNLIMITED
PASSWORD_GRACE_TIME UNLIMITED
PASSWORD_VERIFY_FUNCTION NULL;
Puis on l'attribue au compte HR :
ALTER USER HR PROFILE HR;
Débloquer le compte
Si le compte est verrouillé vous aurez le message ORA-28001: the password has expired
Pour supprimer le verrouillage, se connecter avec le compte administrateur et exécuter l'ordre suivant :
ALTER USER HR ACCOUNT UNLOCK;
NB : si vous êtes sous Unix et que votre compte est dans le groupe "dba", cela se fait par la commande "sqlplus / as sysdba". Sinon il vous faut connaitre le mot de passe du compte "system". Attention : si vous n'avez pas un minimum de compétence Oracle, passez la main à un administrateur plutôt que de casser quelque chose ...
Pour supprimer le warning ORA-28011, le seul moyen que j'ai trouvé est de repositionner l'ancien mot de passe :
ALTER USER HR IDENTIFIED BY ...;
ALTER USER HR ACCOUNT UNLOCK;
NB : si vous êtes sous Unix et que votre compte est dans le groupe "dba", cela se fait par la commande "sqlplus / as sysdba". Sinon il vous faut connaitre le mot de passe du compte "system". Attention : si vous n'avez pas un minimum de compétence Oracle, passez la main à un administrateur plutôt que de casser quelque chose ...
Pour supprimer le warning ORA-28011, le seul moyen que j'ai trouvé est de repositionner l'ancien mot de passe :
ALTER USER HR IDENTIFIED BY ...;
22 septembre 2011
Convertir la description encodée de certains objets HR Access
Depuis HRv3e, un certain nombre d'objets ont une description en base "illisible" car encodée au format MIME base64.
Ci dessous par exemple la description d'une page Web :
select ZONXML from WF25 where GPECRA||CDECRA='FPW0F703' order by NOLIG4;
00040018Coder-Version: 1.00037Content-Type: text/xml; charset=UTF-80033Content-Transfer-Encoding: base640034Content-Description:HRWFormEntity00005B44PD94bWwgdmVyc2lvbj0iMS4wIj8+DQo8SFJXSU5ET1cgV2lkdGg9IjEwMjQiIEhlaWdodD0iMTEwMCIgU3R5bGU9IiIgVmVyc2lvbj0iNS4wLjAiIHV1aWQ9IjlBNzMyM0Y4LTQ3MEYtNDJBMy05NzUxLTU0Q0JFRjQxNTkzRCIgQm9yZGVyPSJOb25lIiBGb290ZXJBY3Rpb25zPSJDQU5DRUwiPg0KCTxIUlBBTkVMIE1vZGU9InRhYiIgdXVpZD0iNDlFMzQ3MkItRDk2OC00NDg5LThBRTctMkNFOEQ2NTdFM0UyIiBMZWZ0PSIwIiB
...
Ci dessous un exemple de décodage de la description d'une page Web HRv5.
Il a fallu ordonner et joindre les multiples lignes de description :
echo "set lines 3900
select ZONXML||'\' from WF25 where GPECRA||CDECRA='FPW0F703'
order by NOLIG4;" |
i_sql |
sed '$s/\\$//' | sed -e :a -e '/\\$/N; s/\\\n//; ta' | sed -e 's/^.*Content-Description: HRWFormEntity........//' -e 's/^.*Encoding: base64........//' |
perl -MMIME::Base64 -ne 'print decode_base64($_)' |
sed -e 's/é/é/g' -e 's/ê/ê/g' -e 's/à /à/g' -e 's/è/è/g' -e 's/#@/@/g' -e 's/ô/ô/g' -e 's/î/î/g' -e 's/â/â/g' -e 's/û/û/g' -e 's/ç/ç/g' -e 's/ù/ù/g' | tr '@' '\n'
Dans cet exemple de commande on a :
ce qui donne :
<?xml version="1.0"?>
<HRWINDOW Width="1024" Height="1100" Style="" Version="5.0.0" uuid="9A7323F8-470F-42A3-9751-54CBEF41593D" Border="None" FooterActions="CANCEL">
<HRPANEL Mode="tab" uuid="49E3472B-D968-4489-8AE7-2CE8D657E3E2" Left="0" Top="0" Width="1024" Height="477" LabelContext="page" Style="PAN05" EnableContext="default">
<HRDS uuid="C2451795-82F1-4C7F-BEDB-712F11229D24" Left="0" Top="0" Width="774" Height="234" Typerep="Z" Maxrowrep="1" Maxcolrep="1" Titlerep="1" Type="normal" HideEmptyrep="0">
<HRPARAMS Left="18" Top="63" Width="738" Height="72" uuid="D21F177F-0433-4011-972E-A52577058799">
<HRPANEL Left="18" Top="63" Width="738" Height="72" Mode="simple" LabelContext="page" Style="PAN02" uuid="83BDF6FD-591F-47E5-A0D1-9ECEEFF251FB" EnableContext="default">
...
Ci dessous par exemple la description d'une page Web :
select ZONXML from WF25 where GPECRA||CDECRA='FPW0F703' order by NOLIG4;
00040018Coder-Version: 1.00037Content-Type: text/xml; charset=UTF-80033Content-Transfer-Encoding: base640034Content-Description:HRWFormEntity00005B44PD94bWwgdmVyc2lvbj0iMS4wIj8+DQo8SFJXSU5ET1cgV2lkdGg9IjEwMjQiIEhlaWdodD0iMTEwMCIgU3R5bGU9IiIgVmVyc2lvbj0iNS4wLjAiIHV1aWQ9IjlBNzMyM0Y4LTQ3MEYtNDJBMy05NzUxLTU0Q0JFRjQxNTkzRCIgQm9yZGVyPSJOb25lIiBGb290ZXJBY3Rpb25zPSJDQU5DRUwiPg0KCTxIUlBBTkVMIE1vZGU9InRhYiIgdXVpZD0iNDlFMzQ3MkItRDk2OC00NDg5LThBRTctMkNFOEQ2NTdFM0UyIiBMZWZ0PSIwIiB
...
Ci dessous un exemple de décodage de la description d'une page Web HRv5.
Il a fallu ordonner et joindre les multiples lignes de description :
echo "set lines 3900
select ZONXML||'\' from WF25 where GPECRA||CDECRA='FPW0F703'
order by NOLIG4;" |
i_sql |
sed '$s/\\$//' | sed -e :a -e '/\\$/N; s/\\\n//; ta' | sed -e 's/^.*Content-Description: HRWFormEntity........//' -e 's/^.*Encoding: base64........//' |
perl -MMIME::Base64 -ne 'print decode_base64($_)' |
sed -e 's/é/é/g' -e 's/ê/ê/g' -e 's/à /à/g' -e 's/è/è/g' -e 's/#@/@/g' -e 's/ô/ô/g' -e 's/î/î/g' -e 's/â/â/g' -e 's/û/û/g' -e 's/ç/ç/g' -e 's/ù/ù/g' | tr '@' '\n'
Dans cet exemple de commande on a :
- i_sql qui est un utilitaire exécutant un SQLPLUS,
- un premier sed qui fusionne les lignes et supprime l'entête HR Access "Content-Description...base64" qui précède la description de l'objet,
- un perl qui décode la description,
- un second sed qui rétabli les caractères accentués.
ce qui donne :
<?xml version="1.0"?>
<HRWINDOW Width="1024" Height="1100" Style="" Version="5.0.0" uuid="9A7323F8-470F-42A3-9751-54CBEF41593D" Border="None" FooterActions="CANCEL">
<HRPANEL Mode="tab" uuid="49E3472B-D968-4489-8AE7-2CE8D657E3E2" Left="0" Top="0" Width="1024" Height="477" LabelContext="page" Style="PAN05" EnableContext="default">
<HRDS uuid="C2451795-82F1-4C7F-BEDB-712F11229D24" Left="0" Top="0" Width="774" Height="234" Typerep="Z" Maxrowrep="1" Maxcolrep="1" Titlerep="1" Type="normal" HideEmptyrep="0">
<HRPARAMS Left="18" Top="63" Width="738" Height="72" uuid="D21F177F-0433-4011-972E-A52577058799">
<HRPANEL Left="18" Top="63" Width="738" Height="72" Mode="simple" LabelContext="page" Style="PAN02" uuid="83BDF6FD-591F-47E5-A0D1-9ECEEFF251FB" EnableContext="default">
...
21 septembre 2011
Suppression impossible. L'utilisateur est connecté à HRa Space (code erreur 2004)
Avec HRa Suite 7, si vous cherchez a supprimer un compte avec HR Studio, alors que ce compte possède des données de session dans les tables de travail HR Access, votre demande sera rejetée.
Ce rejet est justifié si l'utilisateur est effectivement connecté.
En revanche, il n'est pas rare que les tables MX** se chargent de données obsolètes. Dans ce cas nettoyez les par un DELETE :
DELETE FROM MX10 WHERE USERID='...';
COMMIT:
Votre suppression de compte sera alors acceptée.
Ce rejet est justifié si l'utilisateur est effectivement connecté.
En revanche, il n'est pas rare que les tables MX** se chargent de données obsolètes. Dans ce cas nettoyez les par un DELETE :
DELETE FROM MX10 WHERE USERID='...';
COMMIT:
Votre suppression de compte sera alors acceptée.
20 septembre 2011
Accès HRWeb aux travaux ZO associés aux demandes, Correction de ZO2O.NUDORI
Le dossier de travail sous HRv7, conserve dans la rubrique ZO2O.NUDORI le NUDOSS de la demande ZO associée. En cas de suppression et de recréation de la demande, le lien est perdu et l'interface Web ne peut plus afficher les anciens travaux associés à la demande (ce lien est codé dans la page AABV800D)
Pour lister les travaux déphasés :
Ordre SQL DB2:
select ZO00D.NUDOSS, ZO2O.NUDORI, ZO00T.NUDOSS, ZO00T.CDPHAS, ZO00T.CDELMT, ZO00T.TYTMPL, ZO00T.IDREQU, ZO00T.FLGJOB, ZO00T.TISOUM
from ZO00 ZO00T, ZO2O,ZO00 ZO00D
where ZO00T.NUDOSS=ZO2O.NUDOSS
and ZO00T.CDPHAS=ZO00D.CDPHAS and ZO00T.CDELMT=ZO00D.CDELMT and ZO00T.TYTMPL=ZO00D.TYTMPL and ZO00T.IDREQU=ZO00D.IDREQU
and ZO00D.FLGJOB='0' and ZO00D.TISOUM='0001-01-01-00.00.00.000000'
and ZO00D.NUDOSS<>ZO2O.NUDORI
Ordre SQL Oracle : remplacer "0001-01-01-00.00.00.000000" par "0001-01-01"
Pour corriger les déphasages :
Ordre SQL DB2:
update ZO2O
set ZO2O.NUDORI = (
select coalesce(
(select ZO00D.NUDOSS from ZO00 ZO00D, ZO00 ZO00T
where ZO00T.NUDOSS=ZO2O.NUDOSS
and ZO00T.CDPHAS=ZO00D.CDPHAS and ZO00T.CDELMT=ZO00D.CDELMT and ZO00T.TYTMPL=ZO00D.TYTMPL and ZO00T.IDREQU=ZO00D.IDREQU
and ZO00D.FLGJOB='0' and ZO00D.TISOUM='0001-01-01-00.00.00.000000')
,0)
from SYSIBM.SYSDUMMY1)
Ordre SQL Oracle : remplacer "coalesce" par "nvl", "0001-01-01-00.00.00.000000" par "0001-01-01" et "SYSIBM.SYSDUMMY1" par "DUAL"
Pour lister les travaux déphasés :
Ordre SQL DB2:
select ZO00D.NUDOSS, ZO2O.NUDORI, ZO00T.NUDOSS, ZO00T.CDPHAS, ZO00T.CDELMT, ZO00T.TYTMPL, ZO00T.IDREQU, ZO00T.FLGJOB, ZO00T.TISOUM
from ZO00 ZO00T, ZO2O,ZO00 ZO00D
where ZO00T.NUDOSS=ZO2O.NUDOSS
and ZO00T.CDPHAS=ZO00D.CDPHAS and ZO00T.CDELMT=ZO00D.CDELMT and ZO00T.TYTMPL=ZO00D.TYTMPL and ZO00T.IDREQU=ZO00D.IDREQU
and ZO00D.FLGJOB='0' and ZO00D.TISOUM='0001-01-01-00.00.00.000000'
and ZO00D.NUDOSS<>ZO2O.NUDORI
Ordre SQL Oracle : remplacer "0001-01-01-00.00.00.000000" par "0001-01-01"
Pour corriger les déphasages :
Ordre SQL DB2:
update ZO2O
set ZO2O.NUDORI = (
select coalesce(
(select ZO00D.NUDOSS from ZO00 ZO00D, ZO00 ZO00T
where ZO00T.NUDOSS=ZO2O.NUDOSS
and ZO00T.CDPHAS=ZO00D.CDPHAS and ZO00T.CDELMT=ZO00D.CDELMT and ZO00T.TYTMPL=ZO00D.TYTMPL and ZO00T.IDREQU=ZO00D.IDREQU
and ZO00D.FLGJOB='0' and ZO00D.TISOUM='0001-01-01-00.00.00.000000')
,0)
from SYSIBM.SYSDUMMY1)
Ordre SQL Oracle : remplacer "coalesce" par "nvl", "0001-01-01-00.00.00.000000" par "0001-01-01" et "SYSIBM.SYSDUMMY1" par "DUAL"
12 septembre 2011
Message d'erreur SORT020U: SORT(EXTSM) failed - sort engine status = 24
Cette erreur provient de l'utilitaire mfsort. Elle survient lors de la génération d'un fichier indexés de plus de 4 Go.
SORT013U: I/O error on dataset '/hraccess/file/PAPFR/PVBDFAS0
SORT014U: Status = 24
SORT020U: SORT(EXTSM) failed - sort engine status = 24
Cause : Par défaut le format des fichiers indexés on un IDXFORMAT (format des fichiers indexés) à 1 pour les fichiers dont les enregistrements sont de longueur fixe, et IDXFORMAT 3 pour les longueurs variables. Ces formats de fichier sont limités à 4 Go (cf http://supportline.microfocus.com/documentation/books/sx20books/fhlimi.htm#s006)
Solution : Changer le format des fichiers indexés pour passer l'IDXFORMAT à 8, ce qui porte la limite de volume à 128 To ou 8MTo avec FILEPOINTERSIZE=8 (longueur en octets pour stockage des pointeurs)
FILEMAXSIZE=8
IDXFORMAT=8
-i[:command] - rebuild and display information
-v[:n] - display running count every n records
-e - continue after duplicate key error
-q - quick rebuild
-p - rebuild format 8 file in place (no backup)
-n[:command] - no output - just display file information
-x:n - key of reference [out-file only]
-d - rebuild corrupt data file
-y - force rebuild when file size discrepancy reported
-z - specifies server for all files
Ci joint un lien Microfocus à consulter sur le sujet.
Attention : ces fichiers prennent la forme d'un fichier unique (par opposition aux habituels fichiers .idx associés aux fichiers de données). Ceci peut avoir un impact sur des chaines ou des scripts qui prennent en charge ces fichiers ".idx".
SORT013U: I/O error on dataset '/hraccess/file/PAPFR/PVBDFAS0
SORT014U: Status = 24
SORT020U: SORT(EXTSM) failed - sort engine status = 24
Cause : Par défaut le format des fichiers indexés on un IDXFORMAT (format des fichiers indexés) à 1 pour les fichiers dont les enregistrements sont de longueur fixe, et IDXFORMAT 3 pour les longueurs variables. Ces formats de fichier sont limités à 4 Go (cf http://supportline.microfocus.com/documentation/books/sx20books/fhlimi.htm#s006)
Solution : Changer le format des fichiers indexés pour passer l'IDXFORMAT à 8, ce qui porte la limite de volume à 128 To ou 8MTo avec FILEPOINTERSIZE=8 (longueur en octets pour stockage des pointeurs)
- Ajouter dans le fichier $EXTFH le paramètre IDXFORMAT=8
FILEMAXSIZE=8
IDXFORMAT=8
- Convertir les fichiers avec la commande rebuild ... (à confirmer : je n'ai pas eu l'occasion de tester)
-i[:command] - rebuild and display information
-v[:n] - display running count every n records
-e - continue after duplicate key error
-q - quick rebuild
-p - rebuild format 8 file in place (no backup)
-n[:command] - no output - just display file information
-x:n - key of reference [out-file only]
-d - rebuild corrupt data file
-y - force rebuild when file size discrepancy reported
-z - specifies server for all files
Ci joint un lien Microfocus à consulter sur le sujet.
Attention : ces fichiers prennent la forme d'un fichier unique (par opposition aux habituels fichiers .idx associés aux fichiers de données). Ceci peut avoir un impact sur des chaines ou des scripts qui prennent en charge ces fichiers ".idx".
2 septembre 2011
La version de l'applet (x.x.x) est incompatible avec celle de l'application (y.y.y)
En cas de montée de version, ce message d'erreur peut survenir lors de l'affichage des pages du client riche HRaSpace v7.
Il est dû au fait que l'upgrade a déployé sur le serveur Web des fichiers dont l'horodatage est antérieur à votre dernière navigation.
La meilleure solution est donc de demander à l'installateur de mettre à jour l'horodatage des fichiers du serveur Web (pour forcer les postes clients a rafraichir leur cache). Par exemple pour un serveur Unix ou Linux :
cd .../webapps
find . -type f -exec touch {} \;
Sinon, une solution de contournement est de nettoyer le cache de votre JVM.
La JVM SUN garde dans son cache les applet des différentes applications auxquelles le poste s'est connecté.
Ce cache est différent de celui de IE ou Firefox.
Pour mon poste il se trouve dans C:\Documents and Settings\Administrator\Application Data\Sun\Java\Deployment\cache
Pour le nettoyer,
Il est dû au fait que l'upgrade a déployé sur le serveur Web des fichiers dont l'horodatage est antérieur à votre dernière navigation.
La meilleure solution est donc de demander à l'installateur de mettre à jour l'horodatage des fichiers du serveur Web (pour forcer les postes clients a rafraichir leur cache). Par exemple pour un serveur Unix ou Linux :
cd .../webapps
find . -type f -exec touch {} \;
Sinon, une solution de contournement est de nettoyer le cache de votre JVM.
La JVM SUN garde dans son cache les applet des différentes applications auxquelles le poste s'est connecté.
Ce cache est différent de celui de IE ou Firefox.
Pour mon poste il se trouve dans C:\Documents and Settings\Administrator\Application Data\Sun\Java\Deployment\cache
Pour le nettoyer,
- Affichez le panneau de configuration Java (par exemple sous Windows XP dans "Démarrer/ Panneau de configuration / Java")
- Trouvez la section "Fichiers Internet temporaires", bouton "Affichez",
- Dans la pop-up sélectionner les "ressources", et triez par URL.
- Il est ensuite nécessaire de retrouver les fichiers préfixés par l'URL de votre environnement (nom/adresse IP + port).
- L'applet est nommée "hrapplet.jar". Mais par sécurité supprimez tous les fichiers faisant référence à l'environnement concerné.
1 septembre 2011
Console d'évènement sous HRaSpace v7
Avec HRv7 est apparue la console d'évènements. On y trouve en général des messages concernant les traitements batch.
Les évènements sont stockés dans la table EV10 :
NUMEVT INTEGER
SOURCE CHARACTER 12
CATEGO CHARACTER 12
SERVNM CHARACTER 40
TIMDEB TIMESTAMP
TIMFIN TIMESTAMP
POERRE CHARACTER 1
IDGPRG INTEGER
USERID CHARACTER 25
TEANNU CHARACTER 1
FILENM CHARACTER 254
DESCRS CHARACTER 55
DESCRL VARCHAR 3000
COMPLT VARCHAR 200
Il est possible de retrouver les évènements tracés en table EV10 et analysant les squelettes :
* squelette (source/catégorie)
* BCM "DESCENTER" "ERRSYS" <- Conditionnement <DEBESP> dans le squelette
* BHR "HRASERVER" "CONNECT" <- Conditionnement <DEBESP> dans le squelette
* BHV "SELFSERVICE" "INSTANT" <- Conditionnement <DEBESP> dans le squelette
* BOP "HRASERVER" "BATCHJOB"
* BTS "DESCENTER" "DEPLOY" <- Conditionnement <DEBESP> dans le squelette
On note que malheureusement, la plupart des évènements sont réservés à HRAS du fait d'un conditionnement dans BGZ et BGX si W-WPVA-ESPISV = "ISV" au lieu de "ESP" (les plates-formes dites "ESP" sont des plates formes hébergeant des clients à HRAS) ... Contournement possible : générer un BGZ et un BGX spécifique avec W-WPVA-ESPISV = "ESP", créer une chaine RBZ spécifique, regénérer les programmes BHR BCM BHV BTS (et faire un arret/relance de OpenHR)
Notez qu'il est possible de faire apparaître des évènement sur traitements TP grâce au contexte TBP079 de BNL
insert into PP15 values ('PPCLIDEV','EV_RCVMAIL','digix@webmail.com');
insert into PP15 values ('PPCLIDEV','EV_CDTEMP','DIGIXXXX');
En revanche cette fonction est dans la pratique inutilisable :
Les évènements sont stockés dans la table EV10 :
NUMEVT INTEGER
SOURCE CHARACTER 12
CATEGO CHARACTER 12
SERVNM CHARACTER 40
TIMDEB TIMESTAMP
TIMFIN TIMESTAMP
POERRE CHARACTER 1
IDGPRG INTEGER
USERID CHARACTER 25
TEANNU CHARACTER 1
FILENM CHARACTER 254
DESCRS CHARACTER 55
DESCRL VARCHAR 3000
COMPLT VARCHAR 200
Il est possible de retrouver les évènements tracés en table EV10 et analysant les squelettes :
* squelette (source/catégorie)
* BCM "DESCENTER" "ERRSYS" <- Conditionnement <DEBESP> dans le squelette
* BHR "HRASERVER" "CONNECT" <- Conditionnement <DEBESP> dans le squelette
* BHV "SELFSERVICE" "INSTANT" <- Conditionnement <DEBESP> dans le squelette
* BOP "HRASERVER" "BATCHJOB"
* BTS "DESCENTER" "DEPLOY" <- Conditionnement <DEBESP> dans le squelette
On note que malheureusement, la plupart des évènements sont réservés à HRAS du fait d'un conditionnement dans BGZ et BGX si W-WPVA-ESPISV = "ISV" au lieu de "ESP" (les plates-formes dites "ESP" sont des plates formes hébergeant des clients à HRAS) ... Contournement possible : générer un BGZ et un BGX spécifique avec W-WPVA-ESPISV = "ESP", créer une chaine RBZ spécifique, regénérer les programmes BHR BCM BHV BTS (et faire un arret/relance de OpenHR)
Notez qu'il est possible de faire apparaître des évènement sur traitements TP grâce au contexte TBP079 de BNL
Activation de mails d'alerte
Pour compléter la console d'évènement accessible en Web, il est possible de demander l'activation d'un envoi de mail sur évènement :- création et déploiement du modèle de mail DIGIXXXX créé pour l'occasion :
- Alimentation en PP15 des paramètres d'activation de la fonctionnalité 'Nom du serveur de mail, Destinataires du mail, Code template
insert into PP15 values ('PPCLIDEV','EV_RCVMAIL','digix@webmail.com');
insert into PP15 values ('PPCLIDEV','EV_CDTEMP','DIGIXXXX');
En revanche cette fonction est dans la pratique inutilisable :
- impossible de choisir les types d'évènements justifiant un mail - on est donc "noyé" sous le nombre des messages,
- l'objet du mail correspond au libellé du modèle de mail et ne peut être enrichi,
- le mail contient trop peu d'informations (par exemple, en cas de tentative de connexion, le mail ne dit pas si cette dernière a été acceptée ou refusée !),
- un mail peut arriver 15 minutes après l'évènement ... pas essence le mail n'est pas un système d'alerte fiable.
Inscription à :
Articles (Atom)




