Offrez la

Le module RPG IV CallerID permet d'identifier le programme ayant provoqué une modification d'une base de données. Vous êtes-vous jamais demandé ce qui se cachait à  l'autre bout de l'appel d'un programme trigger ? Eh bien, il est maintenant possible d'installer "CallerID" (gratuitement) pour permettre aux programmes trigger de déceler l'origine des modifications survenues dans la base de données.

Techniquement, des opérations internes sur les fichiers OS/400 telles que QDBPUT (Database add a record) et QDBUDR (Database update, delete, or release a record) entraînent l'appel d'un programme trigger. Toutefois, avec l'aide de quelques API de gestion des messages, il est possible d'identifier le programme qui se cache derrière ces opérations.

La connaissance de l'origine des modifications de la base de données peut se révéler fort utile. Envisageons les scénari suivants :

Attention: inondation. Etant donné que les triggers interceptent toutes les modifications effectuées dans un fichier base de données, ils peuvent se révéler efficaces pour assurer la cohérence des données dans une ou plusieurs applications. Mais, un fichier qui change fréquemment peut imposer une charge très importante à  un programme trigger. Aussi, afin de limiter le surcroît de travail de ce type de programme, on peut choisir de filtrer certaines des modifications pour que le programme trigger n'exécute pas l'intégralité de sa routine à  chaque fois qu'une modification est effectuée.

Supposons que vous utilisiez un programme trigger pour introduire des modifications démographiques effectuées par une application sur une autre, et que l'application effectuant les modifications stocke des informations démographiques et financières dans le même fichier. Supposons également que vous ayez un traitement de nuit sur ce fichier, qui ne met à  jour que les informations financières mais agit sur un grand nombre d'enregistrements. Plutôt que de comparer systématiquement les images de chaque champ "démographie" avant et après que le programme trigger ait été appelé, vous pouvez simplement filtrer les modifications effectuées par le traitement de nuit.

Surveiller toutes les issues. Peut-être essayez-vous de faire un contrôle qualité en surveillant la fréquence à  laquelle il est nécessaire de "glisser" des modifications dans une base de données du fait de limitations des applications existantes. Il est possible de calculer le nombre de fois que DFU (Data File Utility ), SQL ou un utilitaire base de données quelconque a été utilisé pour modifier certains fichiers de la base. Même si vos applications standards sont excellentes, vous pouvez souhaiter garder une trace des interventions réalisées sur les fichiers sans utiliser d'application, pour identifier des violations de sécurités potentielles, ou d'éventuels besoins en formation.

Eviter les boucles sans fin. Imaginons que vous utilisiez des programmes triggers pour transmettre des modifications démographiques entre une application A et une application B. Quand un fichier est mis à  jour dans l'application A, le programme trigger met à  jour le fichier associé de l'application B, et vice versa. Ce processus paraît clair et simple. Cependant, il se pose un problème lorsque le programme trigger de l'application A met à  jour un fichier de l'application B, obligeant le trigger de cette dernière à  mettre à  jour l'enregistrement original qui a été modifié dans l'application A. Ce cas de figure peut provoquer l'appel récursif du programme trigger de l'application A, d'où risque de bouclage.

Des boucles inutiles peuvent également poser problème lorsqu'une interface EDI (Echange de Données Informatisées) est utilisée entre deux systèmes. Une modification de la base de données d'un système se répercuter de système en système jusqu'à  ce que le système récepteur sache que la modification provient du système émetteur, et que par conséquent il n'est pas nécessaire de lui renvoyer la modification.