Faire passer votre message

de code. Outre les mécanismes de communication tels que les paramètres, les valeurs de renvoi et les mémoires tampons de déclencheurs, de nombreux langages supportent aussi certains types de reporting d’erreurs via des messages, des exceptions et des codes d’erreur. Ces fonctions favorisent la portabilité du code et désignent plus clairement la nature d’une communication particulière. Ainsi, bien que vous puissiez utiliser un paramètre pour signaler qu’une erreur s’est produite dans une procédure stockée, en utilisant une exception SQL vous soulignez le fait que la condition est inhabituelle et inattendue.

Certaines techniques de coding permettent aussi des variables qui sont définies dans une composante du code et atteintes dans une autre composante. Par exemple, une sous-routine RPG peut accéder aux données définies dans une sous-routine différente. Bien que, parfois, vous puissiez améliorer légèrement les performances en utilisant des variables partagées, en général les utilisateurs ne perçoivent pas les différences de performances. Il faut donc limiter l’utilisation des variables partagées au code étroitement intégré non réutilisé par des applications multiples. Faute de quoi, on perd un avantage important de la modularisation : la possibilité de changer une composante du code sans en affecter une autre. Lorsque les données partagées conviennent, on peut améliorer la maintenabilité en définissant les variables partagées dans un point central (comme les D-specs d’un programme RPG).

On peut aussi recourir à diverses techniques pour établir la communication asynchrone entre des composantes du code. Dans le scénario le plus simple, un fichier peut être un mécanisme de communication asynchrone. Par exemple, une application de saisie de commandes crée de nouvelles commandes et caractérise chaque enregistrement d’en-tête de commande avec un statut « N » (nouveau). Pendant la nuit, un processus batch imprime les listes d’emballage pour toutes les nouvelles commandes et change leur statut en « S » (en suspens).

Dans le même esprit, on peut utiliser des files d’attente de données pour une communication asynchrone plus immédiate entre deux applications. Bien que les files d’attente de données soient exclusives à l’iSeries, on trouve des concepts similaires sur beaucoup d’autres plates-formes. Par exemple, la gamme de produits IBM MQ Series s’appuie entièrement sur le concept de messagerie asynchrone.