Pont API entre ERP SAP et mainframe industriel

Contexte

Ce groupe industriel du CAC 40 venait de finaliser un déploiement SAP S/4HANA sur l’ensemble de ses filiales européennes. L’objectif était d’unifier la gestion financière et supply chain sur une plateforme unique.

Mais un problème critique n’avait pas été anticipé : le cœur de la gestion de production — ordres de fabrication, gestion des stocks matières premières, traçabilité ISO — était piloté par un mainframe IBM vieux de 20 ans, avec des milliers de lignes de COBOL certifiées ISO 9001. Ces programmes ne pouvaient pas être modifiés sans remettre en cause la certification, un processus de 18 mois et plusieurs centaines de milliers d’euros.

La situation créée : SAP S/4HANA “ne savait pas” ce qui se passait sur le mainframe. Les équipes de production imprimaient les rapports mainframe le matin, les ressaisissaient dans SAP l’après-midi. Un flux de travail manuel, source d’erreurs, qui annulait une partie de la valeur de l’ERP.

Défi

La contrainte centrale : aucune modification du code COBOL certifié ISO 9001. Toute modification d’un programme certifié entraîne une re-certification partielle ou totale, avec un délai et un coût incompatibles avec le planning du projet.

La complexité technique : les données mainframe étaient stockées dans des fichiers VSAM (Virtual Storage Access Method), un format de données ancien non-relationnel, accessible uniquement via des programmes COBOL spécifiques. SAP, lui, attend du JSON ou des appels BAPIs.

La contrainte de performance : les opérateurs de production avaient besoin d’une vue quasi-temps réel sur les stocks pour piloter les ordres de fabrication. La synchronisation nocturne, qui prenait 24 heures, n’était plus acceptable.

Approche

Choix architectural : façade de lecture non-intrusive.

Plutôt que de modifier les programmes COBOL existants, un nouveau programme COBOL “extracteur” a été développé et installé en dehors du périmètre certifié. Ce programme lisait les fichiers VSAM en mode lecture seule et publiait les données dans un format structuré via MQ Series.

Ce choix a été validé avec l’auditeur ISO : un programme en lecture seule sur des fichiers VSAM n’affecte pas la certification des programmes de mise à jour.

//EXTRACT  JOB (ACCT),'VSAM EXTRACTOR',CLASS=A,MSGCLASS=X
//STEP1    EXEC PGM=VSAMEXTR
//STEPLIB  DD DISP=SHR,DSN=PROD.NEWLIB.LOADLIB
//STOCK    DD DISP=SHR,DSN=PROD.VSAM.STOCK
//ORDFA    DD DISP=SHR,DSN=PROD.VSAM.ORDERFAB
//MQOUT    DD DISP=SHR,DSN=PROD.MQSERIES.QUEUE
//SYSOUT   DD SYSOUT=*

Ce job tournait toutes les 90 secondes via le scheduler JCL interne.

Côté SAP : un adapter SAP BTP (Business Technology Platform) consommait le topic Kafka alimenté par MQ Series, transformait les données COBOL/VSAM en BAPIs SAP, et mettait à jour les stocks et ordres de fabrication dans S/4HANA.

Une API REST légère (AWS Lambda + Java) permettait également à SAP de déclencher certaines actions sur le mainframe (création d’un ordre de fabrication) en écrivant dans une table DB2 que les programmes COBOL lisaient à intervalle régulier.

Sécurité. Toute l’intégration était sécurisée via OAuth2 + mTLS entre les composants AWS et SAP BTP, avec logs d’audit complets pour la traçabilité ISO.

Résultats

Le gain de temps le plus visible était la disparition de la “ressaisie de 14h” que les opérateurs effectuaient chaque après-midi depuis 3 ans. Six mois après le déploiement, le ROI du projet était atteint rien qu’en heures-homme économisées.

[À COMPLÉTER PAR ABDERRAHMANE] — Confirmation des métriques avec le groupe industriel concerné