Fonctionnement du serveur HRD Query

30 Juin 2003


Principes

1) L'atelier HRD Studio donne la possibilité de concevoir des requêtes, des mises en pages maquettées puis de mettre en exploitation ces rapports pour les rendre accessibles aux utilisateurs.

2) L'interface Web HR Access permet - via le module Opération ou le Compagnon - de les soumettre en mode synchrone ou asynchrone, puis de consulter les états résultants en bénéficiant de la confidentialité HR Access.

3) Constitué d’un Démon java, le serveur de HRD Query gère des besoins de type "extraction des données" et "mise en page" des résultats, ainsi que de "stockage des états" dans un "Volume d’Archivage". Il prend en charge la production des documents élaborés (PDF, HTML ...). Les chaînes batch classiques ont été modifiées pour faire appel à ce serveur pour toute édition élaborée.





Les étapes de diffusion, d’impression sont laissées à la charge de produits externes dont c’est la spécialité.

Contrairement à HRv3 où les Query étaient conçus à travers l’Interface Utilisateur, avec HRv5 cette possibilité est réservée à HRD Studio. Le gestionnaire ne peut pas concevoir ses requêtes via l'interface HRWeb.

Conception

L’interface évolue sur la base de l’outil HRD Query HRv3. L’atelier permet de concevoir des requêtes population, des mises en pages maquettées, des rapports (objets QG, QL, QP, QR stockés en tables EN). Il permet de déclarer les types de sorties autorisés (HTML, PDF, CSV).

Grâce aux sous rapports, les informations répétitives peuvent être maquettées de manière indépendante du dossier lui même :
  • Soit en leur dédiant une ou plusieurs bandes spécifiques (entête de groupe, détail, …),
  • Soit en les affichant sous forme de mini-tableaux – limité en nombre de lignes - qui se placent librement dans le formulaire).
 Le maquetteur a été entièrement refondu :
  • Initialiser la mise en page, ajouter des bandes puis partir des données pour ajouter des zones (bouton droit).
  • Tester la requête (validité, exécution, sortie – avec des données au format XML pour les éditions batch)
  • Définir des critères d’éclatement (dispatching) du fichier pour le serveur HRD Query.


Les objets réalisés sont « mis en exploitation » (action accessibles dans HRD Studio) pour être convertis en dossier Opération :
  • NPM mise en page spécialisée,
  • NPP population batch,
  • NPQ rapport.

Ces dossiers ZO doivent être livrés sur l’environnement de production pour être directement utilisables par le gestionnaire : ces dossiers Opération font référence aux objets (rubrique ZO00-CDELMT) mais ils en sont indépendants.


Utilisation

Les « Populations » et « Mises en page spécialisées » servent aux chaînes batch classiques :
  • Les requêtes de présélection de Population exprimée en langage de Query peuvent être utilisées par les explorations, exports ou chaînes de paie ...
  • Les mises en page à appliquer peuvent être utilisés pour transformer en PDF les fichiers XML générés par les programmes (ex : DBL génère un XML pour le bulletin).

Les « Rapports » peuvent être soumis par le gestionnaire en TP ou batch. L'Assistant de Gestion permet le lancement des rapports (type de dossier NPQ), le suivi de leur déroulement, et la consultation du résultat archivé. Le Compagnon fournit un Assistant pour en faciliter la prise en main.

 Une particularité des rapports est qu’il existe deux modes de soumission :
  • Le mode de soumission classique dit « Batch ». La demande est dupliquée en un dossier de travail, l’état est généré par le serveur HRD Query et stocké, puis la référence au document est renseignée dans le dossier Opération.
  • Le mode de soumission « TP ». Dans ce mode, l’extraction et la mise en forme du rapport sont transmises directement au serveur HRD Query par le serveur Web (RMI) 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.

Des répertoires réglementaires servent à référencer les états produits par les chaînes batch :
  • UZ0 (états), sont listés par HRD Query dans l’onglet « Définition » des objets « Mise en page spécialisée »,
  • UZ1 (états / phase / step), basculés dans les templates Opération lors des mises en exploitation de rapports,
  • UZ2 (formats).
A noter : quand une chaine batch fait une demande de mise en forme d'état au serveur de Query, le traitement est pour elle "asynchrone". C'est à dire que la fin du batch ne signifie pas que l'état est disponible.

Les dossiers "Template"

Le dossier généré par la « mise en exploitation » d’un objet HRD Query est un dossier « Template » qui contient la description XML des requêtes de sélection, d’extraction et de la maquette. Il doit être dupliqué en un dossier de Demande classique si l’on veut y saisir des paramètres.

A noter : un écran permet de resynchroniser les demandes "classiques" dans le cas ou leur description serait obsolète (comparaison des ZO4T-TIMODI).

Le dossier Template peut recevoir des Attributs de gestion (ZO3Y) ou d’exploitation (ZO5X), le tout étant utilisable par exemple dans les traitements de confidentialité.

Pour les Demandes, la saisie des paramètres (ZO5Q) se fait dans une pop-up banalisée. Des scripts permettent de gérer leur nombre et leur mise en forme. Dans le cas des soumissions TP, les paramètres ne sont pas conservés dans ZO. Leur rémanence est pilotée par script (stockage d’un fichier dans l’arborescence « work » du serveur Web).

Il est possible d’indiquer avant la sousmission un Destinataire (ZO00-CDDEST), les sorties états attendues (ZO3P), et faire référence à un objet « Site » devient obligatoire (ZO00-CDSITE - il permet de préciser par quels serveurs sera pris en charge le rapport).

C’est la confidentialité du user destinataire qui est prise en compte lors de l’extraction des données. Le code destinataire peut être un utilisateur de type « groupe » (ex : créer un user groupe « PAYE » pour les états de paie). La confidentialité sur les résultats peut utiliser des critères relatifs aux états générés (ZO3Q) comme par exemple les critères de dispatching (par exemple si un rapport est éclaté par filiale).

Du coté de HR Design Server

En batch, « Populations », « Mises en pages » et « rapports » sont gérés par le serveur de Query sur demande du serveur Design. A cette occasion de nouveau programmes (de qualification GO) sont utilisés :
  • BOU (création de fichiers de commande pour requête, édition, transfert),
  • preselection.jar (appel du serveur de Query, construction de l’ordre select),
  • BOV (exécution de la sélection).
  • Emission de fichiers par FTP (ou CP si le serveur de query est local)
Dans le cas du lancement hors Opération d’une chaîne avec query ou état, BOP doit assumer la création d’un dossier de travail. A cet effet,
  • La carte PA49 doit renseigner l’information ZO00 (code du template),
  • La carte PA48 le contenu des informations obligatoires : ZO3P (mises en page), ZO5T (présélections), ZO5X, ZO5Q (paramètres d’exécution).
Dans le cas des batchs classiques (paie, explorations), les données sont fournies au format XML au serveur HRD Query pour mise en page.
  • Dans certains cas, les fichiers $SIGACS/param/TYBExxxx précisent au sous programme DHE de BLZ comment convertir le fichier ES historique en un fichier XML Data (Titre, Ruptures, Lignes) – par exemple pour les bulletins.
  • Dans d’autres cas, le Cobol fait appel a BXM pour générer directement un XML Data.
  • Des adaptations ont été faites dans un second temps pour permettre d'ajouter une mise en forme aux états des explorations NBX

Le serveur HRD Query

Le serveur HRD Query est une application Java chargée de centraliser la gestion des requêtes et éditions conçues avec HRD Studio. Il prend la forme :
  • D’un serveur indépendant pour les demandes batch (démon disposant de 2 threads pour les query et les éditions - à démarrer avec l’application),
  • De classes intégrées au serveur Web pour les demandes TP (puis celles-ci furent accédées sur le serveur HRD Query par RMI),
  • D'un « Volume d’archivage » : c’est un répertoire de stockage pour les états générés.
Ce serveur peut être placé sur la même machine que le serveur Design ou sur une machine distante; de même pour le volume de stockage.

Ce serveur prend en charge :
  • Une requête (préselection de NRA)
  • Une requête + une édition + un archivage (cas de NPQ),
  • Une édition + un archivage (cas du bulletin de NJA),
  • Un archivage (cas des listings en mode texte, par exemple ceux de NBX).


Un port de communication doit être paramétré pour son administration par la console. Un second port doit être attribué au listener de préselection de population.

Hors le cas des présélections (invocation via le listener), les demandes de travaux au serveur HRD Query se font via fichiers de commande. Le serveur HRD Query scanne son répertoire « work » et déclenche le traitement demandé :
  • Fichier « .QRY » pour les demandes de query,
  • Fichiers « .LYT » pour les demandes d’édition.
Pour récupérer des données de HR Access, le serveur HRD Query utilise :
  • OpenHR (par exemple pour faire habiller un ordre SQL par les programmes de confidentialité),
  • JDBC (Java DataBase Connector – pour exécuter l’ordre en question).
L’envoi des éditions sur le volume d’archivage se fait par FTP ou "copie" directe.



Le Batch Query Connector surveille la réception de fichiers « .QRY ». Ce fichier de commande contient entre autre le Nudoss du dossier de travail. Le serveur de Query se connecte à la base HR pour récupérer la requête (ZO5C) et habiller les ordres (préfixes, suffixes, confidentialité). Les ordres sont ensuite exécutés pour constitution d’un XML Data. Un fichier « .LYT » est transmis pour demande d’édition.

Le Batch Editing Connector surveille la réception de fichiers « .LYT ». Ce fichier contient entre autre le Nudoss, le code état, le rang d’état. Le serveur de Query se connecte à la base HR pour récupérer la liste des états (ZO3P : n° de sortie, format). Si le fichier de données est un XML Data, il récupère la mise en page (ZO4C) puis génère un PDF ou HTML.

Au final, le serveur archive les documents générés (émission ftp des fichiers) et alimente la liste des états générés (ZO3Q).

La consultation des états générés en batch se fait à travers les écrans Opération (URL construite à partir de ZO3Q-URLSTO). La demande passe par une servlet qui rejoue les contrôle de confidentialité avant de transmettre le document.


NB : toutes les informations permettant les communications entre les serveurs de HR Access sont renseignées dans l’objet "Site".

3 commentaires:

  1. Bonjour, est-il possible de lancer une requete query en ligne de commande sur le serveur ?
    dans notre HRA7, nous constituons des requêtes via le DC, pour fiabilisé les dossiers agents. Je souhaiterais exploiter les résultats (csv, xls ou pdf ) dans des scripts pour ensuite faire de l'envoie de mail au gestionnaire RH ?
    j'ai vu dans les log qu'il génère un XML puis le transforme en fichier résultat pour le présenté à l'utilisateur mais je n'arrive à retrouver ces derniers .

    Merci beaucoup

    RépondreSupprimer
  2. La chaine RJ2 permet de déclencher une demande - en particulier une NPQ (Query). La chaine crée un dossier de travail ZO et passe la main au serveur de Query. Il faut ensuite rivaliser d'astuce pour suivre son exécution (une piste étant d'observer la table EV10 ou la ZO2D). Pour être plus proche du standard on peut aussi regarder dans DC les objets scripts de post-édition. Plus d'éléments sur le compagnon, la doc, et surtout trouver des exemples ...

    RépondreSupprimer
    Réponses
    1. une fois le Query exécuté les résultats sont stockés dans le volume d'archivage. Celui-ci peut être sur la machine locale, ou distant (voir l'objet topologie HRS). Le chemin relatif au fichier peut être retrouvé dans la ZO3Q

      Supprimer