Transfert des données SAP vers Databricks : un guide stratégique pour l'intégration des données
- Databricks
- Databricks
- 7 min de lecture
Dr. Andreas Wagner
L'équipage ? Prêt. La fusée ? Sélectionnée. Vient maintenant la question qui déterminera la réussite ou l'échec de la mission : comment le carburant est-il acheminé dans le système ?
D'un point de vue historique, les systèmes SAP fonctionnaient comme des écosystèmes fermés. Les données d'entreprise précieuses étaient enfermées dans des structures propriétaires, ce qui rendait leur accès difficile pour les plateformes d'analyse modernes et l'intelligence artificielle, ce qui représentait un défi nécessitant d'importantes ressources. Dans l'économie des données actuelle, où la vitesse de traitement des informations constitue le principal avantage concurrentiel, cet isolement n'est plus tenable.
Avec le lancement de SAP Business Data Cloud (BDC), SAP opère un revirement stratégique vers un écosystème ouvert. Cette transformation permet aux entreprises d'exploiter la plateforme de data intelligence Databricks non plus uniquement comme un système cible externe, mais comme partie intégrante d'une architecture hybride.
Table des matières
- 1. Les six méthodes d'extraction des données
- Méthode 1 : JDBC/ODBC (accès direct via l'infrastructure)
- Méthode 2 : SAP SLT (réplication en temps réel basée sur des déclencheurs)
- Méthode 3 : SAP Datasphere Premium Outbound (abstraction sémantique)
- Méthode 4 : solution tierce (risque de non-conformité ODP-RFC)
- Méthode 5 : Partage différentiel sans copie
- Méthode 6 : SDK ABAP pour les hyperscalers
- 2. Conditions techniques générales
- 3. Conclusion et recommandations
1. Les six méthodes d'extraction des données
Le choix de la méthode d'intégration est un choix qui porte sur l'évolutivité, la latence et la préservation de la sémantique métier. En d'autres termes, il s'agit de déterminer quelles infrastructures mettre en place avant même de pouvoir envisager le lancement. Cela semble logique, n'est-ce pas ? Dans la pratique, cinq approches se sont imposées.
Méthode 1 : JDBC/ODBC (accès direct via l'infrastructure)
Cette approche classique utilise le pilote JDBC SAP HANA pour établir une connexion point à point. Il s'agit d'une méthode techniquement directe, dans laquelle les requêtes sont exécutées directement sur le schéma de la base de données. Si cela fonctionne pour des analyses ponctuelles ad hoc, ce modèle atteint ses limites face à des volumes de données massifs. En l'absence d'une fonctionnalité native de capture des données modifiées (CDC), des logiques incrémentielles doivent être mises en œuvre manuellement à l'aide d'horodatages. De plus, la sérialisation des données sur le serveur d'applications sollicite les ressources système, ce qui entraîne souvent des goulots d'étranglement au niveau des performances.
Exemples d'applications pertinentes pour cette approche :
- Prototypage rapide et preuves de concept : lorsque des résultats sont attendus rapidement pour une preuve de concept et que l'infrastructure BDC ou OData n'est pas encore tout à fait prête.
- Extraction des données de base : pour les tables de faible volume et à faible taux de modification (par exemple, les sociétés, les divisions ou les types d'articles), pour lesquelles une simple extraction par lots suffit.
- Découverte des données : lorsque les analystes doivent effectuer des requêtes exploratoires ad hoc directement sur des vues fantômes HANA, sans mettre en place de pipeline permanent.
- Systèmes sans licence ODP : dans les environnements plus anciens où le framework ODP ou les connecteurs modernes ne sont pas encore pris en charge sur le plan technique.
- Risque lié à l'architecture: Conformément à la note SAP 2415336, cette approche entraîne un découplage sémantique complet. Le serveur d'applications SAP étant contourné, toutes les métadonnées, les conversions de devises et les directives de sécurité (DCL) au niveau de l'application font défaut.
- Le piège du coût total de possession: L'ensemble de la logique métier doit être reconstituée manuellement dans Databricks, ce qui entraîne une charge de travail importante en ingénierie des données et une double gestion du modèle de données.
Méthode 2 : SAP SLT (réplication en temps réel basée sur des déclencheurs)
Le serveur de réplication SAP Landscape Transformation Replication Server détecte les modifications de données au niveau des tables à l'aide de déclencheurs de base de données, pratiquement en temps réel.
Charge technique : la mise en œuvre de SLT est extrêmement complexe et nécessite d'importantes ressources. Elle requiert une infrastructure serveur dédiée ainsi qu'une expertise approfondie pour la configuration des mécanismes delta et la surveillance des déclencheurs de base de données. La réplication s'effectuant au niveau purement technique des tables, l'ensemble des liens métier, des jointures et des logiques sémantiques (par exemple, les conversions de devises) doivent être entièrement reconstitués manuellement dans le système cible Databricks. Cela entraîne un effort initial significatif en termes de développement et de maintenance.
Dans quels cas cette approche est-elle justifiée ? Malgré l'importance des moyens qu'elle requiert, la SLT reste la méthode de choix pour :
- Temps réel critique : processus nécessitant une latence de l'ordre de la seconde (par exemple, production en flux tendu, gestion des stocks dans les centres logistiques à haut débit).
- Flux de données continu : scénarios dans lesquels il n'existe pas de fenêtre de traitement par lots en raison d'un fonctionnement 24 heures sur 24, 7 jours sur 7, et où les données doivent circuler en permanence.
- Intégration des systèmes existants : lorsque les systèmes sources ne prennent pas en charge les interfaces OData ou Zero-Copy modernes, mais doivent néanmoins fournir des données en temps réel.
- Date limite stratégique: un serveur SLT autonome repose sur SAP NetWeaver 7.5. Selon la note SAP 2881788, la maintenance standard prendra fin le 31 décembre 2027.
- Perte de logique: Étant donné que ce sont généralement des tables brutes qui sont répliquées, les liens métier (par exemple, les hiérarchies, les conversions de devises) doivent être recréés de manière fastidieuse dans Databricks.
Dans ce contexte, SAP Datasphere fait office de couche d'orchestration intelligente. Elle regroupe les données provenant des systèmes S/4HANA ou BW et les met à disposition via des flux de réplication coordonnés. L'avantage décisif réside dans la préservation du contexte métier. Les données sont traitées sémantiquement au sein de l'enveloppe de sécurité SAP. Lors de l'écriture dans le stockage d'objets (ADLS/S3), la structure logique est conservée, ce qui accélère considérablement le traitement ultérieur dans Databricks.
Exemples d'applications pertinentes pour cette approche :
- Reporting d'entreprise sur des données harmonisées : lorsque des données provenant de plusieurs sources SAP (par exemple, différentes sociétés issues de différentes instances ERP) ont déjà été consolidées dans Datasphere et doivent être transférées vers Databricks sous la forme d'un ensemble homogène.
- Produits de données gérés pour les services métier : mise à disposition de modèles de données certifiés, pour lesquels le respect des règles métier et des autorisations a déjà été garanti au niveau de la Datasphere.
- Éviter la reproduction de la logique : scénarios dans lesquels il convient d'éviter de devoir reconstituer laborieusement dans Databricks des hiérarchies de vues CDS profondément imbriquées ou des calculs complexes (par exemple, des indicateurs calculés).
- Intégration hybride des données : lorsque Datasphere sert de passerelle pour répliquer, de manière sécurisée et contrôlée, les données issues de systèmes sur site (par exemple SAP BW/4HANA) vers un stockage cloud en vue de leur utilisation dans Databricks.
Méthode 4 : solution tierce (risque de non-conformité ODP-RFC)
Les outils ETL spécialisés (tels que Theobald Software, Fivetran ou les services hyperscalers) ont comblé pendant des années le fossé entre SAP et les plateformes tierces. Cette méthode se trouve toutefois à un tournant décisif, qui exige une compréhension approfondie des protocoles sous-jacents.
Le rôle de l'interface RFC : le Remote Function Call (RFC) constitue le système nerveux technologique de l'univers SAP. Il permet à des systèmes externes d'appeler directement des modules fonction au sein de la pile SAP ABAP. Les éditeurs tiers utilisaient principalement le RFC comme protocole de transport pour le cadre ODP (Operational Data Provisioning).
Pourquoi a-t-on emprunté ce chemin ?
- Performances : par rapport aux interfaces HTTP, RFC offre un débit de données très élevé.
- Fonctionnalité Delta : grâce à ODP-RFC, les fournisseurs tiers pouvaient accéder en mode natif aux files d'attente Delta des extracteurs SAP. Cela permettait une capture efficace des données modifiées (CDC) pour des tables volumineuses, sans surcharger les systèmes sources par des extractions complètes.
- Accès universel : il s'agissait de la « clé passe-partout » permettant d'accéder aussi bien aux extracteurs SAPI classiques (Service API Extractors) et aux fournisseurs BW qu'aux vues ABAP CDS modernes.
Qu'est-ce qui a changé ?
Dans les notes SAP 3255746 et 3439624, SAP déclare que l'API ODP-RFC est réservée exclusivement à la communication entre applications SAP. D'un point de vue technique, cela signifie que SAP met en place un mécanisme de validation : à partir de juin 2026, un correctif de sécurité vérifiera le « type d'abonné » à chaque appel ODP. S'il s'agit d'une application non-SAP, l'accès sera bloqué. SAP impose ainsi le passage à des interfaces plus modernes et plus faciles à contrôler, telles que ODP-OData ou l'approche stratégique « zero-copy » (méthode 5), afin de minimiser les risques de sécurité et de mieux faire respecter les droits de propriété intellectuelle au niveau des données. Toutefois, SAP restreint également fortement l’utilisation des services OData pour l’exportation de données à partir de systèmes non-SAP via la politique API SAP, au point 2.2.2.
Un changement de paradigme architectural – ou bien la meilleure façon de prendre un nouveau départ ?
Il s'agit de la méthode la plus efficace en matière d'intégration moderne des données – et, sur le plan architectural, de l'approche la plus élégante proposée par Systemcheck. Au lieu de transférer laborieusement les données par des câbles, tout déplacement physique des données est totalement supprimé.
S'appuyant sur le protocole ouvert Delta Sharing, BDC Connect génère des liens temporaires sécurisés par cryptographie (URL pré-signées). Les nœuds de travail Databricks accèdent directement aux données d'origine stockées dans SAP Object Store, sans serveur d'application intermédiaire, sans copies redondantes en mémoire et sans goulots d'étranglement. Il en résulte une évolutivité quasi illimitée, associée à une protection maximale des données.
Règles relatives à la persistance des données :
- Matérialisation temporaire : l'enregistrement de copies de données dans le système cible (par exemple, Databricks) est autorisé uniquement à des fins d'optimisation des performances. Cela permet d'éviter les requêtes répétées sur des enregistrements identiques et d'améliorer l'expérience utilisateur. Toutefois, le stockage permanent des données d'origine inchangées en tant que point d'accès principal est interdit.
- Stockage permanent grâce à l'enrichissement : dès que les données SAP sont transformées, agrégées ou enrichies par des modèles d'IA (par exemple, jointures avec des données tierces), le résultat perd son statut de simple produit de données SAP. Ces données enrichies peuvent être conservées sans limite de durée dans le système cible (par exemple, Databricks Delta Lake).
- Interdiction de redistribution : les produits de données fournis peuvent être utilisés au sein de la plateforme connectée, mais ne peuvent pas être redistribués vers des systèmes en aval situés en dehors de l'écosystème SAP ou de ses partenaires (pas de « pass-through »).
Méthode 6 : SDK ABAP pour les hyperscalers
L'approche autonome « Clean Core » : un contrôle maximal sans intergiciel
Alors que d'autres méthodes attendent que les données soient récupérées (Pull), c'est ici le système SAP lui-même qui prend les commandes. Via le SDK ABAP (disponible pour AWS, Azure et GCP), la pile ABAP écrit activement et de manière hautement performante les données directement dans le stockage cloud (par exemple S3, Cloud Storage ou ADL Gen2) sur lequel l'environnement Databricks opère. Cette approche est la réponse architecturale au paradigme « Clean Core ».
Avantages de l'intégration native dans le cloud :
- Suppression des intermédiaires : aucune couche ETL supplémentaire n'est nécessaire. La communication s'effectue de manière cryptée, directement entre SAP et le stockage de l'hyperscaler.
- Performances et évolutivité : les données étant transmises au format Parquet ou JSON, très performant, cela élimine la charge sérielle sur le serveur d'applications, qui constitue souvent un goulot d'étranglement dans le cas des requêtes RFC classiques.
Règles relatives à la mise à disposition des données :
- Ingestion basée sur le stockage : les données sont d'abord acheminées vers une « zone d'atterrissage » du stockage cloud. À partir de là, Databricks se charge de l'orchestration. Cela permet une séparation stricte entre la charge transactionnelle SAP et le calcul analytique.
- Gouvernance: Le contrôle du moment de l'extraction et du volume des données reste entièrement entre les mains du système SAP, ce qui facilite le respect des règles de conformité internes.
- Évolutivité vs. charge de travail: bien que la mise en œuvre via l'ABAP SDK offre des performances et une indépendance maximales, elle implique un effort de développement initial plus important que BDC Connect.
Le guide Databricks d'Andreas & Yvonne
Vous voulez toutes les informations importantes en un coup d'œil ?
Téléchargez dès maintenant le guide gratuit de SAP Databricks !
2. Conditions techniques générales
Comparaison technique des paramètres d'intégration
Nécessité réglementaire : la migration de l'ODP vers le RFC en 2026
La note SAP 3255746 définit l'API ODP-RFC comme étant réservée exclusivement à la communication entre les applications SAP. Pour tous les outils tiers, cela signifie la fin d'un mode d'accès bien établi, mais désormais considéré comme non sécurisé.
Les entreprises qui continuent à utiliser des extracteurs basés sur RFC doivent avoir mis en place une nouvelle architecture cible d'ici le Security Patch Day, le 9 juin 2026.
Universal Governance : sécurité de bout en bout
Dans un environnement informatique hybride, la sécurité ne doit pas s’arrêter aux limites du système, tout comme un centre de contrôle ne peut être responsable que de la moitié d’une mission spatiale. L’architecture moderne exige une harmonisation sans faille des identités :
- Microsoft Entra ID fait office de fournisseur d'identité central.
- Le système de gestion des identités (IPS) synchronise automatiquement les identités avec le service SAP Cloud Identity Service (IAS).
- Unity Catalog (Databricks) utilise les mêmes identités pour les contrôles d'accès granulaires au niveau des tables, des lignes et des colonnes.
Résultat : les modifications ou désactivations de rôles dans Entra ID prennent effet immédiatement et de manière cohérente, de SAP Datasphere au notebook Databricks.
Rentabilité et analyse du coût total de possession
Les intégrations traditionnelles mobilisent des ressources considérables dans le domaine de la gestion manuelle des pipelines (Data Plumbing). Souvent, jusqu’à 80 % des ressources d’un projet sont consacrées à la maintenance de ces connexions plutôt qu’à la création de valeur proprement dite. L’approche « zero-copy » réduit ce coût total de possession (TCO) en s’attaquant aux principaux facteurs de coûts :
- Frais d'infrastructure : les coûts sont principalement liés aux transferts de données entre régions et au traitement des requêtes API. Cependant, comme il n'est pas nécessaire de gérer des copies redondantes des données dans des systèmes tiers, les coûts bruts de stockage diminuent.
- Frais Premium : lors de l'utilisation de plateformes partenaires telles que Snowflake ou Microsoft Fabric, un supplément est facturé en fonction de la charge de calcul des produits de données SAP. Ce supplément ne s'applique pas en cas d'utilisation de solutions OEM natives au sein de l'écosystème SAP.
- Coûts opérationnels : la suppression de la maintenance ETL complexe réduit considérablement les coûts de personnel liés aux ingénieurs de données.
Par rapport aux frais de licence liés aux outils tiers et aux ressources humaines considérables nécessaires à la mise en place d'un pipeline classique, l'approche « zero-copy » offre une structure de coûts plus claire sur le plan architectural et évolutive à long terme.
3. Conclusion et recommandations
Le choix de la méthode d'intégration est une décision fondamentale pour la pérennité de la stratégie en matière de données. Alors que les interfaces héritées sont soumises à des contraintes réglementaires et techniques, SAP Business Data Cloud ouvre la voie vers un écosystème évolutif et ouvert.
Identifiez immédiatement toutes les interfaces basées sur RFC à l'aide du programme RODPS_REPL_SUBSCRIBER_ASSESS.
Remplacez les processus ETL nécessitant beaucoup de maintenance par BDC Connect afin de tirer immédiatement parti de la puissance d'innovation de Databricks Mosaic AI sur vos données SAP.
Mettez en place SAP Databricks pour réaliser des analyses contextuelles approfondies de SAP et utilisez BDC Connect comme passerelle pour l'intégration globale des données d'entreprise.
Prêt à passer à l'étape suivante ? Nos experts vous accompagnent de l'audit jusqu'à la mise en production de l'intégration des données.
Votre stratégie en matière de données est personnalisée – vos conseils devraient l'être également.
Le choix entre ces méthodes dépend de nombreux facteurs : votre environnement système existant, vos objectifs commerciaux et votre culture en matière de données. Il n'existe pas de réponse standard.
Discutons sans engagement de la solution la mieux adaptée à vos besoins. Veuillez nous contacter pour un entretien individuel.
