Que faire de tout cela ?

et le programme appelé est protégée et par conséquent cachée. La seule interface
disponible vers l’objet est constituée par des propriétés qui correspondent aux
paramètres du programme RPG et une méthode runCommand qui rassemble le tout et
exécute le programme. Le résultat est un business object Java réutilisable fini
dont la vraie implémentation en tant que programme RPG est cachée aux yeux de
quiconque utilise la classe et donc s’intègre sans couture dans RPG et Java.



La classe TestCla.java fournit également une méthode main, qui démontre brièvement
la fonctionnalité de base de la classe. Comme indiqué précédemment, l’exemple
de programme Java met en oeuvre les trois moutures de base des paramètres et démontre
les propriétés partNo et fPrice de la classe Java définie et le partDesc et fPrice
que l’on extrait via les fonctions  » assessor  » traditionnelles. La méthode runCommand
est exécutée entre le moment où les propriétés sont définies et extraites.



La méthode runCommand fonctionne de manière identique aux autres parties du programme
Java. Les classes helper sont instanciées localement de manière à  correspondre
aux propriétés disponibles de la classe TestCla.java et des paramètres compris
par le programme RPG. Les objets helper instanciés sont ensuite utilisés pour
convertir les propriétés TestCla correspondantes en leur représentation octets
EBCDIC, lesquels sont ensuite passés dans le constructeur de classe ProgramParameter
où leurs valeurs seront utilisées comme entrée au programme RPG.



Les objets ProgramParameter à  utiliser pour la sortie sont des valeurs entières
passées qui correspondent à  la taille en octets des données renvoyées depuis le
programme RPG. Quelle taille l’entier doit-il faire ? L’entier passé au constructeur
ProgramParameter pour préparer l’objet à  recevoir la sortie doit correspondre
à  la taille des classes helper utilisées pour convertir la valeur en octets. Comme
illustré dans le programme Java, le deuxième objet ProgramParameter est instancié
avec une valeur de 30 correspondant à  la taille de l’objet aDesc AS400Text utilisé
pour traiter les descriptions de pièces. A son tour, le troisième objet ProgramParameter
est instancié avec sa valeur d’entrée fPrice et la valeur entière de 4, qui correspond
à  l’objet helper aPrc AS400Float4 utilisé pour traiter le prix. Le premier ProgramParameter
n’a pas d’entier passé au constructeur puisque ce paramètre ne sera utilisé que
pour l’entrée. Les nouveaux objets ProgramParameter font désormais partie d’un
tableau qui est passé dans la méthode setProgram de l’objet ProgramCall, en même
temps que la totalité du chemin d’accès IFS (Integrated File System) et du nom
du programme RPG étant exécuté.



Le programme RPG est ensuite exécuté, avec paramètres et tout le reste, en invoquant
la méthode run de l’objet ProgramCall. A partir de là , il existe deux manières
pour indiquer si le programme RPG s’est exécuté correctement. L’une via ActionCompletedListener
qui est implémenté dans le constructeur. Quand ActionCompletedEvent est initié,
tous les messages AS/400 renvoyés par le programme sont imprimés de manière itérative
à  partir d’un tableau.



L’autre manière consiste à  utiliser la valeur de renvoi booléenne de la méthode
d’exécution elle-même : une valeur vrai (true) ou faux (false) est renvoyée selon
que le programme RPG qui a été appelé s’est exécuté jusqu’à  son terme ou non.
Dans notre exemple, si la valeur de renvoi de notre méthode run est vraie, indiquant
une exécution réussie, les valeurs des objets ProgramParameter désignés pour la
sortie sont extraites via la méthode getOutputData et positionnées à  leurs propriétés
correspondantes dans la classe TestCla.java, en utilisant à  nouveau leurs classes
helper respectives pour convertir les tableaux d’octets EBCDIC en un format que
le programme Java pourra reconnaître.



Toute cette activité dans la méthode runCommand est transparente vis-à -vis de
l’utilisation de la classe. La méthode main démontre l’utilisation fonctionnelle
de la classe, en mettant tout particulièrement l’accent sur sa simplicité. Nous
définissons les propriétés via les méthodes assessor traditionnelles communes
en Java, en leur passant les valeurs de base de PT225 comme numéro de pièce (part
number) et la valeur numérique de 20,0 comme prix. La méthode runCommand est ensuite
invoquée, suivie des méthodes assessor extrayant les valeurs des propriétés modifiées
et les imprimant vers System.out. Quand nous exécutons la classe TestCla.java
compilée, la sortie se présente ainsi :



Command completed.

Results:

PT225

Ravin Muffler

16,0



Comme les champs DESC et DISC dans le fichier indexé PRT002 sur l’AS/400 correspondent
à  la valeur du numéro de pièce de PT225 et contiennent les valeurs Ravin Muffler
et 0.2, respectivement, le paramètre description est mis à  jour avec le contenu
du champ DESC et le paramètre prix (price) est recalculé avec les résultats du
champ DISC, produisant la sortie ci-dessus : pièce PT225, au tarif de 20,00 dollars,
est une promotion Ravin Muffler avec une remise de 20 %, donnant un prix de vente
de 16,00 dollars !