Origine dati SAP ERP

Il livello di base di dati di Google Cloud Cortex Framework per SAP ERP richiede la connettività ai dati non elaborati del sistema di origine. Sono supportati sia SAP ECC sia SAP S/4HANA.

Prima di eseguire il deployment dei contenuti di Cortex Framework, le tabelle SAP ERP pertinenti devono essere replicate in BigQuery. Puoi farlo inserendo i dati in un set di dati di livello non elaborato dedicato per l'elaborazione di Change Data Capture (CDC) o utilizzando pipeline CDC consolidate per alimentare direttamente il livello di base di dati. Per maggiori informazioni, consulta Requisiti tecnici per la replica dei dati SAP ERP.

Puoi utilizzare qualsiasi strumento di replica di tua scelta, a condizione che possa replicare i dati in formato di tabella non elaborata in BigQuery. Ad esempio, Google Cloud le soluzioni includono il BigQuery Connector per SAP (richiede SAP SLT), e il BigQuery Toolkit per SAP.

Per garantire la compatibilità tra i set di dati non elaborati replicati da SAP ERP e il livello di base di dati di Cortex Framework, assicurati di soddisfare i seguenti requisiti.

Requisiti tecnici per la replica dei dati SAP ERP

Assicurati di esaminare e completare i seguenti requisiti tecnici per la replica dei dati SAP in Cortex Framework in BigQuery.

  1. Struttura dei dati non elaborati: i dati di ECC o S/4HANA devono essere inseriti in BigQuery con la stessa struttura delle tabelle di base in SAP e senza trasformazioni aziendali. Le tabelle devono essere replicate con i nomi dei campi, i tipi e la granularità richiesti così come esistono in SAP.

  2. Configurazione della tabella: l'elenco delle tabelle da trasformare è definito nel file table_settings.yaml (che si trova in config/cortex/data_foundation/sap). Se durante il deployment manca una tabella obbligatoria, i prodotti dati specifici che dipendono da essa non funzioneranno.

  3. Requisiti dei metadati: devi replicare le tabelle dei metadati come DD03L dall'origine SAP al set di dati non elaborati (configurato come origine per il modulo di base in config/config.yaml). Tieni presente che, sebbene queste tabelle di metadati debbano esistere nel set di dati non elaborati, non devono essere incluse nel file table_settings.yaml di base di dati e non vengono elaborate dal livello di base di dati. Assicurati che la tabella DD03L replicata contenga i record dei metadati dei campi per tutte le tabelle che prevedi di importare (ad esempio tabelle personalizzate o supplementari come sflight). Gli script di build di Cortex Framework e il resolver delle dipendenze leggono queste righe di metadati per identificare gli elenchi di colonne, i tipi di dati e le relazioni di chiave primaria tra le tabelle.

  4. Maiuscole/minuscole: i nomi delle tabelle SAP replicate in BigQuery devono essere in minuscolo per la compatibilità del modello dei dati di Cortex Framework (ad esempio, la tabella SAP MARA diventa mara in BigQuery).

  5. Nomi degli oggetti (colonne) e caratteri speciali: per i nomi degli oggetti (colonne) contenenti caratteri speciali (come /, - o trattini bassi iniziali _), Cortex prevede un pattern di sanificazione generico:

    • Tutti i caratteri non alfanumerici vengono sostituiti con un trattino basso _.
    • I trattini bassi e le cifre iniziali non sono consentiti. Ad esempio, /GOOG/TEST diventa goog_test e _DATAAGING diventa dataaging. Se lo strumento di replica inserisce i dati mantenendo i trattini bassi iniziali, è necessario un passaggio di normalizzazione (alias) nel livello di base di dati.

  6. Campi di propagazione dei dati: per supportare CDC (Change Data Capture) e la propagazione dei dati, le tabelle SAP replicate devono avere:

    • Un flag di operazione denominato operation_flag (L = caricamento iniziale, I = inserimento, U = aggiornamento, D = eliminazione).
    • Un timestamp denominato recordstamp (compilato con il timestamp corrente al momento del caricamento).
    • Facoltativo: nelle tabelle replicate _DS_RAW viene scelto un campo aggiuntivo is_deleted (BOOLEAN) (impostato su false per impostazione predefinita durante il caricamento iniziale). Le visualizzazioni di runtime generate da Cortex fanno riferimento a questa colonna, ma può essere rimossa dai modelli CDC e di visualizzazione prima dell'esecuzione se lo strumento di replica non la produce.

  7. Tipi di dati: mappatura necessaria dei tipi di dati SAP con i tipi di dati BigQuery per la compatibilità:

    Necessario per le operazioni standard:

    Tipo di dati SAP Tipo di dati BigQuery Descrizione
    DATS DATE Tipo di dati Data
    TIMS TIME Tipo di dati Ora

  8. Altamente consigliato per precisione e compatibilità:

    • CURR (valuta) e QUAN (quantità) mappati su NUMERIC o BIGNUMERIC (evita FLOAT64 per evitare errori di arrotondamento nei calcoli finanziari).
    • NUMC (carattere numerico) mappato su STRING (per conservare gli zeri iniziali per i numeri di documenti e gli articoli, garantendo l'unione corretta).

  9. Compressione del payload: per evitare che le colonne SAP vuote (valori iniziali come spazi o zeri) vengano riempite con NULL in BigQuery, assicurati che la compressione del payload sia disattivata nella configurazione del connettore (o che l'opzione "Invia non compresso" sia attivata). In questo modo, le stringhe vuote o gli zeri vengono mantenuti come tali nella destinazione anziché essere impostati su NULL per impostazione predefinita.