Anbindung von SAP-Systemen

Es gibt mehrere Möglichkeiten, SAP-Daten in die DQC Platform zu bringen. Welcher Weg der richtige ist, hängt von Ihrem Landscape ab (ECC, S/4HANA, BW/4HANA, Datasphere), von den zu validierenden Datenmengen sowie davon, ob Sie im SAP-Application-Layer bleiben oder direkt auf die Datenbank zugreifen möchten.

Übersicht

SAP HANA — direkter Datenbankzugriff

DQC verbindet sich direkt mit einer SAP-HANA-Datenbank über einen read-only-technischen Benutzer. Konzeptionell ist das derselbe Ansatz, den Power BI für SAP nutzt: Die Application-Schicht wird umgangen, und Daten werden direkt aus der HANA-Datenbank gelesen.

Ideal für:

• SAP BW- und BW/4HANA-Umgebungen

• SAP-Datasphere-Umgebungen

• Eigene HANA-basierte Data Marts und Reporting-Schichten

• Große analytische Workloads, bei denen Durchsatz zählt

Trade-off: SAP-Application-Logik (Validierungen, virtuelle Felder, ABAP-Code) wird umgangen — das Datenmodell in HANA muss bereits das abbilden, was geprüft werden soll.

→ Detail-Anleitung: Verbindung zu SAP HANA

SAP OData — im Application-Layer bleiben

OData-Services, die durch SAP NetWeaver Gateway, S/4HANA oder BW bereitgestellt werden, exponieren Tabellen und Entitäten über HTTP. Die Berechtigungssteuerung erfolgt durch SAP selbst über PFCG-Rollen — DQCs Zugriff bleibt damit innerhalb des etablierten SAP-Berechtigungsmodells.

Ideal für:

• Transaktionale Daten oder Stammdaten, die bereits als OData-Service freigegeben sind

• Kleinere Datenmengen, bei denen SAP-Business-Logik berücksichtigt werden muss

• Organisationen, die Zugriffe lieber über SAP-Rollen vergeben als über einen dedizierten DB-Benutzer

Trade-off: OData hat höheren Overhead pro Anfrage als der direkte HANA-Zugriff und eignet sich daher weniger für sehr große Extrakte. Bevorzugen Sie OData v4 gegenüber v2 für bessere Schema-Metadaten.

→ Detail-Anleitung: Verbindung zu OData

Drittanbieter-Connectoren (z.B. Theobald)

Wenn weder ein direkter HANA-Zugriff noch OData ausreichen — etwa weil Sie ABAP CDS Views, BAPIs oder Delta-Extraktionslogik benötigen — können Drittanbieter-Tools die Lücke zwischen SAP und DQC schließen.

DQC hat dabei eine harte Anforderung: der Drittanbieter-Connector muss seine Daten über eine SQL-Schnittstelle bereitstellen. DQC liest diesen SQL-Endpunkt anschließend über einen seiner Standard-Connectoren (PostgreSQL, Microsoft SQL Server, Snowflake, …). Aus Sicht von DQC ist es eine ganz normale SQL-Datenquelle.

Geeignete Tools sind beispielsweise:

• Theobald Software (theobald-software.com) — extrahiert SAP-Daten und stellt entweder einen SQL-/JDBC-Endpunkt bereit oder schreibt sie in eine Zieldatenbank

• Andere ETL- oder Replikationswerkzeuge, die SAP-Daten in ein SQL-erreichbares Ziel materialisieren

Typisches Muster: Das Drittanbieter-Tool schreibt SAP-Daten in ein Staging-Schema (PostgreSQL, MS SQL, Snowflake, …); DQC verbindet sich mit diesem Staging-Schema über den passenden Standard-Connector.

Best Practices für SAP-Verbindungen

• Verwenden Sie einen dedizierten, read-only-technischen Benutzer — niemals ein persönliches Konto

• Geben Sie die ausgehende IP der DQC-Plattform frei, falls Ihre Netzwerkrichtlinien dies erfordern

• Beschränken Sie den Zugriff auf die Schemata, Entitäten oder Tabellen, die für die Datenqualitätsprüfungen tatsächlich benötigt werden

• Für HANA: konfigurieren Sie eine Workload Class mit Speicher-, Thread- und Timeout-Limits, um Runaway-Queries zu vermeiden

• Für OData: bevorzugen Sie v4 gegenüber v2 für bessere Schema-Metadaten und Performance

• Dokumentieren Sie pro Datendomäne, welcher Ansatz verwendet wird (z.B. Stammdaten via OData, Analytics via HANA), damit die Begründung für spätere Operatoren nachvollziehbar bleibt