Les UDF : une bonne mise en bouche pour SQL

me semble pas que la communauté AS/400
les ait demandés.

Certains, parmi les plus
importants de nos clients, nous ont pas poussés à  créer des UDF

Anderson : Bien que beaucoup de nos
clients ne nous aient pas poussés à  créer des UDF, certains, parmi les plus
importants, l’ont fait. Nous avons également soulevé un très grand intérêt
dans la communauté des éditeurs. Beaucoup de fournisseurs d’applications
souhaitent vendre leurs produits sur de nombreux systèmes différents, et ils
veulent faciliter leur travail d’assistance grâce à  certaines de ces
techniques de coding avancées. Les UDF et les UDT procurent le typage puissant
et le polymorphisme d’un langage orienté objet. Et cet aspect intéresse tout
particulièrement plusieurs des grands éditeurs AS/400.

Milligan : Je pense également que la
communauté AS/400 peut utiliser des UDF pour démarrer avec SQL. Je tiens également
à  indiquer que l’on peut écrire des UDF en utilisant n’importe quel
langage évolué de l’AS/400. Les UDF permettent de réutiliser les routines
RPG ou Cobol existantes pour effectuer un calcul ou exécuter une certaine
action et appeler ces routines depuis une interface SQL. Si une routine RPG
calcule un tarif d’assurance d’un détenteur de police particulier, on peut
désormais l’appeler depuis une instruction SQL.

Hoffman : Mais alors, comment, d’un
point de vue SQL, faire la différence entre une UDF et un appel de procédure ?

Anderson : La distinction est simple. On
évoque un appel de procédure en utilisant soit l’instruction SQL Call, soit
la structure ODBC (Open Database Connectivity) équivalente pour appeler une
procédure. C’est une procédure autonome, bien délimitée, chargée
d’effectuer beaucoup de travail. Tandis qu’une fonction est intégrée à 
l’intérieur d’une autre instruction SQL, comme Select, Update ou Delete.
Une UDF est comparable à  toute autre fonction scalaire que nous livrons déjà 
avec le langage SQL (quelque chose que l’on utilise à  l’intérieur
d’autres instructions SQL) tandis que l’appel d’une procédure en SQL équivaut
à  appeler un programme que l’on écrirait, peut-être en RPG.

Milligan : Pour calculer des tarifs
d’assurance, par exemple, on pourrait utiliser un appel de procédure cataloguée
pour obtenir le profil de crédit d’un client. Mais, si l’on veut écrire
une instruction Select chargée d’explorer et de recueillir des informations
sur certains clients à  partir d’un certain état, on utiliserait un appel UDF
pour calculer le tarif d’assurance au moment de la sélection de chaque
client.

Hoffman : Peut-on cataloguer le même
morceau de code RPG, par exemple, à  la fois comme procédure cataloguée et
comme UDF ?

Anderson : Là , c’est un peu plus délicat.
Une UDF renvoie toujours un argument, et une procédure peut avoir un paramètre
d’entrée/sortie. On pourrait donc, théoriquement, cataloguer le même
morceau de code à  la fois comme une procédure cataloguée et comme une UDF,
mais ce n’est pas leur vocation. Si l’on voulait intégrer un morceau commun
de code à  l’intérieur d’une UDF et intégrer un autre morceau de code dans
la procédure C, il faudrait avoir un autre segment de code exécutable que
l’on appellerait à  partir des deux. On pourrait encore utiliser le même code
exécutable en coulisses, mais on souhaiterait probablement un frontal différent
parce que le style de paramétrage utilisé pour ces deux concepts est lui-même
différent.

Guthrie : Je me demande où tout cela
conduit le développeur lambda sur écrans passifs en RPG. Ces gens
utilisent-ils vraiment SQL à  ce point ?

Milligan : Absolument. En la matière, il
faut considérer à  la fois les clients et les fournisseurs de logiciels tiers.
Il y a du monde dans les deux secteurs, particulièrement parmi nos fournisseurs
de logiciels majeurs : tout ce qu’ils écrivent pour l’accès à  leurs bases
de données est en SQL. Progressivement, les gens passent du tout RPG à  deux
autres techniques : soit intégrer SQL dans le code RPG, soit passer à 
Java et réaliser l’accès SQL au moyen de JDBC 
(Java Database Connectivity). Au cours des derniers dix-huit mois, on a
constaté un vrai décollage de l’intégration de SQL en RPG, même dans les
comptes AS/400 traditionnels.

Au cours des derniers dix-huit
mois, on a constaté un vrai décollage de l’intégration de SQL en RPG, même
dans les comptes AS/400 traditionnels

Guthrie : Si des programmeurs RPG doivent
écrire un programme impliquant une table qui crée des LOB et autres, que
peuvent-ils escompter ?

Milligan : Ils peuvent intégrer SQL, le
cas échéant, pour traiter les colonnes présentant ces nouveaux types de données.
De la sorte, ils n’ont pas à  jeter aux oubliettes toutes leurs connaissances
de ce langage, pour utiliser exclusivement SQL.

Guthrie : Si les programmeurs doivent
simplement déplacer des données et s’ils ne veulent pas intégrer dans SQL
pour ce faire, le RPG aura-t-il à  se plaindre de ces types de données ?

Milligan :
Oui.

Guthrie : Il serait donc plus simple de définir
un programme LOB ?

Milligan : Si l’on veut qu’un
programme RPG puisse fonctionner avec simplement les types de données
traditionnels et laisser les nouveaux UDT pour un programme distinct, on
pourrait créer un fichier de visualisation SQL n’incluant pas les nouveaux
types de données, que le programme RPG utiliserait comme un fichier logique.
Cet autre programme pourrait ensuite utiliser SQL pour accéder directement à 
la table et à  ses colonnes UDT.

Anderson : Outre l’omission de champs
LOB dans un fichier de visualisation ou logique, on peut aussi créer une vue et
tronquer les données LOB en les associant à  un type de données caractère. Ce
fichier logique n’ayant plus de types de données LOB réel, le RPG pourrait
l’utiliser. On ne pourrait pas obtenir la totalité des données LOB (c’est
d’ailleurs pourquoi on doit en principe utiliser SQL pour y accéder) mais,
dans certains cas, peu importe. Après tout, peut-être ne veut-on obtenir que
les 10 premiers Ko d’un LOB particulier.

Guthrie : Particulièrement avec un
locator, on pourrait fort bien déplacer des données sans les connaître ou
s’en préoccuper vraiment.

Anderson : C’est vrai pour SQL. Mais ce
n’est pas vrai pour le RPG, qu’il faudrait améliorer pour supporter les
locators comme variable RPG, si on le souhaitait, pour accéder vraiment aux
données par l’intermédiaire d’un locator.