Source de données SAP ERP

La couche de base de données Google Cloud Cortex Framework pour SAP ERP nécessite une connectivité aux données brutes du système source. SAP ECC et SAP S/4HANA sont compatibles.

Avant de déployer le contenu de Cortex Framework, les tables SAP ERP pertinentes doivent être répliquées dans BigQuery. Pour ce faire, vous pouvez transférer les données en les plaçant dans un ensemble de données de couche brute dédié au traitement de la capture des données modifiées (CDC, Change Data Capture) ou en utilisant des pipelines CDC établis pour alimenter directement la couche de base de données. Pour en savoir plus, consultez Exigences techniques pour la réplication des données SAP ERP.

Vous pouvez utiliser l'outil de réplication de votre choix, à condition qu'il puisse répliquer les données au format de table brute dans BigQuery. Par exemple, Google Cloud les solutions incluent le BigQuery Connector pour SAP (nécessite SAP SLT), et le BigQuery Toolkit pour SAP.

Pour assurer la compatibilité entre les ensembles de données brutes répliqués de SAP ERP et la couche de base de données Cortex Framework, assurez-vous de respecter les exigences suivantes.

Exigences techniques pour la réplication des données SAP ERP

Assurez-vous de consulter et de respecter les exigences techniques suivantes pour répliquer les données SAP dans Cortex Framework dans BigQuery.

  1. Structure des données brutes : les données d'ECC ou de S/4HANA doivent être transférées dans BigQuery avec la même structure que les tables de base dans SAP et sans transformations métier. Les tables doivent être répliquées avec les noms de champs, les types et la granularité requis tels qu'ils existent dans SAP.

  2. Configuration des tables : la liste des tables à transformer est définie dans le fichier table_settings.yaml (situé sous config/cortex/data_foundation/sap). Si une table requise est manquante lors du déploiement, les produits de données spécifiques qui en dépendent échoueront.

  3. Exigences concernant les métadonnées : vous devez répliquer les tables de métadonnées telles que DD03L de votre source SAP vers l'ensemble de données brutes (configuré comme source de votre module de base dans config/config.yaml). Notez que, bien que ces tables de métadonnées doivent exister dans l'ensemble de données brutes, elles ne doivent pas être incluses dans le fichier table_settings.yaml de la base de données et ne sont pas traitées par la couche de base de données. Assurez-vous que la table DD03L répliquée contient les enregistrements de métadonnées de champ pour toutes les tables que vous prévoyez d'ingérer (telles que les tables personnalisées ou supplémentaires comme sflight). Les scripts de compilation et le résolveur de dépendances de Cortex Framework lisent ces lignes de métadonnées pour identifier les listes de colonnes, les types de données et les relations de clé primaire entre les tables.

  4. Casse : les noms des tables SAP répliquées dans BigQuery doivent être en minuscules pour assurer la compatibilité avec le modèle de données Cortex Framework (par exemple, la table SAP MARA devient mara dans BigQuery).

  5. Noms d'objets (colonnes) et caractères spéciaux : pour les noms d'objets (colonnes) contenant des caractères spéciaux (comme /, - ou des traits de soulignement au début _), Cortex s'attend à un modèle de nettoyage générique :

    • Tous les caractères non alphanumériques sont remplacés par un trait de soulignement _.
    • Les traits de soulignement et les chiffres au début ne sont pas autorisés. Par exemple, /GOOG/TEST devient goog_test, et _DATAAGING devient dataaging. Si votre outil de réplication transfère des données en conservant les traits de soulignement au début, une étape de normalisation (alias) est requise dans la couche de base de données.

  6. Champs de propagation des données : pour prendre en charge la CDC (capture des données modifiées) et la propagation des données, les tables SAP répliquées doivent comporter les éléments suivants :

    • Un indicateur d'opération nommé operation_flag (L = chargement initial, I = insertion, U = mise à jour, D = suppression).
    • Un code temporel nommé recordstamp (rempli avec le code temporel actuel au moment du chargement).
    • Facultatif : un champ supplémentaire is_deleted (BOOLEAN) est choisi dans les tables répliquées _DS_RAW (valeur par défaut "false" lors du chargement initial). Les vues d'exécution générées par Cortex font référence à cette colonne, mais elle peut être supprimée des modèles CDC et de vue avant l'exécution si l'outil de réplication ne la produit pas.

  7. Types de données : mappage nécessaire des types de données SAP avec les types de données BigQuery pour assurer la compatibilité :

    Nécessaire pour les opérations standards :

    Type de données SAP Type de données BigQuery Description
    DATS DATE Type de données temporelles
    TIMS TIME Type de données temporelles

  8. Fortement recommandé pour la précision et la compatibilité :

    • CURR (devise) et QUAN (quantité) mappés sur NUMERIC ou BIGNUMERIC (évitez FLOAT64 pour éviter les erreurs d'arrondi dans les calculs financiers).
    • NUMC (caractère numérique) mappé sur STRING (pour conserver les zéros non significatifs pour les numéros de document et les numéros d'article, ce qui garantit la réussite des jointures).

  9. Compression de la charge utile : pour éviter que les colonnes SAP vides (valeurs initiales telles que des espaces ou des zéros) ne soient remplies avec NULL dans BigQuery, assurez-vous que la compression de la charge utile est désactivée dans la configuration du connecteur (ou que l"option "Envoyer non compressé" est activée). Cela garantit que les chaînes vides ou les zéros sont conservés tels quels dans la cible au lieu d'être définis par défaut sur NULL.