SAP SHDB Transaction Recorder: Session vs Call Transaction

You hear it everywhere: SHDB belongs to the past, replaced by BAPIs, the Migration Cockpit and OData services. That is a convenient simplification for project managers who want to lock in a standard. It is also false. SHDB remains the only native mechanism that lets you script a SAP transaction when no BAPI covers the need, when a custom screen embeds user-exits or dynamic popups, or when a one-shot mass correction has to ship in two days rather than two months of RFC development. For a SAP consultant working on Z transactions or on projects with a lot of custom code, the natural companion of batch input remains something to master seriously.

What SHDB really does under the hood

SHDB stands for Screen Helper / Demo for Batch input. In concrete terms, it is a transaction recorder. You start the tool, you run a transaction manually (selecting a menu, entering a field, confirming with an OK code), you stop the recording, and SAP produces two deliverables.

First deliverable, the BDCDATA structure, an ABAP internal table that describes each replayed screen. Each row contains five main fields: PROGRAM (name of the dynpro program), DYNPRO (screen number), DYNBEGIN (screen start flag), FNAM (field name) and FVAL (value to enter). Three special fields drive the behavior: BDC_OKCODE for the action code, BDC_CURSOR for the cursor position, BDC_DYNPRO for the current dynpro number.

Second deliverable, an ABAP program skeleton that calls BDC_OPEN_GROUP, loops over the data to run BDC_INSERT, and closes with BDC_CLOSE_GROUP. This skeleton is rudimentary. It is up to you to add the reading of the source file (CSV, staging table, SQL selection), error handling and logging.

This mechanism differs from a BAPI on one crucial point: SHDB replays the presentation layer, so it goes through all the screen validations, all the dynpro user-exits, all the business checks that SAP runs for a human user. A BAPI bypasses the presentation layer and hits the functional layer directly. SHDB is therefore slower, but also more faithful to the behavior of a real data entry.

Session Method vs Call Transaction: decision criteria

SHDB offers two methods to run the generated code. The choice drives performance, traceability and error handling. This is not a cosmetic decision.

My default reflex on a project: Session Method by default, unless real time is needed or the volume is below a thousand records. The traceability through SM35 largely makes up for the slowness. For Call Transaction, never deliver without a structured error handler that stores the messages from MESSTAB in an application log.

The recording best practices that make the difference

A quality SHDB recording is no longer to produce than a sloppy one, but it survives the months and the updates. Here are the practices I apply systematically.

1. Lock the layout through SHD0 before SHDB. If the transaction has screen variants or optional fields that appear depending on context, fix the variant beforehand. A session recorded on a configurable screen breaks at the first Customizing change. Details in our article on SHD0 and transaction variants.
2. Keep the scope minimal. One recording = one use case = one path. Do not try to cover every variation in a single recording. Several small specialized recordings survive better than one large universal recording.
3. Set BDC_OKCODE, BDC_CURSOR, BDC_DYNPRO explicitly. Do not rely on the default values. The behavior varies with the execution context (user, locale, GUI version) if these three fields are not controlled.
4. Test on three different data sets. A nominal case, a case with empty optional fields, a case with warning messages to dismiss. Three sets are enough to flush out most of the defects before industrialization.
5. Document the recorded transaction and the user parameters. The recording does not contain the locale, the user profile, or the GUI version. Tracking these elements in the project documentation saves several hours of debugging in case of a later bug.

The S / A / L update modes: what they really change

Beyond the choice of Session Method or Call Transaction, SHDB offers three update modes that determine how and when database writes are committed. This is the parameter most often misunderstood by juniors, and it has real consequences in production.

Mode S, synchronous. The program waits until the update is fully committed in the database before handing back control. Consistency guaranteed: if a cascade of tables must be updated, everything is committed together or nothing is. Slower, especially on large volumes, but the only mode recommended for critical transactions (material creation, production order, accounting postings).

Mode A, asynchronous. The program hands back control immediately after scheduling the update. SAP commits in the background. Maximum performance, but the risk is cross-table inconsistency if the calling program loops quickly and commits dependent changes. To be used only on isolated transactions whose writes do not depend on one another.

Mode L, local update. Update in user memory, without going through the standard update task mechanism. Very specific use cases: programs that want to control the commit moment themselves through an explicit ABAP COMMIT WORK statement. Avoid it as long as you do not have a precise technical reason.

Practical recommendation: Mode S by default. Switch to A only on very large volume batches where performance is critical, and after validating that the writes are independent. Use L only on the explicit advice of a senior ABAP developer.

The 5 mistakes that ruin an SHDB recording

These five mistakes account for the overwhelming majority of the incidents I see on SHDB recordings that end up breaking in production.

1. Recording without freezing the layout. The confirmation popup, the mandatory warning message, the field that appears only when the previous value equals X, everything that is not systematic at recording time will become the bug that breaks the session in production. Prerequisite: SHD0 lock before SHDB.
2. Not handling BDC_OKCODE explicitly. The action code left blank behaves differently depending on the context. Set it on each screen (/00 to confirm, /BACK to go back, etc.).
3. Ignoring the MESSTAB table on the Call Transaction side. In Call Transaction, error messages do not go into a queue. If you do not capture them in MESSTAB and do not log them, you lose the trace of what failed. Classic mistake: SY-SUBRC at zero but critical warnings in MESSTAB left unprocessed.
4. Confusing Mode A and Mode S on a cascade of tables. Mode A looks more performant at recording time, but if the transaction writes into several dependent tables (header + lines + texts), the asynchronous mode can commit half of it while the other half fails, leaving an inconsistent state in the database.
5. Industrializing without replaying on several data sets. The recording works on your recording data set, yes. On the real business data that has legitimate variations (empty fields, foreign dates, different locales), it breaks. Always replay on at least three representative sets.

When to prefer BAPI, Migration Cockpit or LSMW over SHDB

SHDB is not the first option for most loading needs in 2026. Before scripting, always check the alternatives.

BAPI or dedicated RFC. If a public BAPI covers the target business object, take it without hesitation. Clearer ABAP reading, better performance, stability against GUI version changes. SHDB only comes back if no BAPI covers 100% of the need (dynamic business popups, custom Z screens with no public BAPI).

Migration Cockpit (LTMC). For an initial load on S/4HANA of standard objects (material, customer, vendor, BOM, equipment), LTMC is the official SAP tool. XML / Excel templates, staging tables, native error handling, and adaptation to S/4HANA constraints. SHDB becomes redundant except for custom objects that are not covered.

LSMW. Still usable on active ECC projects, but to be avoided for any new S/4HANA development. SAP recommends LTMC as a replacement. Reusing existing LSMW scripts during a migration: yes. Starting a new project in LSMW: no. Related article on the SAP rollout for the project context.

SHDB remains relevant in three cases. First case: custom Z transaction with no matching public BAPI. Second case: one-shot mass correction where developing a clean RFC program would cost more than the need itself. Third case: reusing legacy BDC scripts on a subsidiary joining a central rollout, a pragmatic transition before migrating to BAPI or LTMC.

On my industrial projects, SHDB never disappeared from the toolbox. It always comes back when a custom Z transaction has no BAPI, or when a mass correction has to ship in two days. Mastering it solidly is better than pretending it belongs to the past.

Pierre Balbinot, SAP PP / EAM consultant

Frequently asked questions about SHDB

In summary: SHDB, a tactical tool for the 2026 SAP consultant

SHDB has not disappeared. It has merely stopped being the default tool. In 2026, it steps in on the blind spots of BAPIs and the Migration Cockpit, where the standard does not reach. Mastering SHDB seriously means locking the layout upfront through SHD0, choosing Session Method or Call Transaction on objective criteria, controlling the S / A / L update modes without confusion, and always validating on several data sets before industrializing. The senior reflex is not to ban SHDB, it is to know when to come back to it.

Keep reading

01

SAP Tutorials

Beginner's guide to batch management in SAP MM

I have seen consultants tick the "Batch management" box on thousands of materials in a MASS run, without realizing the batch level was still set at client level. A few...

Pierre B. 12 min read

02

SAP Tutorials

SAP batch determination and management

You are configuring SAP batch determination and the engine does not kick in. You are picking batches in the wrong order even though the sort rule is correctly set up....

Pierre B. 12 min read

03

SAP Tutorials

SAP Serial Number: OIS2 setup and material vs equipment

A SAP serial number is the unique identifier attached to one specific physical unit of a given material. It is the tool for unit-level traceability, the foundation for individualized after-sales...

Pierre B. 15 min read

04

SAP Tutorials

SAP Functional Specification: WRICEF template and pitfalls

Most SAP consultants treat the functional specification as administrative drudgery to dispatch before getting to the real work. Rookie mistake. A well-written FS decides on its own whether the development...

Pierre B. 18 min read