> Tech > Offrez la

Offrez la

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

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.

Malheureusement, dans les scenari ci-dessus, le nom du programme recherché n’est
pas aisément disponible au programme trigger. Un programme trigger ne reçoit des
informations que sur l’événement qui l’a déclenché (ajout, mise à  jour ou suppression
par exemple) et sur le fichier concerné par la modification. Mais, avec le module
RPG IV CallerID, il est possible d’obtenir facilement l’information recherchée.
Il suffit de lier le module à  un programme trigger pour déterminer le programme
à  l’origine de la modification de la base de données.

Pour obtenir le nom du programme qui a déclenché le trigger, CallerID utilise
deux API de gestion des messages: QMHSNDPM (Send Program Message) et QMHRCVPM
(Receive Program Message). En premier lieu, le programme utilise l’API QMHSNDPM
pour envoyer un message à  la file d’attente des messages à  l’entrée de la pile
d’appel du programme modifié. Ensuite, l’API QMHRCVPM récupère le message de la
file d’attente de messages, obtenant ainsi le nom du programme associé à  cette
entrée dans le processus.

CallerID utilise deux API de
gestion des messages: QMHSNDPMet QMHRCVPM

Pour identifier l’emplacement exact de l’entrée de la pile d’appel, CallerID utilise
un compteur de pile d’appel. Ce nombre indique combien d’appels de la pile d’appel
séparent une entrée de CallerID. Pour ma part, j’ai utilisé la logique suivante
pour déterminer la valeur exacte du compteur de pile d’appel à  utiliser: si le
compteur de pile d’appel est égal à  0 pour l’entrée de la pile d’appel du module
CallerID, alors le module principal du trigger qui a appelé CallerID est égal
à  1, la procédure d’entrée de programme trigger du programme (PEP) est égale à 
2, les programmes base de données internes (QDBPUT ou QDBUDR par exemple), qui
réalisent les opérations sur le fichier, ont pour valeur 3, et l’entrée de la
pile d’appel du programme à  l’origine de la modification de base de données (c’est-à -dire
du WRITE, UPDATE, du DELETE ou de toute autre st de mise à  jour) est égale à  4
(chaque programme RPG/400 ILE contient implicitement une PEP. Lorsqu’un programme
ILE est appelé, la PEP est d’abord ajoutée à  la pile d’appel.
Ensuite, le système effectue automatiquement un appel de procédure et le module
principal du trigger est ajouté à  la pile d’appel).

Téléchargez gratuitement cette ressource

Cybersécurité sous contrôle à 360°

Cybersécurité sous contrôle à 360°

Avec Cloud in One, les entreprises ne gagnent pas uniquement en agilité, en modernisation et en flexibilité. Elles gagnent également en sécurité et en résilience pour lutter efficacement contre l’accroissement en nombre et en intensité des cyberattaques. Découvrez l'axe Cybersécurité de la solution Cloud In One.

Tech - Par iTPro.fr - Publié le 24 juin 2010