Integration in SAP

Auf dieser Seite werden die Schritte zur Integration von SAP-Betriebslasten (SAP ECC und SAP S/4 HANA) in der Cortex Framework Data Foundation beschrieben. Mithilfe von vordefinierten Vorlagen für die Datenverarbeitung mit Dataflow-Pipelines bis hin zu BigQuery kann Cortex Framework die Integration von SAP-Daten in BigQuery beschleunigen. Cloud Composer plant und überwacht diese Dataflow-Pipelines, um Erkenntnisse aus Ihren SAP-Betriebsdaten zu gewinnen.

In der Datei config.json im Cortex Framework Data Foundation-Repository werden die Einstellungen konfiguriert, die für die Übertragung von Daten aus einer beliebigen Datenquelle erforderlich sind, einschließlich SAP. Diese Datei enthält die folgenden Parameter für laufende SAP-Arbeitslasten:

  "SAP": {
        "deployCDC": true,
        "datasets": {
            "cdc": "",
            "raw": "",
            "reporting": "REPORTING"
        },
        "SQLFlavor": "ecc",
        "mandt": "100"
    }

In der folgenden Tabelle wird der Wert für jeden SAP-Betriebsparameter beschrieben:

Parameter Bedeutung Standardwert Beschreibung
SAP.deployCDC CDC bereitstellen true Generieren Sie Verarbeitungsscripts für die kontinuierliche Datenübertragung, die als DAGs in Cloud Composer ausgeführt werden.
SAP.datasets.raw Rohdaten-Dataset für Landingpage - Wird vom CDC-Prozess verwendet. Hier landen die Daten aus SAP im Replikationstool. Wenn Sie Testdaten verwenden, erstellen Sie ein leeres Dataset.
SAP.datasets.cdc Mit CDC verarbeiteter Datensatz - Dataset, das als Quelle für die Berichtsansichten und als Ziel für die DAGs für die verarbeiteten Einträge dient. Wenn Sie Testdaten verwenden, erstellen Sie ein leeres Dataset.
SAP.datasets.reporting SAP-Datensatz für Berichte "REPORTING" Name des Datensatzes, auf den Endnutzer für die Berichterstellung zugreifen können, in dem Ansichten und für Nutzer sichtbare Tabellen bereitgestellt werden.
SAP.SQLFlavor SQL-Variante für das Quellsystem "ecc" s4 oder ecc. Bei Testdaten belassen Sie den Standardwert (ecc).
SAP.mandt Mandant oder Kunde "100" Standardmandant oder -kunde für SAP. Bei Testdaten belassen Sie den Standardwert (100).
SAP.languages Sprachfilter ["E","S"] SAP-Sprachcodes (SPRAS), die für relevante Felder (z. B. Namen) verwendet werden sollen.
SAP.currencies Währungsfilter ["USD"] SAP-Zilwährungscodes (TCURR) für die Währungsumrechnung.

Es gibt keine erforderliche Mindestversion von SAP. Die ECC-Modelle wurden jedoch auf der derzeit frühesten unterstützten Version von SAP ECC entwickelt. Unterschiede zwischen den Feldern in unserem System und anderen Systemen sind unabhängig von der Version zu erwarten.

Datenmodell

In diesem Abschnitt werden die SAP-Datenmodelle (ECC und S/4HANA) anhand von Entitätsbeziehungsdiagrammen (ERD) beschrieben.

SAP ECCSAP S/4 HANA

Entitäts-Beziehungs-Diagramm für SAP ECC

Abbildung 2 SAP ECC: Entity Relationship Diagram (ER-Diagramm).

Entitäts-Beziehungs-Diagramm für SAP S/4HANA

Abbildung 2 SAP S/4HANA: Entitäts-Beziehungs-Diagramm.

Basisansichten

Dies sind die blauen Objekte in der ERD. Sie sind Ansichten auf CDC-Tabellen ohne andere Transformationen als einige Aliasse für Spaltennamen. Scripts in src/SAP/SAP_REPORTING ansehen

Berichtsdatenansichten

Das sind die grünen Objekte in der ERD. Sie enthalten die relevanten Dimensionsattribute, die in den Berichtstabellen verwendet werden. Scripts in src/SAP/SAP_REPORTING ansehen

Dienstprogramm- oder BQML-Ansicht

Dies sind die gelben Objekte in der ERD. Sie enthalten die zusammengeführten Fakten und Dimensionen. Diese Art von Ansicht wird für die Datenanalyse und Berichterstellung verwendet. Scripts auf src/SAP/SAP_REPORTING ansehen

Zusätzliche Tags

Die farbcodierten Tags in diesem ERD stehen für die folgenden Funktionen der Berichtstabellen:

Tag Farbe Beschreibung
L Gelb Dieses Tag bezieht sich auf ein Datenelement oder -attribut, das die Sprache angibt, in der die Daten gespeichert oder angezeigt werden.
S/4 Rot Dieses Tag gibt an, dass bestimmte Attribute für SAP S/4HANA spezifisch sind (dieses Objekt ist möglicherweise nicht in SAP ECC vorhanden).
MANDT Lila Dieses Tag gibt an, dass bestimmte Attribute den Parameter MANDT enthalten, der den Kunden oder die Kunden-ID darstellt, um zu ermitteln, zu welcher Kunden- oder Unternehmensinstanz ein bestimmter Datensatz gehört.
EXT Rot Dieses Tag gibt an, dass bestimmte Objekte aus DAGs oder externen Datensätzen stammen. Das bedeutet, dass das markierte Entitäts- oder Tabellenobjekt nicht direkt im SAP-System selbst gespeichert wird, sondern mithilfe eines DAG oder eines anderen Mechanismus extrahiert und in SAP geladen werden kann.
T Lila Dieses Tag gibt an, dass bestimmte Attribute automatisch mithilfe des konfigurierten DAG materialisiert werden.
S Rot Dieses Tag gibt an, dass die Daten in einer Entität oder Tabelle von mehreren Währungen beeinflusst werden.

Voraussetzungen für die SAP-Replikation

  • In Cortex Data Foundation werden SAP-Tabellen mit denselben Feldnamen und -typen repliziert, wie sie in SAP erstellt wurden.
  • Solange die Tabellen mit demselben Format, denselben Feldnamen und derselben Detaillierung wie in der Quelle repliziert werden, ist es nicht erforderlich, ein bestimmtes Replikationstool zu verwenden.
  • Tabellennamen müssen in BigQuery in Kleinbuchstaben erstellt werden.
  • Die Liste der von SAP-Modellen verwendeten Tabellen ist im CDC cdc_settings.yaml verfügbar und kann dort konfiguriert werden. Wenn eine Tabelle bei der Bereitstellung nicht aufgeführt ist, funktionieren die davon abhängigen Modelle nicht. Andere Modelle werden dann erfolgreich bereitgestellt.
  • Beachten Sie Folgendes, wenn Sie BigQuery-Connector für SAP verwenden:
  • Wenn Sie keine Testdaten bereitstellen und während der Bereitstellung CDC-DAG-Scripts generieren möchten, muss die Tabelle DD03L für SAP-Metadaten aus SAP in das Quellprojekt repliziert werden. Diese Tabelle enthält Metadaten zu Tabellen, z. B. die Liste der Schlüssel. Sie ist erforderlich, damit der CDC-Generator und der Abhängigkeitsauflöser funktionieren. In dieser Tabelle können Sie auch Tabellen hinzufügen, die nicht vom Modell abgedeckt werden, um CDC-Scripts zu generieren, z. B. benutzerdefinierte oder Z-Tabellen.

  • Bei geringfügigen Abweichungen in einem Tabellennamen kann es in einigen Ansichten zu Fehlern kommen, da SAP-Systeme aufgrund von Versionen oder Add-ons geringfügige Abweichungen aufweisen und Strukturen an Tabellen anhängen oder weil einige Replikationstools Sonderzeichen möglicherweise etwas anders behandeln. Wir empfehlen, die Bereitstellung mit turboMode : false auszuführen, um die meisten Fehler mit einem einzigen Versuch zu erkennen. Beispiel:

    • Bei Feldern, die mit _ beginnen (z. B. _DATAAGING), wird das _ entfernt.
    • Felder dürfen in BigQuery nicht mit / beginnen.

    In diesem Fall können Sie die fehlerhafte Ansicht anpassen, um das Feld auszuwählen, wie es von Ihrem ausgewählten Replikationstool gelandet wird.

Rohdaten aus SAP replizieren

Die Data Foundation dient dazu, Daten- und Analysemodelle für Berichte und Anwendungen bereitzustellen. Die Modelle nutzen die Daten, die mit einem bevorzugten Replikationstool aus einem SAP-System repliziert wurden, z. B. eines der in den Leitfäden zur Datenintegration für SAP aufgeführten Tools.

Daten aus dem SAP-System (entweder ECC oder S/4HANA) werden in Rohform repliziert. Die Daten werden ohne Änderungen an der Struktur direkt aus SAP in BigQuery kopiert. Es ist im Grunde ein Spiegelbild der Tabellen in Ihrem SAP-System. In BigQuery werden Tabellennamen in Kleinbuchstaben für das Datenmodell verwendet. Auch wenn Ihre SAP-Tabellen Namen in Großbuchstaben haben (z. B. MANDT), werden sie in BigQuery in Kleinbuchstaben (z. B. mandt) umgewandelt.

Voraussetzungen für die SAP-Replikation

Beachten Sie die folgenden Voraussetzungen für die Replikation von SAP-Daten mit Cortex Framework Data Foundation.

  • Datenintegrität: In Cortex Framework Data Foundation werden SAP-Tabellen mit denselben Feldnamen, Typen und Datenstrukturen wie in SAP repliziert. Solange die Tabellen mit demselben Format, denselben Feldnamen und derselben Detaillierung wie in der Quelle repliziert werden, ist kein spezielles Replikationstool erforderlich.
  • Tabellennamen: BigQuery-Tabellennamen müssen in Kleinbuchstaben erstellt werden.
  • Tabellenkonfiguration: Die Liste der von SAP-Modellen verwendeten Tabellen ist in der CDC-Datei (Change Data Capture) cdc_settings.yaml verfügbar und kann dort konfiguriert werden. Wenn eine Tabelle während der Bereitstellung nicht aufgeführt ist, schlagen die davon abhängigen Modelle fehl, während andere unabhängige Modelle erfolgreich bereitgestellt werden.
  • Bestimmte Überlegungen zum BigQuery-Connector für SAP:
    • Tabellenzuordnung: Weitere Informationen zur Conversion-Option finden Sie in der Dokumentation zur Standardtabellenzuordnung.
    • Datensätzetkomprimierung deaktivieren: Wir empfehlen, die Datensatzkomprimierung zu deaktivieren, da sich diese sowohl auf die Cortex-CDC-Ebene als auch auf den Cortex-Berichtsdatensatz auswirken kann.
  • Metadatenreplizierung: Wenn Sie keine Testdaten bereitstellen und während der Bereitstellung keine CDC-DAG-Scripts generieren, achten Sie darauf, dass die Tabelle DD03L für SAP-Metadaten aus SAP im Quellprojekt repliziert wird. Diese Tabelle enthält Metadaten zu Tabellen, z. B. eine Liste der Schlüssel. Sie ist für die Funktion des CDC-Generators und des Abhängigkeitsauflösers erforderlich. In dieser Tabelle können Sie auch Tabellen hinzufügen, die nicht vom Modell abgedeckt sind, z. B. benutzerdefinierte oder Z-Tabellen, damit CDC-Scripts generiert werden können.

  • Geringe Abweichungen bei Tabellennamen berücksichtigen: Wenn es geringfügige Abweichungen bei einem Tabellennamen gibt, werden in einigen Ansichten möglicherweise keine erforderlichen Felder gefunden, da SAP-Systeme aufgrund von Versionen oder Add-ons geringfügige Abweichungen haben können oder weil einige Replikationstools Sonderzeichen möglicherweise etwas anders behandeln. Wir empfehlen, die Bereitstellung mit turboMode : false auszuführen, um die meisten Fehler mit einem einzigen Versuch zu erkennen. Zu den häufigsten zählen folgende:

    • Bei Feldern, die mit _ beginnen (z. B. _DATAAGING), wird das _ entfernt.
    • Felder dürfen in BigQuery nicht mit / beginnen.

    In diesem Fall können Sie die fehlerhafte Ansicht anpassen, um das Feld auszuwählen, das von Ihrem ausgewählten Replikationstool bereitgestellt wird.

Verarbeitung von Change Data Capture (CDC)

Wählen Sie einen der folgenden CDC-Verarbeitungsmodi aus, die das Cortex-Framework für Replikationstools zum Laden von Datensätzen aus SAP bietet:

  • Append-always: Jede Änderung wird in einem Datensatz mit einem Zeitstempel und einem Vorgangsflag (Einfügen, Aktualisieren, Löschen) eingefügt, damit die letzte Version identifiziert werden kann.
  • Beim Landen aktualisieren (Merge oder Upsert): Eine aktualisierte Version eines Datensatzes wird erstellt, wenn die Landingpage in der change data capture processed aufgerufen wird. Er führt den CDC-Vorgang in BigQuery aus.

Cortex Framework Data Foundation unterstützt beide Modi, für „append-always“ gibt es jedoch CDC-Verarbeitungsvorlagen. Einige Funktionen müssen für die Aktualisierung auf der Landingpage kommentiert werden. Beispiel: OneTouchOrder.sql und alle zugehörigen Abfragen. Die Funktion kann durch Tabellen wie CDPOS ersetzt werden.

CDC-Verarbeitung

Abbildung 1. CDC-Verarbeitung.

CDC-Vorlagen für Tools konfigurieren, die im Modus „Immer anhängen“ replizieren

Wir empfehlen dringend, die cdc_settings.yaml gemäß Ihren Anforderungen zu konfigurieren. Einige Standardfrequenzen können zu unnötigen Kosten führen, wenn das Unternehmen keine so hohe Datenaktualität benötigt. Wenn Sie ein Tool verwenden, das im Modus „append-always“ ausgeführt wird, bietet die Cortex Framework Data Foundation CDC-Vorlagen, um die Aktualisierungen zu automatisieren und eine aktuelle Version der Wahrheit oder des digitalen Zwillings im vom CDC verarbeiteten Datenpool zu erstellen.

Sie können die Konfiguration in der Datei cdc_settings.yaml verwenden, wenn Sie CDC-Verarbeitungsscripts generieren müssen. Informationen zu den Optionen finden Sie unter CDC-Verarbeitung einrichten. Für Testdaten können Sie diese Datei als Standard beibehalten.

Nehmen Sie alle erforderlichen Änderungen an den DAG-Vorlagen vor, die für Ihre Airflow- oder Cloud Composer-Instanz erforderlich sind. Weitere Informationen finden Sie unter Cloud Composer-Einstellungen abrufen.

Optional: Wenn Sie Tabellen nach der Bereitstellung einzeln hinzufügen und verarbeiten möchten, können Sie die Datei cdc_settings.yaml so ändern, dass nur die benötigten Tabellen verarbeitet werden. Führen Sie dann das angegebene Modul noch einmal aus, indem Sie src/SAP_CDC/cloudbuild.cdc.yaml direkt aufrufen.

CDC-Verarbeitung einrichten

Während der Bereitstellung können Sie Änderungen in Echtzeit mithilfe einer Ansicht in BigQuery zusammenführen oder einen Zusammenführungsvorgang in Cloud Composer (oder einer anderen Instanz von Apache Airflow) planen. Mit Cloud Composer können Sie die Scripts so planen, dass die Zusammenführungsvorgänge regelmäßig ausgeführt werden. Die Daten werden jedes Mal auf die neueste Version aktualisiert, wenn die Zusammenführungsvorgänge ausgeführt werden. Häufigere Zusammenführungsvorgänge führen jedoch zu höheren Kosten. Passen Sie die geplante Häufigkeit an Ihre geschäftlichen Anforderungen an. Weitere Informationen finden Sie unter Von Apache Airflow unterstützte Planung.

Das folgende Beispielskript zeigt einen Auszug aus der Konfigurationsdatei:

  data_to_replicate:
    - base_table: adrc
      load_frequency: "@hourly"
    - base_table: adr6
      target_table: adr6_cdc
      load_frequency: "@daily"

Diese Beispielkonfigurationsdatei hat folgende Auswirkungen:

  1. Erstellen Sie eine Kopie von SOURCE_PROJECT_ID.REPLICATED_DATASET.adrc in TARGET_PROJECT_ID.DATASET_WITH_LATEST_RECORDS.adrc, falls Letzteres nicht vorhanden ist.
  2. Erstellen Sie ein CDC-Script im angegebenen Bucket.
  3. Erstellen Sie eine Kopie von SOURCE_PROJECT_ID.REPLICATED_DATASET.adr6 in TARGET_PROJECT_ID.DATASET_WITH_LATEST_RECORDS.adr6_cdc, falls letztere nicht vorhanden ist.
  4. Erstellen Sie ein CDC-Script im angegebenen Bucket.

Wenn Sie DAGs oder Laufzeitansichten erstellen möchten, um Änderungen für Tabellen zu verarbeiten, die in SAP vorhanden sind, aber nicht in der Datei aufgeführt sind, fügen Sie sie dieser Datei vor der Bereitstellung hinzu. Das funktioniert, solange die Tabelle DD03L im Quell-Dataset repliziert wird und das Schema der benutzerdefinierten Tabelle in dieser Tabelle vorhanden ist. Mit der folgenden Konfiguration wird beispielsweise ein CDC-Script für die benutzerdefinierte Tabelle zztable_customer und eine Laufzeitansicht erstellt, um Änderungen in Echtzeit für eine andere benutzerdefinierte Tabelle namens zzspecial_table zu prüfen:

    - base_table: zztable_customer
      load_frequency: "@daily"
    - base_table: zzspecial_table
      load_frequency: "RUNTIME"

Beispiel für eine generierte Vorlage

Mit der folgenden Vorlage werden Änderungen verarbeitet. Änderungen wie der Name des Zeitstempelfelds oder zusätzliche Vorgänge können an dieser Stelle vorgenommen werden:

  MERGE `${target_table}` T
  USING (
     SELECT *
     FROM `${base_table}`
     WHERE
        recordstamp > (
            SELECT IF(
                MAX(recordstamp) IS NOT NULL,
                MAX(recordstamp),
                TIMESTAMP("1940-12-25 05:30:00+00"))
            FROM `${target_table}` )
  ) S
  ON ${p_key}
  WHEN MATCHED AND S.operation_flag='D' AND S.is_deleted = true THEN
    DELETE
  WHEN NOT MATCHED AND S.operation_flag='I' THEN
    INSERT (${fields})
    VALUES
    (${fields})
  WHEN MATCHED AND S.operation_flag='U' THEN
  UPDATE SET
      ${update_fields}

Wenn Ihr Unternehmen Daten nahezu in Echtzeit benötigt und das Replikationstool dies unterstützt, kann im Bereitstellungstool die Option RUNTIME verwendet werden. Das bedeutet, dass kein CDC-Script generiert wird. Stattdessen würde eine Ansicht den aktuellsten verfügbaren Datensatz zur Laufzeit für die sofortige Konsistenz prüfen und abrufen.

Verzeichnisstruktur für CDC-DAGs und ‑Scripts

Die Cloud Storage-Bucket-Struktur für SAP-CDC-DAGs erwartet, dass die SQL-Dateien in /data/bq_data_replication generiert werden, wie im folgenden Beispiel. Sie können diesen Pfad vor der Bereitstellung ändern. Wenn Sie noch keine Cloud Composer-Umgebung haben, können Sie diese später erstellen und die Dateien in den DAG-Bucket verschieben.

with airflow.DAG("CDC_BigQuery_${base table}",
                template_searchpath=['/home/airflow/gcs/data/bq_data_replication/'], ##example
                default_args=default_dag_args,
                schedule_interval="${load_frequency}") as dag:
    start_task = DummyOperator(task_id="start")
    copy_records = BigQueryOperator(
      task_id='merge_query_records',
        sql="${query_file}",
        create_disposition='CREATE_IF_NEEDED',
        bigquery_conn_id="sap_cdc_bq", ## example
        use_legacy_sql=False)
    stop_task = DummyOperator (task_id="stop")
    start_task >> copy_records >> stop_task

Die Scripts, die Daten in Airflow oder Cloud Composer verarbeiten, werden bewusst getrennt von den Airflow-spezifischen Scripts generiert. So können Sie diese Scripts in ein anderes Tool Ihrer Wahl übertragen.

Für MERGE-Vorgänge erforderliche CDC-Felder

Geben Sie die folgenden Parameter für die automatische Generierung von CDC-Batchprozessen an:

  • Quellprojekt + Dataset:Dataset, in dem die SAP-Daten gestreamt oder repliziert werden. Damit die CDC-Scripts standardmäßig funktionieren, müssen die Tabellen ein Zeitstempelfeld (recordstamp) und ein Vorgangsfeld mit den folgenden Werten haben, die alle während der Replikation festgelegt werden:
    • I: für „Einfügen“.
    • U: für „Update“ (Aktualisierung).
    • D: „Zum Löschen“
  • Zielprojekt + Dataset für die CDC-Verarbeitung: Das Script generiert standardmäßig die Tabellen aus einer Kopie des Quell-Datasets, falls sie nicht vorhanden sind.
  • Replizierte Tabellen: Tabellen, für die die Scripts generiert werden müssen
  • Verarbeitungshäufigkeit: Gibt an, wie oft die DAGs gemäß der Cron-Notation ausgeführt werden sollen:
  • Ziel-Cloud Storage-Bucket, in den die CDC-Ausgabedateien kopiert werden.
  • Name der Verbindung: Der Name der von Cloud Composer verwendeten Verbindung.
  • Optional: Name der Zieltabelle: Verfügbar, wenn das Ergebnis der CDC-Verarbeitung im selben Dataset wie das Ziel verbleibt.

Leistungsoptimierung für CDC-Tabellen

Bei bestimmten CDC-Datasets können Sie die Tabellenpartitionierung, die Tabellengruppierung oder beides in BigQuery nutzen. Diese Wahl hängt von den folgenden Faktoren ab:

  • Größe und Daten der Tabelle.
  • In der Tabelle verfügbare Spalten.
  • Echtzeitdaten mit Datenansichten
  • Daten, die als Tabellen materialisiert werden.

Standardmäßig werden durch CDC-Einstellungen keine Tabellenpartitionierung oder kein Tabellenclustering angewendet. Sie können die Einstellungen so konfigurieren, wie es für Sie am besten passt. Wenn Sie Tabellen mit Partitionen oder Clustern erstellen möchten, aktualisieren Sie die Datei cdc_settings.yaml mit den entsprechenden Konfigurationen. Weitere Informationen finden Sie unter Tabellenpartition und Clustereinstellungen.

  1. Diese Funktion gilt nur, wenn ein Datensatz in cdc_settings.yaml für die Replikation als Tabelle (z. B. load_frequency = "@daily") konfiguriert und nicht als Ansicht (load_frequency = "RUNTIME") definiert ist.
  2. Eine Tabelle kann sowohl eine partitionierte als auch eine geclusterte Tabelle sein.

Wenn Sie ein Replikationstool verwenden, das Partitionen im Rohdatensatz zulässt, z. B. BigQuery-Connector für SAP, wird empfohlen, zeitbasierte Partitionen in den Rohtabellen festzulegen. Die Partitionsart funktioniert besser, wenn sie der Häufigkeit für CDC-DAGs in der cdc_settings.yaml-Konfiguration entspricht. Weitere Informationen finden Sie unter Designüberlegungen für die SAP-Datenmodellierung in BigQuery.

Optional: SAP-Inventarmodul konfigurieren

Das SAP-Inventarmodul des Cortex Framework enthält die Ansichten InventoryKeyMetrics und InventoryByPlant, die wichtige Informationen zu Ihrem Inventar liefern. Diese Ansichten werden von monatlichen und wöchentlichen Snapshot-Tabellen mit speziellen DAGs unterstützt. Beide können gleichzeitig ausgeführt werden und beeinflussen sich nicht gegenseitig.

So aktualisieren Sie eine oder beide Snapshot-Tabellen:

  1. Aktualisieren Sie SlowMovingThreshold.sql und StockCharacteristicsConfig.sql, um den Grenzwert für wenig bewegte Artikel und die Lagereigenschaften für verschiedene Materialtypen an Ihre Anforderungen anzupassen.

  2. Führen Sie für das erstmalige Laden oder die vollständige Aktualisierung die DAGs Stock_Monthly_Snapshots_Initial und Stock_Weekly_Snapshots_Initial aus.

  3. Für nachfolgende Aktualisierungen planen oder führen Sie die folgenden DAGs aus:

    • Monatliche und wöchentliche Updates:
      • Stock_Monthly_Snapshots_Periodical_Update
      • Stock_Weekly_Snapshots_periodical_Update
    • Tägliches Update:
      • Stock_Monthly_Snapshots_Daily_Update
      • Stock_Weekly_Snapshots_Update_Daily

  4. Aktualisieren Sie die Zwischenansichten StockMonthlySnapshots und StockWeeklySnapshots, gefolgt von den Ansichten InventoryKeyMetrics und InventoryByPlants, um die aktualisierten Daten zu sehen.

Optional: Ansicht „Texte der Produkthierarchie“ konfigurieren

In der Ansicht „Texte der Produkthierarchie“ werden Materialien und ihre Produkthierarchien flach dargestellt. Die resultierende Tabelle kann verwendet werden, um dem Trends-Add-on eine Liste von Begriffen zu übergeben, um Interessen im Zeitverlauf abzurufen. So konfigurieren Sie diese Ansicht:

  1. Passen Sie die Hierarchieebenen und die Sprache in der Datei prod_hierarchy_texts.sql unter den Markierungen für ## CORTEX-CUSTOMER an.

  2. Wenn Ihre Produkthierarchie mehr Ebenen enthält, müssen Sie möglicherweise eine zusätzliche SELECT-Anweisung hinzufügen, die dem Common Table Expression h1_h2_h3 ähnelt.

    Je nach Quellsystem sind möglicherweise zusätzliche Anpassungen erforderlich. Wir empfehlen, die Geschäftsnutzer oder Analysten schon früh in den Prozess einzubeziehen, um diese zu erkennen.

Optional: Ansichten für die Hierarchieebenenüberprüfung konfigurieren

Ab Version 6.0 unterstützt Cortex Framework die Hierarchie-Ebenenüberprüfung als Berichtsansicht. Dies ist eine erhebliche Verbesserung gegenüber dem alten Hierarchie-Flattener, da jetzt die gesamte Hierarchie flachgelegt wird, die Optimierung für S/4 durch die Verwendung von S/4-spezifischen Tabellen anstelle von alten ECC-Tabellen verbessert wird und die Leistung erheblich gesteigert wird.

Berichtsdatenansichten – Zusammenfassung

Hier finden Sie die folgenden Ansichten im Zusammenhang mit der Hierarchieflachung:

Art der Hierarchie Tabelle mit nur einer flachen Hierarchie Ansichten zum Visualisieren einer flachen Hierarchie Logik für die Integration des Gewinn- und Verlustrechnungskontos mit dieser Hierarchie
Version des Finanzberichts (Financial Statement Version, FSV) fsv_glaccounts FSVHierarchyFlattened ProfitAndLossOverview
Profitcenter profit_centers ProfitCenterHierarchyFlattened ProfitAndLossOverview_ProfitCenterHierarchy
Kostenstelle cost_centers CostCenterHierarchyFlattened ProfitAndLossOverview_CostCenterHierarchy

Beachten Sie Folgendes, wenn Sie Ansichten mit Hierarchie-Flattening verwenden:

  • Die Ansichten mit nur flacher Hierarchie sind funktional mit den Tabellen identisch, die mit der alten Lösung zum Flachstellen von Hierarchien generiert wurden.
  • Die Übersichtsansichten werden nicht standardmäßig bereitgestellt, da sie nur zur Veranschaulichung der BI-Logik dienen. Sie finden den Quellcode im Verzeichnis src/SAP/SAP_REPORTING.

Hierarchie-Flattening konfigurieren

Je nach Hierarchie, mit der Sie arbeiten, sind die folgenden Eingabeparameter erforderlich:

Art der Hierarchie Erforderlicher Parameter Quellfeld (ECC) Quellfeld (S4)
Version des Finanzberichts (Financial Statement Version, FSV) Kontenübersicht ktopl nodecls
Hierarchiename versn hryid
Profit center Klasse des Sets setclass setclass
Organisationseinheit: Kontrollbereich oder zusätzlicher Schlüssel für die Gruppe. subclass subclass
Kostenstelle Klasse des Sets setclass setclass
Organisationseinheit: Kontrollbereich oder zusätzlicher Schlüssel für die Gruppe. subclass subclass

Wenn Sie sich nicht sicher sind, welche genauen Parameter verwendet werden sollten, wenden Sie sich an einen SAP-Berater für Finanzen oder Controlling.

Nachdem die Parameter erfasst wurden, aktualisieren Sie die ## CORTEX-CUSTOMER-Kommentare in den entsprechenden Verzeichnissen entsprechend Ihren Anforderungen:

Art der Hierarchie Code-Speicherort
Version des Finanzberichts (Financial Statement Version, FSV) src/SAP/SAP_REPORTING/local_k9/fsv_hierarchy
Profitcenter src/SAP/SAP_REPORTING/local_k9/profitcenter_hierarchy
Kostenstelle src/SAP/SAP_REPORTING/local_k9/costcenter_hierarchy

Aktualisieren Sie gegebenenfalls die ## CORTEX-CUSTOMER-Kommentare in den relevanten Berichtsansichten im Verzeichnis src/SAP/SAP_REPORTING.

Lösungsdetails

Die folgenden Quelltabellen werden für die Hierarchie-Ebenenüberprüfung verwendet:

Art der Hierarchie Quelltabellen (ECC) Quelltabellen (S4)
Version des Finanzberichts (Financial Statement Version, FSV)
  • fagl_011pc
  • fagl_011zc
  • ska1
  • hrrp_node
  • hrrp_directory
  • ska1
Profitcenter
  • setheader
  • setnode
  • setleaf
  • sethanahier0106
Kostenstelle
  • setheader
  • setnode
  • setleaf
  • sethanahier0101

Hierarchien visualisieren

Mit der SAP-Hierarchie-Flattener-Lösung von Cortex wird die gesamte Hierarchie flachgelegt. Wenn Sie eine visuelle Darstellung der geladenen Hierarchie erstellen möchten, die mit der Darstellung in der SAP-Benutzeroberfläche vergleichbar ist, können Sie eine der Ansichten zum Visualisieren flacher Hierarchien mit der Bedingung IsLeafNode=True abfragen.

Von der bisherigen Lösung zur Hierarchie-Flattening migrieren

Wenn Sie von der alten Lösung zur Hierarchie-Flattening vor Cortex v6.0 migrieren möchten, ersetzen Sie die Tabellen wie in der folgenden Tabelle dargestellt. Prüfen Sie die Feldnamen auf Richtigkeit, da einige Feldnamen leicht geändert wurden. Beispiel: prctr in cepc_hier ist jetzt profitcenter in der Tabelle profit_centers.

Art der Hierarchie Ersetzen Sie diese Tabelle: Mit:
Version des Finanzberichts (Financial Statement Version, FSV) ska1_hier fsv_glaccounts
Profitcenter cepc_hier profit_centers
Kostenstelle csks_hier cost_centers

Optional: SAP-Finanzmodul konfigurieren

Das SAP-Finanzmodul des Cortex-Frameworks enthält die Ansichten FinancialStatement, BalanceSheet und ProfitAndLoss mit wichtigen Finanzdaten.

So aktualisieren Sie diese Finanztabellen:

Für den anfänglichen LadevorgangFür die regelmäßige Aktualisierung
  1. Prüfen Sie nach der Bereitstellung, ob der CDC-Datensatz richtig ausgefüllt ist. Führen Sie dazu bei Bedarf alle CDC-DAGs aus.
  2. Achten Sie darauf, dass die Ansichten für die Hierarchie-Flattening-Funktion für die von Ihnen verwendeten Hierarchietypen (FSV, Kostenstelle und Profitcenter) richtig konfiguriert sind.

  3. Führen Sie den DAG financial_statement_initial_load aus.

  4. Wenn Sie die Daten als Tabellen bereitgestellt haben (empfohlen), aktualisieren Sie die folgenden Elemente in der Reihenfolge, indem Sie die entsprechenden DAGs ausführen:

    1. Financial_Statements
    2. BalanceSheets
    3. ProfitAndLoss
  1. Prüfen Sie, ob die Ansichten für die Hierarchieflattening-Funktion für die von Ihnen verwendeten Hierarchietypen (FSV, Kostenstelle und Profitcenter) richtig konfiguriert und auf dem neuesten Stand sind.

  2. Planen oder führen Sie den DAG financial_statement_periodical_load aus.

  3. Wenn Sie die Daten als Tabellen bereitgestellt haben (empfohlen), aktualisieren Sie die folgenden Elemente in der Reihenfolge, indem Sie die entsprechenden DAGs ausführen:

    1. Financial_Statements
    2. BalanceSheets
    3. ProfitAndLoss

In den folgenden Übersichten können Sie die Daten aus diesen Tabellen visualisieren:

  • ProfitAndLossOverview.sql, wenn Sie die FSV-Hierarchie verwenden.
  • ProfitAndLossOverview_CostCenter.sql, wenn Sie die Kostenstellenhierarchie verwenden.
  • ProfitAndLossOverview_ProfitCenter.sql, wenn Sie die Profit Center-Hierarchie verwenden.

Nächste Schritte