par Sharon L. Hoffman - Mis en ligne le 23/03/2005 - Publié en Mai 2004
Appelez les programmes RPG à partir d'applications Java grâce à une solution de type
SQL standard
La nécessité de nouvelles interfaces utilisateur est l'un des ressorts du changement
des applications dans le monde iSeries. Très souvent, les développeurs
iSeries créent des GUI ou des interfaces de type navigateur en utilisant Java,
soit en solo, soit combiné à des technologies connexes comme les JSP (Java
Server Pages). Ces mêmes développeurs s'efforcent aussi de relier ces nouvelles
interfaces utilisateur avec les données et la logique de gestion de
l'iSeries ...Bien que les applications Java puissent travailler directement avec des données
iSeries, il est souvent préférable de confier à un programme iSeries le soin
de manipuler des données pour le compte
des applications Java. Ainsi, en appelant un
programme, on bénéficie du code existant
qui traite une logique de gestion complexe.
La performance et la sécurité sont
aussi améliorées par l'appel d'un programme
iSeries plutôt que l'envoi de multiples
requêtes de données en aller-retour
sur le réseau.
Comme on le verra dans la section suivante,
il y a plusieurs manières d'initier un
appel de programme à partir de Java. Nous
nous en tiendrons ici aux appels de procédures
stockées JDBC, qui vous permettent de tirer parti des programmes
iSeries existants tout en écrivant du code Java chargé de minimiser les particularités
de chaque plate-forme.
Les procédures stockées unissent java à RPG
L’IBM Toolbox for Java propose quatre options pour appeler des programmes
iSeries à partir de Java :
- classe ProgramClass
- classe CommandCall
- classe ProgramCallDocument (Program
Call Markup Language, ou
PCML) - classe CallableStatement (appel de
procédure stockée JDBC)
Nous nous concentrerons sur l’appel
de programmes iSeries à partir de
Java en utilisant la procédure stockée
JDBC et CallableStatement. Mais, avant
d’entrer dans les détails de ce genre
d’appel, voyons rapidement les différences
entre ces quatre méthodes
d’appel de programmes.
Des quatre choix, tous, à l’exception
des procédures stockées, sont
propres à l’iSeries. Utiliser des techniques
propres à l’iSeries dans vos applications
Java présente deux inconvénients
: limitation de la portabilité et,
peut-être plus important, difficulté
pour des développeurs maîtrisant Java,
mais peu familiarisés avec l’iSeries, de
comprendre votre code. Cette seule
raison plaide pour l’utilisation des procédures
stockées JDBC.
Les deux solutions, ProgramCall et
CommandCall, présentent un autre inconvénient
: comme les types de données
Java diffèrent de leurs homologues
iSeries, chaque paramètre doit
être traduit avant d’être transmis au
programme ou à la commande iSeries
et les paramètres de sortie doivent être
reconvertis en types de données Java
appropriés. Alors qu’IBM offre des
classes Toolbox pour traiter la conversion,
chaque paramètre d’entrée nécessite
au moins deux lignes de code
supplémentaires pour la conversion.
Et si les paramètres font partie d’une
structure de données, il faut du code
additionnel. Quoique plus faciles à gérer,
les paramètres de sortie ont encore
besoin d’au moins une ligne de
code de plus par paramètre.
PCML supprime la complexité de la
conversion des paramètres mais reste
une solution propre à l’iSeries. De
plus, PCML demande une certaine
connaissance de XML, même si, à partir
de la V5R2, les compilateurs RPG et
Cobol incluent une option permettant
de générer un fichier PCML qui décrit
les paramètres du programme. Pour
un coup d’oeil pratique à PCML et une
analyse plus approfondie de l’intérêt
d’appeler des programmes iSeries à
partir de Java plutôt que d’accéder aux
données directement, voir l’article
« Faciliter les appels de programmes à
partir de Java » (iSeries News mars
2003 ou sur www.itpro.fr ).
Les procédures stockées JDBC résolvent
ces deux problèmes. JDBC est
le standard basé sur SQL Java. Quand
on appelle un programme à partir de
SQL, il est considéré comme une procédure
stockée. S’il est vrai que l’application
des procédures stockées diffère
beaucoup selon la base de données et
la plate-forme, la terminologie des procédures
stockées est générique. Par
conséquent, un développeur Java utilise
un code presque identique pour
appeler une procédure stockée iSeries
ou une procédure stockée Oracle. Les
seules différences sont le nom du driver
JDBC et de la chaîne URL utilisés
pour désigner le driver. Du fait de cette
standardisation, l’utilisation de JDBC
pour appeler une procédure stockée
est la meilleure solution pour appeler
des programmes iSeries d’un point de
vue Java. D’un point de vue iSeries, les
procédures stockées procurent la plupart
des avantages des autres solutions
Toolbox pour l’appel de programmes.
Toutefois, les procédures stockées
présentent quelques restrictions : par exemple, on ne peut pas traiter un programme
de service comme une procédure
stockée. Certains s’interrogent
aussi sur les performances des procédures
stockées. Mais, comme IBM
améliore continuellement la performance
de SQL et de Java pour l’iSeries,
il est bon d’expérimenter les procédures
stockées et d’appliquer quelques
suggestions quant au réglage des
performances, avant de rejeter une solution
par procédure stockée. (Voir
l’encadré « Autres lectures » pour des
informations générales sur JDBC et les
procédures stockées.)
Après les mérites des procédures
stockées pour accéder aux ressources
iSeries à partir de Java, voyons comment
mettre en oeuvre ces procédures.
Téléchargez cette ressource

Percer le brouillard des rançongiciels
Explorez les méandres d’une investigation de ransomware, avec les experts de Palo Alto Networks et Unit 42 pour faire la lumière dans la nébuleuse des rançongiciels. Plongez au cœur de l’enquête pour comprendre les méthodes, les outils et les tactiques utilisés par les acteurs de la menace. Découvrez comment prévenir les attaques, les contrer et minimiser leur impact. Des enseignements indispensables aux équipes cyber.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- AI Appreciation Day,16 juillet « cet email de 10 pages aurait pu se résumer en 3 points »
- L’informatique quantique perçue comme la menace de cybersécurité la plus critique
- Bâtir une entreprise AI-native : par où commencer
- La France à l’avant-garde de la conteneurisation et de l’IA générative
- La souveraineté numérique pour renforcer la cybersécurité
