BDC: CALL TRANSACTION vs Batch Input Session Method

BDC works at dynpro level. A BDC data table identifies program, screen, OK codes and screen fields exactly as the transaction expects them. CALL TRANSACTION USING executes that sequence immediately and can return BDCMSGCOLL messages to the caller. The session method builds a batch-input session, traditionally through BDC_OPEN_GROUP/BDC_INSERT/BDC_CLOSE_GROUP, which operators later process in SM35 or schedule for background processing. Because BDC drives the presentation flow rather than a business API, changes in screen sequence, required fields, popups, user defaults or transaction variants can break an interface that once worked.

Use CALL TRANSACTION when no suitable released API exists, transaction logic is stable, volume is manageable and the caller needs immediate per-record feedback. Use a session when operational visibility, restartability and manual reprocessing are more important than immediate synchronous response, especially in legacy migration loads. Before choosing either, search for a BAPI, IDoc, OData/SOAP API, migration object or application-specific mass-load tool. BDC should be a fallback for classic GUI transactions, not the first integration pattern.

BDC sits above SAP GUI/dynpro logic and below the business transaction, whereas BAPIs and APIs call the application layer directly. SHDB records transactions and helps generate BDC field sequences; SM35 monitors sessions. Authorization checks still run under the executing user. COMMIT behavior is owned by the called transaction. Background execution can differ from foreground because dialogs, screen values and frontend-dependent behavior are unavailable. Fiori apps generally do not provide BDC-compatible dynpro flows.

A legacy migration must create an object for which no supported API exists. The team records the transaction with SHDB, builds BDC data, and initially tests CALL TRANSACTION in foreground to understand errors. For the production load they choose session processing so failed records remain visible in SM35 and can be reprocessed after master-data correction. Months later a support package adds a mandatory screen field; the session begins failing, demonstrating why the interface needs regression testing after UI changes.

BDC can still work for classic SAP GUI transactions in S/4HANA on-premise/private cloud, but it is not a clean-core integration pattern and is irrelevant to many Fiori-only/cloud scenarios. S/4HANA migration projects should prefer Migration Cockpit objects, released APIs, IDocs or BAPIs when available. Existing BDCs deserve upgrade testing because simplification items and transaction redesign can change screens even when the business process remains.

ABAP/data-migration teams build and test BDC logic. Functional consultants own the transaction flow, mandatory fields and configuration. Operations teams monitor SM35 sessions. Architects should challenge every new BDC requirement and document why no supported business interface is available.

SHDB helps record dynpro sequences and SM35 monitors batch input sessions. The RFC-vs-BAPI topic explains why business APIs are more stable integration contracts; the BAPI library should be checked before introducing BDC.

Production verification: Capture transaction code, recorded program and screen sequence, BDC field names and OK codes, execution mode, update mode, user, BDCMSGCOLL messages and any SM35 session identifier. Re-record the transaction in the target release when screen flow changes instead of patching around missing fields blindly.

Operational readiness: For production readiness of BDC: CALL TRANSACTION vs Batch Input Session Method, add one reproducible test case with realistic data volume and boundary values, one negative test that proves the failure contract, and one operational check that a support developer can run without changing productive data. Record the exact program, class or function and any release-dependent API assumptions. Where the topic affects performance or transaction consistency, compare evidence before and after the change instead of relying on coding folklore or one sandbox execution.