Liste et code des objets depuis HRv2 jusqu'à HRv9

Ci dessous une liste des codes et noms des différents type d'objets de conception HR Access.

• Ceux apparus avec HRv3 sont en rouge, 
• avec HRv3e en jaune, 
• avec HRv5 en vert., 
• avec HRv7 en bleu 
• et enfin avec HRv9 en violet.

AM : Arbre de publication
AN : Arbre fonctionnel
AP : Groupe de processus
AR : HRa Scope
AS : Plan de site
AT : Service
BP : Processus Guidé
CA : Code action fonctionnelle HRv5 / contextuelle HRv7
CC : Condition cataloguée
CO : Code confidentialité
CT : Documentation commune
CX : Action fonctionnelle HRv7
DO : Document d'exploration 
EC : Ecran C/S (obsolète)
ET : Etats
EX : Exploration
E0 : Objets générique E0
E1 : Elément graphique
E2 : Document de fusion
E3 : Ressource Web
E4 : Objets générique E4
E5 : Objets générique E5
E6 : Objets générique E6
E7 : Objets générique E7
E8 : Objets générique E8
E9 : Objets générique E9
FM : Fichiers Micro
FO : Formulaire
FP : Famille procédure C/S (obsolète)
FS : Feuille de style C/S (obsolète)
GB : Groupe de processus guidés
GD : Groupe de perspectives
GE : Groupe d'écrans C/S (obsolète)
GF : Groupe de formulaires
GK : Groupe de collections
GM : Groupe de descriptions données métier
GR : Groupe de requête DXE/TP (obsolète)
GT : Groupe de traitements
GX : Groupe d'exploration
HB : Activités
HD : Perspective
IN : Information
IO : Information ODS
IW : Information WH (déjà présent dans les dernières v3e)
KL : Collection
LI : Lien
LY : Action fonctionnelle localisée
MI : Description de données métier
NA : Assistant de Navigation
NN : Noeud
NS : Etape de l'Assistant
OD : Outbound process
OG : Groupe d'Outbound process
PA : Profil application (obsolète)
PE : Profil navigation (obsolète)
PI : Profil de information (obsolète)
PO : Profil action (obsolète)
PP : Profil population (obsolète)
PR : Profil requête (obsolète)
PC : Procédure C/S (obsolète)
PH : Plate-forme physique
PJ : Projet
PL : Plate-forme logique
PM : Paramètre
PS : Processus
PW : Serveur Web (obsolète)
QD : Query DataModel (inutilisé)
QG : Groupe de requêtes HRQuery
QL : Mise en page spécialisée HRQuery
QP : Population HRQuery
QR : Rapport HRQuery
RO : Rôle (modèle, structure)
RQ : Requête DXE/TP (obsolète)
SD : Structure de données
SG : Script plug-in
SI : Site HRv3e / Topologie système
SO : Structure de données ODS
SP : Sous-projet
ST : Type de dossier
SW : Structure de données WH (déjà présent dans les dernières v3e)
SY : Macro systèmes
TR : Traitement
UC : Utilisateur
WF : Page Web
WG : Groupe de pages Web
WK : Code workflow
WS : Charte graphique Web
ZC : Modèle de mail

A compter des clients HRStudio 7.30.60 (et le kit Tâche pour les HRv7)
AE : Objets "Tâche"

Calculer le nombre de jours (hors WE) dans l'année

Ci joint une fonction DB2 trouvée sur le forum de http://www.tek-tips.com. Elle vous permet de calculer le nombre de jours ouvrables (lundi, mardi ... vendredi - sans considération de jours fériés) entre deux dates.

exemple : script DDL PSBBGJ_BUSINESSDAYS.sql

CREATE FUNCTION business_days (low_date DATE, high_date DATE)
RETURNS INTEGER
BEGIN ATOMIC
   DECLARE bus_days INTEGER DEFAULT 0;
   DECLARE cur_date DATE;
   SET cur_date = low_date;
   WHILE cur_date < high_date DO
      IF DAYOFWEEK(cur_date) IN (2,3,4,5,6) THEN
         SET bus_days = bus_days + 1;
      END IF;
      SET cur_date = cur_date + 1 DAY;
   END WHILE;
   RETURN bus_days;
END!
COMMIT!

création de la fonction :
cat PSBBGJ_BUSINESSDAYS.sql | db2 -vtd\!

utilisation de la fonction :
select HR.business_days(DATE ('2012-01-01'),DATE ('2013-01-01')) from sysibm.sysdummy1
-----------
        261

Lister les utilisateurs HRaSpace actifs

Encore une donnée que l'on aimerait voir sur la console d'administration ...

Ci joint un SELECT permettant de connaître la liste des utilisateurs HRaSpace actifs dans les 10 dernières minutes :

Exemple Oracle
select USERID,max(TSACTI) from MX10 group by USERID having max(TSACTI) + 1/24/6 > SYSDATE

Exemple DB2
select USERID,max(TSACTI) from MX10 group by USERID having max(TSACTI) + 10 minutes > CURRENT_TIMESTAMP

Pour connaître la liste des utilisateurs connectés, remplacer le délai de 10 minutes par le délai d'inactivité maximum (par défaut 30 minutes, sauf si vous avez paramétré une ligne OP_TIMEOUT en table PP15).

Tracer les consultations en LG10 avec BNE

Vous avez bien lu ... Il est possible depuis HRv7 de tracer les consultations de données faites depuis HRaSpace en table LG10 (en temps normal ces traces sont utilisées lors des mises à jour).

Après exécution du contexte TBP068 de BNE, la variable UT-TEECLG est consultée par le squelette.

• Si UT-TEECLG est positionnée à 1 par traitement, on trace l'affichage de l'information,
• Si UT-TEECLG est positionnée à 2, on trace l'affichage de chacune des occurrences.

A noter :

• La trace est effectuée par le programme BNE. Il s'agit donc des données envoyées par le serveur HR au poste client. En conséquence :
• Le client hr-rich-client standard appelle les dossiers par paquet (la taille du paquet est paramétrable dans chaque page Web, cf. item "Dossiers demandés par transaction" dans l'onglet "Définition"),
• On trace donc des données que l'utilisateur a demandées, mais pas nécessairement qu'il a effectivement consultées.

Quelques précautions d'usage :

• Les tables **LG10 peuvent devenir extrêmement volumineuse et perturber les performances de l'application,
• L'activation des traces doit toujours se faire de manière ciblée : lister les cas d'usage nécessitant des traces, conditionnez les,
• Purger régulièrement les tables **LG10 des traces obsolètes.

Extrait du squelette BNE
708900*N8DBG.    NOTE *ECRITURE DANS LA TABLE LG10        *.            P005
709000 F8DBG.    IF    UT-TEECLG NOT = ZERO                             P005
709100           AND   W-WPD1-TYINFO NOT = "S"                          P010
709200           NEXT SENTENCE ELSE GO TO     F8DBG-FN.                 P010
709300*N8DBK.    NOTE *CONSERVATION INFO                  *.            P005
709400 F8DBK.    IF    PE-CDINFO = "1"                                  P005
709500           AND   UT-TEECLG = "1"                                  P020
709600           NEXT SENTENCE ELSE GO TO     F8DBK-FN.                 P020
709700*PE INFO.                                                         P020
709800     MOVE        " " TO LG10-GRLG10-ARR.                          P035
709900     MOVE        1 TO W-WP00-LGINFS.                              P036
710000     PERFORM     F9Z THRU F9Z-FN.                                 P040
710100 F8DBK-FN. EXIT.                                                  P040
710200*N8DBN.    NOTE *CONSERVATION TOUTES OCCURRENCES    *.            P005
710300 F8DBN.    IF    UT-TEECLG = "2"                                  P005
710400           NEXT SENTENCE ELSE GO TO     F8DBN-FN.                 P005
710500     MOVE        1-ZONINF TO S-ZONINF.                            P020
710600     MOVE        1-CDINFO TO S-CDINFO.                            P030
710700     MOVE        1-CDSTDO TO S-CDSTDO.                            P040
710800     PERFORM     F9YIG THRU F9YIG-FN.                             P050
710900     MOVE        S-ZONTRI TO LG10-ZONTRI.                         P060
711000     MOVE        S-ZONINF TO LG10-GRLG10-ARR.                     P070
711100     MOVE        W-WPD1-LGINFS TO W-WP00-LGINFS.                  P080
711200     PERFORM     F9Z THRU F9Z-FN.                                 P090
711300 F8DBN-FN. EXIT.                                                  P090

Merci Nicolas pour l'information.

Eclater un fichier (de bordereaux) avec la commande awk

Il est fréquent qu'il faille découper un fichier en plusieurs morceaux (interfaces, éditions). Pour cela c'est la commande "grep" qui est la plus souvent utilisée.

Exemple : avec le fichier de bordereaux ${FIC} suivant,

000000000HRMYI11                                  *FZD00                       0HRMYI11
000000000HRMYI12                                  *FZD00                       0HRMYI12
000000000HRMYI21                                  *FZD00                       0HRMYI21
000000000HRMYI22                                  *FZD00                       0HRMYI22
000000000HRMYI31                                  *FZD00                       0HRMYI31
000000000HRMYI32                                  *FZD00                       0HRMYI32
000000000HRMYI41                                  *FZD00                       0HRMYI41

Si l'on souhaite éclater le fichier suivant suivant le code du répertoire réglementaire (YI1, YI2, ... en colonne 13 sur 3 caractères) il est nécessaire :

• De lister les valeurs du code (découpage, tri et élimination des doublons) :

   cut -c13-15 ${FIC} | sort -u

• De boucler pour chaque valeur de code

   while ... do ... done

• D'extraire les bordereaux pour chacun des codes dans un fichier ${FIC}.${CODE}

   grep "^000000000HRM${CODE:-   }" ${FIC} > ${FIC}.${CODE}
        NB : ${CODE:-   } permet d'attribuer par défaut la valeur "   " à CODE

Soit :
rm -f  ${FIC}.* # Purge prealable
cut -c13-15 ${FIC} | sort -u | while read CODE
do
   grep "^000000000HRM${CODE:-   }" ${FIC} > ${FIC}.${CODE}
done

L'inconvénient est qu'il faut exécuter la commande "grep" autant de fois qu'il y a de valeur au critère d'éclatement. Quand le fichier est volumineux, le traitement peut être long (si un grep met 1 minutes, 10 greps prendront 10 minutes).

Une solution : la commande awk. Celle ci permet d'obtenir le même résultat en une passe :

rm -f  ${FIC}.* # Purge prealable
awk "{CODE=substr(\$0,13,3); print \$0 > \"$FIC.\"CODE }" ${FIC}

• CODE=substr permet d'extraire les caractères 13 à 15 de chaque bordereaux et de les stocker dans la variable CODE,
• print $0 écrit le bordereau,
• > "$FIC."CODE redirige l'écriture dans des fichiers suffixés par CODE,
• Tout est dans l'utilisation de quotes doubles pour que les variables Unix dans le script awk soient interprétées, et dans la mise en place des caractères "\" protégeant les champs et les quotes propres au "awk"...

Supprimer des processus consommateurs sur le système Unix

La commande "ps" permet de lister les processus actifs. Ceux consommateurs de puissance on un "C" supérieur à zéro. Ceux TRES consommateurs ont un "C"proche de 100.

Exemple avec les processus du compte Unix "hradev" (utilisez "ps -efl" pour les voir tous) :
ps -flu hradev
F S UID         PID    PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
0 S hradev      998       1  0  79   0 - 589377 387239 05:45 ?       00:00:31 /usr/local/java/jre1.5.0_22/bin/...
1 S hradev      5498      1  0  76   0 - 12487 339348 05:45 ?        00:00:00 AP0
0 R hradev      8115  20450  0  76   0 -   732 -      10:09 pts/1    00:00:00 ps -flu hradev
4 S hradev      20450 20449  0  75   0 -   581 -      08:12 pts/1    00:00:00 -pdksh
0 S hradev      28408 30058  0  76   0 - 12208 354116 10:00 ?        00:00:01 /hradev/bin/RTSDGN TYBXBHR
0 S hradev      30058     1  0  76   0 - 593166 322567 05:45 ?       00:00:24 /usr/local/java/jre1.5.0/bin/...

Pour repérer les processus très consommateurs, filtrez sur la colonne "C" :

ps -efl | awk '($6 != 0) {print $0}'
F S UID        PID  PPID  C  PRI  NI ADDR SZ WCHAN  STIME TTY      TIME       CMD
0 R hraqua    21895 21867 99  87   2 -  1400 -      Sep19 ?        1-15:30:47 awk -v FicIn=/hraqua/txt...

On voit ici un processus de hraqua actif depuis 1 jour et 15 heures ... On peut penser qu'il s'agit d'un processus "fou". S'en assurer auprès des développeurs et administrateurs avant de décider de le supprimer.

La commande vmstat indique une consommation CPU par la machine d'environ 25% (additionner les CPU user et sys - ne pas considérer la 1ère ligne qui est une moyenne) :

vmstat 2 5
procs -----------memory----------   ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache     si   so    bi    bo   in    cs us sy id wa
 1  0 358952 958104  49420 13338560    2    2   376   328    6     4 15 10 65 10
 1  0 358952 954488  51716 13338864    0    0     0   776 1175  2955 14 12 72  2
 1  0 358952 954552  51812 13338768    0    0     0   358 1030  2859 13 12 74  1
 1  0 358952 954488  51900 13338680    0    0     0   322 1034  2845 13 12 74  0
 1  0 358952 954680  51988 13338592    0    0     8   336 1054  2912 13 12 73  2

On tue avec hraqua le processus fou :
kill 21895

La CPU est libérée :
vmstat 2 10
procs -----------memory----------   ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache     si   so    bi    bo   in    cs us sy id wa
 1  0 358952 952592  54268 13340472    2    2   376   328    6     4 15 10 65 10
 0  0 358952 952528  54356 13340644    0    0     4   270 1038  2744  0  0 98  2
 0  0 358952 952592  54436 13340564    0    0     0   270 1031  2699  3  0 96  1
 0  0 358952 952560  54516 13340484    0    0     0   242 1030  2701  0  0 99  1
 0  0 358952 952432  54604 13340656    0    0     0   216 1034  2653  0  0 99  1

EXCLU CAR CE DOSSIER OU UN AUTRE DU MEME EMPLOYE EST SELECTIONNE DANS UN CALCUL DE PAIE CONCURRENT

Ce message apparaît avec HRv7. Il signifie qu'un autre calcul de paie K3W a déjà sélectionné ce dossier.

Toutefois, si certains de vos dossiers sont systématiquement exclus de la paie :

• Contrôlez qu'une paie n'est pas déjà en cours,
• Si une paie tourne, mettez vous d'accord avec son instigateur,
• Si cette paie est en boucle, tuez la (sous Unix, commande kill) puis passez à l'étape suivante,
• S'il n'y a pas de K3W actives, contrôlez la table TP33. S'il existe des occurrences avec POPULS valorisé à "K3W", nettoyez les :

DELETE FROM TP33 WHERE POPULS='K3W'

Lancer des calculs de paie en parallèle

Sur les systèmes Unix, un processus est lié à un processeur. Aussi un batch consommateur n'utilisera qu'une partie de la puissance de la machine, ceci au détriment de son temps de traitement. Si l'applicatif le permet, il peut donc être avantageux de "couper" le batch en plusieurs et d'exécuter ceux ci en parallèle. Cette problématique est particulièrement vraie pour le calcul de paie dès que l'on possède plus de 10.000 dossiers actifs.

Depuis HRv7, avec la chaine de paie K3W et le stockage des résultats dans les tables du PRDB, paralléliser le calcul est très simple :

• créez n dossiers de demandes "Opération" pour K3W, et dans chacune d'entre elles, 
• indiquez un "identifiant de job" différent (il sert de suffixe au fichiers de travail - sans cela vous rencontrerez des erreurs de type "file locked"),
• précisez des populations de travail complémentaires mais disjointes (sans quoi vous aurez des messages "EXCLU CAR CE DOSSIER OU UN AUTRE DU MEME EMPLOYE EST SELECTIONNE DANS UN CALCUL DE PAIE CONCURRENT"),
• soumettez les demandes.

L'ordre de sélection des populations de travail peut être basé sur un critère fonctionnel (par exemple sur la codification des matricules, le statut, la société ...) ou technique : il est assez pratique de prendre comme critère le NUDOSS lui même : on précise via la fonction MODULO dans quelle population un dossier est traité.

Exemple :

• Population 1 sur 2 : NUDOSS pairs

SELECT NUDOSS FROM ZY00 WHERE MOD(NUDOSS,2)=0

• Population 2 sur 2 : NUDOSS impairs

SELECT NUDOSS FROM ZY00 WHERE MOD(NUDOSS,2)=1 

Analyser les temps de traitement des fonctions Cobol avec le "Profiler"

Cobol offre un analyseur de temps de traitement. Ci joint un lien vers un article de la Micro Focus Community.

Pour l'activer il faut compiler l'exécutable avec une option particulière, lancer le traitement puis extraire les résultats obtenus :

• Modifier le .profile pour exporter, dans en fin de chapitre "VARIABLES D'ENVIRONNEMENT COBOL" la variable COBPRFDIR=$TMPDIR
• Faites une RBZ du programme à analyser avec conservation des sources

Conservation des fichiers de compilation (0/1)  [0]: 1

• Dans $TMP contrôlez la présence des fichiers *.idy et *.cbl
• Retrouvez (dans le log de la RBZ) et adaptez la commande de compilation Cobol "cob"  pour y ajouter l'option -C PROFILE
• Recompilez le programme (exemple avec FFCALDBI) avec l'option -C PROFILE

cob32 -C nolist -vz -C ASSIGN=EXTERNAL ... -C COPYLIST -C NORESEQ -C PROFILE -U /hradev/txt/tmp/FFCALDBI.cbl

• Copiez le généré (suffixe ".so" en général - consulter ${SUFMOD}) dans $SIGACS/prod/gnt
• Conservez le fichier *.idy dans $TMP
• Si le programme concerné est un programme TP, faites un arrêt / démarrage de OpenHR,
• Exécutez votre traitement,

Une fois l'exécution du programme terminée, un fichier *.ipf est créé dans $TMPDIR,

• Pour en lire les données, utilisez la commande cobprof (ici avec une limitation a 25 lignes) :

cobprof FFCALDBI.ipf +LIST | head -25

Total time:    1517240 milliseconds.      Module called once.
% time      time   entries  ms/entry      paragraph
-------------------------------------------------------------------------------
 45.35    688110        26     26466      UTTDP424-XB0B0LEC-XY
 10.99    166750 308687680         0      UTTBPUUU-XB0BBL5J-NC
 10.87    164900 308678970         0      UTTBPUUU-XB0BBL5J-NE
 10.51    159450 308678970         0      UTTBPUUU-XB0BBL5J-NC-900
 10.32    156650 308678970         0      UTTBPUUU-XB0BBL5J-NE-FN
  5.90     89460       151       592      GIP-ECR-01
  0.95     14400  26188434         0      UTTBPUUU-XB0BBL5J-AF
  0.94     14280  26192800         0      UTTBPUUU-XB0BBL5J-AE
  0.93     14150  26188434         0      UTTBPUUU-XB0BBL5J-AE-900
  0.92     13930       340        41      GIPLEC-01
  0.78     11890  26188434         0      UTTBPUUU-XB0BBL5J-AF-FN
  0.13      1950     22757         0      F8LCD
  0.12      1770      5550         0      RECHJOUR-01
  0.09      1410       150         9      VALCOND-DS3
  0.07      1020   1587369         0      RECH-ZYX3-01
  0.06       920      8710         0      UTTBPUUU-XB0BBL5J-PA
  0.06       910       150         6      TRICOND
  0.05       820   1582719         0      RECH-ZYX3-02
  0.04       560       150         4      F5025-2
  0.04       550         1       550      F-SGR2-01-TDP401

NB : En cas de message "Open Fail on .idy for FFCALDBI.idy", c'est que le fichier *.idy a été perdu. Pour pouvoir utiliser cobprof il vous faut le recréer (commande cob).

Vous trouverez :

• Total time : temps CPU total
• paragraph : fonction cobol concernée,
• %time : pourcentage du temps total d'exécution passé dans ladite fonction,
• time : temps en ms
• entries : nombre de passages dans la fonction
• ms/entry : temps moyen par passage

Notez le "Module called once" : le programme a été exécuté une seule fois (les statistiques sont cumulées à chaque exécution - si vous ne souhaitez pas cela, vous devez supprimer/renommer le *.ipf avant chaque exécution).

Si une fonction appelle un sous programme, le temps de ce sous programme est comptabilisé dans la fonction - sauf si ce sous programme est lui même compilé avec l'option "PROFILE".

La validité des résultats fournis par cet utilitaire est toutefois sujette à caution ... En effet, dans mon exemple :

• UTTDP424-XB0B0LEC-XY est une fonction "vide" qui ne fait qu'un "perform" vers UTTBPUUU-XB0BBL5J ... qu'elle prenne 688 secondes pour 26 appels n'est pas compréhensible,
• et si le temps attribué à cette fonction cumule celui des fonctions performées, pourquoi voit-on alors plus bas des références à ces même fonctions UTTBPUUU-XB0BBL5J ?
• Mode "Profiler" activé le traitement complet dure 28 minutes, mais une fois ce mode désactivé (recompilation sans l'option -C PROFILE) le temps de traitement passe à 3 minutes !
• En fait le mode "Profiler" semble extrêmement sensible aux boucles (ici 300.000 passages dans chacune des fonctions UTTBPUUU-XB0BBL5J-NC/NE...) et ralentit significativement le traitement ...

En conclusion, si ce Cobprof vous donne la cause de vos problèmes de performance, tant mieux ... Mais regardez son analyse avec circonspection.

• Limitez son usage a des cas de "simples" (ex : un seul dossier traité).

• Contrôlez que les temps de traitement avec / sans le mode "Profiler" est inchangé.

PS : Pour supprimer ce mode "Profile", refaites une RBZ sur le module concerné.

BOP-BBAO0026-Un job est déjà en cours d'exécution avec le même identifiant

Depuis HRv7, le programme BOP contrôle qu'au démarrage une même chaîne n'est pas déjà en cours d'exécution.

Ces contrôles sont à la source des messages :
BOP-BBAO0026-Un job est déjà en cours d'exécution avec le même identifiant (BOP ou BI0)

BI0-BBAO0027 Un job est déjà en cours d'exécution avec le même identifiant &1 - traitement forcé
BI0-BBAO0028-Job vérouillé Identifiant &1

Les verrous

1. L'information ZO7L sert au verrouillage d'un cycle (et ZO7U : Libération d'un cycle). La table PG70 permet de mémoriser la présence d'un verrou.
2. En début de cycle, lors de la soumission du traitement, un contrôle est effectué sur la table PG70 pour le numero de travail soumis. Si aucun verrou n'est présent, alors la soumission est lancée et un verrou est posé.
3. En fin de cycle, si la phase s'est exécutée sans anomalie (code retour < 05), le verrou est levé.

A noter :

• En standard les NRA les K22 et en HRv7.0 les K2W posent un verrou. Les chaînes NRB et NRD les lèvent.
• Le contrôle peut bloquer un traitement si un verrou n'a pas été levé. Si vous utilisez un cycle assurez vous donc d'avoir demandé la libération du verrou dans la demande NRB/NRD (onglet "Libération du cycle") et que les deux demandes ont bien le même numéro de travail,
• Pour ne pas être bloquée, une soumission de NRA isolée déclenche un traitement BNA AA87L1NA qui passe la ZO7L-TEFORC à 1.
• Organisez les numéros de travail de vos demandes Opération. Si vous ne vous en sortez pas, mécanisez une purge régulière de la PG70 !

Les travaux en cours

Ce contrôle bloque car un dossier de travail ZO est "en cours" depuis moins de 24 heures.

• Fermez le en alimentant sa date de fin dans ZO2C par update SQL ou via le lien suivant :

(le javascript associé en profite pour alimenter dans la ZO2C-ZOSOUM la date et le code de l'utilisateur ayant forcé l'horodatage de fin du travail).
 

• Sinon supprimez le dossier de travail ZO concerné !

• Ou (si le traitement est lancé par un enchaînement) mettez le IDFJOB de la demande NRC à blanc (ou zéro) : BOP va alors l'incrémenter jusqu'à en trouver un libre  !

BOP-BBAO0003-DOSSIER INCONNU 538976288 - Corriger par update SQL les ZO2B.NUDODE déphasés

Sous HRv7
Les dossiers ZO des chaînes d'enchaînement NRC font référence aux demandes à enchaîner dans l'information ZO2B.
Ils stockent en ZO2B.NUDODE le NUDOSS de ces demandes.

Si vous livrez des dossiers ZO NRC par NOZ, les NUDODE des demandes appelées sont re-numérotées.
Si la demande n'est pas trouvée, le NUDODE sera passé à zéro.

Lors de l'exécution de la NRC, si des NUDODE sont nuls, le programme BOP va de nouveau rechercher les demandes pour corriger le dossier de travail.
S'il ne le trouve pas vous aurez une erreur BOP-BBAD0015-ERREUR D'ACCES ... : ZO00/8K/DD/SELECT/000000000000100

Il peut toutefois arriver que les NUDODE de la ZO2B ne soient plus en phase avec les NUDOSS des dossiers ZO concernés :

• Du fait d'un bug, il est parfois alimenté à 538976288, ce qui correspond à la valeur associée à un SPACE mis dans une variable numérique ...
• En cas de suppression et de recréation SQL d'un dossier de demande ZO référencé par une NRC (en TP un traitement empêche la suppression d'une demande référencée).

Dans le "meilleur" des cas, le NUDODE pointe sur un dossier inexistant.
Vous aurez alors l'erreur BOP-BBAO0003-DOSSIER INCONNU

En revanche si le NUDODE pointe sur un NUDOSS attribué à une autre demande que celle prévue ...
Vous aurez des surprises (ex : imaginez si une NRB s'exécute à la place d'une NBX) !

Pour faire un constat, exécutez :
select ZO2B.NUDOSS, ZO2B.NUDODE, ZO2B.CDPH01, ZO2B.IDREQU, ZO2B.CDELMT, ZO2B.LIBEDE,
 '<->', ZO00.CDPHAS, ZO00.CDPHAS, ZO00.IDREQU, ZO00.CDELMT, ZO00.LISOUM
 from ZO2B LEFT OUTER JOIN ZO00 on ZO2B.NUDODE=ZO00.NUDOSS
 where ((ZO2B.CDPH01<>ZO00.CDPHAS or ZO00.CDPHAS is null)
   or (ZO2B.IDREQU<>ZO00.IDREQU or ZO00.IDREQU is null)
   or (ZO2B.CDELMT<>ZO00.CDELMT or ZO00.CDELMT is null));

Ci joint un exemple d'update pour corriger ZO2B.NUDODE (pour Oracle) :
update ZO2B set ZO2B.NUDODE = (select coalesce(
         (select ZO00.NUDOSS from ZO00
            where ZO00.CDPHAS=ZO2B.CDPH01 and ZO00.CDELMT=ZO2B.CDELMT and ZO00.IDREQU=ZO2B.IDREQU
              and ZO00.FLGJOB='0' and ZO00.TISOUM='0001-01-01-00.00.00'),0)
         from DUAL);

(Pour DB2 remplacez DUAL par SYSIBM.SYSDUMMY1)

Livrer une mise en page spécialisée

Un objet "Mise en page spécialisée" concerne la mise en forme d'un état batch (PDF, HTML, CSV ...).

Sur l'environnement source, il faut "déployer" l'objet (avec HRv5 le terme utilisé est "mettre en exploitation").

Cette action va créer un dossier ZO avec CDPHAS='NPM', IDREQU=' ', FLGJOB='0' et CDELMT égal au code de l'objet concerné (avec HRv5, remplacer IDREQU=' ' par SUFXDM=' ' et FLGJOB='0' par TISOUM='0001-01-01').

• Les données de déploiement sont à livrer sur la cible (par une NOY/NOZ sur le dossier ZO concerné).
• Livrer l'objet est utile (pour les besoins de suivi et de maintenance à chaud) mais pas indispensable : l'objet n'est pas utilisé lors de l'exécution de la mise en forme par le serveur de Query.

Il peut être nécessaire d'évaluer les "références croisées", car la description de cette mise en page peut être "copiée" par des dossier de demande ZO de chaînes batchs (exploration, paie) : ZO4T (champs CDPHAS CDELMT TIMODI TERAFR) et ZO4C (CDMEPA TYPOUT NULINE ZONVAR).

Vous pouvez retrouver les demandes ZO utilisant vos mises en page par une requête sur la table ZO3P :

Avec HRv5
select CDPHAS,CDELMT,SUFXDM,LISOUM,CDMEPA from ZO00,ZO3P where ZO00.NUDOSS=ZO3P.NUDOSS and TISOUM='0001-01-01' and SUFXDM <> ' ' and CDMEPA <> ' ' order by CDMEPA

Avec HRv7
select CDPHAS,CDELMT,IDREQU,LISOUM,CDMEPA from ZO00,ZO3P where ZO00.NUDOSS=ZO3P.NUDOSS and FLGJOB='0' and IDREQU <> ' ' and CDMEPA <> ' ' order by CDMEPA

• Sur la source rafraichissez le(s) dossier(s) de demande ZO utilisant vos mises en page puis  les livrer.

Un écran dans HRaSpace permet de faire ce "refresh" : Outils d'administration, Configurer les travaux batch, Rafraichissement des objets (en HRv5 dans "Assistant de Gestion")

Equilibrage de charge entre un Apache et deux HRaSpace v7 sous Tomcat

L'objectif est de faire en sorte que Apache répartisse les utilisateurs sur deux serveur Tomcat . Ceci peut être utile pour répartir la charge (load balancing) et sécuriser l'exploitation (crash d'un des serveurs). En revanche, il faudra livrer les mises à jour de l'arborescence du client riche sur chacun des serveurs. Cette configuration n'est donc adaptée qu'aux environnements sans publication par HRStudio.

La configuration initiale du site est la suivante :

• un Apache en frontal,
• un Tomcat avec son application HRaSpace v7,
• une base JetSpeed déportée sur l'instance DB2 de HR Design.

A noter :

• si un des Tomcat "tombe", HRAccess n'assure pas la persistance de la session des utilisateurs. Ceux initialement affectés au Tomcat défaillant seront basculés sur le rescapé où ils devront se ré-authentifier (ce n'est pas une configuration de "cluster" avec réplication de session).
• Apache a été compilé avec le module proxy_balancer (présence du fichier /hraxxx/apache/modules/mod_proxy_balancer.so et dans httpd.conf : LoadModule proxy_balancer_module modules/mod_proxy_balancer.so)

• L'expérience montre qu'un schema JetSpeed unique est suffisant.

Coté Tomcat

Mise en place d'un second tomcat et son fichier de configuration :

• fermeture et copie de l'arbo tomcat /hraxxx/hraspace dans /hraxxx/hraspace.balancer, 
• dans le server.xml du nouveau Tomcat, les ports 5208* sont modifiés en 5209* (pour mon test les Tomcat sont "côte à côte" sur le même serveur. Installés sur deux machines distinctes, cette modification serait inutile).

•  Définition des Routes dans les fichiers "server.xml" de chaque Tomcat :

    <!-- Define the top level container in our container hierarchy
    <Engine name="Catalina" defaultHost="localhost">
    -->

    <Engine name="Catalina" defaultHost="localhost"
    jvmRoute="route1" debug="0">

(et route2 pour le second Tomcat)

Coté Apache

Fermer Apache, puis dans le extra/httpd_hraccess.conf de mon Apache (mon httpd.conf inclue cet extra) :

• Mise en commentaire du routage initial (Tomcat unique) :

# Single local Tomcat
# ProxyPass /  ajp://localhost:52085/
# ProxyPassReverse /  ajp://localhost:52085/

• Mise en place du "répartiteur" avec Proxy balancer,
• Redirection de chacune des application HRaSpace (merci Stéphane pour le tuyau) sur le cluster  par ProxyPass,
• Avec stickysession (pour que les requêtes de l'utilisateurs "restent" dirigées sur le serveur qui lui a été attribué lors de sa première transaction),
• Correction avec ProxyPassReverse des messages retournés pour rétablir l'entête initial :

# Load balancing two local Tomcats

<Proxy balancer://HRaCluster>
   BalancerMember ajp://localhost:52085/ loadfactor=1 route=route1
   BalancerMember ajp://localhost:52095/ loadfactor=1 route=route2
   # byrequests / bytraffic / bybusyness
   # ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass        /hra-space balancer://HRaCluster/hra-space stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hra-space balancer//localhost:52085/hra-space
ProxyPassReverse /hra-space balancer//localhost:52095/hra-space
ProxyPass        /hr-dms    balancer://HRaCluster:52083/hr-dms stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-dms    balancer//localhost:52085/hr-dms
ProxyPassReverse /hr-dms    balancer//localhost:52095/hr-dms
ProxyPass        /hr-rich-client balancer://HRaCluster:52083/hr-rich-client stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-rich-client balancer//localhost:52085/hr-rich-client
ProxyPassReverse /hr-rich-client balancer//localhost:52095/hr-rich-client
ProxyPass        /hr-portlets    balancer://HRaCluster:52083/hr-portlets stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-portlets    balancer//localhost:52085/hr-portlets
ProxyPassReverse /hr-portlets    balancer//localhost:52095/hr-portlets
ProxyPass        /hr-self-service balancer://HRaCluster:52083/hr-self-service stickysession=JSESSIONID|jsessionid nofailover=OnProxyPassReverse /hr-self-service balancer//localhost:52085/hr-self-service
ProxyPassReverse /hr-self-service balancer//localhost:52095/hr-self-service
ProxyPass        /hr-configuration-tool-web balancer://HRaCluster:52083/hr-configuration-tool-web stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-configuration-tool-web balancer//localhost:52085/hr-configuration-tool-web
ProxyPassReverse /hr-configuration-tool-web balancer//localhost:52095/hr-configuration-tool-web
ProxyPass        /hr-admin-console balancer://HRaCluster:52083/hr-admin-console stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-admin-console balancer//localhost:52085/hr-admin-console
ProxyPassReverse /hr-admin-console balancer//localhost:52095/hr-admin-console
ProxyPass        /hr-online-query  balancer://HRaCluster:52083/hr-online-query stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-online-query  balancer//localhost:52085/hr-online-query
ProxyPassReverse /hr-online-query  balancer//localhost:52095/hr-online-query

ProxyTimeout 300

Coté Objet Site HRS

Créer une seconde fonction "Serveur Web" pour pouvoir accéder au second Tomcat sur la console d'administration Web de HRaSpace (je vois que l'on peut créer des "Cluster" de serveur Web mais je n'en connais pas les implications ... A tester).

Pour finir

• Un lien sur la doc Apache :http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

• Noter que le "balancer" Apache a sa propre console : http://mon.serveur.apache:52000/balancer-manager

 
• Vous pouvez tester la répartition en altérant le loadfactor puis en contrôlant avec la console ou par consultation des logs sur quel Tomcat vous êtes redirigé.
  

Corriger par update SQL les ZX00.NUGEST déphasés

Si vous chargez des dossiers ZY et ZX par NOZ sur un environnement possédant déjà des dossiers, il y a de fortes chances que les NUDOSS ZY d'origine soient re-numérotés.Du coup, les NUGEST ZX ne seront plus en phase avec les NUDOSS des dossiers ZY concernés.

Pour faire un constat, exécutez :
select
ZX00.NUDOSS, ZX00.NUGEST, ZX00.SOCCLE, ZX00.MATRIC, ZY00.SOCCLE, ZY00.MATCLE
from ZX00 LEFT OUTER JOIN ZY00 on ZX00.NUGEST=ZY00.NUDOSS
where (
    (ZX00.SOCCLE<>ZY00.SOCCLE or ZY00.SOCCLE is null)
    or
    (ZX00.MATRIC<>ZY00.MATCLE or ZY00.MATCLE is null))

Ci joint un exemple d'update pour corriger ZX00.NUGEST.

Pour Oracle
update ZX00 set ZX00.NUGEST = (
  select coalesce( 
    (select ZY00.NUDOSS from ZY00 where ZX00.SOCCLE=ZY00.SOCCLE and ZX00.MATRIC=ZY00.MATCLE)
    ,0)
    from DUAL);

Pour DB2 remplacez DUAL par SYSIBM.SYSDUMMY1

A noter : Avec cet ordre SQL, les dossier ZX sans correspondance avec des matricules ZY auront un NUGEST nul.

 SQL> select nugest from zx00;
       181
 SQL> select soccle,matric,nugest from zx00;
 SOC MATRIC           NUGEST
 - - - - - - - - - - - - - - - - - -
 FRR FRP1047             181

 SQL> select nudoss,soccle,matcle from zy00 where nudoss = 181;
 no rows selected

 SQL> update ZX00 set ZX00.NUGEST = (select coalesce((select ZY00.NUDOSS from ZY00 where ZX00.SOCCLE=ZY00.SOCCLE and ZX00.MATRIC=ZY00.MATCLE),0) from DUAL);
 1 row updated.

 SQL> select soccle,matric,nugest from zx00;
 SOC MATRIC           NUGEST
 - - - - - - - - - - - - - - - - - -
 FRR FRP1047               0

grep et message "Fichier binaire ... concorde"

Vous utilisez la commande "grep" sur un fichier texte et celle ci répond "Fichier binaire ... concorde" au lieu de vous afficher les lignes concernées. Ceci est du au fait que la commande a estimé que le fichier était de type "binaire", donc non affichable.  

Forcez le type du fichier en utilisant une des options suivantes :

grep -a
grep --text
grep --binary-files=text.