🚀 Optimiser les appels API en RPG : Gestion des gros volumes de données et parsing JSON avec YAJL

Dans le monde de l’intégration système, les APIs REST sont devenues incontournables pour échanger des données entre applications. Mais quand ces APIs retournent des réponses JSON volumineuses, comment les traiter efficacement en RPG sans saturer la mémoire ou perdre en performance ?

Dans un récent projet, j’ai dû relever ce défi en développant un programme RPG/ILE pour synchroniser des commandes clients via une API externe. Voici les solutions techniques clés mises en œuvre pour gérer ces contraintes :

🔹 1. Gestion des gros volumes de données : Éviter les buffers saturés

Les APIs peuvent retourner des réponses JSON de plusieurs Mo, bien au-delà des limites des buffers RPG classiques (32Ko par défaut). Pour contourner ce problème, j’ai opté pour :

✅ L’écriture directe dans l’IFS :

• Au lieu de stocker la réponse JSON en mémoire, le programme écrit les données par morceaux dans un fichier temporaire sur l’IFS (Integrated File System).

• Cela permet de traiter des réponses de taille illimitée sans risque de débordement.

• Une fois le fichier complet, il est lu et parsé progressivement, réduisant ainsi la charge mémoire.

✅ Utilisation des flux AXIS (Web Services Client for ILE) :

• La bibliothèque AXIS d’IBM permet de gérer les appels HTTP/HTTPS avec des méthodes comme axiscTransportReceive(), qui lit les données par blocs.

• Couplé à une boucle de réception, cela évite de tout charger en mémoire d’un coup.

💡 Pourquoi c’est efficace ? 

→ Moins de risques de plantage (plus de MCH1210 ou MCH3601 liés à la taille des buffers).

→ Meilleure scalabilité : le programme peut gérer des réponses de 10 Mo comme de 1 Go sans modification.

🔹 2. Parsing JSON structuré avec YAJL

Une fois les données récupérées, il faut les déstructurer pour les stocker en base. Ici, le choix s’est porté sur YAJL (Yet Another JSON Library) pour plusieurs raisons :

✅ Parsing rapide et léger :

• YAJL est une bibliothèque C optimisée, intégrée en RPG via le DATA-INTO.

• Elle permet de mapper directement le JSON vers des structures de données RPG (DS), sans avoir à écrire manuellement des boucles de parsing.

✅ Gestion des schémas complexes :

• Le JSON retourné par l’API contenait des objets imbriqués (commandes, articles, adresses, expéditions, etc.).

• Avec YAJL, j’ai pu définir des DS qualifiées reflétant exactement la structure du JSON, comme : 

  

• Le DATA-INTO avec %PARSER('YAJL/YAJLINTO') fait alors le travail de mapping automatiquement.

✅ Tolérance aux erreurs :

• L’option allowextra=yes permet d’ignorer les champs JSON non mappés, évitant ainsi des plantages si l’API évolue.

• Un log d’erreurs est généré en cas de problème de format (QMHSNDPM).

💡 Pourquoi YAJL plutôt qu’un parsing "maison" ? 

→ Gain de temps : Pas besoin d’écrire des centaines de lignes pour extraire chaque champ. 

→ Moins d’erreurs : Le mapping est déclaratif et validé à la compilation. 

→ Performances : YAJL est beaucoup plus rapide qu’un parsing manuel avec %SCAN ou %SUBST.

🔹 3. Optimisations complémentaires

Pour rendre le tout encore plus robuste, j’ai ajouté : 

🔸 Un système de token JWT avec rafraîchissement automatique (stocké en base). 

🔸 Des transactions SQL optimisées (NO COMMIT pour les lectures, commit groupé pour les mises à jour). 

🔸 Un logging détaillé (via QMHSNDPM et SNDMSG) pour le suivi des erreurs. 

🔸 La gestion des timezones pour les dates (conversion ISO → timestamp).

📌 En résumé : Les bonnes pratiques à retenir

🚀 Pourquoi ce choix technique est-il pertinent en 2025 ?

Avec l’essor des microservices et des APIs cloud, les systèmes IBM i doivent de plus en plus dialoguer avec l’extérieur. Les solutions comme :

• AXIS pour les appels HTTP/HTTPS,

• YAJL pour le parsing JSON,

• L’IFS pour gérer les gros volumes,

… permettent de moderniser le RPG sans tout réécrire en Java ou Node.js.