Soumission de travaux par l’assistant de gestion

6 Juillet 2004


L'Assistant de gestion est une arborescence spécialisée de l'applicatif Web HR Access qui permet au gestionnaire de demander le lancement d'une chaîne de traitements batch.

L'objectif de cette page est de présenter comment le standard d'HR Access v5 gère la soumission de batch via l'interface graphique du module Opérations. Puis de voir quelles possibilités peuvent se présenter pour personnaliser le fonctionnement du module, illustrées d'exemples tirés de retours d’expériences

Concepts

  • Dossier de demande
Pour lancer un batch, un utilisateur a accès à des dossiers de demande. Ces dossiers de demande sont des formulaires de saisie de paramètres. Un utilisateur peut créer de nouveaux dossiers de demandes, ou utiliser des dossiers existants dont il n'est pas nécessairement propriétaire (en fonction des règles de confidentialité mises en place).
  • Phase
A un dossier de demande correspond une "Phase HR Access", c'est à dire un type d'opération fonctionnelle – par exemple NRA : "Export de données". Une phase fait parfois référence à plusieurs chaînes batch (par exemple pour NRA la chaîne d’ "Export de données d’unités organisationnelles" ou celle d' "Export de données de salariés"). Il est alors nécessaire de préciser en paramètre le processus HR Access à utiliser.
  • Dossier de travail
Une fois la demande soumise, le batch génère un dossier de travail. Celui-ci est un compte rendu destiné à recueillir les informations relatives à l'exécution de cette demande (codes retour, liste des états générés ...). Le dossier de travail appartient à l’utilisateur qui a soumis la demande et il est horodaté.
  • Processus
La demande soumise fait généralement référence à un processus. Celui-ci se présente sous la forme d'un code. Par exemple, le processus AS6FS : un certain type d'export de données - famille de batch NRA).
  • Exécutables
Le processus est physiquement composé d’une famille d’exécutables (programmes cobols, shells d'HR Access).
  • États
Les exécutables génèrent des logs, des états, émettent des codes de retour. Ceux-ci sont remontés dans le dossier de travail lors de chaque exécution.

Fonctionnement de "Opérations"

l'assistant de gestion

Grâce à des écrans spécialisés, le gestionnaire peut :
  • Saisir des paramètres de lancement,
  • Soumettre des demandes de lancement, 
  • Consulter les comptes rendus des travaux, parfois les états édités.
L'assistant de gestion propose une page Web par phase (la saisie des paramètres propres à chaque phase se fait sur des écrans spécialisés). Une fois saisi, un lot de paramètres constitue un "dossier de demande". La soumission du batch se fait sur une pop up banalisée. Une fois lancée, la chaîne créera un "dossier de travail" dans lequel se retrouveront les codes retours, messages, liens vers les états.

La plupart des chaînes du standard (techniques et applicatives) sont disponibles dans l'assistant de gestion.

Observations :
- Le vocabulaire de HR Access est parfois spécifique. Exemple : une "phase" signifie un type de "batch", une "soumission" une demande d'exécution ...
- Les pop-up de "recherche avancée" disposent souvent d'un nombre de critères insuffisants,
- La notion de dossiers de "demandes" (formulaire de paramètres) et de "travaux" (comptes rendus), n'est pas intuitive,
- Les paramètres à saisir sont parfois à destination d'un développeur plutôt que d'un fonctionnel (exemple pour la chaîne de mise à jour batch : chemin Unix au fichier de bordereau, Code processus, numéro de job …),
- Dans le menu de l'assistant de gestion, les chaînes de paie sont bien libellées pour un gestionnaire. En revanche, les chaînes "outils" (import / export de données, explorations) n'ont évidemment pas de libellé fonctionnel,
- L'arborescence Web HRv5 est "coupée en deux" et distingue la partie "demandes" de la partie "travaux" ce qui oblige à une navigation fastidieuse et à une double sélection de dossier
- Le contenu des travaux est plus destiné à un informaticien (liste de programmes, codes retours, logs) qu'à un gestionnaire,
- Le gestionnaire doit de lui même suivre le déroulement du batch. HR Access en standard ne l'informe pas de la fin du traitement automatiquement,
- Par défaut, la confidentialité est ouverte à tous. Un gestionnaire peut donc utiliser les demandes ou consulter les travaux crées par un autre utilisateur,

Le processus Opérations

L'assistant de gestion s'appuie sur des processus HR dits "Opérations" (FP800, JA800, AS800 …).


Ces processus sont de qualification GO. Ils possèdent en conséquence une liste de programmes très proches de ceux dits de gestion de dossier classiques (BNM, BNA, BNK, BNL …), à laquelle s'ajoute quelques programmes spécifiques à leur fonction :
  • BOT soumission de chaîne en conversationnel
  • BOB habillage de chaîne
  • BOP Initialisation de chaîne
  • BOU Invocation du serveur d'édition HR Query
  • BOV Résolution d'une sélection de population
  • BOW Liaison entre les explorations et le serveur HR Query
A cette qualification est aussi associée des phases particulières :
  • RBQ Epuration des demandes et travaux
  • NRC Soumissions enchaînées
  • NPQ Soumission d'un query
  • NBW Génération d'une exploration
  • NBX Soumission d'une exploration
Observations :
- Les processus AS800, FP800, JA800 ne disposent pas de la même liste de phases disponible. 

La structure de données Opérations

Le processus utilise en base une structure de données multi-type de nature "Opérations" appelée ZO.

Un type de dossier permet de décrire l'ensemble des paramètres nécessaires au lancement d'un type de chaîne donnée, sous forme d'informations obligatoires ou facultatives. On trouve par exemple un type de dossier correspondant à la chaîne d'exécution des explorations (NBX), un correspondant à la chaîne de Paie Normale (NJA), etc…

Un paramètre correspond à une information de la structure de données ZO. Par exemple,
  • DA Paramètres de la chaîne NJA,
  • DB Paramètres de la chaîne NJB,
Chaque type de dossier comporte en outre un certain nombre d'informations techniques dont la description physique ne doit pas être modifiée.

Pour les demandes (extrait) :
  • 00 Identification des dossiers 1D Horodatage de dernier traitement
  • 1M Nom de processus lancement groupé
  • 1P Nom de processus de la chaîne à lancer
  • 1S Demande de soumission
  • 1L Attributs de substitution passés à BOT
  • 1T Attributs de substitution technique
  • 1U Attributs de substitution du gestionnaire
  • 3X Attributs de conceptions
  • 3Y Attributs de gestion 
  • ...
Pour les explorations :
  • 5E Code exploration
  • 5V Groupes de valeurs
  • 5Z Paramètres explorations
  • 4*
Pour les templates et Query :
  • 4T Template associé
  • 5K Elément du template
  • 3P Etats prévus et mise en page associée
  • 4C Mise en page compilée
  • 5B Population batch compilée
  • 5Q Paramètres du query
  • 5C Query compilé
  • 5S Compléments sur les paramètres
  • 5T Description de la présélection
  • 5W Requête SQL de présélection
  • 5X Exploitation du query
Pour les enchaînements :
  • 2A Information enchaînement
  • 2B Etapes élémentaires
  • 2E Substitutions 
  • 2G Dossier enchaînement associé au travail
  • 2H Etape enchaînement
  • 2L Groupe étapes
  • 2M Compte-rendu du groupe d'étapes

Pour les travaux :
  • 2C Compte-rendu d'exécution d'une chaîne
  • 2D Display des Cobols
  • 2O Dossier de demande d'origine
  • 2P Codes retours des programmes
  • 2S Script activé à exécuter
  • 3Q Etats construits
  • 3L Contenu des lignes d'états stockés en base
Ces informations prennent la forme de tables dans la base de données. NB : les informations ZO00, ZO1A, ZO1C, ZO1D, ZO1S ayant le même "segment d'accueil" 00, leurs colonnes se retrouvent dans la table ZO00.
Les dossiers en base sont de 3 "natures" :
  • Dossiers template (pour HR Query), caractérisés par un horodatage de soumission et un code utilisateur vierges, ils peuvent être dupliqués pour initialiser des dossiers de demande,
  • Dossiers de demande, propriétés d'un utilisateur, et caractérisés par un horodatage de soumission vierge (ZO00-TISOUM = "0001-01-01-00.00.00"), ils sont utilisés pour saisir des paramètres à destination d'un batch,
  • Dossiers de travail, propriétés d'un utilisateur, et horodatés, ils contiennent les codes retours et horodatages des programmes Cobol exécutés, voire des éléments de log et de listing.
Le développement de la confidentialité sur les données de ZO suivent les mêmes principes que pour toute autre structure applicative (profils informations, populations). On pourra en particulier se baser sur :
  • ZO00-CDUSER : utilisateur créateur du dossier de demande / de travail
  • ZO00-CDDEST : utilisateur destinataire du Query
  • ZO3X : Attributs de conception (qualification technique du batch - ex : poids)
  • ZO3Y : Attributs de gestion (qualification fonctionnelle du batch - ex : domaine applicatif)
  • ZO3Q : Etats construits (codes des états, critères d'éclatement)

Observations :
- Les tables à vocation technique ont leur description en dur dans les squelettes des programmes Opération. Leur description ne peut donc pas être modifiée, même si HR Studio semble l'autoriser,
- La distinction entre "template", "demande" et "travail" n'est pas toujours évidente car basée sur le contenu de certains champs (code utilisateur, horodatage de soumission) et stocké dans le même jeu d'informations.

 

La soumission d'une chaîne par Opérations

La soumission (la demande d'exécution) se fait à partir du bandeau de l'interface, via une pop-up banalisée (activation de la coche "Soumission" puis validation de la saisie). Un message HR Access de demande de mise à jour du témoin ZO1S-TESOUD est alors transmis aux programmes serveur.

Observations :
- La pop-up de soumission est "compliquée" pour un utilisateur non averti,
- Le message d' "erreur" indiquant que la demande a bien été soumise est surprenant.

La soumission provoquera notamment :
  • Le positionnement à 1 du témoin de soumission (ZO1S-TESOUD), l'alimentation dans le dossier de demande de l'horodatage de soumission de la demande (ZO1S-TISOUD),
  • Via les programmes conversationnels, le déclenchement du programme BOT,
  • Ce programme exécute une séquence de shells (job, OPER) en leur transmettant notamment en paramètre le nom du batch demandé et l'identifiant du dossier de demande,
  • Ces shells copient et habillent le script batch demandé (via le programme BOB), et en exécutent la copie,
  • Le batch exécute le programme BOP pour basculer les paramètres stockés dans le dossier de "demande" en base dans des fichiers puis initialiser un dossier de "travail". Le batch continue par l'exécution de programmes spécialisés. Le dernier programme BLZ clôt le dossier de travail.

L'exécution est immédiate (le gestionnaire a aussi la possibilité de demander l' "activation" de la demande cf. chap. "Modes de soumission particuliers" pour que celle ci soit lancée en différé par l'exploitant).

  • Les programmes BNM, BNA, BNK
Ce sont les programmes gérant les demandes TP de mises à jour des données des dossiers de la structure ZO. En cas de demande de mise à jour de l'information ZO1T, ils vont contrôler la faisabilité de la soumission, préparer le dossier de demande (alimentation du témoin et de l'horodatage de soumission), puis le programme BNM appellera BOT.
  • Le programme BOT

Ce sous programme TP - appelé après les programmes BNA et BNK – récupère le radical de la chaîne à exécuter, lance le script $SIGACS/bin/job en lui transmettant en paramètre les cartes PA45, PA46 et PA47 (nom du batch demandé, identifiant du dossier de demande, contenu de l’information ZO1T …).

Les champs et cartes paramètres ont la description suivante :
OPER suivi des code plate forme, radical du processus Opération, Nom du shell à lancer, puis

PA45
- NUDOSX Numéro de dossier (c5 à 13)
- CDUSER Code utilisateur (c14 à 21)
- CDPROS Code processus (c22 à 26)
- TEMNRC Témoin de 'soumission enchaînée' (c27)
- LITRAV Libellé du travail (c28 à 67)
PA46 - NMJOBS Nom du job soumis (c5 à 12)
- CDCMPT Code comptable (c13 à 16) - champ de ZO1T
- NOCASI Numéro de casier (c17 à 20) - champ de ZO1T
- ZOCPTS Zone complémentaire (c21 à 24) - champ de ZO1T
- ZOCLEX Classe d'exécution (c25 à 36) - champ de ZO1T
- ZOCLIM Classe d'impression (c37) - champ de ZO1T
- NBIMPR Nombre d'impressions (c38) - champ de ZO1T
- CDIMPR Code imprimante (c39 à 50) - champ de ZO1T
- CDDEST Nom du destinataire (c51 à 58)
- CDPROS Nom du processus (c59 à 63)
- CDEXPL Nom de l'exploration (c64 à 69)
PA47 - ZOOPU1 Zone utilisateur opération (c5 à 12) - champ de ZO1T
- ZOOPU2 Zone utilisateur opération (c13 à 20) - champ de ZO1T
- ZOOPU3 Zone utilisateur opération (c21 à 28) - champ de ZO1T
- ZOOPU4 Zone utilisateur opération (c29 à 40) - champ de ZO1T
- ZOOPU5 Zone utilisateur opération (c41 à 52) - champ de ZO1T

La soumission du script job par le programme Cobol BOT est réalisée par un appel à une fonction C dédiée - cf. fonction XSNDJOB du source $SIGACS/adm/src/bhrsocket.c - de la manière suivante :

Extrait de $SIGACS/skel/pgm/XXXXXBOT :


086800* PARAMETRES D'ECHANGE AVEC 'XSNDJOB'
086900 01 7-JC00-IDENTX PICTURE X(8) VALUE "7-JC00".
087000 01 7-JC00-PARTAM.
087100 05 7-JC00-CDPARM PICTURE X(4).
087200 05 FILLER PICTURE X(76).
087300 01 7-JC00-DESJOB.
087400 05 7-JC00-CODPHA PICTURE X(4) VALUE "OPER".
087500 05 7-JC00-VALDAT PICTURE X(3) VALUE SPACES.
087600 05 FILLER PICTURE X(2) VALUE " '".
087700*!!! CDPLPH REMPLACE PAR CDUTIL DANS BIB. NTO !!!
087800 05 7-JC00-CDPLPH PICTURE X(8)
087900*<SUBRAD>CDPLPH.
088000 VALUE "%1".
088100 05 7-JC00-RDPROS PICTURE X(5)
088200*<SUBRAD>RDPROS.
088300 VALUE "%1".
088400 05 7-JC00-NMJCL.
088500 10 FILLER PICTURE X(8).
088600 05 7-JC00-NMOCCU PICTURE 9(2).
088700 05 7-JC00-PARDEM PICTURE X(80)
088800 OCCURS 10.
088900 05 FILLER PICTURE X(1) VALUE "'".
089000 05 7-JC00-TIMDAT PICTURE X(28).
089100 01 7-JC00-LNGJOB PICTURE S9(4)
089200 COMP VALUE +861.

174200*N9R. NOTE *************************************.
174300* * *
174400* *APPEL DU READER *
174500* * *
174600* *************************************.
174700 F9R. EXIT.
174800*N9RCD. NOTE *OUVERTURE DU READER *.
174900 F9RCD.
175000 MOVE WP00-NMJCL TO 7-JC00-NMJCL.
175100 MOVE ZERO TO 7-JC00-NMOCCU.
175200 F9RCD-FN. EXIT.
175300*N9RED. NOTE *ECRITURE DANS LE READER *.
175400 F9RED.
175500 MOVE W-WP00-ZOLJCL TO 7-JC00-PARTAM.
175600 IF 7-JC00-CDPARM = "PA45"
175700 OR 7-JC00-CDPARM = "PA46"
175800 OR 7-JC00-CDPARM = "PA47"
175900 ADD 1 TO 7-JC00-NMOCCU
176000 MOVE 7-JC00-PARTAM TO
176100 7-JC00-PARDEM (7-JC00-NMOCCU).
176200 F9RED-FN. EXIT.
176300*N9RHD. NOTE *FERMETURE DU READER *.
176400 F9RHD.
176500 EXEC SQL COMMIT END-EXEC.
176600 INSPECT 7-JC00-DESJOB
176700 REPLACING ALL LOW-VALUES
176800 BY SPACES.
176900 CALL "XSNDJOB" USING 7-JC00-DESJOB
177000 7-JC00-LNGJOB
177100 ON OVERFLOW GO TO F9RXD.
177200 F9RHD-FN. EXIT.


Extrait de $SIGACS/adm/src/APJ.c :

#define MONITEUR_JOB "sh $SIGACS/bin/job "
#define LNG_MONITEUR 19

/*** */
/*** XSNDJOB : lancement des jobs */
/*** ======= */
/*** */
void XSNDJOB(Nomjob,Ljob)
char *Nomjob; /* commande a executer */
short *Ljob; /* longueur du nom du job (pointeur sur ...) */


Tant que le batch n'a pas réellement démarré, la demande peut être annulée par saisie de la coche d'annulation ZO1C-TECANC dans le dossier de demande.

Observations :
- Il est matériellement impossible de disposer du temps nécessaire pour annuler une soumission de demande avant son exécution,
  • Le script job
Le script job réceptionne les paramètres de soumission de BOT ou des scripts de soumission Unix (scripts subxx du répertoire $SIGACS/bin). A réception d'une demande Opération, ce shell lance le script OPER du répertoire $SIGACS/bin en tâche de fond (utilisation de la commande "batch" ~ "at now -qb"), et lui passe les cartes paramètres.

Ce script écrit un log : $TMP/a.batch non cumulatif (écrasé par la dernière soumission).

Exemples de paramètres transmis à OPER pour la soumission du shel FD0MJRBM :

PPZC6DEVAS800FD0MJRBM03
PA45656679947DIGIX   FD0MJ
PA46 ...  FD0MJ
PA47

  • Le script OPER et le programme BOB
Le script OPER réceptionne et formate les cartes PA45, PA46 et PA47 pour le programme BOB puis exécute celui-ci. Ce programme lit le shell à soumettre (de $SIGACS/prod/shl) pour en faire une copie (dans $SIGACS/txt/tmp) habillée et suffixée :
- Substitution de la carte PA49 du shell standard par la PA45 réceptionnée,
- Substitution des paramètres d'habillage par leur contenu (par exemple, £US = code utilisateur, £ND = numéro de dossier de demande).
- Pour certaines chaînes, quelques paramètres de substitution peuvent être alimentés par l'utilisateur dans l'information ZO1T ou ZO1I du dossier de demande.

Puis OPER lance la copie habillée de la chaîne.
Ce script écrit un log : $LOG/OPER.$nupro (pid Unix)

Exemples de tags habillés par BOB présents dans le shell $SIGACS/prod/shl/FD0MJRBM :


then
echo "*-------------------------- STEP050A ---------------------------*"
echo "* Chargement de paramètres dans T050PA *"
echo "*---------------------------------------------------------------*"
echo "PA490 "\ devient PA45
>$TMP/T050PA."$nupro"
echo "\n"
fi

echo "\n"
fi
TOFMVTS=M-#OR
##*<DEBJCL>*FT* <-si fichier fixe à trier
if [ ! "$TOFMVTS" ] || [ "$TOFMVTS" != "L" ]; then
TOFMVTS="R"; fi
if [ "$TOFMVTS" = "R" ] ; then
if
[ $MAX_RETOUR -le 4 ]
then
echo "*-------------------------- STEP120N ---------------------------*"
echo "* Tri des mouvements en entrée *"
echo "*---------------------------------------------------------------*"
SORTIN=£FI <- nom du fichier

export SORTIN
SORTOUT=$TMP/T120OUT."$nupro"
export SORTOUT



L'exécution d'une chaîne soumise par Opération

La chaîne écrit un compte rendu dans $LOG, et indique ses horodatage de début et fin d'exécution dans $SIGACS/file/RES.

Une fois que le batch a démarré, le traitement peut être stoppé par saisie de la coche d'annulation ZO1C-TECANC dans le dossier de travail. L'arrêt sera effectif après la fin du programme en cours.

Observations :
- Le fichier RES est dans le principe intéressant mais son formatage le rend difficilement utilisable : les horodatages de début et de fin de traitement sont sur des lignes différentes,
- La plupart des chaînes HR Access ont comme défaut de ne pouvoir être soumises en parallèle du fait de contentions fichiers. Par exemple :
     . Lors de la paie à la demande – NJL – le fichier concaténant les résultats de calcul du mois est écrasé à chaque exécution. En cas d’exécutions simultanées de plusieurs instances de la chaîne, le fichier peut être perdu,
     · Les chaînes d’extraction de bordereaux – NRA – génèrent un fichier (PSBBI101/2/3/4/5/6/7/8/9) dont le nom n’est pas paramétrable. En cas d’exécutions simultanées de plusieurs instances de la chaîne, le fichier peut être perdu,
     · Les chaînes de chargement batch – NRB et RBM – utilisent des fichiers temporaires de nom fixe (PSBBBMM1/2/7). En cas d’exécutions simultanées de plusieurs instances d’une des chaînes, le résultat est aléatoire (arrêt brutal d’une des chaînes, double arrêt brutal, chargement en double),
-  Certaines chaînes – NJU, NJT (chargement du PRDB), NRC (enchaînements), NRD (chargement de l’infocentre) – soumettent des chaînes filles via une mécanique particulière : exécution d’un programme BSC avec en paramètre en table PG20 le nom de la chaîne fille à habiller et soumettre. L’alimentation simultanée de plusieurs instances de ces chaînes peut générer des contentions sur la table (la clef étant le code du processus HR Access concerné).
  • Le programme BOP
Utilisant le paramètre PA45, il contrôle le dossier de demande, crée le dossier travail par copie du dossier de demande, libère le dossier de demande, puis bascule les informations paramètre de ce dossier travail dans ses différentes sorties fichier après les avoir reformatées sur 80 caractères (sorties 0 à 9),

Le programme BOP :
- Vérifie que la demande existe (l'identifiant de la demande est transmis au programme via la carte paramètre PA45). Si BOP rencontre une carte PA49 au lieu de la carte PA45, cela signifie pour lui que les paramètres ne sont pas saisis dans un dossier de demande, mais dans un fichier paramètre (cf. chap. "Modes de soumission particuliers")
- S'assure que pour le dossier de demande, les témoins de soumission ou d'activation sont topés (ZO1S-TESOUD, ZO1A-TEDMAC) et que le témoin de cancel est vierge (ZO1C-TECANC),
- Réinitialise les témoins de soumission, d'activation ou de cancel de la demande pour la libérer,
- Initialise un dossier de travail (nb : il n'est pas possible de prendre la main sur le numéro de dossier attribué - voir pour les risques d'attribution de clé en double)
- Boucle sur la liste des informations stockant les paramètres pour en basculer le contenu dans des fichiers.

Cette bascule des paramètres est permise par l'indication dans la chaîne batch du lien entre les informations paramètre et les fichiers temporaires (enregistrements dans l'entrée PB de BOP, alimenté par exemple à 25S2 pour le BOP de la chaîne RBM : information ZO25, Sortie fichier S2). Les traitements de BOP formatent ensuite les sorties fichier (par exemple, le traitement AA 8251OP lit l'information ZO25 pour écrire une carte PA25).

Exemples d'appel de paramètres dans le shell $SIGACS/prod/shl/FD0MJRBM :


echo "*-------------------------- STEP050B ---------------------------*"
echo "* Chargement de paramM-htres dans T050PB *"
echo "*---------------------------------------------------------------*"
echo "50S0PA52EBBBM 1 0001 " >$TMP/T050PB."$nupro"
echo "24S1 " >>$TMP/T050PB."$nupro"
echo "25S2 " >>$TMP/T050PB."$nupro"
echo "26S3 " >>$TMP/T050PB."$nupro"
echo "87S4 " >>$TMP/T050PB."$nupro"
echo "88S4 " >>$TMP/T050PB."$nupro"
echo "93S6 " >>$TMP/T050PB."$nupro"
echo "50S7PA52EBBBW 1 0001 " >>$TMP/T050PB."$nupro"
echo "50S8PA52EBBBV 1 0001 " >>$TMP/T050PB."$nupro"
echo "50S9PA52EBBBY 1 0001 " >>$TMP/T050PB."$nupro"
echo "\n"

Exemples de traitement AA8251OP de bascule de l'information ZO25 dans le fichier paramètre :

------------------------------------------------------ AA
* -------------- PARAMETRE PA25 ----------------
*
01 U-PA25.
05 U-PA25-CDSTRC PICTURE X(04).
05 U-PA25-NUMJOX.
10 U-PA25-NUMJOB PICTURE 9(09).
05 U-PA25-NUPART PICTURE X(01).
05 U-PA25-TYANOM PICTURE X(01).
05 U-PA25-TELG10 PICTURE X(01).
05 U-PA25-TESIMU PICTURE X(01).
05 U-PA25-POERRE PICTURE X(01).
05 U-PA25-TYFONC PICTURE X(01).
05 FILLER PICTURE X(61).
------------------------------------------------------ AA
N TRAITEMENTS INFO 25 10 IT UT-CDINFO = "25"
* DECOUPAGE PARAMETRE PA25 DE BMM
M UT-ZOSP80 U-PA25
M "PA25" U-PA25-CDSTRC
M 2-ZO25-NUMJOB U-PA25-NUMJOB 99 IT U-PA25-NUMJOX = SPACES
M 2-ZO25-NUPART U-PA25-NUPART 99 IT U-PA25-NUPART = SPACES
M 2-ZO25-TYANOM U-PA25-TYANOM 99 IT U-PA25-TYANOM = SPACES
M 2-ZO25-TELG10 U-PA25-TELG10 99 IT U-PA25-TELG10 = SPACES
M 2-ZO25-TESIMU U-PA25-TESIMU 99 IT U-PA25-TESIMU = SPACES
M 2-ZO25-POERRE U-PA25-POERRE 99 IT U-PA25-POERRE = SPACES
M 2-ZO25-TYFONC U-PA25-TYFONC 99 IT U-PA25-TYFONC = SPACES
M U-PA25 UT-ZOSP80
GFC
 

Exemples de PA49 habillée en PA45 dans le shell FD0MJRBM:

echo "*-------------------------- STEP050A ---------------------------*"
echo "* Chargement de parametres dans T050PA *"
echo "*---------------------------------------------------------------*"
echo "PA45656679947DIGIX   AS907 "\
>$TMP/T050PA."$nupro"
echo "\n"

  • Les programme exécutés et le sous programme BSI

Les programmes spécifiques à la chaîne demandée récupèrent leurs paramètres des sorties de BOP. Ils remontent leur code retour dans le dossier de travail via le sous programme BSI (alimentation de l'information ZO2P). BSI gère aussi l'éventuelle demande d'arrêt du batch (ZO1C-TECANC).

Observations :
- L'utilisation du témoin de cancel est sans effet dans le cas d'un programme bloqué dans une boucle infinie. Son utilité est toute relative.
  • HR Query
Certains batch font appel au serveur java HR Query pour demander le mise en forme d’états (CSV, PDF, TXT). Dans ce cas, HR Query
- Va chercher dans le dossier de travail les propriétés liées au query demandé (liste des états demandés – information ZO3P – requête de sélection de population, requête d’extraction des données, maquette de l’état),
- Alimente dans le dossier de travail la liste des états produits (information ZO3Q) dont un lien pointant vers chacun d’entre eux.

Observations :
- HR Query a besoin de l’existence d’un dossier de travail pour fonctionner,
- L’appel à HR Query pour édition est asynchrone. Le batch peut donc se terminer avant que le serveur de Query n’ait réalisé les états demandés.
  • Les programmes BLZ
Ce programme enrichit le dossier travail des résultats d'exécution de la chaîne, édite les états et displays, et clôture la chaîne via l'information 2C du dossier de travail : dans le dernier programme BLZ de la chaîne le témoin TEMFIN du paramètre PA51 est positionné à 1 afin de provoquer la clôture de la chaîne.

Observations :
- Si le batch se termine en "fin anormale" du fait d'une commande Unix (copie, déplacement, tri d'un fichier et espace disque insuffisant, fichier absent à tort …), il est fréquent que le BLZ final sorte en erreur et ne clôture pas le dossier de travail, et / ou ne soit pas capable de remonter un code retour pertinent,

 

Des modes de soumission particuliers

  • Lancement manuel d'une demande active

L’utilisateur peut activer une demande sans la soumettre (champ ZO1A-TEDMAC). Pour cela il faut alimenter les paramètres d'exécution différée et soumettre le traitement. 
- OPER lance BOB qui stocke le script habillé de la chaine dans l'information ZO2S de la demande,
- La demande est ensuite bloquée. Un écran permet de lister les demandes bloquées et de les libérer.
- L'exploitant devra gérer l’exécution de ces traitements en automatisant une exécution récurente de la chaine RBB

La chaine RBB exécute le programme BOD qui :
- Liste les demandes activées dont la date d'échéance est dépassée
- Pour chaque demande :
  - Incrémente un numéro de suffixe
  - Rédige dans un fichier le script de la chaine mémorisé en ZO2S
  - Exécute $SIGACS/bin/OPE2 via XSNDJOB et passe le numéro de suffixe

Après avoir changé le suffixe $nupro par le numéro issu de BOD, le script OPE2 lance le script rédigé en tâche de fond (nohup &).

Si la planification est récurrente (ex : tous les derniers jours du mois) le programme BOP - après avoir créé le dossier de travail - calcule et met à jour la date de prochaine exécution dans le dossier de demande.

Observations :
- Si RBB repère plusieurs traitements à déclencher, tous seront exécutés en parallèle
- OPE2 déplace le log de $TMP dans $LOG alors que le traitement est en cours ...

 

  • Lancement manuel d'une chaîne sans dossier de demande
Lors du lancement manuel d'une chaîne sans demande associée, l'enregistrement paramètre PA49 permet à l'utilisateur d'indiquer s'il désire la production d'un dossier travail.

La carte paramètre PA49 a la description suivante :
PA49
- TECRDT Témoin de création du dossier travail(c5)
- CDUSER Nom de l'utilisateur (c6 à 13)
- CDPHAS Code chaîne (c14 à 16)
- SUFXDM Suffixe de la demande (c17 à 19)
- CDELMQ Code complément (c20 à 27)
- CDDEST Code destinataire (c28 à 35)
- CDSITE Nom du site (c36 à 43)
- LITRAV Libellé du travail (c44 à 79)

L'entrée PC (fichiers $SIGACS/param/TYBPP{CDPHAS}), structurée comme l'enregistrement paramètre PA48, permet de saisir les paramètres d'exécution des programmes de la chaîne (paramètres normalement saisis dans le dossier de demande) sous forme d'enregistrements de 80 caractères. Ces enregistrements doivent êtres structurés de la manière suivante :
- Nom de l'information 2 caractères
- Numéro de sortie 2 caractères
- Valeurs d'exécution 76 caractères

Exemple pour NJA : DAS1DA18SOCDDDN401DM0401.  Soit : information ZODA, sortie 1 de BOP, carte paramètre DA18, société SOC, demande DDD, code période de paie N401, période de paie DM0401.

Observations :
- BOB n'étant pas exécuté dans ce cas, l'étape d'habillage de la chaîne devra être réalisée par un spécifique,
- La création d’un dossier de travail est facultative, sauf si le batch fait appel au serveur de HR Query pour une présélection ou une édition.
  • Soumissions enchaînées
Avec HR Access V5, apparaissent des demandes pour des chaînes NRC dites d'enchaînement. Les enchaînements sont des batch Opération sérialisant des demandes de batch classiques.

Ces enchaînements peuvent être automatiques ou pas à pas. On définit la liste des groupes d’étapes, des étapes élémentaires, et les demandes associées. Pour chaque étape élémentaire, il est possible de définir des substitutions de chaînes de caractères et des conditions d'exécutions. Une fois ces éléments définis il est possible de soumettre l’enchaînement pour un groupe d’étapes. Ce sont alors toutes les étapes de ce groupe dans l’ordre des rangs d’exécution qui sont lancées.

Par exemple, une demande NRC pourra faire référence :
- A une demande de NRA pour génération de bordereaux
- A une demande de NRB pour intégration de ces bordereaux


La chaîne NRC exécutera des instances du programme BSE qui :
- Vérifieront la condition d’exécution de l’étape suivante
- Habilleront la chaîne (prise en compte des substitutions spécifiques)
- Lanceront la chaîne suivante

L’alimentation de la zone Condition permet de signifier pour chaque triplet groupe-rang-étape la condition d’exécution de ce dernier au sein de l’exécution de l’enchaînement. La grammaire des conditions :
- AND OR,
- Préfixes GRP JOB,
- Etats RUN NOTRUN,
- Code retour général STATUS
- Code retour utilisateur USSTATUS,
- Dernière chaîne exécutée LAST.
Le sous-programme BSF de BSE possède un contexte permettant la résolution de ces conditions par traitement.


La chaîne NRC habille et soumet des chaînes filles :
- NRC initialise le traitement en générant un dossier de travail principal et en alimentant en table PG30 la liste des étapes unitaires. Il soumet une chaîne NRF,
- NRF débute les enchaînements en habillant, soumettant et créant le dossier de travail de la première chaîne,
- Chaque batch applicatif ajoute ses informations d'exécution (codes retours, displays, listings) dans son dossier de travail, et supprime sa référence de la table PG30,
- Des chaînes NRE sont réalisées suite à chaque batch applicatif pour déterminer la suite à donner (contrôle des conditions d'enchaînement), créer le dossier de travail, habiller et soumettre la chaîne suivante,
- La chaîne NRH termine l'enchaînement en clôturant le dossier de travail principal.


Observations :
- Les informations sont tantôt présentes dans le dossier de demande de l'enchaînement NRC, tantôt dans les pop-up des conditions / substitutions, tantôt dans les dossiers de demande appelés,
- Les conditionnements sont relativement basiques, et peu souples d'utilisation, principalement basés sur des codes retours cobol peu significatifs (la chaîne RBM de mise à jour batch se terminera en "fin normale" même si toutes les demandes de mise à jour sont rejetées ; la chaîne NJB de paie de correction se terminera en "fin anormale" si aucun dossier n’est sélectionné) ; l’analyse de logs est impossible,
- NRC peut donc être dépendante de la bonne remontée en base des codes retours des programmes,
- Le dossier de travail de la chaîne NRC est peu clair : impossible de savoir si le batch a réalisé toutes ses étapes ou s'il s'est arrêté en cours de route pour non vérification d'une condition,
- La chaîne NRC soumet ses chaînes filles via l’exécution d’un programme BSE avec en paramètre en table PG30 le numéro d'ordre et l'horodatage de la chaîne fille à habiller et soumettre. La soumission simultanée de plusieurs instances de cette chaîne peut générer des contentions sur la table PG30. De plus, les comptes rendus et listings étant suffixés par le numéro du processus Unix initial, certains documents pourront donc être perdus.
- La chaîne NRC fonctionne avec un témoin particulier spécifique à la carte paramètre PA45. En conséquence elle ne peut être soumise manuellement sans dossier de demande.
  • Soumissions TP de HR Query
Une particularité des rapports HR Query est qu’il existe deux modes de soumission :
- Le mode de soumission classique dit "Batch". Le message est transmis au serveur applicatif qui soumet une chaîne nommée NPQ. La demande est dupliquée en un dossier de travail, l’état est généré par le serveur java HRD Query et stocké sur disque, puis la référence au document est renseignée dans le dossier de travail Opération.
- Le mode de soumission "TP". Dans ce mode, l’extraction et la mise en forme du rapport sont traitées directement par le serveur Web et le résultat affiché dans le navigateur du gestionnaire. Il n’y a pas de dossier de travail, ni de stockage de l’état sur disque, et le traitement est synchrone. L'application HR Access présente sur le serveur Web possède les classes du serveur java HRD Query.

Observations :
- dans le cas des soumissions TP, dupliquer le dossier Template est inutile : les paramètres ne sont pas stockés en base mais dans la session Web,

Points d'entrée pour une personnalisation 

Généralités

L’objet de ce chapitre est de présenter les points d’entrée utilisables pour contrôler la soumission des batch, et maîtriser la charge machine. Quelques points sont à noter en préalable :
  • Pour gérer un système de file d’attente, il sera nécessaire de disposer d’un programme serveur (démon) qui sur la base de critères fonctionnels et techniques distribuera des jetons d’exécution.
  • Il semble souhaitable que l’utilisateur puisse disposer sur la même interface des écrans lui permettant de soumettre le batch et de ceux permettant d’en avoir le suivi et les résultats. L’utilisateur étant à l’origine connecté à l’application HR Access, il est naturel que la solution utilise ou détourne celle de l’assistant de gestion intégré au produit.
  • La présence d’un dossier de "travail" et des dossiers "template" est indispensable au fonctionnement de HR Query. Si l’on désire pourvoir utiliser les Query, le spécifique devra s’appuyer sur le schéma HR standard du module Opération associé. 
  • Si l'on désire maîtriser les soumissions de query, il est nécessaire de supprimer dans l'interface l'accès au mode de soumission dit "TP" qui est traité directement par l'application Web HR AccessHH.

 

IHM

Le code de l’applet est fermé aux personnalisations. En revanche, les pages de l’interface peuvent être personnalisées, et exécuter du script, et HR Access V5 permet de faire appel à une applet ou une servlet spécifique et de le gérer comme un objet publiable.

Ainsi, il est possible :
  • De faire dans une page appel par script à une servlet / applet spécifique. Dans cette hypothèse, l’application spécifique chargée de gérer les batch est présente coté serveur Web. Elle pourrait communiquer avec le serveur à travers socket IP, OpenHR ou du remote shell.
Observations :
- Rédiger du code java coté client (script, applet) peut permettre de mieux traiter l’interface utilisateur,
- Une servlet spécifique n’est pas suffisante. Il faut lui associer un démon installé coté serveur applicatif.

 

BNA/K/L et BOT

En standard, la demande de mise à jour du témoin de soumission de l’information ZO1S déclenchera, suite aux programmes TP classiques (BNA, BNK, BNL) un appel au programme BOT et à la fonction XSNDJOB. Il n’existe pas de contexte dans BOT permettant de personnaliser l’exécution de XSNDJOB. Le programme BOT lui même est un programme du moteur HR Design. Il n’est donc pas possible de le personnaliser par un patch utilisateur spécifique.

Toutefois, il est possible :
  • De remplacer la mise à jour de l’information ZO1S par la ZO1A (pour activation de la demande) ou d’une information spécifique, ce qui inhibe le déclenchement automatique du batch.
  • De remplacer la mise à jour de l’information ZO1S / ZO1A par celle d’une information spécifique, et d’ajouter un traitement dans les programmes BNA ou BNK qui fasse appel à XSNDJOB sur condition – ou qui fasse appel à une fonction C spécifique.
Observations :
- En cas d’utilisation de l’activation, un outil spécifique devra lister les demandes activées et gérer l’habillage des shells et leur exécution,
- Conditionner l’exécution de XSNDJOB est illusoire, les programmes Cobol ne sachant pas accéder à des informations du système.

 

XSNDJOB

Cette fonction C permet de lancer le script Unix "$SIGACS/bin/job" en tâche de fond. Elle est incluse au module APJ.c qui est linké au runtime Cobol de HR Access (exécutable $SIGACS/bin/RTSDGN). Elle peut donc être appelée de tout programme Cobol HR Access. Les sources du XSNDJOB et les règles de compilation du RTSDGN sont disponibles.

Ainsi, il est possible :
  • De modifier le source du APJ.c.
  • De développer une fonction spécifique dans ou hors du APJ.c et de linker cette fonction au RTSDGN.
La fonction modifiée / spécifique pourrait par exemple :
  • Exécuter un script différent de $SIGACS/bin/job
  • Transmettre la demande de batch à un processus démon
  • Exécuter le shell en avant plan plutôt qu’en tâche de fond (ceci est en fait à déconseiller si l’on veut que l’utilisateur soit libéré).
Observations :
- La programmation C est plus technique mais offre une grande souplesse pour ce qui est des accès aux informations système et de la communication avec un processus démon spécifique.

 

Job

Ce script Unix est en standard le point d’entrée des demandes de soumission batch transmises par les script Unix $SIGACS/bin/sub* et par l’assistant de gestion. Job regarde si le shell dont le nom lui est transmis en paramètre se trouve dans $SIGACS/prod/shl ou dans $SIGACS/bin avant de demander son exécution en tâche de fond. Son code source est disponible.

Il est possible par exemple de :
  • Demander la soumission en tâche de fond avec un niveau de priorité particulier (commande Unix nice),
  • Transmettre la demande de batch à un processus démon
  • Demander la soumission en tâche de fond sur une file d’attente Unix (commande at -q),
  • Demander la soumission en tâche de fond à une date particulière (commande at -t),

Observations :
- L’accès et la personnalisation de ce composant sont extrêmement simples,
- Ce script a pour avantage / inconvénient de centraliser les demandes de soumission de Opération ET celles des scripts $SIGACS/bin/sub**,

 

OPER

Ce script Unix est en standard le point d’entrée des demandes de soumission issues de l’assistant de gestion. Il habille et soumet la chaîne demandée en avant plan. Son code source est disponible.

Il est possible par exemple :
  • De compléter l’habillage du script (commande Unix sed) – par exemple pour permettre des exécutions simultanées, ajouter une impression de fichier …
  • De récupérer la consommation CPU du script (commande time ou timex) pour alimenter des statistiques,
  • De détourner la demande d’exécution du batch sur un script, un ordonnanceur ou un outil spécifique (ligne de commande Unix, fichier pilote, …)
Observations :
- L’accès et la personnalisation de ce composant sont extrêmement simples,
- Ce script a pour avantage / inconvénient de ne traiter que les demandes de soumission de Opération.

 

Exemples d'implémentations spécifiques



Détournement des batch sur une file d'attente Unix

Pour limiter le nombre de processus batch actifs, les demandes ont été soumises à travers des files d’attentes Unix.

Le script ${SIGACS}/bin/job a été modifié pour faire appel à ces queues:
  • Les paies à la demande NJL sont lancées sur la queue "e"
  • Les paies de correction NJC et explorations NBX sur la queue "b"
  • Tous les autre batch sur la queue "a"

Archivage des batch diurnes pour exécution en différé


Les demandes d’exécution de batch des utilisateurs ne sont pas exécutées immédiatement, mais archivées pour être exécutées en fin de journée.

Le script OPER est personnalisé de façon à ce que :
  • Les shells habillés par les soumissions des utilisateurs soient stockées dans un répertoire d’archivage, suffixés non par le PID Unix mais par le numéro du dossier de demande Opération (ainsi, une demande soumise plusieurs fois est écrasée),
  • L’exécution de chacun des shells ne soit pas réalisée.
Dans l’ordonnanceur, un spécifique traitera les demandes par ordre de soumission.

Détournement des paies à la demande vers un ordonnanceur

Les calculs de paie à la demande sont détournées pour être soumises par l'ordonnanceur. Une contrainte de non simultanéité est placée pour éviter les conflits d’accès sur les fichiers.
En l’occurrence, en cas de demande de soumission de NJL le script :
  • Initialise les variables d’environnement nécessaires à l'ordonnanceur,
  • Génère une version habillée de la chaîne NJL par exécution d’un script EXECBOB spécifique,
  • Demande à l'ordonnanceur de traiter la demande
  • L’ordonnanceur lance un shell spécifique Unv.Lance_NJL.sh pour exécuter la version habillée de NJL

Soumissions de batch en ligne de commande Unix

L'exploitation désirait automatiser ses tâches. Pour traiter la soumission automatisée des travaux, le module Opération n'est pas utilisable :
  • Le module Opération n’offre qu’une interface utilisateur,
  • Les ordonnanceurs fonctionnement généralement par programmation shell. Si des scripts de soumission existent parfois en standard (ex : subrm pour la chaîne RBM), ils sont conversationnels. De plus, leur source est parfois personnalisé,
  • Les chaînes standard ne supportent généralement pas les exécutions simultanées. Il est donc nécessaire de les adapter pour les rendre plus robustes.
Il est dès lors apparu indispensable de disposer d'un outil Unix de soumission des travaux :
  • en ligne de commande Unix,
  • basé sur les chaînes standard,
  • adaptant celles-ci pour les rendre plus robuste.
Des shells spécifiques sub_*** ont été développés. Ils permettent de soumettre un batch sans passer par le processus Opération, et en ayant le minimum de paramètres à saisir.

Ce script s'exécute comme une ligne de commande Unix classique et émet un code retour. Exemple pour une mise à jour batch RBM :

sub_rbm -p FD0MJ -f $SIGACS/file/PAPFR/PSBDMJ0D     > $LOG/FD0MJRBM.log
CODE_RETOUR=$?


Aucun commentaire:

Enregistrer un commentaire