Quand le programme CGI-RPG est appelé

l’ajouter à  un répertoire de
liaison dans le CGILIB et y faire
référence en utilisant le mot-clé BNDDIR
sur la carte H du programme
CGI-RPG.

Mon programme CGI-RPG n’utilise que trois des API CGI pour réaliser le
travail:

• QtmhRdStin lit l’entrée d’un formulaire
HTML

• QtmhCvtDb convertit un flux de
données HTML en une base de données/
structure de données AS/400

• QtmhWrStout réécrit les données
dans le navigateur

Remarque : Comme les API CGI
sont écrites en C, il faut bien respecter les majuscules et les minuscules, sous
peine de ne pas trouver les fonctions.

Quand le programme CGI est appelé,
l’entrée provenant du formulaire
est lue dans le programme. Cela se fait
dans la sous-routine ReadStdIn en utilisant
l’API QtmhRdStin. Quand les
données HTML seront lues dans le programme,
la variable RcvDta ressemblera
aux données illustrées figure 2.

Vous pouvez commencer à  diviser
la chaîne en utilisant toutes les nouvelles
fonctions intégrées (BIF, built-in
functions) du RPG IV, mais il existe un
moyen bien plus simple. Dans la sousroutine
CvttoDB, l’API QtmhCvtDb est
appelée. La sous-routine analyse syntaxiquement
tous les champs du formulaire
HTML et les transfère dans une
base de données ou structure de données
AS/400.

J’ai défini une structure de données
externe appelée PA9001DS, qui a
les mêmes noms de champs que ceux
qui sont utilisés dans le formulaire
HTML. Après le CALLB à  QtmhCvtDb,
les champs sont mappés dans les
champs de la structure de données et
ils finissent en structure de données
HTMLdata, définie en utilisant le motclé
ExtName. Avec ce genre de définition,
il est très facile de changer le programme
pour utiliser d’autres fichiers
base de données, parce que l’API
QtmhCvtDb ne voit qu’une structure
de données appelée HTML.

Après l’appel de la sous-routine
CvttoDB, la variable appelée WrtDta
(qui contient les données HTML qui
sont réécrites dans le navigateur) est
assortie d’une constante « Contenttype:
text/html ». Il est important de
vous souvenir de ce détail parce qu’il
indique au navigateur que HTML arrive
; sinon le navigateur n’affichera pas
le résultat.

Notez également que les données
HTML sont renvoyées au navigateur
sous forme d’un long flux. Donc,
chaque fois que je veux ajouter davantage
de HTML à  visualiser dans le navigateur,
je le place simplement à  la fin
de la variable WrtDta.

La seule raison pour laquelle j’utilise
la constante NewLine (qui contient
la valeur hexadécimale 15) est que je
veux donner bonne mine au code
HTML généré dans le navigateur. Sans
NewLine, le HTML aurait une allure rébarbative,
sans sauts de ligne, et serait
difficile à  lire.

Ensuite, la sous-routine SubrActions est appelée. Elle établit
l’appel adressé au programme de service
CBX003 d’après le contenu du
champ appelé ACTION et d’après les
valeurs lues dans le formulaire HTML.
Si l’appel de la procédure CBX003 se
termine par une erreur, le champ
OOPS sera mis à  *ON, indiquant
qu’une erreur s’est produite.

Une fois le programme revenu de
SubrActions, une autre sous-routine
appelée SetReply est exécutée. Elle
crée un champ appelé HTMLreply
d’après le contenu du champ vérificateur
d’erreur OOPS et de l’ACTION
exécutée par le formulaire HTML. A ce
stade, la réponse au navigateur est bien
définie.

C’est le moment d’élaborer le code
HTML qui sera réécrit dans le navigateur.
Il y a pour cela plusieurs méthodes.
Personnellement, j’utilise un fichier
squelette HTML parce qu’il rend
les modifications faciles et qu’il ne demande
au CGI-RPG que de remplir les
données. C’est la sous-routine
LoadHTML qui se charge de cette partie
du travail.

Le fichier squelette est lu en utilisant
la commande QCMDEXC pour
remplacer le membre PA9001 dans le
fichier source HTMLSRC dans la bibliothèque
CGILIB.

(J’ai dû renommer le format d’enregistrement
du fichier source HTML,
de HTMLSRC en SRCREC, faute de
quoi le programme ne se serait pas
compilé.)

Le membre contient du code
HTML ordinaire. Pour savoir où mettre
dans la réponse les données provenant
de la sous-routine SetReply, j’invente
mes propres mots-clés puis j’utilise les
BIF %SCAN et %REPLACE pour remplir
les données correctes.

La figure 3 contient un exemple. On
voit d’abord le squelette HTML puis le
code de remplacement du mot-clé &reply.
Cette méthode est intéressante car
elle me permet de déplacer le mot-clé
dans une autre ligne et une autre position,
tout en laissant le programme CGIRPG
se comporter comme prévu.

Dans la sous-routine LoadHTML,
tout le HTML est collecté dans un
champ appelé WrtDta, d’une longueur
de 4.500 octets. Cette longueur peut
parfaitement être augmentée si la réponse
HTML dépasse 4.500 octets.

Quand le programme a fini de lire
le fichier HTML squelette et d’insérer
les données appropriées, il ne reste
plus qu’à  écrire les données dans le navigateur.
On le fait dans la sous-routine
WrtToHTTP en utilisant l’API
QtmhWrStout.

Pour trouver la longueur des données
HTML générées, j’utilise le code
opération CHECKR et stocke la longueur
réelle dans le champ WrtDtaLen, qui sera utilisé quand le programme
appellera l’API QtmhWrStout.

Après l’appel de l’API, WrtDta ne
contient plus que des blancs. Ce n’est
pas indispensable parce que le programme
se termine avec *INLR mis à 
ON et, par conséquent, le champ sera
blanc lors du prochain appel. Mais
j’ai quand même redonné une virginité
à  WrtDta pour que le prochain
programmeur sache que j’ai fini d’utiliser
ce champ. Peut-être un jour quelqu’un
remplacera le *INLR par un RETURN.

Il ne reste plus qu’à  mettre l’indicateur
*INLR sur on. Le résultat
s’affichera aussitôt dans le navigateur.