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, i tipi e la granularità dei campi 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 di dati specifici che dipendono da essa non funzioneranno.

  3. Requisiti dei met1adata: devi replicare la tabella DD03L dall'origine SAP. Questa tabella è fondamentale per il risolutore di dipendenze perché contiene metadati e chiavi dei campi.

  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) che contengono 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 con i trattini bassi iniziali conservati, è 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: viene scelto un campo aggiuntivo is_deleted (BOOLEAN) nelle tabelle replicate _DS_RAW (impostato su false per impostazione predefinita al 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 basati sulla data
    TIMS TIME Tipo di dati basati sul tempo

  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 documento e i numeri di articolo, garantendo unioni riuscite).

  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 conservati come tali nella destinazione anziché essere impostati su NULL per impostazione predefinita.