La console d'audit des mouvements

Dans l'article précédent je présentait une console d'audit HRaSuite 9 avec un client HR 7.30.20. J'ai depuis constaté que la 7.30.30 avait apporté plusieurs évolutions :

• Du coté de HRaSpace, cette console est devenue une Webapp à part entière nommée hr-audit-console

• La console est accessible par défaut au rôle ALLRHLO (l'activité AUDITSUP lui est rattachée avec les structures de données ZA ZB ZC ZD ZE ZY). 

• Les paramètres techniques dans l'objet Topologie ont été pré-paramétrés :

• Le libellé d'accès a été corrigé :

• Et l'interface a évolué. Elle est désormais plus conforme à l'usage et semble stable

Que du bon, donc ...

0509-150 Le module dépendant libcobrts.2.so n'a pas pu être chargé

La variable LIBPATH ou LD_LIBRARY_PATH sert à localiser les librairie de COBOL. Elle est positionnée par le .profile - et est "remise en place" par le script $ENV. Sans cela il arrive que les processus Unix fils perdent la valeur de cette variable.

Le symptôme classique de la perte de cette variable est le message suivant (en général lorsqu'une chaîne batch exécute un tri MFSort) :


message : exec() : 0509-036 Impossible de charger le programme /opt/cobol/bin/mfsort32 en raison des erreurs suivantes :
0509-150 Le module dépendant libcobrts.2.so n'a pas pu être chargé.
0509-022 Impossible de charger le module libcobrts.2.so.
0509-026 Erreur système : Un fichier ou un répertoire du chemin d'accès n'existe pas. 

En standard le script $ENV de HRAccess est nommé en standard $FILE/.kshrc. Le préfixe "." rend le fichier invisible (sauf à utiliser l'option "-a" de la commande "ls"). Il est donc peu connu - et soumis au risque d'être purgé ou oublié lors des duplications.

Je préfère le rendre visible et le déplacer sous le nom $SIGACS/adm/cfg/kshrc.cfg. Si vous faites de même n'oubliez pas de corriger l'alimentation de $ENV et de faire un arrêt - démarrage pour que les transactionnels prennent en compte votre mise à jour.

Addendum : modifier aussi les scripts $SBIN/OPER job strcalck3w et stpcalck3w qui appellent directement $FILE/.kshrc au lieu d'utiliser la variable $ENV ...

Un nouveau journal dans LG12 avec HRv9

Avec HRv9 des tables "journal des mises à jour" **LG12 apparaissent pour chaque structure de données en plus des **LG10. Celle ci contiennent les mêmes données mais au format XML.

Les tables

A comparer les deux tables, seul les champs de stockage des données changent : **LG10-ZOLG10 devient **LG12-NUMENR et **LG12-ZONXML. Attention : un enregistrement XML peut donc être "découpé" sur plusieurs lignes de la table.

Et ces tables **LG12 possèdent 3 index :

• IX1**LG12 (TILG12, CDINFO)
• IX2**LG12 (USERID, TILG12, CDINFO)
• IX3**LG12 (NUDOSS, TILG12, NUORDI, CDINFO)

Notez que les deux tables possèdent depuis HRv7 des champs personnalisables alimentables par traitement (UT-ZOUT01 à UT-ZOUT06). 

Pensez à automatiser la purge de ces tables **LG12 en plus de celle des **LG10 historiques.

Choisir la version de JVM utilisée par le client riche de HRaSpace

Il est fréquent d'être contraint à une migration de version HR Client du fait d'une incompatibilité avec la version de JVM déployée sur le site.



Si vous êtes maître de votre poste vous pouvez installer / modifier le choix de la JVM activée (control panel / java). Toutefois cela peut poser problème à d'autres applications.


Dans le cas d'un ensemble de postes "matricés", mettre à jour le poste n'est pas possible. Il peut être intéressant de déployer une mise a jour "temporaire" de HRaSpace forçant le navigateur à utiliser une ancienne JVM...
En effet, si plusieurs version de JVM sont disponibles sur le poste client - un paramètre "java_version" dans les balises <APPLET> ou <OBJECT> de la page permet de préciser au navigateur une préférence dans le choix de la JVM à utiliser.

A lire : http://www.oracle.com/technetwork/java/javase/index-141751.html#JAVA_VERSION_EXAMPLES

Merci à Michel pour son analyse et ses tests (faits sous HRaSpace v7) ...