Apache-Airflow-Integration
Stand 2026-09-03
SAPs eigene Scheduler — BW-Prozessketten, S/4HANA-Job-Scheduling, Datasphere-Task-Chains — versagen in dem Moment, in dem ein Ladevorgang nach Databricks, in einen externen Data Lake oder zu einer individuellen Qualitätsprüfung wechseln muss; Airflow schließt genau diese Lücke. Die entscheidende Frage bei einer BDC- oder Datasphere-Migration ist, wo die Grenze des DAG verläuft: Airflow sollte auslösen und abfragen, niemals Zeilen zur Transformation in den eigenen Worker ziehen — sonst wird jeder Ladevorgang über wenige Tausend Zeilen zu einem Engpass und blinden Fleck. Berater, die einen wiederholungssicheren, SLA-überwachten, systemübergreifenden DAG entwerfen können — und wissen, warum ein Datasphere-OAuth-Token mitten im Lauf erneuert werden muss, nicht nur beim DAG-Start —, verlangen im EMEA-Markt 950-1.350 €/Tag, mehr bei Finanzabschluss- oder S&OP-Arbeit, wo eine verpasste SLA Sichtbarkeit bis auf Vorstandsebene hat.
Was Sie lernen
- Mehrschichtige Airflow-DAGs für SAP-Analytics-Ladevorgänge entwerfen — das Auslösen der Extraktion (BW-Prozesskette, S/4HANA-OData, Datasphere-Replication-Flow) vom Staging und der Transformation trennen, mit atomaren, idempotenten Tasks und korrekter Retry-Logik für SAP-spezifische Fehlermodi
- Airflow-zu-HANA-Konnektivität mit dem Paket apache-airflow-providers-sap-hana implementieren, mit Zugangsdaten-Store-Verwaltung, SSL-Konfiguration und Orchestrierungsmustern für HANA-Stored-Procedures bei BW/4HANA-Open-Hub-Szenarien
- Datasphere-Task-Chains und -Transformation-Flows über die Datasphere-REST-API in Airflow-DAGs integrieren, einschließlich OAuth2-Token-Lebenszyklusverwaltung für lang laufende DAG-Ausführungen
- SLA-basierte Alarmierung konfigurieren, die operative Signale an Fachbereichsstakeholder weiterleitet (nicht nur an Engineering), und Task-Dauermetriken instrumentieren, um HANA-Performance-Regressionen zu erkennen, bevor sie SLA-Fenster verletzen
Warum Airflow SAP-Ladevorgänge orchestriert statt SAPs eigener Werkzeuge
SAP verfügt über eigene Planungs- und Prozessorchestrierungswerkzeuge: BW-Prozessketten, S/4HANA-Job-Scheduling über das ABAP-Job-Framework, Datasphere-Task-Chains und die Integration Flows der SAP Integration Suite. Jedes davon ist innerhalb seiner eigenen Domäne hervorragend. Der Grund, warum Airflow in SAP-Analytics-Landschaften auftaucht, ist, dass keines davon Domänengrenzen sauber überschreitet. Eine Datasphere-Task-Chain kann nicht darauf warten, dass ein in BDC laufendes Databricks-Notebook fertig wird. Ein ABAP-Job im SAP-Job-Framework kann keine Python-basierte Qualitätsprüfung in einem externen Data Lake auslösen. Ein Integration Flow kann keinen komplexen Abhängigkeitsgraphen mit Verzweigungslogik, Fehlerbehebung und SLA-basierter Alarmierung ausdrücken.
Airflow löst das systemübergreifende Abhängigkeitsproblem — es wird zum Dirigenten, der Arbeit über SAP HANA, Datasphere, S/4HANA OData, Databricks, GCS/Azure Blob/S3 und individuelle Python-Operatoren hinweg sequenziert, alles innerhalb eines einzigen DAG, in dem Abhängigkeiten, Wiederholungsversuche und Monitoring als Code ausgedrückt werden.
Die zu respektierende Grenze: Airflow orchestriert, transformiert aber nicht. Airflow-Operatoren sollten Arbeit in dem System auslösen, dem die Daten gehören (eine HANA-Prozedur, ein Datasphere-Transformation-Flow, ein Databricks-PySpark-Job), statt Daten in den Airflow-Worker zu extrahieren und dort zu verarbeiten. Airflow-Worker sind nicht für spaltenorientierte analytische Workloads ausgelegt.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung mit SAP-Analytics-Projekten
- Zunächst die Kernkonzepte wiederholen: C087, C083, C047
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Ein europäischer Industriefertiger migriert seine BW/4HANA-Finanzabschluss-Ladevorgänge unter SAP Business Data Cloud nach Datasphere und Databricks.
- Das Anti-Pattern erkennen und vermeiden: Daten zur Transformation in den Airflow-Worker ziehen (PythonOperator + pandas).
- Die zentrale Entscheidung des Moduls anwenden: Airflow vs. native SAP-Orchestrierung (BW-Prozessketten, Datasphere-Task-Chains) — Airflow nur dort einsetzen, wo Abhängigkeiten Systemgrenzen überschreiten.
- Die Beherrschung anhand des KPI verfolgen: SLA-Verfehlungsrate beim Finanzabschluss-DAG (Ziel: 0 Verfehlungen pro Monat beim 07:00-Uhr-Dashboard-SLA; Warnsignal: mehr als 1 Verfehlung/Monat ohne für Stakeholder sichtbare Ursache).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.