log­fo­ri : log­ging appli­ca­tif et tra­ça­bi­li­té pour déve­lop­peurs IBM i

Quand je déve­loppe sur IBM i, il y a tou­jours un moment où je me pose la même question :

que fait réel­le­ment mon appli­ca­tion une fois en production ?

Pas ce qu’elle est cen­sée faire.
Ce qu’elle fait vrai­ment, dans un job, à un ins­tant don­né, avec un contexte précis.

C’est de ce besoin très concret qu’est né log­fo­ri.

Le constat de départ

Dans beau­coup d’applications IBM i, le log­ging appli­ca­tif est souvent :

• dis­per­sé dans le code,
• peu homo­gène,
• dif­fi­cile à exploiter,
• et rare­ment pen­sé comme un vrai com­po­sant applicatif.

On ajoute des traces au fil de l’eau, par­fois pour débo­guer, par­fois pour ras­su­rer…
mais sans vision d’ensemble.

Résul­tat :
👉 com­prendre un com­por­te­ment appli­ca­tif ou ana­ly­ser un inci­dent devient long et pénible.

Ce que j’ai vou­lu faire avec logfori

Avec log­fo­ri, mon objec­tif était simple :
👉 struc­tu­rer le log­ging appli­ca­tif, sans alour­dir le code métier.

Je vou­lais :

• une API claire pour pro­duire des logs applicatifs,
• des niveaux de mes­sages expli­cites (INFO, DEBUG, WARN, ERROR…),
• une sépa­ra­tion nette entre logique métier et tra­ça­bi­li­té,
• un com­po­sant réuti­li­sable d’un pro­jet à l’autre.

Bref, quelque chose de simple, lisible et cohé­rent pour un déve­lop­peur IBM i.

Une approche prag­ma­tique, orien­tée déve­lop­peurs IBM i

log­fo­ri n’est pas un fra­me­work “magique”.
C’est une brique appli­ca­tive, pen­sée pour être inté­grée progressivement :

• uti­li­sable en RPG ILE / SQLRPGLE,
• cohé­rente avec une archi­tec­ture en ser­vice pro­grams,
• adap­tée aus­si bien aux trai­te­ments batch qu’aux pro­grammes interactifs,
• com­pa­tible avec des démarches de refac­to­ring et d’industrialisation.

On peut l’introduire là où le besoin se fait sen­tir, sans tout remettre en cause.

Pour­quoi struc­tu­rer le log­ging applicatif ?

Un log­ging appli­ca­tif bien pen­sé permet :

• de mieux com­prendre le com­por­te­ment réel des applications,
• de diag­nos­ti­quer plus rapi­de­ment les incidents,
• d’améliorer la main­te­na­bi­li­té du code,
• et d’homogénéiser les pra­tiques au sein d’une équipe.

Ce n’est pas du “confort”.
C’est un outil de qua­li­té logi­cielle.

Un socle pour aller plus loin

log­fo­ri pose aus­si les bases de :

• l’obser­va­bi­li­té appli­ca­tive sur IBM i,
• une exploi­ta­tion plus effi­cace en production,
• une meilleure com­mu­ni­ca­tion entre déve­lop­pe­ment et support.

C’est typi­que­ment le genre de com­po­sant qu’on oublie…
jusqu’au jour où il devient indispensable.

Le pro­jet

Le pro­jet est open-source et dis­po­nible ici :
🔗 https://github.com/IBMiservices/logfori

Il est pen­sé pour évo­luer, être enri­chi, et sur­tout être uti­li­sé sur des pro­jets IBM i réels.

Conclu­sion

Avec log­fo­ri, j’ai vou­lu appor­ter une réponse simple à un besoin récur­rent :
👉 rendre les appli­ca­tions IBM i plus lisibles, plus com­pré­hen­sibles et plus exploi­tables.

Un outil fait par un déve­lop­peur IBM i,
pour des déve­lop­peurs IBM i.

Sources / Références

• Dépôt offi­ciel du pro­jet log­fo­ri :
  https://github.com/IBMiservices/logfori
• Bonnes pra­tiques géné­rales de log­ging appli­ca­tif :
  prin­cipes issus des fra­me­works de log­ging modernes (niveaux, sépa­ra­tion logique métier / tra­ça­bi­li­té, lisi­bi­li­té des logs)