Automatiser les traitements HR avec RBB

Depuis HRv5 l’utilisateur peut demander l’« Activation » de demandes Opération. Toutefois l'ensemble des fonctionnalités n'est vraiment présent qu'avec HRv7. Les détails ci dessous ...

Seul manque encore l'automatisation des lancement chaque minute. Peut être que le serveur de Query - qui prend déjà en charge l'envoi des mails - se verra-t-il dans le futur attribuer cette tâche ?

L'interface Web

Au niveau de la demande Opération, l’utilisateur peut préciser une fréquence et une date de première exécution du traitement batch.



L’activation (par soumission de la demande) provoque:

• Le déclenchement du script OPER, 
• Le programme BOB va « archiver » le script habillé de la chaîne à exécuter dans l’information ZO2S du dossier de demande, 
• Et « verrouiller » la demande opération qui n'est alors plus modifiable.

L’utilisateur peut consulter la liste des traitements « activés » voire en déprogrammer. 

 
 
L’exécution du traitement est déléguée à l’exploitant qui doit exécuter la chaîne RBB à fréquence régulière.

La chaîne RBB

La chaîne (script subbb) soumet TOUS les traitements dont la date d’activation dépasse la date système,

Pour lister les traitements en attente, passez par l'interface ou exécutez la requête suivante :
SELECT NUDOSS, TEDMAC, TIDMAC FROM ZO00         
WHERE  TEDMAC <> 'N' AND    TESOUD =  '1' 
ORDER BY TIDMAC,TEDMAC

Les étapes de la soumission sont les suivantes :

• subbb lance RBB (chaîne générée avec un processus Opération),
• Le programme BOD en boucle :

1. Ecrit pour la première demande trouvée la chaîne stockée en ZO2S dans $TMP/T120JS."$nupro"
2. Lance OPE2 (via XSNDJOB et job)
3. OPE2 exécute la chaîne définitive en arrière plan,
4. BOD reprend la main. En cas d’activation « périodique » il recalcule et met à jour automatiquement la date de la prochaine exécution dans la demande ZO, 
5. puis passe à la demande suivante.

Pour que tout fonctionne de manière transparente il est nécessaire d'automatiser l'exécution régulière de la chaîne RBB (par exemple par crontab). Au vu du fonctionnement standard, la fréquence d'exécution doit être la minute.

Si vous souhaitez les espacer plus (10 ou 30 minutes par exemple), je pense préférable de modifier OPE2 pour que les traitements se déclenchent en avant plan (ce qui évite la concurrence de traitements incompatibles ou dépendants) :

nohup ksh $TMP/JS."$NUMJOB" > $TMP/"$JOBLOG" 2>&1 &
CODE_RETOUR=$?
PID=$!

devient alors

ksh $TMP/JS."$NUMJOB" > $TMP/"$JOBLOG" 2>&1
CODE_RETOUR=$?
PID=$$

A noter : La chaîne RBB est compatible avec les enchaînements NRC.

Afficher une différence de dates en "heures minutes secondes" avec DAY TO SECOND (Oracle)

Christophe m'a indiqué cette fonction Oracle.
Elle permet d'afficher une différence de dates au format heures-minutes-secondes :

Exemple avec ce SELECT qui liste les traitements batch exécutés ce jour par ordre de durée d'exécution décroissante :

select CDPHAS,IDREQU,CDELMT,TIMDEB,TIMFIN,CDRET,(TIMFIN - TIMDEB) DAY TO SECOND(0) DELTA from ZO00,ZO2C where ZO00.NUDOSS=ZO2C.NUDOSS and FLGJOB='1' and CDRET <> ' ' and TIMFIN > trunc(SYSDATE) order by 7 desc ;

CDP IDREQU             CDELMT   TIMDEB              TIMFIN              CD DELTA
--- ------------------ -------- ------------------- ------------------- -- ----------------------------------------
NRB DIGIX                       2013-06-11-01.00.41 2013-06-11-01.06.26 01 +00 00:05:45
K2W DIGIX                       2013-06-11-12.07.52 2013-06-11-12.13.00 04 +00 00:05:00
NJ6 DIGIX                       2013-06-11-11.00.55 2013-06-11-11.02.45 01 +00 00:01:50

*GE01BMQ-00000000-BHS-92BJ/Unknown logical table name

Depuis HRv7 la chaîne RBN (création de population batch) ne sais plus accéder aux tables externes au produit et génère une erreur :
 
                                    Phase BN

Sélection SQL de la population :
select NUDOSS from ZY00 A, DIGIX B where A.NUDOSS = B.NUDOSS
 
*-------------------------- STEP120N ---------------------------*
*              Constitution d'une population batch              *
*---------------------------------------------------------------*
...
*GE01BMQ-00000000-BHS-92BJ/Unknown logical table name    /DIGIX


Idem pour les pré-sélections SQL dans les chaînes fonctionnelles - par exemple avec NRA :
*-------------------------- STEP120N ---------------------------*
*                 Pré-sélection des populations                 *
*---------------------------------------------------------------*
...
AS800BOV-BBAD0036-BOV (9P/HS) ERREUR DANS MODULE BHS : CODE RETOUR 99  - Unknown logical table name / DIGIX


BMP puis BMQ (respectivement BOV) font appel à BHS qui consulte BHH...
Et dans le squelette de BHH on constate que le nom des tables est contrôlé par rapport à une liste "en dur".

S'il faut accéder à une tables externe ... il ne reste plus qu'à la nommer (soit directement - soit via un synonyme) comme une information ou une table d'objet (ex : YY99 ou AP00) !

Automatiser les traitements HR avec RJ2

Depuis HRv7.1 HR Access offre en standard une chaine de soumission des demandes Opération : la chaîne RJ2 (dite "Lanceur universel"). Ce qui permet :

• D'exécuter un traitement à partir du système Unix,
• Sans avoir a renseigner de fichier paramètres,
• Tous les paramètres étant dans la demande ZO.

 L'objet principal de cette chaîne est de permettre l'interfaçage de HRAccess avec un ordonnanceur.

Prérequis :

• Avoir paramétré la/les demande(s) "Opération" à utiliser,
• Et comme le rappelle le Guide Technique - avoir généré les exécutables associés !

Ligne de commande Unix :
sh ${PSHL}/${RDOPER}RJ2 "${JSCRI}" "${IDREQU}" "${CDELMT}" "${TEXSER}" "${ROLMSB}" "${ROLVSB}"

avec :

• RDOPER le radical d'un de vos processus Opération (AS800, FP800 ou autre).
• JSCRI le nom de la chaîne (AS0FSNRA, FP800NBX, AS800NPQ ...)
• IDREQU le code de la demande Opération (à blanc pour les templates Query)
• CDELMT le code du query (en cas de template Query, à blanc sinon)
• TEXSER nom du verrou pour sérialisation - ne pas dépasser 25 caractères (carte PA4S)
• ROLMSB modèle de rôle à appliquer
• ROLVSB valeur de rôle à appliquer

A noter :

• La RJ2 n'est présente que sur les systèmes Unix et Linux,
• Seules les chaînes accessibles par Opération / l'Assistant de Gestion sont éligibles,
• La chaîne n'est pas compatible avec les "enchaînements" NRC,
• Une analyse des logs reste nécessaire car les codes retours sont parfois imparfaits - ou ne peuvent prendre en compte des appréciations d'ordre fonctionnel (des rejets dans une NRB sont-ils bloquants ? et une "population vide" ?),
• Second point capital : une gestion des mises à jour des paramètres des demandes Opération est à mettre en place. Car certains doivent évoluer - soit en fonction de la date système - soit du cycle de paie ...