Le programme de génération de rapport en expansion permanente

Le développement d'une application dans laquelle un utilisateur entre des critères de sélection et un ordre de tri représente souvent un défi en même temps qu'une frustration en matière de tâche de développement. Cependant, les conditions de sélection et de tri sont courantes dans les applications de génération de rapports

et d’exportation.

Certaines entreprises forment simplement leurs utilisateurs à Query/400 de sorte
qu’elles n’ont pas besoin de créer une application pour répondre aux besoins de
production des rapports des utilisateurs. Toutefois, après avoir approuvé et mis
en place leurs superbes architectures, les utilisateurs ont tendance à revenir
et dire : « Nous avons, nous aussi, besoin de cela ! » Et les développeurs sont
renvoyés à la case départ (ex : SEU) pour apporter des modifications au code source.

Heureusement, on peut utiliser le SQL intégré (le membre source est de type SQLRPGLE)
pour créer un générateur de rapports sur un fichier (dans ce cas, un fichier employé
appelé EMPPF. Si on n’a pas utilisé SQL intégré dans un programme RPG, mon programme
simple (figure 2) représente un bon exemple de programme qu’on peut étendre au
fil du temps, à mesure que les besoins de tri et de sélection apparaissent.

Ce programme SQL intégré utilise le RPG pour récupérer les données saisies par
l’utilisateur, puis pour concevoir une instruction SQL exécutée sur le fichier
employés. La figure 3 présente l’écran de saisie du programme RPG ILE.

On utilise également SQL pour extraire chaque enregistrement du fichier employé
dans le programme RPG, dans lequel il est possible de faire tout ce qu’on veut
(exemple : imprimer un rapport, charger un sous-fichier, exporter vers un autre
fichier).

RUNSQL Guide Express

Cet encadré a constitué, dans NEWSMAGAZINE de décembre 1997, une annexe
à l’article « Un browser de journaux intelligible ».

Avec RUNSQL, les commandes SQL peuvent s’exécuter sur un AS/400 même si
celui-ci ne dispose pas du logiciel de développement SQL DB2/400 Query Manager
et du Kit de développement SQL (57xx-ST1). La commande RUNSQL est également
un excellent outil frontal pour le support intégré de l’AS/400 des requêtes
de Query Management sous SQL.
L’utilitaire RUNSQL fait appel aux membres sources suivants :

o Définition de requête Query Management ZUQXSQL
o Programme CL ZUCXSQL
o Définition de commande RUNSQL

Pour créer l’utilitaire, procédez ainsi en remplaçant mabib par le nom de
votre bibliothèque :

1. Créer les fichiers physiques sources QCLSRC et QCMDSRC, s’ils n’existent
pas déjà :

CRTSRCPF FILE(mabib/QCLSRC) +
TEXT(‘Source CL’)

CRTSRCPF FILE(mabib/QCMDSRC) +
TEXT(‘Source CMD’)

2. Créer le fichier physique source QQMQRYSRC :

CRTSRCPF FILE(mabib/QQMQRYSRC) +
RCDLEN(91) +
TEXT(‘QM Query Source’)

3. Placer la définition de requête Query Management ZUQXSQL dans le membre
ZUQXSQL de QQMQRYSRC, le programme CL ZUCXSQL dans le membre ZUCXSQL de
QCLSRC, et la définition de commande RUNSQL dans le membre RUNSQL de QCMDSRC.

4. Ajouter la bibliothèque mabib à la liste des bibliothèques :

ADDLIBLE LIB(mabib)

5. Créer la définition de requête ZUQXSQL :

CRTQMQRY QMQRY(mabib/ZUQXSQL) +
SRCFILE(mabib/QQMQRYSRC)

6. Créer le programme CL ZUCXSQL:

CRTCLPGM PGM(mabib/ZUCXSQL) +
SRCFILE(mabib/QCLSRC)

7. Créer la commande RUNSQL :

CRTCMD CMD(mabib/RUNSQL) +
PGM(*LIBL/ZUCXSQL) +
SRCFILE(mabib/QCMDSRC)

Lors de l’utilisation de la commande RUNSQL, vérifier que mabib figure dans
la liste des bibliothèques. La commande peut être invoquée de manière interactive
ou en batch.

Figure 4 Description du fichier EMPPF
Champs	Colonne	Longueur	Intitulé
EMPNO	9	0	Numéro d’employé
LNAME		16	Nom
FNAME		12	Prénom
HPHONE	7	0	Téléphone domicile
ADDR1		40	Adresse 1
ADDR2		40	Adresse 2
ZIP	5	0	Code postal
DEPT		12	Département
WPHONE	7	0	Téléphone bureau
BDATE		10	Date de naissance
HIREYR	4	0	Date d’embauche
SALARY	5	0	Salaire

L’utilisation du SQL intégré pour le générateur de rapports présente des avantages.
Etant donné que l’instruction SQL crée la sélection d’enregistrement et l’ordre
de tri, il n’est pas nécessaire d’avoir un fichier logique pour chaque ordre de
tri possible dans le fichier employé. Il est également inutile d’avoir une logique
de sélection complexe dans le programme puisque SQL sélectionne les enregistrements
pour nous.

Le fait que SQL permette un point unique de débogage constitue un autre avantage.
Si le programme ne produit pas la sortie escomptée, il suffit de déboguer l’instruction
SQL créée. La figure 4 illustre la présentation du fichier EMPPF.

L’une des premières choses que l’on peut remarquer dans le programme SQLRPGLE
de la figure 2 est que EMPPF n’est pas répertorié en cartes F. Ce n’est pas nécessaire.
Les cartes F ne contiennent que le fichier écran et Qprint pour l’impression du
rapport indiqué dans le programme. Une structure de données basée sur EMPPF et
définie en externe apparaît en A. La structure de données est utilisée pour récupérer
le résultat de l’opération SQL Fetch (en F).

Après réception de l’entrée de l’utilisateur, le programme définit la variable
SQLStmt sur la clause de base (en B). J’utilise de nombreuses constantes dans
le programme pour illustrer les parties variables de l’instruction SQL.

En C, le programme vérifie si des critères de sélection ont été entrés. On remarque
que les instructions Eval utilisent la fonction intégrée %TRIM pour s’assurer
que la variable SQLStmt contient toujours la valeur originale de SQLStmt plus
les besoins à annexer.

La variable WhereUsed indique si le WHERE a déjà été annexé, à un moment ou à
un autre, à l’instruction SQL. Le programme ne contient que deux critères de sélection
mais il peut, par la suite, contenir plusieurs options de sélection et on doit
toujours savoir si on doit utiliser WHERE en tant que partie de l’opération d’ajout
ou si on doit commencer avec la conjonction AND.

Ensuite, en D, le programme détermine l’ordre de tri en annexant le verbe sélectionné
ORDER BY à la fin de la variable SQLStmt.
En E, le traitement SQL commence. Chaque instruction SQL commence par la directive
/Exec et se termine par /End-Exec. Les quatre instructions définissent respectivement
le format de date et le niveau de validation, préparent le processeur SQL selon
l’instruction SQL de la variable SQLStmt, déclarent un curseur à utiliser dans
l’opération Fetch et ouvrent le curseur pour qu’on puisse récupérer les enregistrements.

En F, on commence à s’amuser. Chaque opération Fetch réussie amène un enregistrement
de EMPPF dans notre structure de données EMPFILEDS, décrite en externe. Si l’opération
Fetch échoue, cela signifie que la variable sqlcod contient un code erreur. L’erreur
la plus courante indique qu’on a atteint la fin des enregistrements et qu’on doit
quitter la boucle.

C’est la magie des traitements SQL imbriqués

« Où la variable sqlcod est-elle déclarée » ? En fait, c’est la magie des traitements
SQL imbriqués. Lorsqu’on compile un programme avec un type de membre SQLRPGLE,
le compilateur AS/400 applique les structures de données SQL nécessaires et insèrent
le code nécessaire pour le traitement de SQL dans le programme RPG. La variable
sqlcod fait partie de cette structure de données SQL.

Enfin, le curseur est fermé en G, et notre programme est terminé.
Une fois le programme défini et en fonctionnement, un utilisateur peut revenir
et demander un nouvel ordre de tri ou une nouvelle sélection. Pas de problème.
Il suffit d’ajouter les constantes pour annexer le nouvel ordre de tri et la nouvelle
clause de sélection à la fin de la variable SQLStmt. On peut répondre ainsi à
ces requêtes en très peu de temps.