On entend partout que SHDB appartient au passé, remplacé par les BAPI, Migration Cockpit et les services OData. C’est une simplification commode pour les chefs de projet qui veulent figer un standard. C’est aussi faux. SHDB reste le seul mécanisme natif qui permet de scripter une transaction SAP quand aucune BAPI ne couvre le besoin, quand l’écran custom embarque des user-exits ou des popups dynamiques, ou quand un correctif de masse one-shot doit livrer en deux jours plutôt qu’en deux mois de développement RFC. Pour un consultant SAP qui travaille sur des transactions Z ou sur des projets avec beaucoup de spécifique, le compagnon naturel du batch input reste à maîtriser sérieusement.
SHDBenregistre une transaction SAP écran par écran et génère une structureBDCDATArejouable plus un programme ABAP réutilisable.- Deux méthodes d’exécution : Session Method (passe par SM35, traçable, reprise sur erreur native) ou Call Transaction (synchrone, plus rapide, pas de queue native).
- Trois modes de mise à jour :
Ssynchrone (cohérence garantie),Aasynchrone (perf),Llocal (cas spéciaux). - Verrouiller le layout via SHD0 AVANT l’enregistrement, sinon la session casse au premier changement de variante d’écran.
- Toujours renseigner
BDC_OKCODE,BDC_CURSORetBDC_DYNPROexplicitement, jamais les laisser à la valeur par défaut.
Ce que SHDB fait vraiment sous le capot
SHDB est l’abréviation de Screen Helper / Demo for Batch input. Concrètement, c’est un enregistreur de transaction. Vous démarrez l’outil, vous déroulez manuellement une transaction (sélection d’un menu, saisie d’un champ, validation par OK code), vous arrêtez l’enregistrement, et SAP produit deux livrables.
Premier livrable, la structure BDCDATA, une table interne ABAP qui décrit chaque écran rejoué. Chaque ligne contient cinq champs principaux : PROGRAM (nom du programme dynpro), DYNPRO (numéro d’écran), DYNBEGIN (drapeau de début d’écran), FNAM (nom du champ) et FVAL (valeur à saisir). Trois champs spéciaux pilotent le comportement : BDC_OKCODE pour le code d’action, BDC_CURSOR pour la position du curseur, BDC_DYNPRO pour le numéro de dynpro courant.
Deuxième livrable, un squelette de programme ABAP qui appelle BDC_OPEN_GROUP, boucle sur les données pour faire des BDC_INSERT, et clôt avec BDC_CLOSE_GROUP. Ce squelette est rudimentaire. À vous d’ajouter la lecture du fichier source (CSV, table de staging, sélection SQL), la gestion des erreurs et le logging.
Ce mécanisme est différent d’un BAPI sur un point crucial : SHDB rejoue la couche présentation, donc il passe par toutes les validations écran, tous les user-exits dynpro, tous les contrôles métier que SAP exécute pour un utilisateur humain. Un BAPI court-circuite la couche présentation et tape directement la couche fonctionnelle. SHDB est donc plus lent, mais aussi plus fidèle au comportement d’une saisie réelle.
Session Method vs Call Transaction : critères de décision
SHDB propose deux méthodes pour exécuter le code généré. Le choix conditionne la performance, la traçabilité et la gestion d’erreur. Ce n’est pas une décision cosmétique.
| Critère | Session Method | Call Transaction |
|---|---|---|
| Traçabilité | Forte (logs SM35) | Faible (à coder) |
| Performance | Plus lente (queue + replay) | Rapide (exécution directe) |
| Reprise sur erreur | Native via SM35 | Manuelle, log à coder |
| Volume recommandé | Gros volumes batch (> 10k) | Faible volume ou temps réel |
| Cas d’usage type | Migration, correctif de masse | Interface intégrée, RFC déclenchée |
Mon réflexe sur mission : Session Method par défaut, sauf besoin de temps réel ou volume inférieur à mille enregistrements. La traçabilité via SM35 compense largement la lenteur. Pour Call Transaction, ne livrez jamais sans un handler d’erreur structuré qui range les messages de MESSTAB dans un log applicatif.
Les bonnes pratiques d’enregistrement qui font la différence
Un enregistrement SHDB de qualité n’est pas plus long à produire qu’un enregistrement bâclé, mais il survit aux mois et aux mises à jour. Voici les pratiques que j’applique systématiquement.
- Verrouiller le layout via SHD0 avant SHDB. Si la transaction comporte des variantes d’écran ou des champs optionnels qui apparaissent selon contexte, fixez la variante en amont. Une session enregistrée sur un écran configurable casse au premier changement de paramétrage. Détails dans notre article sur SHD0 et les variantes de transaction.
- Scoper minimal. Un enregistrement = un cas d’usage = un chemin. Ne pas chercher à couvrir toutes les variations en un seul recording. Plusieurs petits recordings spécialisés survivent mieux qu’un gros enregistrement universel.
- Renseigner BDC_OKCODE, BDC_CURSOR, BDC_DYNPRO explicitement. Ne pas se fier aux valeurs par défaut. Le comportement varie selon le contexte d’exécution (utilisateur, locale, version GUI) si ces trois champs ne sont pas pilotés.
- Tester sur trois jeux de données différents. Un cas nominal, un cas avec champs optionnels vides, un cas avec messages d’avertissement à dismisser. Trois jeux suffisent à débusquer la majorité des défauts avant industrialisation.
- Documenter la transaction enregistrée et les paramètres utilisateur. Le recording ne contient pas la locale, ni le profil utilisateur, ni la version GUI. Tracer ces éléments dans la documentation projet évite plusieurs heures de debug en cas de bug ultérieur.
Les modes de mise à jour S / A / L : ce qu’ils changent vraiment
Au-delà du choix Session Method ou Call Transaction, SHDB propose trois modes de mise à jour qui déterminent comment et quand les écritures en base sont commitées. C’est le paramètre le plus mal compris par les juniors, et il a des conséquences réelles en production.
Mode S, synchrone. Le programme attend que la mise à jour soit complètement commitée en base avant de rendre la main. Cohérence garantie : si une cascade de tables doit être mise à jour, tout est commit ensemble ou rien. Plus lent, surtout sur de gros volumes, mais le seul mode recommandé pour des transactions critiques (création matériel, ordre de production, écritures comptables).
Mode A, asynchrone. Le programme rend la main immédiatement après avoir programmé la mise à jour. SAP commit en arrière-plan. Performance maximale, mais le risque c’est l’incohérence inter-tables si le programme appelant boucle vite et commit des modifications dépendantes. À utiliser uniquement sur des transactions isolées dont les écritures ne dépendent pas les unes des autres.
Mode L, local update. Mise à jour en mémoire utilisateur, sans passer par le mécanisme standard d’update task. Cas d’usage très spécifiques : programmes qui veulent contrôler eux-mêmes le moment du commit via une instruction ABAP COMMIT WORK explicite. Évitez tant que vous n’avez pas une raison technique précise.
Recommandation pratique : Mode S par défaut. Passez en A uniquement sur des batchs très gros volumes où la perf est critique, et après avoir validé que les écritures sont indépendantes. N’utilisez L que sur conseil explicite d’un développeur ABAP senior.
Les 5 erreurs qui ruinent un recording SHDB
Ces cinq erreurs représentent l’écrasante majorité des incidents que je vois sur les recordings SHDB qui finissent par casser en production.
- Enregistrer sans figer le layout. La popup de confirmation, le message d’avertissement obligatoire, le champ qui apparaît seulement quand la donnée précédente vaut X, tout ce qui n’est pas systématique à l’enregistrement deviendra le bug qui casse la session en prod. Pré-requis : SHD0 lock avant SHDB.
- Ne pas gérer
BDC_OKCODEexplicitement. Le code d’action laissé à blanc se comporte différemment selon le contexte. Renseignez-le sur chaque écran (/00pour validation,/BACKpour retour, etc.). - Ignorer la table
MESSTABcôté Call Transaction. En Call Transaction, les messages d’erreur ne vont pas en queue. Si vous ne les capturez pas dansMESSTABet ne les loggez pas, vous perdez la trace de ce qui a échoué. Erreur classique :SY-SUBRCà zéro mais des warnings critiques dansMESSTABnon traités. - Confondre Mode A et Mode S sur une cascade de tables. Mode A semble plus performant à l’enregistrement, mais si la transaction écrit dans plusieurs tables dépendantes (entête + lignes + textes), l’asynchrone peut commit la moitié, et l’autre moitié plante, état incohérent en base.
- Industrialiser sans rejouer sur plusieurs jeux de données. Le recording fonctionne sur votre jeu d’enregistrement, oui. Sur les vraies données métier qui ont des variations légitimes (champs vides, dates étrangères, locales différentes), il casse. Toujours rejouer sur au moins trois jeux représentatifs.
Quand préférer BAPI, Migration Cockpit ou LSMW à SHDB
SHDB n’est pas la première option pour la plupart des besoins de chargement en 2026. Avant de scripter, vérifiez systématiquement les alternatives.
BAPI ou RFC dédiée. Si une BAPI publique couvre l’objet métier visé, prenez-la sans hésiter. Lecture ABAP plus claire, performance meilleure, stabilité face aux changements de versions GUI. SHDB ne revient que si aucune BAPI ne couvre 100 % du besoin (popups dynamiques métier, écrans custom Z sans BAPI publique).
Migration Cockpit (LTMC). Pour un chargement initial sur S/4HANA d’objets standards (matériel, client, fournisseur, BOM, équipement), LTMC est l’outil officiel SAP. Templates XML / Excel, staging tables, gestion d’erreur native, et adaptation aux contraintes S/4HANA. SHDB devient redondant sauf pour les objets custom non couverts.
LSMW. Encore utilisable sur des projets ECC actifs, mais à éviter pour tout nouveau développement S/4HANA. SAP recommande LTMC en remplacement. Reprendre des scripts LSMW existants en migration : oui. Démarrer un nouveau projet en LSMW : non. Article connexe sur le rollout SAP pour le contexte projet.
SHDB reste pertinent dans trois cas. Premier cas : transaction Z custom sans BAPI publique correspondante. Deuxième cas : correctif de masse one-shot où développer un programme RFC propre coûterait plus cher que le besoin. Troisième cas : reprise de scripts BDC hérités sur une filiale qui rejoint un déploiement central, transition pragmatique avant migration vers BAPI ou LTMC.
Sur mes missions industrielles, SHDB n’a jamais disparu de la boîte à outils. Il revient toujours quand une transaction Z custom n’a pas de BAPI, ou quand un correctif de masse doit livrer en deux jours. Le maîtriser solidement vaut mieux que prétendre qu’il appartient au passé.
Pierre Balbinot, consultant SAP PP / EAM
Questions fréquentes sur SHDB
SHDB fonctionne-t-il sur S/4HANA ?
Oui. SHDB est pleinement supporté en S/4HANA 2026. Il fonctionne sur toutes les transactions SAP GUI dynpro classiques, y compris les transactions custom Z. Les transactions Fiori UI5 ne sont pas couvertes par SHDB (utiliser OData ou RAP à la place).
Quelle différence entre Session Method et Call Transaction ?
Session Method génère une session batch input visible et pilotable via SM35 (traçabilité forte, reprise sur erreur native, plus lent). Call Transaction exécute directement la transaction en temps réel sans queue (plus rapide, pas de log natif, gestion erreur à coder). Choix selon volume + besoin de traçabilité.
À quoi servent BDC_OKCODE, BDC_CURSOR et BDC_DYNPRO ?
Ces trois champs spéciaux de la structure BDCDATA pilotent respectivement le code d’action (validation, retour, annuler), la position du curseur, et le numéro de dynpro. Les renseigner explicitement est obligatoire pour un comportement stable. Les oublier provoque des erreurs aléatoires selon le contexte d’exécution.
Quel mode de mise à jour choisir : S, A ou L ?
Mode S (synchrone) : la mise à jour est commitée avant retour, cohérence garantie, plus lent. Mode A (asynchrone) : retour immédiat, mise à jour en arrière-plan, performance maximale mais risque incohérence inter-tables. Mode L (local update) : mise à jour mémoire utilisateur, cas spécifiques rares. Par défaut, utiliser S sauf perf critique.
Peut-on enregistrer une transaction Fiori avec SHDB ?
Non. SHDB enregistre uniquement les transactions SAP GUI dynpro (ABAP screens). Pour automatiser une application Fiori UI5, il faut utiliser les services OData exposés, le Business Object RAP, ou un outil tiers comme eCATT. SHDB reste pertinent pour toute la couche GUI classique.
En résumé : SHDB, outil tactique du consultant SAP 2026
SHDB n’a pas disparu. Il a juste cessé d’être l’outil par défaut. En 2026, il intervient sur les angles morts des BAPI et de Migration Cockpit, là où le standard ne couvre pas. Maîtriser SHDB sérieusement, c’est verrouiller le layout en amont via SHD0, choisir Session Method ou Call Transaction sur des critères objectifs, piloter les modes de mise à jour S / A / L sans confusion, et toujours valider sur plusieurs jeux de données avant d’industrialiser. Le réflexe de senior n’est pas de bannir SHDB, c’est de savoir quand y revenir.
À 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.