SAP ERP-Datenquelle

Für die Data Foundation-Ebene des Google Cloud Cortex Framework für SAP ERP ist eine Verbindung zu den Rohdaten des Quellsystems erforderlich. Sowohl SAP ECC als auch SAP S/4HANA werden unterstützt.

Vor der Bereitstellung von Cortex Framework-Inhalten müssen relevante SAP ERP-Tabellen in BigQuery repliziert werden. Dazu können Sie Daten in einem speziellen Rohdatensatz für die Change Data Capture-Verarbeitung (CDC) ablegen oder etablierte CDC-Pipieren verwenden, um die Data Foundation-Ebene direkt zu speisen. Weitere Informationen finden Sie unter Technische Anforderungen für die Replikation von SAP ERP-Daten.

Sie können ein beliebiges Replikationstool verwenden, sofern es Daten im Rohdatenformat in BigQuery replizieren kann. Beispiele für Lösungen sind der Google Cloud BigQuery-Connector für SAP (erfordert SAP SLT) und das BigQuery Toolkit für SAP.

Um die Kompatibilität zwischen den replizierten Rohdatensätzen aus SAP ERP und der Data Foundation-Ebene des Cortex Framework zu gewährleisten, müssen Sie die folgenden Anforderungen erfüllen.

Technische Anforderungen für die Replikation von SAP ERP-Daten

Prüfen Sie die folgenden technischen Anforderungen für die Replikation von SAP-Daten in das Cortex Framework in BigQuery und erfüllen Sie sie.

  1. Rohdatenstruktur: Daten aus ECC oder S/4HANA sollten mit derselben Struktur wie die Basistabellen in SAP und ohne geschäftliche Transformationen in BigQuery landen. Tabellen müssen mit den erforderlichen Feldnamen, Typen und der erforderlichen Granularität repliziert werden, wie sie in SAP vorhanden sind.

  2. Tabellenkonfiguration: Die Liste der zu transformierenden Tabellen wird in der Datei table_settings.yaml definiert (unter config/cortex/data_foundation/sap). Wenn während der Bereitstellung eine erforderliche Tabelle fehlt, schlagen die entsprechenden Datenprodukte fehl.

  3. Metadatenanforderungen: Sie müssen die Tabelle DD03L aus Ihrer SAP-Quelle replizieren. Diese Tabelle ist für den Abhängigkeitsresolver von entscheidender Bedeutung, da sie Feldmetadaten und Schlüssel enthält.

  4. Groß-/Kleinschreibung: Die Namen der replizierten SAP-Tabellen in BigQuery müssen in Kleinbuchstaben sein, um die Kompatibilität mit dem Cortex Framework-Datenmodell zu gewährleisten. Die SAP-Tabelle MARA wird beispielsweise in BigQuery zu mara.

  5. Objektnamen (Spalten) und Sonderzeichen: Für Objektnamen (Spalten), die Sonderzeichen wie /, - oder führende Unterstriche _ enthalten, erwartet Cortex ein generisches Bereinigungsmuster:

    • Alle nicht alphanumerischen Zeichen werden durch einen Unterstrich _ ersetzt.
    • Führende Unterstriche und Ziffern sind nicht zulässig. Beispiel: /GOOG/TEST wird zu goog_test und _DATAAGING zu dataaging. Wenn Ihr Replikationstool Daten mit beibehaltenen führenden Unterstrichen ablegt, ist ein Normalisierungsschritt (Aliasing) in der Data Foundation-Ebene erforderlich.

  6. Felder für die Datenweitergabe: Zur Unterstützung von CDC (Change Data Capture) und der Datenweitergabe müssen replizierte SAP-Tabellen Folgendes enthalten:

    • Ein Vorgangsflag mit dem Namen operation_flag (L = anfänglicher Ladevorgang, I = Einfügen, U = Aktualisieren, D = Löschen).
    • Einen Zeitstempel mit dem Namen recordstamp (der zum Zeitpunkt des Ladevorgangs mit dem aktuellen Zeitstempel gefüllt wird).
    • Optional: In replizierten _DS_RAW Tabellen wird ein zusätzliches Feld is_deleted (BOOLEAN) ausgewählt (Standardwert ist „false“ beim anfänglichen Ladevorgang). Laufzeitansichten, die von Cortex generiert werden, verweisen auf diese Spalte. Sie kann jedoch vor der Ausführung aus den CDC- und Ansichtsvorlagen entfernt werden, wenn sie vom Replikationstool nicht erstellt wird.

  7. Datentypen: Erforderliche Zuordnung von SAP-Datentypen zu BigQuery-Datentypen für die Kompatibilität:

    Erforderlich für Standardvorgänge :

    Datentyp SAP Datentyp BigQuery Beschreibung
    DATS DATE Datumsdatentyp
    TIMS TIME Zeitdatentyp

  8. Für Genauigkeit und Kompatibilität dringend empfohlen :

    • CURR (Währung) und QUAN (Menge) werden NUMERIC oder BIGNUMERIC zugeordnet. Vermeiden Sie FLOAT64, um Rundungsfehler bei Finanzberechnungen zu verhindern.
    • NUMC (Numerisches Zeichen) wird STRING zugeordnet, um führende Nullen für Dokumentnummern und Artikelnummern beizubehalten und so erfolgreiche Joins zu gewährleisten.

  9. Nutzlastkomprimierung: Damit leere SAP-Spalten (Anfangswerte wie Leerzeichen oder Nullen) in BigQuery nicht mit NULL gefüllt werden, muss die Nutzlastkomprimierung in der Connector- Konfiguration deaktiviert sein (oder „Unkomprimiert senden“ aktiviert sein). Dadurch wird sichergestellt, dass leere Strings oder Nullen im Ziel beibehalten werden, anstatt standardmäßig NULL zu verwenden.