Partager via

Rubriques avancées SAP CDC

  • Article

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !

Découvrez les rubriques avancées du connecteur SAP CDC, telles que l’intégration de données pilotée par les métadonnées, le débogage, etc.

Paramétrisation d’un flux de données de mappage CDC SAP

L’une des principales forces des pipelines et des flux de données de mappage dans Azure Data Factory et Azure Synapse Analytics est la prise en charge de l’intégration des données pilotée par les métadonnées. Grâce à cette fonctionnalité, il est possible de concevoir un ou quelques pipelines paramétrisés qui peuvent servir à gérer l’intégration de centaines, voire de milliers de sources. Le connecteur SAP CDC a été conçu selon ce principe : toutes les propriétés pertinentes, qu’il s’agisse de l’objet source, du mode d’exécution, des colonnes clés, etc., peuvent être fournies via des paramètres afin d’optimiser la flexibilité et de réutiliser le potentiel des flux de données de mappage SAP CDC.

Pour comprendre les concepts de base de la paramétrisation des flux de données de mappage, consultez Paramétrisation des flux de données de mappage.

Dans la galerie de modèles Azure Data Factory et Azure Synapse Analytics, il existe un pipeline et un flux de données de modèle qui montre comment paramétriser l’ingestion de données SAP CDC.

Paramétrisation de la source et du mode d’exécution

Les flux de données de mappage ne font pas nécessairement appel à un artefact de jeu de données : les transformations de la source et du récepteur offrent un type de source (ou un type de récepteur) Inline. Dans ce cas, toutes les propriétés de source définies dans un jeu de données ADF peuvent être configurées dans les options de la source de la transformation de la source (ou l’onglet Settings (Paramètres) de la transformation du récepteur). L’utilisation d’un jeu de données inline offre un meilleur aperçu et simplifie la paramétrisation d’un flux de données de mappage, car la configuration complète de la source (ou du récepteur) est maintenue à un seul emplacement.

Pour SAP CDC, les propriétés les plus couramment définies via des paramètres se trouvent sous les onglets Source options(Options de la source) et Optimize (Optimiser). Lorsque Source type (Type de la source) est défini sur Inline, les propriétés suivantes peuvent être paramétrisées dans les options de la source.

  • ODP context (Contexte ODP) : les valeurs de paramètre valides sont
    • ABAP_CDS pour les vues ABAP Core Data Services
    • BW pour SAP BW ou SAP BW/4HANA InfoProviders
    • HANA pour les vues d’information SAP HANA
    • SAPI pour les sources de données/extracteurs SAP
    • lorsque SAP Landscape Transformation Replication Server (SLT) est utilisé comme source, le nom de contexte ODP est SLT~<Alias de file d’attente>. La valeur de Queue Alias (Données de file d’attente) se trouve sous Administration Data (Données d’administration) dans la configuration SLT du cockpit SLT (SAP transaction LTRC).
    • ODP_SELF et RANDOM sont des contextes ODP utilisés à des fins de validation technique et de test, et ne sont généralement pas dignes d’intérêt.
  • ODP name (Nom ODP) : indiquez le nom d’ODP dont vous souhaitez extraire les données.
  • Run mode (Mode d’exécution) : les valeurs de paramètre valides sont
    • fullAndIncrementalLoad pour Full on the first run, then incremental (Complet à la première exécution, puis incrémentiel), qui lance un processus de capture des changements de données et extrait un instantané de données complet et actuel
    • fullLoad for Full on every run (Complet à chaque exécution), qui extrait un instantané de données complet et actuel sans lancer de processus de capture des changements de données.
    • incrementalLoad pour Incremental changes only (Changements incrémentiels uniquement), qui lance un processus de capture des changements de données sans extraire d’instantané complet et actuel.
  • Key columns (Colonnes de clés) : les colonnes de clés sont fournies sous forme de tableau de chaînes (entre guillemets doubles). Par exemple, lorsque vous utilisez la table SAP VBAP (éléments de commande client), la définition de clé doit être ["VBELN", "POSNR"] (ou ["MANDT","VBELN","POSNR"] si le champ client est également pris en compte).

Paramétrisation des conditions de filtre pour le partitionnement de la source

Sous l’onglet Optimize (Optimiser), un schéma de partitionnement de source (consultez Optimisation des performances pour les charges complètes ou initiales) peut être défini via des paramètres. En règle générale, cela passe par deux étapes :

  1. Définissez un paramètre pour le schéma de partitionnement de source au niveau du pipeline.
  2. Ingérez le paramètre de partitionnement dans le flux de données de mappage.

Format JSON d’un schéma de partitionnement

Le format à l’étape 1 suit le standard JSON, consistant en un tableau de définitions de partition, chacune d’elles étant un tableau de conditions de filtre individuelles. Ces conditions elles-mêmes sont des objets JSON dont la structure est calquée sur les options de sélection dans SAP. En fait, le format exigé par l’infrastructure SAP ODP est essentiellement le même que celui des filtres DTP dynamiques dans SAP BW :

{ "fieldName": <>, "sign": <>, "option": <>, "low": <>, "high": <> }

Par exemple

{ "fieldName": "VBELN", "sign": "I", "option": "EQ", "low": "0000001000" }

correspond à une clause SQL WHERE ... WHERE "VBELN" = '0000001000', ou

{ "fieldName": "VBELN", "sign": "I", "option": "BT", "low": "0000000000", "high": "0000001000" }

correspond à une clause SQL WHERE ... WHERE "VBELN" BETWEEN '0000000000' AND '0000001000'

Ainsi, la définition JSON d’un schéma de partitionnement contenant deux partitions se présente comme suit

[
    [
        { "fieldName": "GJAHR", "sign": "I", "option": "BT", "low": "2011", "high": "2015" }
    ],
    [
        { "fieldName": "GJAHR", "sign": "I", "option": "BT", "low": "2016", "high": "2020" }
    ]
]

la première partition contenant les exercices fiscaux (GJAHR) 2011 à 2015, et la deuxième partition contenant les exercices fiscaux 2016 à 2020.

Notes

Azure Data Factory n’effectue aucune vérification sur ces conditions. Par exemple, c’est à l’utilisateur de vérifier que les conditions de partition ne se chevauchent pas.

Les conditions de partition peuvent être plus complexes, comportant elles-mêmes plusieurs conditions de filtre élémentaires. Il n’existe pas de conjonctions logiques qui définissent explicitement la façon de combiner plusieurs conditions élémentaires au sein d’une même partition. La définition implicite dans SAP se présente comme suit (uniquement pour les sélections d’inclusion, c’est-à-dire le « signe » : « I » – pour l’exclusion) :

  1. les conditions d’inclusion (« signe » : « I ») pour le même nom de champ sont combinées avec OR (mentalement, placez la condition résultante entre crochets)
  2. les conditions d’exclusion (« signe » : « E ») pour le même nom de champ sont combinées avec OR (là encore, mentalement, placez la condition résultante entre crochets)
  3. les conditions résultantes des étapes 1 et 2 sont
    • en combinaison avec AND pour les conditions d’inclusion,
    • en combinaison avec AND NOT pour les conditions d’exclusion.

Par exemple, la condition de partition

    [
        { "fieldName": "BUKRS", "sign": "I", "option": "EQ", "low": "1000" },
        { "fieldName": "GJAHR", "sign": "I", "option": "BT", "low": "2020", "high": "2025" },
        { "fieldName": "GJAHR", "sign": "E", "option": "EQ", "low": "2023" }
    ]

correspond à une clause SQL WHERE ... WHERE ("BUKRS" = '1000') AND ("GJAHR" BETWEEN '2020' AND '2025') AND NOT ("GJAHR" = '2023')

Notes

Veillez à utiliser le format interne SAP pour les valeurs basses et hautes, incluez des zéros de début et exprimez les dates de calendrier sous la forme d’une chaîne de huit caractères au format « AAAAMMJJ ».

Ingestion du paramètre de partitionnement dans le flux de données de mappage

Pour ingérer le schéma de partitionnement dans un flux de données de mappage, créez un paramètre de flux de données (par exemple, « sapPartitions »). Pour transmettre le format JSON à ce paramètre, il doit être converti en chaîne à l’aide de la fonction @string() :

Capture d’écran montrant comment ingérer le schéma de partitionnement dans le flux de données de mappage.

Enfin, sous l’onglet optimize (optimiser) de la transformation de la source de votre flux de données de mappage, sélectionnez le type de partition « Source », puis entrez le paramètre de flux de données dans la propriété Partition conditions (Conditions de partition).

Capture d’écran montrant comment utiliser le paramètre de partitionnement sous l’onglet optimize (optimiser) de la transformation de la source.

Paramétrisation de la clé de point de contrôle

Lorsque vous utilisez un flux de données paramétrisé pour extraire les données de plusieurs sources SAP CDC, il est important de paramétriser la clé de point de contrôle de l’activité de flux de données de votre pipeline. La clé de point de contrôle est utilisée par Azure Data Factory pour gérer l’état d’un processus de capture des changements de données. Pour éviter que l’état d’un processus CDC remplace l’état d’un autre processus, vérifiez que les valeurs de clé de point de contrôle sont uniques pour chaque jeu de paramètres utilisé dans un flux de données.

Notes

Pour vérifier le caractère unique de la clé de point de contrôle, une bonne pratique est d’ajouter la valeur de la clé de point de contrôle à l’ensemble de paramètres de votre flux de données.

Pour plus d’informations sur la clé de point de contrôle, consultez Transformer des données avec le connecteur SAP CDC.

Débogage

Les pipelines Azure Data Factory peuvent être exécutés via des exécutions déclenchées ou de débogage. Ces deux options présentent une différence fondamentale : les exécutions de débogage exécutent le flux de données et le pipeline en fonction de la version actuelle modélisée dans l’interface utilisateur, tandis que les exécutions déclenchées exécutent la dernière version publiée d’un flux de données et d’un pipeline.

Pour SAP CDC, il y a un autre aspect à comprendre : pour éviter que les exécutions de débogage aient une incidence sur un processus de capture des changements de données existant, les exécutions de débogage utilisent une valeur de « processus abonné » différente (consultez Surveiller les flux de données CDC SAP) de celle des exécutions déclenchées. Par conséquent, elles créent des abonnements distincts (c’est-à-dire, des processus de capture des changements de données) au sein du système SAP. De plus, la valeur de « processus abonné » pour les exécutions de débogage a une durée de vie limitée à la session de l’interface utilisateur du navigateur.

Notes

Pour tester la stabilité d’un processus de capture de changement des données avec SAP CDC sur une période plus longue (par exemple, plusieurs jours), le flux de données et le pipeline doivent être publiés, et les exécutions déclenchées doivent être exécutées.