Source de données SAP ERP

Important : Les étapes décrites sur cette page sont requises pour le déploiement de Cortex Framework . Pour le déploiement de démonstration, vous pouvez ignorer cette page.

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 tous deux 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 garantir 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 la table DD03L à partir de votre source SAP. Cette table est essentielle pour le résolveur de dépendances, car elle contient des métadonnées et des clés de champ.

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 (tels que /, - ou des traits de soulignement de 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 de 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 de 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 de début des numéros de document et des numéros d'article, ce qui garantit la réussite des jointures).
   Remarque : En règle générale, vous pouvez supposer que le mappage par défaut est correct tant que les mêmes opérations peuvent être appliquées au champ cible. Si les mappages sont modifiés, les clients peuvent CAST manuellement les types de données dans les modèles.

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 remplacés par NULL par défaut.