Extraction des données de SAP ECC (2024)

De nombreuses applications SAP Data Services (DS) utilisent les données SAP ECC comme source. Il arrive maintenant que DS supporte plusieurs mécanismes pour extraire les données de SAP ECC. Laquelle choisir ? Il existe souvent une méthode préférée, en fonction de la fonctionnalité requise et des capacités offertes dans le contexte réel du système source. Dans ce blog, je discute de toutes les différentes options.

Commencez par configurer un magasin de données pour le système source SAP :

Figure 1 : Définition du magasin de données SAP

Les paramètres obligatoires sont le nom d'utilisateur et le mot de passe, le nom (ou l'adresse IP) du serveur d'applications SAP, le numéro de client et de système (instance).

1/. Flux de données "régulier"

Lors de l'extraction à partir d'une seule table, faites-le dans un flux de données standard. Importez la définition de table à partir du référentiel de métadonnées dans l'explorateur du magasin de données et utilisez-la comme source dans un flux de données.

Une extraction de la table de données de base client KNA1 ressemble à ceci :

Figure 2 : Flux de données – extrait de KNA1

Notez le petit triangle rouge dans l'icône de la table source. C'est une indication d'un extrait direct de la couche de données SAP.

C'est la méthode la plus simple. Aucune mesure particulière n'est nécessaire au niveau du système source. L'extraction s'exécutera comme une tâche de dialogue SAP. Notez qu'il existe un paramètre de délai d'attente (configurable par le système, généralement 10, 30, 60 minutes) pour les travaux de dialogue. La tâche DS échouera lorsque l'extraction des données prendra plus de temps.

Les conditions where sont transmises à la base de données sous-jacente. Ceci est bénéfique pour la performance au travail. Assurez-vous également d'extraire uniquement les colonnes qui sont vraiment nécessaires. La durée du processus d'extraction est liée de manière linéaire au volume de données, qui est égal au nombre d'enregistrements * taille moyenne des enregistrements. Moins il y a de données transférées, plus la tâche DS s'exécute rapidement.

Figure 3 : Transformation de requête – extrait de KNA1, à l'exclusion des enregistrements obsolètes

Figure 4 : Code SQL généré – la clause where est poussée vers le bas

Cette approche est particulièrement avantageuse lors de la mise en œuvre de charges incrémentielles. Lorsque la table source contient une colonne avec un horodatage de dernière modification, vous pouvez facilement implémenter la capture des données modifiées (CDC) basée sur la source. Gardez une trace des horodatages que vous avez utilisés lors de l'extraction incrémentielle précédente (utilisez une table de contrôle pour cela), initialisez les variables globales avec ces valeurs et utilisez-les dans la clause where de votre transformation Query.

Figure 5 : Transformation de la requête – Extrayez les enregistrements récemment créés ou modifiés de MARA

Figure 6 : Code SQL généré – CDC basé sur la source

2/. Flux de données ABAP

Bien que les conditions where soient transmises à la base de données sous-jacente à partir d'un flux de données normal, les jointures ne le sont pas (les opérations de tri et de regroupement ne le sont pas non plus !), ce qui entraîne souvent des performances abominables, en particulier lorsqu'il s'agit de volumes de données plus importants.

Lorsque vous souhaitez extraire les données de base du matériau de MARA et compléter chaque enregistrement avec la description du matériau en anglais de MAKT, vous pouvez créer un flux de données comme celui-ci :

Figure 7 : Flux de données – extrait de MARA et MAKT

Figure 8 : Transformation de requête – joindre MARA et MAKT sur les colonnes MANDT et MATNR

Figure 9 : Code SQL généré – pas de jointure

DS génère deux instructions SQL. Il extrait d'abord tous les enregistrements actuels de MARA. Et ensuite, pour chaque enregistrement individuel, il récupère la description anglaise correspondante (MATNR = AIVariable_1 et MANDT = AIVariable_2). Cette approche conduit à autant d'allers-retours vers la base de données sous-jacente qu'il y a d'enregistrements dans la table MARA ! Ce n'est valable que lorsqu'il s'agit de petit* ensembles de données.

Vous pouvez améliorer les performances en modifiant les propriétés des tables source.

Les paramètres par défaut sont :

Figure 10 : Propriétés de la table source par défaut

Faire de MARA la table de conduite (en lui donnant un plus hautRejoindre le rangque MAKT) et la mise en cache de MAKT en mémoire conduit à une génération de code SQL complètement différente, sans allers-retours singuliers vers la base de données. La table MARA passe par le flux de données, la table MAKT est mise en cache et la jointure est résolue dans la mémoire DS.

Figure 11 : Propriétés modifiées de la table source

Figure 12 : Code SQL généré – cache MAKT

La faisabilité de cette approche est impactée par 2 paramètres :

• La quantité de mémoire disponible pour la mise en cache
• Le temps nécessaire pour mettre en cache la table MAKT

Cela fonctionne parfaitement pour les petites tables. Mais ce n'est pas non plus une solution performante lorsque MAKT et MARA sont trop grands

La solution recommandée pour extraire à partir d'une jointure de tables SAP consiste à utiliser un flux de données ABAP.

Figure 13 : Flux de données ABAP – extrait de MARA et MAKT

DS génère du code ABAP correspondant aux propriétés des tables source et à la logique du flux de données. Le tableau avec le plus hautRejoindre le classem*ntdevient la table de conduite. Dans ce cas également, la durée du processus d'extraction est liée de manière linéaire au volume de données : moins il y a de données transférées, plus la tâche DS s'exécute rapidement.

Figure 14 : Code ABAP généré

Le code ABAP est transmis au système SAP et y est exécuté. Seuls les résultats du programme sont renvoyés à DS pour un traitement ultérieur. Cette approche ne fonctionne que lorsque le système SAP est ouvert au développement ! Assurez-vous également que :

• LeOption d'exécution ABAPest réglé surGénérer et exécuter.
• LeExécuter en arrière-plan (par lots)la propriété est définie surOuipour éviter le délai d'attente dans les travaux de dialogue SAP.
• LeMéthode de transfert de donnéesest réglé surRFC. LeDestination RFCdoit être défini dans le système SAP. Les autres méthodes de transfert de données sont là uniquement pour des raisons de compatibilité ascendante et ne doivent plus être utilisées. Ils conduisent tous à des performances inférieures.

Figure 15 : Définition du magasin de données SAP

Pour exécuter la même tâche DS dans des niveaux autres que de développement de votre environnement, transférez d'abord le programme ABAP de DEV vers TST, PRD... Met leOption d'exécution ABAPpourExécuter préchargéet exécutez la tâche DS. Il ne générera pas à nouveau le code ABAP, mais exécutera le code transporté.

Les flux de données ABAP sont également une solution pratique pour implémenter des charges incrémentielles pour les tables ECC qui ne contiennent pas de colonne d'horodatage de dernière modification. Les insertions et modifications dans KNA1 sont enregistrées dans les tables CDHDR et CDPOS. Utilisez un flux de données ABAP pour joindre KNA1 à ces tables. Assurez-vous que CDHDR obtient le plus hautRejoindre le classem*nt, KNA1 le plus bas, afin d'obtenir le code généré le plus efficace. Et incluez les conditions où :

• Filtrez les clients actuels
• Obtenir les enregistrements récemment modifiés uniquement
• À partir des entrées correctes dans les tables de journal

Figure 16 : flux de données ABAP – extrait de KNA1

Figure 17 : Transformation de requête – joindre KNA1 avec CDHDR et CDPOS

Figure 18 : Transformation de requête – Extraire les enregistrements récemment créés ou modifiés de KNA1

3/. Extracteur SAP

Les extracteurs SAP sont conçus pour BW Business Content. Ils contiennent toute la logique des transformations commerciales courantes, des agrégations possibles et également comment identifier déjà les changements, ils sont donc très adaptés à la mise en œuvre de charges incrémentielles.

La fonctionnalité DS Extractor s'appuie sur l'API ODP (Operational Data Provisioning). DS prend en charge tous les types de sources ODP pris en charge par l'API ODP, y compris la fonctionnalité CDC.

Dans un flux de données standard, DS utilise RFC pour appeler l'API de réplication de données ODP. Les conditions where ne sont pas poussées jusqu'à l'extracteur. Cela signifie que toutes les données sont extraites de l'extracteur et que le filtrage est effectué ensuite dans DS. Importez la définition d'objet ODP à partir du référentiel de métadonnées dans l'explorateur de magasin de données.

Figure 19 : Extracteur d'importation 0CUSTOMER_ATTR

Assurez-vous de régler leMode d'extractionpourMettre en doute. Utilisez-le ensuite comme source dans un flux de données. Une extraction de l'objet ODP 0CUSTOMER_ATTR ressemble à ceci :

Figure 20 : Flux de données – extrait de 0CUSTOMER_ATTR

Si vous souhaitez extraire uniquement un sous-ensemble mineur des données, utilisez l'objet ODP comme source dans un flux de données ABAP.

Figure 21 : flux de données ABAP – extrait de 0CUSTOMER_ATTR

Ajoutez la clause where à la transformation Query.

Figure 22 : Transformation de requête : extrayez les clients américains actuels de 0CUSTOMER_ATTR

DS génère l'ABAP qui appelle l'API de réplication de données ODP. Le code généré contient la logique pour filtrer les enregistrements inutiles.

Figure 23 : Code ABAP généré

La mise en œuvre de CDC est vraiment un jeu d'enfant pour les extracteurs qui sont « compatibles delta ». Assurez-vous de régler leMode d'extractionpourCapture de données modifiées (CDC). Lors de l'importation de l'objet ODP.

Figure 24 : Extracteur d'importation 0PROJECT_ATTR

Utilisez-le ensuite comme source dans un flux de données. Il n'est pas nécessaire d'ajouter une condition basée sur le temps dans la clause where. La logique d'extraction garantit que seuls les enregistrements nouveaux et modifiés sont transmis à DS. Assurez-vous simplement que leCharge initialepropriété de l'objet ODP est définie surNon. Réglez-le uniquement surOuilorsque vous souhaitez que la table cible soit réinitialisée.

Figure 25 : Propriétés de l'objet ODP

Incluez une transformation Map_CDC_Operation pour synchroniser automatiquement la table cible avec l'objet source. La transformation traduira la valeur Row Operation dans le type de ligne DS correspondant :

• Je > Insérer
• B & U : image avant et après d'une mise à jour
• D > Supprimer

Figure 26 : Flux de données – extrait delta de 0PROJECT_ATTR

4/. Fonction ECC

DS peut également appeler des fonctions ECC compatibles RFC renvoyant des tables en tant que sources de flux de données. Si une fonction ECC standard n'est pas compatible RFC, vous avez besoin d'une fonction wrapper compatible RFC qui transmet les paramètres à la fonction standard, l'appelle et transmet les résultats à DS.

Vous ne pouvez importer les métadonnées d'une fonction que par leur nom. Appelez-le à partir d'une transformation de requête en sélectionnant Nouvel appel de fonction… dans le menu contextuel de son schéma de sortie. Sélectionnez la fonction dans le magasin de données ECC. Définissez le(s) paramètre(s) d'entrée et sélectionnez Paramètre de sortie. L'appel de fonction est ajouté au schéma de sortie.

Figure 27 : Transformation de requête – appeler une fonction ECC

Ensuite, désimbriquez les résultats de retour dans une prochaine transformation de requête avant de les écrire dans une table cible.

Figure 28 : Transformation de requête – désimbriquer le schéma de sortie de la fonction

5/. Serveur de réplication SAP LT (SLT)

DS peut utiliser SLT Replication Server comme source. Il s'agit d'un moyen très simple et élégant de créer des tâches CDC dans DS. L'utilisation d'objets SLT est similaire à la manière dont DS fonctionne avec des extracteurs SAP.

Définissez le magasin de données SLT comme n'importe quel autre magasin de données SAP. Assurez-vous simplement de sélectionner le bon contexte ODP dans la définition.

Figure 29 : Définition du magasin de données SLT

Vous pouvez ensuite importer les tables dont vous avez besoin pour extraire les données.

Figure 30 : Métadonnées de la table SLT

Utilisez l'objet ODP comme source dans un flux de données. La première fois que le flux de données est exécuté, il fera un extrait complet de la table sous-jacente. Toutes les exécutions successives en effectueront automatiquement une incrémentielle et ne transmettront que le delta.

Figure 31 : Flux de données – extrait delta de MARA à SLT

6/. IDOC

Les travaux en temps réel DS peuvent lire les messages IDOC et les fichiers IDOC. Les tâches par lots DS ne peuvent lire que des fichiers IDOC.

Importez la définition de métadonnées IDOC par nom à partir du magasin de données SAP. Utilisez l'IDOC comme source de fichier dans un flux de données au sein d'un travail par lots.

Figure 32 : Flux de données – extrait delta de la source du fichier IDOC

Double-cliquez sur l'icône IDOC pour ouvrir sa définition et spécifiez le nom du fichier IDOC. Vous pouvez utiliser des caractères génériques (? et *) ou répertorier plusieurs noms de fichiers séparés par des virgules si vous souhaitez traiter plusieurs fichiers dans un seul flux de données.

Figure 33 : Propriétés IDOC

Générez le ou les fichiers IDOC à partir de SAP et exécutez votre travail DS.