Des détails et encore des détails

chaque
paramètre qui sera remplacé à  l’exécution
:

String SQLSPString = new String("Call
hoffman.TaxCalcOutputPacked(?,?,?)");
CallableStatement myStatement =
myConnection.prepareCall(SQLSPString);

Quelques considérations générales
de coding s’imposent quand on
commence à  développer des applications
qui utilisent des procédures stockées
JDBC. Tout d’abord, les méthodes
JDBC ont souvent la possibilité de générer
des exceptions Java, qui sont des
erreurs d’exécution Java. Toute méthode
susceptible d’émettre une exception
doit être placée dans un bloc
try Java. En règle générale, placez tout
le code JDBC dans des blocs try.
Deuxièmement, ni SQL ni Java
n’utilisent la liste des bibliothèques
iSeries par défaut. Vous pouvez
contourner cela lors de la création des
procédures stockées ou des instructions
SQL en indiquant le nom de la bibliothèque
comme un qualificateur,
comme le montre l’exemple d’instructions
SQL suivant.
Une meilleure solution consiste à 
définir la liste des bibliothèques utilisées
par votre procédure stockée, dans
un objet Java Properties. Certes, le fait
d’utiliser une liste de bibliothèques
rend votre code de procédure stockée
un peu moins conforme au standard
Java. Cependant, le fait de confiner les
particularités iSeries à  un objet Properties,
qui est une implémentation
JDBC générique, atténue le besoin des
particularités iSeries et constitue souvent
un bon compromis.
Une fois l’instruction SQL spécifiée,
il faut définir les paramètres d’entrée
pour l’appel du programme : dans
le cas présent, l’état et le montant des
ventes. Dans la pratique, les paramètres
d’entrée sont saisis par l’utilisateur
ou proviennent d’une autre partie
de l’application. Ainsi, un utilisateur
pourrait entrer l’information client et
produit dans une application de saisie
de commandes basée sur le Web et,
fort de cette information, un servlet
Java pourrait générer les paramètres
servant au calcul de la taxe sur les
ventes. Comme les paramètres sont
identifiés par leurs positions dans la
liste, leurs noms importent peu. Le
code suivant définit les deux premiers
paramètres (paramètres d’entrée)
d’après les valeurs de inputSaleState
(un objet Java String) et inputSaleAmt
(un objet Java BigDecimal), respectivement):

myStatement.setString(1, inputSaleState);
myStatement.setBigDecimal(2, inputSaleAmt);

JDBC ne demande aucune conversion
explicite des paramètres mais,
quand on définit et qu’on met en place
des paramètres, il faut tenir compte de
la relation entre les types de données
Java, les types de données SQL et les
types de données iSeries. Par exemple,
des champs packés iSeries ont un type
de données Decimal en SQL, que Java
représente comme un objet Big-
Decimal. Dans l’exemple précédent,
notre programme iSeries accepte un
nombre décimal packé comme second
paramètre, et l’instruction CREATE
PROCEDURE SQL définit ce paramètre
avec un type de données Decimal.
En définissant le second paramètre
d’après un objet BigDecimal, comme
dans le fragment de code précédent,
on parachève l’association entre les
types de données.
Avant d’appeler la procédure stockée,
il nous faut aussi enregistrer les
variables Java qui recevront les éventuels
paramètres de sortie. Notre
exemple n’en a qu’un : le paramètre
décimal packé contenant la taxe calculée.
Contrairement à  RPG, les procédures
stockées ne traitent pas tous les
paramètres à  la fois comme entrée et
sortie. Si vous définissez des paramètres
en vous fondant sur leur utilisation
réelle (par exemple, en considérant
que le montant de la taxe est un
paramètre de sortie), votre utilisation
dans l’application Java doit correspondre
à  l’utilisation qui a été définie
dans le CREATE PROCEDURE SQL.
Ainsi, le troisième paramètre pour cet
exemple doit être enregistré comme
un paramètre de sortie :

myStatement.registerOutputParameter
(3, java.sql.Types.DECIMAL);

Enfin , nous sommes prêts à  appeler
notre programme. Comme nous
avons déjà  établi tous les paramètres,
l’appel lui-même est simple :

myStatement.execute();

Si tout se passe bien, notre paramètre
de sortie sera défini et nous
pourrons l’extraire. La sortie TaxAmt
est définie ailleurs dans l’application
Java avec un type de données de
BigDecimal :

outputTaxAmt = myStatement.getBigDecimal(3);

En vous inspirant de ces quelques
étapes, vous pouvez utiliser JDBC pour
tirer parti de vos programmes RPG et
Cobol existants et conserver un modèle
d’application Java peu tributaire
des particularités de l’iSeries.