| 
TRIGGERS Définitions : Un TRIGGER est un programme contenant un ensemble d'actions effectuées automatiquement quand une opération de modification est réalisée sur une table ou un fichier spécifique. L'opération de modification (TRIGGER EVENT) peut être une insertion, une mise à jour ou une suppression depuis un programme applicatif. Le moment d'appel du programme (TRIGGER TIME) peut se situer avant ou après l'opération de modification du fichier. Dans le cas d'une opération de mise à jour, l'appel du programme peut se faire soit toujours, soit uniquement en cas de modification d'une valeur (TRIGGER UPDATE CONDITION). |
|
Cas d'utilisation : Les triggers peuvent être employés pour : - obliger au respect de règles internes - valider des données d'entrée - générer une valeur unique liée à un nouveau champ dans un autre fichier (fonction de substitution) - écrire dans un autre fichier pour conserver une trace - mettre à jour un fichier de références croisées - accéder à des fonctions système (par ex. imprimer un message quand une règle est violée) - dupliquer les données dans un autre fichier pour augmenter la sécurité (sur un autre système ?) |
|
Avantages : - Développement plus rapide des applications Les opérations effectuées par les triggers sont stockées dans la Base de Données, et n'ont donc plus besoin d'être programmées dans chaque application. - Renforcement des règles internes Un trigger est défini une seule fois, mais est utilisé par chaque application accédant à la Base de Données. - Maintenance facilitée Si une règle interne est remplacée, seul le trigger concerné doit être modifié et non chaque programme applicatif. - Amélioration des performances en environnement client/serveur Toutes les règles s'exécutent sur le serveur avant l'envoi du résultat ou la réalisation de l'action B de D. |
|
En pratique : Pour utiliser la fonction trigger, vous devez écrire un programme, puis l'ajouter à un fichier physique. Ajouter déclencheur fich phys (ADDPFTRG) Indiquez vos choix, puis appuyez sur ENTREE. Fichier physique . . . . . . . . FILE ########## Bibliothèque . . . . . . . . . *LIBL Moment de déclenchement . . . . TRGTIME ######## Evénement de déclenchement . . . TRGEVENT ######## Programme . . . . . . . . . . . PGM ########## Bibliothèque . . . . . . . . . *LIBL Remplacer déclencheur . . . . . RPLTRG *NO |
|
Ajouter déclencheur fich phys (ADDPFTRG) Indiquez vos choix, puis appuyez sur ENTREE. Fichier physique . . . . . . . . CLIENTP Nom Bibliothèque . . . . . . . . . *LIBL Nom, *LIBL, *CURLIB Moment de déclenchement . . . . *BEFORE *BEFORE, *AFTER Evénement de déclenchement . . . *UPDATE *INSERT, *DELETE, *UPDATE Programme . . . . . . . . . . . TRIGGER1 Nom Bibliothèque . . . . . . . . . *LIBL Nom, *LIBL, *CURLIB Remplacer déclencheur . . . . . *NO *NO, *YES |
|
Ajouter déclencheur fich phys (ADDPFTRG) Indiquez vos choix, puis appuyez sur ENTREE. Fichier physique . . . . . . . . > CLIENTP Nom Bibliothèque . . . . . . . . . *LIBL Nom, *LIBL, *CURLIB Moment de déclenchement . . . . > *BEFORE *BEFORE, *AFTER Evénement de déclenchement . . . > *UPDATE <--+ *INSERT, *DELETE, *UPDATE Programme . . . . . . . . . . . > TRIGGER1 | Nom Bibliothèque . . . . . . . . . *LIBL | Nom, *LIBL, *CURLIB Remplacer déclencheur . . . . . *NO | *NO, *YES Condition déclenchement en màj *ALWAYS <--+ *ALWAYS, *CHANGE | | .....................|........................ : le mot-clé TRGUPDCND ne s'affiche que si : : TRGEVENT est saisi avec la valeur *UPDATE : :............................................: |
|
Fichier . . . . : QPDSPFD Page/Ligne 1/1 Contrôle . . . . Colonnes 1 - 78 Recherche . . . . *...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+... 14/04/95 Description de fichier Paramètres de la commande DSPFD Fichier . . . . . . . . . . . . . . . . . . : FILE CLIENTP Bibliothèque . . . . . . . . . . . . . . : *LIBL Type d'information . . . . . . . . . . . . : TYPE *ALL Attributs du fichier . . . . . . . . . . . : FILEATR *ALL Système . . . . . . . . . . . . . . . . . . : SYSTEM *LCL ...................................................................... :Description de déclencheur : : Heure de déclenchement . . . . . . . . : *BEFORE : : Evénement de déclenchement. . . . . . . : *UPDATE : : Condition de déclenchement. . . . . . . : *ALWAYS : : Nom du programme . . . . . . . . . . . : PGM TRIGGER1 : : Bibliothèque . . . . . . . . . . . . : LIB AF4TEMP : :....................................................................: |
|
Enlever déclencheur fichier (RMVPFTRG) Indiquez vos choix, puis appuyez sur ENTREE. Fichier physique . . . . . . . . FILE ########## Bibliothèque . . . . . . . . . *LIBL Moment de déclenchement . . . . TRGTIME *ALL Evénement de déclenchement . . . TRGEVENT *ALL ............................................ : Les triggers peuvent être tous enlevés : : en une seule fois, ou bien moment par : : moment, événement par événement. : :..........................................: |
|
Programme trigger et contrôle de validation : FONCTIONNEMENT HORS CONTROLE DE VALIDATION Si le programme applicatif et le programme trigger ne s'exécutent pas sous contrôle de validation, toute erreur du programme trigger laissera les fichiers dans l'état au moment de l'erreur. FONCTIONNEMENT SOUS CONTROLE DE VALIDATION Si le programme applicatif seul s'exécute sous contrôle de validation, l'opération COMMIT du programme applicatif s'applique uniquement à ses propres modifications. Si le programme trigger seul s'exécute sous contrôle de validation, les modifications effectuées par le programme trigger sont validées quand : - le groupe d'activation se termine (COMMIT implicite) - une opération de COMMIT est demandée par le programme |
|
Si le programme applicatif et le programme trigger s'exécutent sous le même contrôle de validation, un arrêt anormal du programme trigger entraînera le Rollback de toutes les opérations qui lui sont associées. Un Rollback est également effectué sur l'opération de modification d'origine. Ceci nécessite que le programme trigger envoie un message d'exception quand l'erreur est détectée. Les deux programmes sont alors fortement couplés , c'est la solution pour un trigger chargé de détecter des erreurs pouvant annuler l'action B de D. Si le programme applicatif et le programme trigger s'exécutent sous des contrôles de validation différents, l'opération COMMIT du programme applicatif n'agit que sur son propre contrôle de validation. La validation des modifications du programme trigger doit être effectuée de façon distincte. les deux programmes sont faiblement couplés, c'est la solution pour un trigger chargé de répercuté des actions (dans un autre fichier) |
|
Ecriture d'un programme trigger : Une opération de modification, sur un fichier physique ayant un trigger associé, déclenchera l'appel du programme trigger concerné. L'opération de modification passera 2 paramètres au programme trigger. Dans ces paramètres, le programme récupérera une copie des enregistrements avant et après l'opération. Paramètres Types Buffer contenant les informations sur l'opération Char(*) Longueur du buffeur Binary(4) Le buffer contient 2 parties, une partie fixe et une partie variable. La partie fixe contient le nom du fichier, du membre, l'événement, le moment, le niveau de vérouillage de la définition de validation, et le CCSID de l'enregistrement concerné par l'opération (soit 95 charac.). La partie variable contient les images de l'enregistrement avant et après modification. |
|
Description du buffer : Dépl Type Champ 0 Char(10) Nom du fichier physique 10 Char(10) Nom de la librairie 20 Char(10) Nom du membre 30 Char(1) Evénement déclencheur (1=INSERT,2=DELETE,3=UPDATE) 31 Char(1) Moment du déclenchement (1=AFTER,2=BEFORE) 32 Char(1) Niveau de verrouillage de la définition de validation (0=*NONE,1=*CHG,2=*CS,3=*ALL) 36 Binary(4) CCSID des données 48 Binary(4) Image avant : Déplacement de l'enregistrement 52 Binary(4) Longueur de l'enregistrement 56 Binary(4) Déplacement de la description des champs 60 Binary(4) Longueur de la description des champs 64 Binary(4) Image après : Déplacement de l'enregistrement 68 Binary(4) Longueur de l'enregistrement 72 Binary(4) Déplacement de la description des champs 76 Binary(4) Longueur de la description des champs 96 Char(*) Début de la zone variable |
|
Le pgm trigger peut signaler une erreur logique : + il doit envoyer un message à l'appelant attention avec ILE, une procédure PEP est ajoutée dans la liste d'invocation. PEP = Program Entry Point il faut donc envoyer 2 niveaux au-dessus ou utiliser la valeur *PGMBDY avec l'API QMHSNDPM (envoi de msg) + l'action base de données est interrompue inachevée. + le message CPF502B est émis, le message envoyé par votre trigger n'est pas retransmis (donc le texte est inutilisable) |
|
Divers : Les triggers peuvent être écrits dans n'importe lequel des langages utilisés sur l'AS/400. Le programme trigger doit être de type *PGM. Il ne peut pas être de type *SRVPGM (programme de service ILE). Le programme ne peut pas contenir d'opérations COMMIT, ROLLBACK ou ENDCMTCTL pour la définition de validation associée au programme applicatif. Les programmes trigger et applicatif peuvent s'exécuter dans des groupes d'activation différents ou non. Il est recommandé de compiler le trigger avec ACTGRP(*CALLER) pour augmenter le lien entre les deux programmes. Un programme trigger peut appeler d'autres programmes, ou même être imbriqué en cascade (une opération dans un trigger provoque l'appel d'un autre trigger). Il peut donc s'appeler de façon récursive. Le nombre maximum de niveaux d'imbrications est 200. |
|
Attention aux cas suivants, provoquant une erreur : - mise à jour du même enregistrement déjà modifié par l'opération de modification, ou par une opération dans le programme trigger. - génération d'un conflit sur le même enregistrement à l'intérieur d'une opération de modification. Par exemple, un enregistrement inséré par l'opération de modification puis supprimé par le programme trigger. Lors de l'ajout d'un programme trigger à un fichier physique, ce dernier et tous les logiques associés sont verrouillés de façon exclusive. Le programme s'applique à tous les membres du fichier physique. Toute modification effectuée par le biais d'un fichier logique, ou d'une vue SQL, entraîne l'appel du programme trigger. Une commande CPYF CRTFILE(*YES) ne reporte pas les attributs triggers sur le fichier créé. Une commande CRTDUPOBJ reporte tous les attributs triggers. |
