Integrazione con SAP

Questa pagina descrive i passaggi di integrazione per i carichi di lavoro operativi SAP (SAP ECC e SAP S/4 HANA) in Cortex Framework Data Foundation. Cortex Framework può accelerare l'integrazione dei dati SAP con BigQuery utilizzando modelli di elaborazione dei dati predefiniti con pipeline Dataflow in BigQuery, mentre Cloud Composer pianifica e monitora queste pipeline Dataflow per ottenere approfondimenti dai dati operativi SAP.

Il file config.json nel repository Cortex Framework Data Foundation configura le impostazioni necessarie per trasferire i dati da qualsiasi origine dati, inclusa SAP. Questo file contiene i seguenti parametri per i workload SAP operativi:

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

La tabella seguente descrive il valore di ogni parametro operativo SAP:

Sebbene non sia richiesta una versione minima di SAP, i modelli ECC sono stati sviluppati sulla versione di SAP ECC meno recente attualmente supportata. Sono previste differenze nei campi tra il nostro sistema e altri sistemi, indipendentemente dalla versione.

Modello dati

Questa sezione descrive i modelli di dati SAP (ECC e S/4 HANA) utilizzando i diagrammi entità-relazione (ERD).

Visualizzazioni di base

Si tratta degli oggetti blu nel diagramma ERD e sono viste delle tabelle CDC senza trasformazioni, ad eccezione di alcuni alias dei nomi delle colonne. Vedi gli script in src/SAP/SAP_REPORTING.

Viste report

Si tratta degli oggetti verdi nel diagramma ERD e contengono gli attributi dimensionali pertinenti utilizzati dalle tabelle dei report. Vedi gli script in src/SAP/SAP_REPORTING.

Visualizzazione Utilità o BQML

Si tratta degli oggetti gialli nel diagramma ER e contengono i fatti e le dimensioni uniti tipo specifico di visualizzazione utilizzato per l'analisi e la generazione di report sui dati. Vedi gli script su src/SAP/SAP_REPORTING.

Tag aggiuntivi

I tag codificati per colore in questo diagramma ER rappresentano le seguenti funzionalità delle tabelle dei report:

Prerequisiti per la replica SAP

Considera i seguenti prerequisiti per i dati di replica SAP con Cortex Framework Data Foundation:

• Integrità dei dati: Cortex Framework Data Foundation prevede che le tabelle SAP vengano replicate con nomi, tipi e strutture di dati dei campi identici a quelli esistenti in SAP. Se le tabelle vengono replicate con lo stesso formato, gli stessi nomi dei campi e la stessa granularità dell'origine, non è necessario utilizzare uno strumento di replica specifico.
• Denominazione delle tabelle: i nomi delle tabelle BigQuery devono essere creati in lettere minuscole.
• Configurazione tabella: l'elenco delle tabelle utilizzate dai modelli SAP è disponibile e configurabile nel file CDC (Change Data Capture) cdc_settings.yaml. Se una tabella non è elencata durante il deployment, i modelli che dipendono da essa non andranno a buon fine, mentre gli altri modelli non dipendenti verranno implementati correttamente.
• Considerazioni specifiche BigQuery Connector per SAP:
  • Mappatura delle tabelle: per quanto riguarda l'opzione di conversione, segui la documentazione sulla mappatura delle tabelle predefinita.
  • Disattivazione della compressione dei record: ti consigliamo di disattivare la compressione dei record che potrebbe influire sia sul livello CDC di Cortex sia sul set di dati dei report di Cortex.
• Replica dei metadati: se non esegui il deployment dei dati di test e non generi gli script DAG CDC durante il deployment, assicurati che la tabella DD03L per i metadati SAP venga replicata da SAP nel progetto di origine. Questa tabella contiene metadati sulle tabelle, ad esempio l'elenco delle chiavi, ed è necessaria per il funzionamento del generatore CDC e del resolver delle dipendenze. Questa tabella ti consente anche di aggiungere tabelle non coperte dal modello, ad esempio tabelle personalizzate o Z, in modo da poter generare script CDC.

• Gestione di piccole variazioni del nome della tabella: se il nome di una tabella presenta piccole differenze, alcune visualizzazioni potrebbero non trovare i campi richiesti, perché i sistemi SAP potrebbero presentare piccole variazioni dovute a versioni o componenti aggiuntivi oppure perché alcuni strumenti di replica potrebbero gestire in modo leggermente diverso i caratteri speciali. Ti consigliamo di eseguire il deployment con turboMode : false per individuare il maggior numero di errori in un solo tentativo. Alcuni problemi comuni includono:

  • I campi che iniziano con _ (ad esempio, _DATAAGING) non hanno più _.
  • I campi non possono iniziare con / in BigQuery.

  In questa situazione, puoi modificare la visualizzazione non riuscita per selezionare il campo così come viene visualizzato dallo strumento di replica che preferisci.

Replicare i dati non elaborati da SAP

Lo scopo di Data Foundation è esporre modelli di dati e analisi per report e applicazioni. I modelli utilizzano i dati replicati da un sistema SAP utilizzando uno strumento di replica preferito, come quelli elencati nelle guide all'integrazione dei dati per SAP.

I dati del sistema SAP (ECC o S/4 HANA) vengono replicati in formato non elaborato. I dati vengono copiati direttamente da SAP a BigQuery senza alcuna modifica alla loro struttura. Si tratta essenzialmente di un'immagine speculare delle tabelle nel tuo sistema SAP. BigQuery utilizza nomi di tabelle in minuscolo per il suomodello dei datii. Pertanto, anche se le tabelle SAP potrebbero avere nomi in maiuscolo (come MANDT), vengono convertite in minuscolo (come mandt) in BigQuery.

Elaborazione Change Data Capture (CDC)

Scegli una delle seguenti modalità di elaborazione CDC offerte da Cortex Framework per gli strumenti di replica per caricare i record da SAP:

• Aggiungi sempre: inserisci ogni modifica in un record con un timestamp e un flag di operazione (Inserisci, Aggiorna, Elimina), in modo che sia possibile identificare l'ultima versione.
• Update when landing (Aggiorna all'arrivo) (unisci o upsert): crea una versione aggiornata di un record all'arrivo in change data capture processed. Esegue l'operazione CDC in BigQuery.

Cortex Framework Data Foundation supporta entrambe le modalità, anche se per l'accodamento permanente fornisce modelli di elaborazione CDC. Alcune funzionalità devono essere commentate per l'aggiornamento all'arrivo. Ad esempio, OneTouchOrder.sql e tutte le relative query dipendenti. La funzionalità può essere sostituita con tabelle come CDPOS.

Configura i modelli CDC per gli strumenti di replica in modalità di accodamento permanente

Ti consigliamo vivamente di configurare cdc_settings.yaml in base alle tue esigenze. Alcune frequenze predefinite potrebbero comportare costi inutili se l'attività non richiede un tale livello di aggiornamento dei dati. Se utilizzi uno strumento che viene eseguito in modalità di accodamento permanente, Cortex Framework Data Foundation fornisce modelli CDC per automatizzare gli aggiornamenti e creare una versione più recente della verità o del gemello digitale nel set di dati elaborato con CDC.

Puoi utilizzare la configurazione nel file cdc_settings.yaml se devi generare script di elaborazione CDC. Per le opzioni, vedi Configurare l'elaborazione CDC. Per i dati di test, puoi lasciare questo file come predefinito.

Apporta tutte le modifiche necessarie ai modelli DAG in base alla tua istanza di Airflow o Cloud Composer. Per saperne di più, vedi Raccolta delle impostazioni di Cloud Composer.

(Facoltativo) Se vuoi aggiungere ed elaborare le tabelle singolarmente dopo il deployment, puoi modificare il file cdc_settings.yaml per elaborare solo le tabelle che ti servono ed eseguire nuovamente la chiamata al modulo specificato src/SAP_CDC/cloudbuild.cdc.yaml direttamente.

Configurare l'elaborazione CDC

Durante il deployment, puoi scegliere di unire le modifiche in tempo reale utilizzando una vista in BigQuery o pianificando un'operazione di unione in Cloud Composer (o qualsiasi altra istanza di Apache Airflow). Cloud Composer può pianificare l'esecuzione degli script per elaborare periodicamente le operazioni di unione. I dati vengono aggiornati all'ultima versione ogni volta che vengono eseguite le operazioni di unione, tuttavia, operazioni di unione più frequenti si traducono in costi più elevati. Personalizza la frequenza pianificata in base alle esigenze della tua attività. Per saperne di più, consulta Pianificazione supportata da Apache Airflow.

Il seguente script di esempio mostra un estratto del file di configurazione:

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

Questo file di esempio di configurazione esegue le seguenti operazioni:

1. Crea una copia da SOURCE_PROJECT_ID.REPLICATED_DATASET.adrc in TARGET_PROJECT_ID.DATASET_WITH_LATEST_RECORDS.adrc, se quest'ultima non esiste.
2. Crea uno script CDC nel bucket specificato.
3. Crea una copia da SOURCE_PROJECT_ID.REPLICATED_DATASET.adr6 in TARGET_PROJECT_ID.DATASET_WITH_LATEST_RECORDS.adr6_cdc, se quest'ultima non esiste.
4. Crea uno script CDC nel bucket specificato.

Se vuoi creare DAG o visualizzazioni di runtime per elaborare le modifiche alle tabelle che esistono in SAP e non sono elencate nel file, aggiungile a questo file prima del deployment. Questa operazione funziona a condizione che la tabella DD03L venga replicata nel set di dati di origine e che lo schema della tabella personalizzata sia presente in questa tabella. Ad esempio, la seguente configurazione crea uno script CDC per la tabella personalizzata zztable_customer e una vista di runtime per analizzare le modifiche in tempo reale per un'altra tabella personalizzata denominata zzspecial_table:

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

Esempio di modello generato

Il seguente modello genera l'elaborazione delle modifiche. Modifiche, come il nome del campo timestamp o operazioni aggiuntive, possono essere modificate a questo punto:

  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}

In alternativa, se la tua attività richiede insight in tempo quasi reale e lo strumento di replica lo supporta, lo strumento di deployment accetta l'opzione RUNTIME. Ciò significa che non verrà generato uno script CDC. Una visualizzazione, invece, esegue la scansione e recupera l'ultimo record disponibile in fase di runtime per una coerenza immediata.

Struttura delle directory per i DAG e gli script CDC

La struttura del bucket Cloud Storage per i DAG SAP CDC prevede che i file SQL vengano generati in /data/bq_data_replication, come nell'esempio seguente. Puoi modificare questo percorso prima del deployment. Se non hai ancora un ambiente Cloud Composer disponibile, puoi crearne uno in un secondo momento e spostare i file nel bucket DAG.

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

Gli script che elaborano i dati in Airflow o Cloud Composer vengono generati appositamente separatamente dagli script specifici di Airflow. In questo modo puoi trasferire questi script a un altro strumento a tua scelta.

Campi CDC richiesti per le operazioni MERGE

Specifica i seguenti parametri per la generazione automatica dei processi batch CDC:

• Progetto di origine + set di dati:il set di dati in cui vengono trasmessi o replicati i dati SAP. Affinché gli script CDC funzionino per impostazione predefinita, le tabelle devono avere un campo timestamp (denominato recordstamp) e un campo operazione con i seguenti valori, tutti impostati durante la replica:
  • I: per Inserisci.
  • U: per Aggiorna.
  • D: per l'eliminazione.
• Progetto di destinazione + set di dati per l'elaborazione CDC: lo script generato per impostazione predefinita genera le tabelle da una copia del set di dati di origine se non esistono.
• Tabelle replicate: le tabelle per cui devono essere generati gli script
• Frequenza di elaborazione: seguendo la notazione Cron, la frequenza con cui è prevista l'esecuzione dei DAG:
• Bucket Cloud Storage di destinazione in cui vengono copiati i file di output CDC.
• Nome della connessione: il nome della connessione utilizzata da Cloud Composer.
• (Facoltativo) Nome della tabella di destinazione: disponibile se il risultato dell'elaborazione CDC rimane nello stesso set di dati della destinazione.

Ottimizzazione delle prestazioni per le tabelle CDC

Per alcuni set di dati CDC, potresti voler sfruttare il partizionamento delle tabelle, il clustering delle tabelle o entrambi di BigQuery. Questa scelta dipende dai seguenti fattori:

• Dimensioni e dati della tabella.
• Colonne disponibili nella tabella.
• Necessità di dati in tempo reale con visualizzazioni.
• Dati materializzati come tabelle.

Per impostazione predefinita, le impostazioni CDC non applicano il partizionamento o il clustering delle tabelle. La scelta di configurarlo in base alle tue esigenze è tua. Per creare tabelle con partizioni o cluster, aggiorna il file cdc_settings.yaml con le configurazioni pertinenti. Per saperne di più, consulta Partizione della tabella e Impostazioni del cluster.

1. Questa funzionalità si applica solo quando un set di dati in cdc_settings.yaml è configurato per la replica come tabella (ad esempio load_frequency = "@daily") e non definito come vista (load_frequency = "RUNTIME").
2. Una tabella può essere sia tabella partizionata che raggruppata in cluster.

Se utilizzi uno strumento di replica che consente le partizioni nel set di dati non elaborati, come BigQuery Connector per SAP, è consigliabile impostare partizioni basate sul tempo nelle tabelle non elaborate. Il tipo di partizione funziona meglio se corrisponde alla frequenza dei DAG CDC nella configurazione cdc_settings.yaml. Per ulteriori informazioni, vedi Considerazioni sulla progettazione per la modellazione dei dati SAP in BigQuery.

(Facoltativo) Configurazione del modulo di inventario SAP

Il modulo Inventario SAP di Cortex Framework include le visualizzazioni InventoryKeyMetrics e InventoryByPlant che forniscono informazioni chiave sul tuo inventario. Queste visualizzazioni sono supportate da tabelle di snapshot mensili e settimanali che utilizzano DAG specializzati. Entrambi possono essere eseguiti contemporaneamente e non interferiscono tra loro.

Per aggiornare una o entrambe le tabelle snapshot:

1. Aggiorna SlowMovingThreshold.sql e StockCharacteristicsConfig.sql per definire la soglia di lento movimento e le caratteristiche delle scorte per diversi tipi di materiali, in base ai tuoi requisiti.

2. Per il caricamento iniziale o l'aggiornamento completo, esegui i DAG Stock_Monthly_Snapshots_Initial e Stock_Weekly_Snapshots_Initial.

3. Per gli aggiornamenti successivi, pianifica o esegui i seguenti DAG:

   • Aggiornamenti mensili e settimanali:
     • Stock_Monthly_Snapshots_Periodical_Update
     • Stock_Weekly_Snapshots_periodical_Update
   • Aggiornamento giornaliero:
     • Stock_Monthly_Snapshots_Daily_Update
     • Stock_Weekly_Snapshots_Update_Daily

4. Aggiorna le visualizzazioni intermedie StockMonthlySnapshots e StockWeeklySnapshots, seguite dalle visualizzazioni InventoryKeyMetrics e InventoryByPlants, rispettivamente, per visualizzare i dati aggiornati.

(Facoltativo) Configurare la visualizzazione Testi gerarchia prodotto

La visualizzazione Testi gerarchia prodotto appiattisce i materiali e le relative gerarchie di prodotto. La tabella risultante può essere utilizzata per fornire al componente aggiuntivo Trends un elenco di termini per recuperare Interesse nel tempo. Configura questa visualizzazione seguendo questi passaggi:

1. Regola i livelli della gerarchia e la lingua nel file prod_hierarchy_texts.sql, nei marcatori per ## CORTEX-CUSTOMER.

2. Se la gerarchia dei prodotti contiene più livelli, potresti dover aggiungere un'ulteriore istruzione SELECT simile all'espressione di tabella comune h1_h2_h3.

   Potrebbero essere disponibili personalizzazioni aggiuntive a seconda dei sistemi di origine. Ti consigliamo di coinvolgere gli utenti aziendali o gli analisti all'inizio del processo per individuarli.

(Facoltativo) Configurazione delle visualizzazioni di flattening della gerarchia

A partire dalla release v6.0, Cortex Framework supporta l'appiattimento della gerarchia come viste dei report. Si tratta di un miglioramento significativo rispetto al legacy hierarchy flattener, in quanto ora appiattisce l'intera gerarchia, esegue un'ottimizzazione migliore per S/4 utilizzando tabelle specifiche di S/4 anziché tabelle ECC legacy e migliora notevolmente le prestazioni.

Riepilogo delle viste report

Trova le seguenti visualizzazioni correlate all'appiattimento della gerarchia:

Tieni presente quanto segue quando utilizzi le visualizzazioni di compressione della gerarchia:

• Le visualizzazioni gerarchiche compresse sono funzionalmente equivalenti alle tabelle generate dalla soluzione di compressione gerarchica legacy.
• Le viste panoramiche non vengono implementate per impostazione predefinita perché sono pensate per mostrare solo la logica BI. Trova il codice sorgente nella directory src/SAP/SAP_REPORTING.

Configurazione dell'appiattimento della gerarchia

In base alla gerarchia con cui stai lavorando, sono necessari i seguenti parametri di input:

Se non hai la certezza dei parametri esatti, rivolgiti a un consulente SAP per la finanza o il controllo.

Una volta raccolti i parametri, aggiorna i commenti ## CORTEX-CUSTOMER all'interno di ciascuna delle directory corrispondenti, in base ai tuoi requisiti:

Se applicabile, assicurati di aggiornare i ## CORTEX-CUSTOMERcommenti all'interno delle visualizzazioni dei report pertinenti nella directory src/SAP/SAP_REPORTING.

Dettagli della soluzione

Per l'appiattimento della gerarchia vengono utilizzate le seguenti tabelle di origine:

Visualizzare le gerarchie

La soluzione di appiattimento della gerarchia SAP di Cortex appiattisce l'intera gerarchia. Se vuoi creare una rappresentazione visiva della gerarchia caricata che sia paragonabile a quella mostrata da SAP nell'interfaccia utente, esegui una query su una delle viste per visualizzare le gerarchie compresse con la condizione IsLeafNode=True.

Migrazione dalla soluzione di appiattimento della gerarchia legacy

Per eseguire la migrazione dalla soluzione di flattening della gerarchia precedente a Cortex v6.0, sostituisci le tabelle come mostrato nella tabella seguente. Assicurati di controllare l'accuratezza dei nomi dei campi, poiché alcuni sono stati leggermente modificati. Ad esempio, prctr in cepc_hier ora è profitcenter nella tabella profit_centers.

(Facoltativo) Configurazione del modulo SAP Finance

Il modulo SAP Finance di Cortex Framework include le visualizzazioni FinancialStatement, BalanceSheet e ProfitAndLoss che forniscono informazioni finanziarie chiave.

Per aggiornare queste tabelle di Finance:

Per visualizzare i dati di queste tabelle, consulta le seguenti visualizzazioni Panoramica:

• ProfitAndLossOverview.sql se utilizzi la gerarchia FSV.
• ProfitAndLossOverview_CostCenter.sql se utilizzi la gerarchia dei centri di costo.
• ProfitAndLossOverview_ProfitCenter.sql se utilizzi la gerarchia del Centro profitti.

(Facoltativo) Attivazione dei DAG dipendenti dalle attività

Cortex Framework fornisce facoltativamente impostazioni di dipendenza consigliate per la maggior parte delle tabelle SQL SAP (ECC e S/4 HANA), in cui tutte le tabelle dipendenti possono essere aggiornate da un singolo DAG. Puoi personalizzarli ulteriormente. Per ulteriori informazioni, consulta DAG dipendenti dalle attività.

Passaggi successivi

• Per saperne di più su altre origini dati e altri carichi di lavoro, vedi Origini dati e carichi di lavoro.
• Per ulteriori informazioni sui passaggi per il deployment negli ambienti di produzione, consulta Prerequisiti per il deployment di Cortex Framework Data Foundation.