Etendre votre horizon

procédures ILE RPG, c’est le mode d’invocation des UDF qui les distingue.

Une UDF est invoquée dans le cadre d’une instruction SQL (comme SELECT), laquelle peut traiter des lignes multiples de données. Une UDF peut être exécutée une fois pour chaque ligne traitée et peut renvoyer une valeur unique ou un ensemble de résultats (c’est-à-dire, une table). Pour en savoir plus sur les UDF SQL, voir la partie 1 de l’article « UDTF SQL » avril 2004 et la partie 2, juin 2004 ou www.itpro.fr Club abonnés.

Les procédures stockées ont des possibilités semblables à celles d’un programme appelé par iSeries et sont invoquées à l’aide d’une instruction CALL SQL. Les procédures stockées acceptent des paramètres d’entrée et de sortie et peuvent être écrites avec pratiquement tout langage iSeries, dont SQL, RPG, Cobol et CL. On peut appeler une procédure stockée en utilisant diverses interfaces SQL. C’est ainsi que le SQL imbriqué en RPG, JDBC en Java, et les triggers SQL supportent tous les appels de procédures stockées. (Pour plus d’informations sur les procédures stockées iSeries, voir « Vous aurez besoin d’un procédure stockée si … », iSeries News avril 2003 ou www.itpro.fr Club Abonnés) Vous aurez aussi beaucoup d’occasions d’améliorer la modularité du code en liant les règles de gestion directement à l’activité de la base de données. Les triggers sont le moyen le plus commode de réaliser cela dans un environnement iSeries. L’OS/400 accepte des déclencheurs écrits en SQL (déclencheurs SQL) et dans d’autres langages comme RPG, Cobol et CL (déclencheurs externes). Contrairement aux programmes appelés ou aux procédures stockées, les déclencheurs ne sont pas lancés explicitement par un appel : ils sont plutôt activés par les opérations effectuées sur la base de données, comme la mise à jour d’un fichier physique. Leur mécanisme de communication est un autre aspect des déclencheurs qui les distingue des appels explicites. Les déclencheurs n’ont pas de paramètres d’entrée ou de sortie définis par l’application. Au lieu de cela, ils ont accès à une mémoire tampon de déclencheur. Quand un déclencheur est activé par suite d’une mise à jour, par exemple, la mémoire tampon de déclencheur contient les images avant et après de l’enregistrement qui a été mis à jour.

Bien que la mémoire tampon de déclencheur fournisse probablement toute l’information d’entrée dont un programme déclencheur a besoin, le manque de paramètres de sortie est plus significatif. Vous pouvez écrire un programme déclencheur qui communique avec l’application qui a activé le déclencheur (par exemple, en mettant à jour un enregistrement), mais il vaut mieux généralement éviter de telles communications en dehors du feedback de diagnostic, parce que l’application qui a activé le déclencheur ne sait peut-être pas qu’un déclencheur est attribué à un fichier et à un type de transaction particulier. Pour comparer les possibilités des UDF, des procédures stockées et des déclencheurs, lire « Améliorer l’architecture applicative avec des solutions bases de données » (décembre 2004 ou www.itpro.fr). Pour plus d’informations sur l’écriture de déclencheurs SQL, voir l’article « Créer des triggers DB2 avec SQL » (mars 2005 ou www.itpro. fr).

Les contraintes sont une autre technique, mais moins couramment utilisée (au moins dans le monde iSeries) pour lier des règles de gestion à la base de données. A vrai dire, les contraintes ne sont pas une technique de modularisation d’application. Cependant, elles donnent la possibilité de supprimer certains types de règles de gestion de programmes individuels et de les définir dans la base de données. Ainsi, on peut définir une contrainte référentielle qui exige que chaque enregistrement d’en-tête de commande contienne un numéro client valide.

Outre la segmentation du code qui traite une tâche particulière, vous vous intéresserez aussi à la manière dont les interfaces utilisateur communiquent avec le code qui traite la logique de gestion. Que vous utilisiez une interface à écran passif, une GUI Windows, ou une interface de type navigateur, vous pouvez améliorer la réutilisation et la maintenabilité du code en utilisant une architecture Model/View/ Controller (MVC) (voir l’article « Nouveau modèle, superbe vue », février 2002 ou www.itpro.fr ).