📲 Automatiser des traitements métiers sur IBM i via des triggers RPG depuis un système Externe

Vous devez réagir à des événements externes (retours SMS, notifications, fichiers, etc.) sur votre IBM i, mais vous ne voulez pas : 

❌ Modifier vos programmes RPG existants ? 

❌ Développer une API REST pour un besoin ponctuel ? 

❌ Gérer des mécanismes complexes comme les data queues ?

Voici comment nous avons résolu ce problème avec un trigger RPG qui : 

🔹 Surveille les insertions dans une table de contrôle (EVENT_QUEUE). 

🔹 Filtre les enregistrements selon des critères métiers (ex: statut = erreur). 

🔹 Délègue le traitement à un programme existant (PROCESS_EVENT) via SBMJOB. 

🔹 Gère les erreurs avec un logging centralisé.

🔧 Implémentation technique (extrait du code réel)

1. Configuration du trigger

Le trigger est attaché à la table EVENT_QUEUE et se déclenche après chaque insertion :

ADDPFTRG FILE(MYLIB/EVENT_QUEUE) TRGTIME(*AFTER) TRGEVENT(*INSERT)
         PGM(MYLIB/TRG_EVENT_HDL) 

2. Analyse du buffer trigger

Le programme RPG (TRG_EVENT_HDL) analyse le buffer reçu pour :

• Extraire les métadonnées (fichier, bibliothèque, type d'événement).

• Récupérer l'image de l'enregistrement inséré (AfterImage).

// Mapping du buffer trigger
pHeader = %Addr(pTriggerBuffer);
If (TriggerHeader.OffsetAfter > 0);
  pAfter = %Addr(pTriggerBuffer) + TriggerHeader.OffsetAfter;
EndIf; 

3. Logique métier conditionnelle

Seuls les événements avec un statut spécifique (ex: EVENT_STATUS = 'ERR') sont traités :

If %Subst(AfterImage.EVENT_STATUS:1:1) = STATUS_ERROR;
  // Soumettre un job pour exécuter le programme métier
  cmdStr = 'SBMJOB CMD(CALL PGM(MYLIB/PROCESS_EVENT) PARM(' +
           '''' + %Trim(AfterImage.EVENT_ID) + '''' +
           ')) JOB(EVENT_PROC) JOBQ(*LIBL/EVENT_JOBQ)';
  Monitor;
    GoCmd(CmdStr:%Len(CmdStr)); // Exécution via QCMDEXC
  On-Error;
    LogError('Erreur lors du traitement de l''événement ID: ' + AfterImage.EVENT_ID);
  EndMon;
EndIf; 

4. Gestion des erreurs

Une procédure dédiée (LogError) utilise QMHSNDPM pour tracer les problèmes :

Dcl-Proc LogError;
  Dcl-Pi *N;
    pErrorMessage Varchar(512) Const;
  End-Pi;
  SndPgmMsg(
    *Blanks:              // Message générique
    *Blanks:              // Fichier par défaut
    pErrorMessage:        // Texte de l'erreur
    %Len(%Trim(pErrorMessage)):
    '*INFO':              // Type d'information
    '*':                  // Pile d'appel actuelle
    1:                    // Niveau 1
    MsgKey:               // Clé du message
    ApiError              // Structure d'erreur
  );
End-Proc; 

✅ Pourquoi cette approche ?

⚠️ Points de vigilance

1. Volume d'insertions :

2. Table d'audit recommandée :

3. Sécurité :

🔄 Comparatif des solutions

💡 Retour d'expérience

Dans un projet récent, cette solution a permis de :

• Automatiser le traitement d'événements externes (ex: échecs de transactions) sans modifier le code métier.

• Réduire les coûts de maintenance de 60% (pas de modifications en cascade).

• Centraliser la logique de déclenchement dans un seul point (le trigger).

Exemple de flux :

Système Externe → ODBC → INSERT INTO EVENT_QUEUE → Trigger TRG_EVENT_HDL → SBMJOB(PROCESS_EVENT) → Traitement métier