On entend encore régulièrement, sur les projets S/4HANA récents, que le batch input « c’est du passé, on n’utilise plus que LTMC ». L’affirmation est commode, elle simplifie la vie d’un chef de projet qui veut figer un standard de migration. Sauf qu’elle est fausse. Le batch input n’a pas disparu, il a changé de rôle. En 2026, il n’est plus l’outil de chargement initial (Migration Cockpit a pris cette place), mais il reste l’arme tactique qu’on dégaine quand une transaction Z custom, un correctif de masse en production ou un script BDC hérité refuse de mourir. Cet article le positionne pour ce qu’il est aujourd’hui : pas la méthode principale, mais un outil de niche dont on ne peut toujours pas se passer.
- Le batch input rejoue automatiquement une transaction écran par écran via une session stockée dans les tables
APQIetAPQD, pilotée parSM35. - En 2026 sur S/4HANA, l’outil par défaut pour un chargement initial est Migration Cockpit (
LTMC), pas le batch input. - Le batch input reste utile dans trois cas : transactions Z custom, correctifs de masse ponctuels en production, maintenance de scripts BDC anciens.
- Pour une nouvelle interface technique, préférez systématiquement une BAPI, un service OData ou un Business Object RAP au batch input.
- Le mode
Backgroundest le seul viable au-delà de quelques milliers d’enregistrements ; le modeProcess foregroundsert au debug, jamais à la production.
Comment fonctionne un batch input sous le capot
Le batch input repose sur un mécanisme baptisé BDC pour Batch Data Communication. L’idée est simple. On enregistre ce qu’un utilisateur ferait à l’écran (sélection d’un menu, saisie d’un champ, validation), on structure cette séquence dans une table système, et on fait rejouer le tout par le système comme s’il s’agissait d’une saisie humaine. SAP ne triche pas avec les contrôles. Chaque écran rejoué passe par les mêmes vérifications de cohérence qu’une saisie manuelle. C’est ce qui explique à la fois la fiabilité de la méthode et sa lenteur relative.
Concrètement, une session batch input est un objet stocké dans deux tables principales. APQI contient l’en-tête de la session (nom, statut, créateur, nombre de transactions). APQD stocke les données écran par écran via la structure ABAP BDCDATA. Deux autres tables interviennent en arrière-plan : APQL pour le verrouillage et APQO pour les sessions en cours d’exécution. Aucune de ces tables ne doit être modifiée directement. Elles sont pilotées par les modules fonctions BDC_OPEN_GROUP, BDC_INSERT et BDC_CLOSE_GROUP.
La transaction SM35 est la console qui permet de voir, analyser et relancer ces sessions. Son écran principal liste toutes les sessions du système avec leur statut : New (créée, pas encore traitée), Run (en cours), Error (au moins un enregistrement a échoué), Keep (terminée mais conservée pour analyse), Read (en lecture seule).
La référence à connaître est la SAP Note 36677, qui détaille les limitations connues et les bonnes pratiques depuis l’époque ECC. Elle reste citée dans les notes plus récentes liées à S/4HANA, ce qui en dit long sur la longévité du mécanisme.
Batch input vs LSMW vs Migration Cockpit LTMC vs BAPI vs OData : quand choisir quoi en 2026
Sur un projet S/4HANA récent, le choix de l’outil de chargement ne se fait plus comme en 2015. Migration Cockpit (LTMC), officiellement disponible depuis S/4HANA 1610, a pris la place que LSMW occupait. Aucun outil ne couvre pourtant tous les besoins. Voici la grille de décision que j’applique sur mes projets.
| Outil | Quand l’utiliser | Quand l’éviter |
|---|---|---|
| Batch input | Transactions Z custom, correctifs ponctuels, sessions héritées à maintenir | Chargement initial S/4HANA, gros volumes récurrents |
| LSMW | Projets ECC encore actifs, scripts existants à reprendre | Tout nouveau développement sur S/4HANA |
| LTMC (Migration Cockpit) | Chargement initial S/4HANA, objets standard couverts, brownfield ou greenfield | Transactions custom non couvertes par un objet de migration officiel |
| BAPI / RFC | Interface technique permanente, intégration entre systèmes, qualité élevée requise | Pas de BAPI publique sur l’objet métier visé |
| OData / RAP | Architecture cloud-first, intégration applicative moderne, S/4HANA Cloud | Pas de service exposé pour l’objet métier, contexte on-premise pur |
La règle implicite : si une BAPI ou un service OData existe et couvre votre objet métier, prenez-les sans hésiter. Vous gagnez en performance, en lisibilité ABAP et en stabilité face aux changements de versions. Le batch input ne revient dans la conversation qu’une fois ces options écartées.
Les 3 modes d’exécution SM35 et leur critère de choix
Quand on lance une session batch input depuis SM35, SAP propose trois modes d’exécution. Le choix n’est pas cosmétique. Il détermine à la fois le temps de traitement et la quantité d’attention humaine requise.
| Mode | Comportement | Quand l’utiliser |
|---|---|---|
| Process foreground (A) | Chaque écran s’affiche, attend la validation. Modification en direct possible. | Debug d’une session qui plante, première exécution d’un script nouveau. Inutilisable en production sur de gros volumes. |
| Display errors only (E) | Avance sans afficher d’écran tant que tout est correct. S’arrête sur erreur. | Sessions de taille moyenne sur des données dont on n’est pas certain. |
| Background (N) | Job en arrière-plan sous l’utilisateur créateur. Aucune interaction. Rapport via SM37. | Seul mode viable au-delà de quelques milliers d’enregistrements. Pattern recommandé par la SAP Note 101968 pour RSBDCSUB. |
Mon réflexe sur mission : je teste toujours en Process foreground sur trois ou quatre enregistrements pris au hasard avant de lancer en Background. Le coût de cinq minutes en mode pas-à-pas évite plusieurs heures de session corrompue à débugger après coup.
Construire une session batch input proprement
Le point d’entrée classique pour générer une session batch input est SHDB (Transaction Recorder). On démarre l’enregistrement, on déroule la transaction qu’on veut industrialiser, on l’arrête, et le système produit deux livrables : la structure BDCDATA remplie, et un squelette ABAP réutilisable qui appelle BDC_OPEN_GROUP, boucle sur les données avec BDC_INSERT, et clôt avec BDC_CLOSE_GROUP.
Trois précautions techniques font la différence entre un script qui survit en production et un qui casse au premier transport :
- Stabiliser l’écran de saisie avant l’enregistrement. Si la transaction comporte des variantes d’écran ou des champs custom optionnels, fixez-les via SHD0 et les variantes de transaction avant de lancer SHDB. Une session enregistrée sur un écran configurable se casse dès que la config change.
- Renseigner systématiquement
BDC_OKCODE,BDC_CURSORetBDC_DYNPRO. Ces trois champs spéciaux pilotent respectivement le code d’action (validation, retour), la position du curseur et le numéro de dynpro. Les oublier provoque des comportements aléatoires selon le contexte d’exécution. - Tester sur trois jeux de données qui couvrent les cas tordus. Un cas nominal, un cas avec champs optionnels vides, un cas avec messages d’avertissement. Cela suffit à débusquer la majorité des bugs avant la session de masse.
Le squelette ABAP généré par SHDB est volontairement basique. À vous d’y ajouter la lecture du fichier source (CSV, table de staging, sélection sur une table métier), la gestion des erreurs ligne à ligne, et le logging au format que votre équipe support utilise. Ne livrez jamais un programme batch input sans handler d’erreur structuré.
Les 7 pièges qui font exploser un batch input en prod
Voici les sept cas que j’ai vus casser des sessions batch input sur mes missions. Aucun n’est exotique. Tous sont prévisibles si on sait ce qu’on cherche.
- Lock conflict sur master data. Si un utilisateur édite l’article ou le compte client en cours, la session bloque. Vérification préalable via
SM12ou créneau d’exécution la nuit obligatoire. - Transport du programme sans transport de la session. Les sessions vivent dans
APQI/APQDet ne sont pas transportables nativement. Le programme oui. Conséquence : on transporte le code en prod puis on recrée la session sur l’environnement cible. - Session de plus de 50 000 enregistrements. Au-delà, le temps de lock sur certaines tables système devient critique. Découpez en sessions de 5 000 à 10 000 enregistrements maximum.
- Écran modal non prévu lors du recording. Une popup de confirmation, un message d’avertissement à dismisser, et toute la session déraille. Test obligatoire en Display errors only sur un échantillon avant production.
- Dépendance à la version SAP GUI ou au thème. Si l’utilisateur d’exécution a un GUI différent du créateur, certains champs peuvent ne pas exister. Toujours exécuter sous un utilisateur technique au profil standardisé.
- Champs custom Z ajoutés après l’enregistrement. Les développeurs aiment ajouter des champs sur les screens custom. Si le champ est apparu après le SHDB, la session ne le remplit pas, et la transaction passe en erreur dès qu’il est obligatoire.
- Dates et formats numériques locaux. Une session enregistrée par un user FR avec format
JJ.MM.AAAAplante chez un user EN au formatMM/DD/YYYY. Forcez les paramètres utilisateur d’exécution explicitement dans le programme.
Si une session échoue partiellement, ne relancez jamais la totalité. SM35 propose une option « Reprocess errors only » qui ne rejoue que les enregistrements en statut Incorrect. Sinon vous risquez les doublons.
Cas d’usage 2026 où batch input reste pertinent
Trois scénarios continuent à justifier le batch input en 2026, malgré la disponibilité de LTMC et des BAPI modernes.
Premier scénario : transaction Z custom non couverte par BAPI. Vous avez développé une transaction custom pour un processus métier spécifique. Aucune BAPI publique ne l’expose. Le développement d’une BAPI dédiée coûte plus cher que le besoin ne le justifie. Le batch input via SHDB livre une solution opérationnelle en une journée.
Deuxième scénario : correctif de masse en production. Un audit interne révèle qu’un champ a été mal saisi sur plusieurs milliers de fiches matière. Vous devez corriger en deux semaines. Lancer un projet de développement BAPI plus tests plus transport prend un mois. Une session batch input MM02 bien construite, validée en pré-prod, livre la correction dans la semaine.
Troisième scénario : rollout S/4HANA avec scripts hérités. Une filiale rejoint le déploiement central. Elle apporte des scripts BDC historiques pour ses chargements récurrents. Réécrire chaque script en LTMC ou en BAPI demande des mois. Maintenir le batch input le temps de la transition, c’est aussi du pragmatisme projet.
Sur les chargements récurrents de nomenclatures (BOM) dans le module PP, j’ai longtemps utilisé du batch input sur CS01 avant de migrer vers la BAPI standard BAPI_MATERIAL_BOM_GROUP_CREATE. Pour les production versions, le cas est différent : la création passe plutôt par les API standard du master data PP. Une fois la BAPI maîtrisée, on ne revient pas en arrière sur ce type de chargement.
Sur mes projets industriels, je n’ai jamais vu un batch input « éliminé une fois pour toutes ». Il revient toujours, sur une transaction Z, un correctif de masse, ou une filiale qui apporte ses scripts. Mieux vaut bien le maîtriser que prétendre ne plus en avoir besoin.
Pierre Balbinot, consultant SAP PP / EAM
Questions fréquentes sur le batch input SAP
À quoi sert la transaction SM35 SAP ?
SM35 (Batch Input: Session Overview) est la transaction de pilotage des sessions batch input. Elle liste toutes les sessions du système, affiche leur statut (New, Run, Error, Keep, Read), permet d’analyser les enregistrements en erreur ligne à ligne, et de relancer le traitement. Pour le mode background, on l’utilise en combinaison avec SM35P (mass processing) et le programme RSBDCSUB.
Quelle différence entre batch input et LTMC (Migration Cockpit) ?
Le batch input simule un utilisateur qui rejoue une transaction écran par écran via la structure BDCDATA et les sessions stockées dans APQI et APQD. LTMC utilise des objets de migration officiels SAP avec staging tables ou fichiers XML, sans passer par les écrans. En 2026 sur S/4HANA, LTMC est l’outil officiel recommandé pour les chargements initiaux ; le batch input reste utile pour les transactions Z custom non couvertes ou pour les correctifs ponctuels en production.
À quoi sert la transaction SHDB SAP ?
SHDB (Transaction Recorder) enregistre une transaction SAP effectuée manuellement et génère automatiquement la structure BDCDATA correspondante ainsi qu’un programme ABAP réutilisable. C’est l’outil de base pour construire une session batch input. Le programme généré utilise les modules fonctions BDC_OPEN_GROUP, BDC_INSERT et BDC_CLOSE_GROUP. Un article dédié à SHDB est en préparation.
Quels sont les 3 modes d’exécution d’un batch input ?
Process foreground (mode A) affiche chaque écran et attend la validation, utile pour debug. Display errors only (mode E) accélère l’exécution et s’arrête seulement sur erreur. Background (mode N) lance un job en arrière-plan sous l’utilisateur créateur, rapport consultable via SM37. Le mode background est le seul viable au-delà de quelques milliers d’enregistrements.
Le batch input est-il obsolète en S/4HANA ?
Non. SAP recommande désormais Migration Cockpit (LTMC) pour les chargements initiaux S/4HANA, mais le batch input reste pleinement supporté et utilisé en 2026 dans trois cas : transactions custom Z non couvertes par LTMC ni BAPI, correctifs de masse ponctuels en production, maintenance d’héritage de scripts BDC anciens. La SAP Note 36677 documente toujours officiellement le batch input.
En résumé : batch input, outil tactique de 2026
Le batch input n’est ni une relique à oublier ni la méthode par défaut de votre prochain projet S/4HANA. C’est un outil tactique qu’on garde affûté pour les cas où LTMC, BAPI et OData ne couvrent pas le besoin. Maîtrisez SM35, le recorder SHDB, les trois modes d’exécution et les sept pièges classiques : vous tiendrez la production sans céder à la mode du « tout LTMC ». Le réflexe de senior, c’est de savoir choisir l’outil adapté à la situation, pas de remplacer toute sa boîte à outils à chaque changement de version.
À lire ensuite
Gestion des lots SAP : guide débutant (MM, PP, QM)
Comprenez la gestion des lots dans SAP : à quoi ça sert, comment activer le batch management dans MM, PP, QM, et créer un lot avec MSC1N. Guide pas à...
Pierre B.
SAP Batch Determination : guide configuration et pièges réels
Tu paramètres la batch determination SAP ? Les 6 étapes (COB1, OPL8, condition tables) plus les pièges qu'on rencontre en prod, par un consultant terrain.
Pierre B.
Numéro de série SAP : guide de décision OIS2, 6 procédures et arbitrage matériel vs équipement PM
Quand activer la sérialisation SAP, comment paramétrer le profil OIS2, choisir parmi les 6 serializing procedures et arbitrer entre numéro de série matériel et équipement PM.
Pierre B.
Spécification fonctionnelle SAP : la trame d’une FS qui tient en projet (WRICEF, validation, pièges)
Guide consultant pour structurer une FS SAP par catégorie WRICEF, valider avec le client et éviter les 7 pièges qui font dériver un développement.
Pierre B.