Schedule SAP batch from Apache Airflow — R/3, ECC, and S/4HANA
Control-M for SAP and AutoSys SAP Agent are the historical gold standard. Airflow now matches them — with the right operators, the right RFC connection pattern, and the right ABAP-variant handling.
What "SAP batch" actually means
SAP runs on its own internal scheduler — SM37 for batch jobs, Process Chains for BW/4HANA, BAPI calls for triggering. Most enterprise schedulers don't replace SAP's internal scheduler; they trigger it externally. The migration is about replacing that external trigger layer — not rewriting SAP jobs in Python. BatchFoundry's pattern uses Airflow plus the pyrfc provider for RFC, and the SAP Cloud SDK for S/4HANA Cloud.
The reference operators
SAPRfcOperatorBuilt on pyrfc — triggers and monitors SAP jobs by name + variantSAPBwOperatorProcess Chain start + monitoring for BW/4HANASAPS4OperatorS/4HANA OData API for cloud-edition triggersAll operators include consistent retry, log capture, and SAP return-code → Airflow state mapping.
What BatchFoundry delivers
- Inventory of every SAP job currently triggered by your existing scheduler
- Mapping table of variants → Airflow params
- Operator library deployable as a private PyPI package
- Side-by-side run vs. existing Control-M for SAP / AutoSys SAP Agent for one full month-end close
Common pitfalls we plan around
- Background user permissions and S_BTCH_ADM profile requirements
- SAP system upgrades that change RFC contracts
- Retry idempotency for finance-relevant jobs
- Calendar alignment between Airflow timetables and SAP factory calendars
What we won't tell you
If your batch is purely inside SAP and triggered only by SAP itself, Airflow is not the right answer — stay on SM37. Airflow shines when SAP is one step inside a larger end-to-end pipeline.
Ready to migrate your SAP triggers?
Talk to a SAP integration engineer about your variant inventory and target Airflow deployment.
Talk to a SAP integration engineer