Retire BDC batch input — move to BAPI, RAP or OData

Batch input (CALL TRANSACTION, BDC sessions) drives the SAP GUI by replaying keystrokes against screens. It’s fragile — a screen change breaks it — and it has no place in a clean, cloud-ready core. The good news: almost everything BDC does has a released, programmatic alternative now.

The decision tree

1. Is there a released BAPI for this transaction? Most posting transactions (orders, materials, postings) have one. Use it — you get real business-logic validation and proper error messages instead of screen scraping.
2. Is it your own custom object? Model it as a RAP business object and change it with EML. Your logic lives in the behavior implementation, callable from anywhere — UI, job, or integration.
3. Is the caller external? Expose an OData service (from the same RAP object) so the upstream system posts cleanly over HTTP.
4. No released API exists yet? Wrap the legacy call behind a released-wrapper facade so there’s a single, swappable seam — and flag it for replacement when SAP ships an alternative.

Why it’s worth it

• It stops breaking. No more “someone changed a screen and the nightly run failed.”
• It’s testable. A BAPI or EML call can be unit-tested; a BDC recording can’t.
• It’s cloud-ready. This is a prerequisite for ABAP Cloud, and it removes a whole category of ATC findings.

A note on idempotency

When you replace a batch job, make the new path idempotent and observable: a correlation id, structured logging, and a retry with backoff for transient failures. Our open-source utilities include small, cloud-safe helpers for exactly this (retry, logger, guard) so you’re not rebuilding them.

Want a hand mapping your batch jobs to released APIs? Book an assessment and we’ll start with the riskiest one.