"Check" sous HRaSpace : Comment faire le point sur les droits d'un compte utilisateur

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

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) :

• 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>).

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é.

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".

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

• 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 

(mon serveur Web étant distant).

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.

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 !

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.

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"