Fiche concept

SAP BW Data Product Generator — chemin de modernisation BW

À jour au 2026-07-23

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que SAP BW Data Product Generator — chemin de modernisation BW ?

Le BW Data Product Generator convertit environ 80 % du patrimoine BW d'un client en Produits de données BDC automatiquement — la troisième voie de modernisation pour les ~17 000 clients ECC et ~4 000 MEE BW qui en ont besoin.

De quoi il s'agit

Le BW Data Product Generator est l'outil disponible aujourd'hui que SAP a livré au Sapphire 2026 comme chemin canonique de sortie de SAP BW vers BDC. Il lit les InfoProviders BW existants (Composite Providers, ADSOs, requêtes) et émet des Produits de données BDC qui préservent la couche sémantique BW.

Pourquoi c'est crucial pour la falaise BW. Environ 17 000 clients ECC et 4 000 MEE BW dans le monde ont besoin d'un chemin de modernisation. Les deux options historiques étaient (a) reconstruire de zéro dans Datasphere — coûteux, lent, risqué — ou (b) lift-and-shift vers BW/4HANA — achète 3 à 5 ans mais ne résout pas le problème lakehouse plus IA. Le Generator est l'option (c) : préserver l'investissement BW, convertir en Produits de données, s'inscrire sur la roadmap BDC.

Ce que le Generator émet. Pour chaque InfoProvider BW, il produit (1) un Produit BDC avec les mêmes champs, types et KPIs métier, (2) la lignée vers la source BW, (3) les métadonnées de gouvernance. Le générateur de modèles de requête compagnon gère la couche requêtes. Résultat net : un consultant BW expérimenté peut convertir environ 80 % du patrimoine BW d'un client en Produits BDC sans réécrire la logique de calcul.

Les 20 % qui ne se convertissent pas proprement. Transformations ABAP personnalisées, unions Composite Provider complexes, chaînes de processus nécessitant une orchestration hors périmètre du Generator — celles-ci requièrent une remodélisation manuelle dans Datasphere ou une modélisation native BDC. Le Generator les signale comme avertissements de conversion.

Pourquoi c'est important

La base client est chiffrée : environ 17 000 clients ECC et 4 000 MEE BW dans le monde ont besoin d'un chemin de modernisation — ce n'est pas un outil de niche.
Le partage 80/20 est explicite et actionnable : le Generator automatise ~80 % des InfoProviders en Produits de données avec lignage préservé, tandis que les 20 % restants (transformations ABAP custom, unions Composite Provider complexes) demandent une remodélisation manuelle.
La règle de décision nomme les deux cas : utiliser le Generator quand la logique BW est fiable et que le reporting ne peut pas s'arrêter ; remodéliser nativement dans Datasphere quand la logique BW elle-même est le problème (exits non documentés, 10+ ans de rustines empilées).

Points clés

Disponible aujourd'hui — chemin canonique SAP de BW vers BDC.
Convertit les InfoProviders (Composite Providers, ADSOs) en Produits BDC préservant la couche sémantique.
Générateur de modèles de requête compagnon gère la couche requêtes BW.
Convertit ~80% du patrimoine BW typique sans réécrire la logique de calcul.
Cible les ~17 000 clients ECC + ~4 000 MEE BW nécessitant un chemin de modernisation (§17.11).
Avertissements de conversion remontent transformations ABAP custom + unions complexes pour remodélisation manuelle.

Termes employés sur cette page

InfoProvider: Abstraction SAP BW désignant tout objet interrogeable par les requêtes BW — Composite Providers, ADSOs (Advanced DataStore Objects), InfoCubes, MultiProviders.
Composite Provider: Objet BW qui unit ou joint plusieurs InfoProviders en une seule surface interrogeable ; le schéma de modélisation BW le plus courant depuis 2015.
ADSO: Advanced DataStore Object — le magasin de données persistant principal de BW/4HANA, qui remplace le DSO/InfoCube classique ; prend en charge à la fois les insertions transactionnelles et le reporting agrégé.
Decision owner: La personne responsable qui accepte l'arbitrage et finance l'action suivante.
Semantic contract: La définition partagée des termes métier, des métriques, des entités et des règles d'accès utilisée par les outils et les équipes.
Control plane: La couche qui applique la politique, l'accès, la traçabilité, la supervision et l'escalade à travers le modèle opérationnel.
Evidence grade: Un label qui distingue le fait vérifié, le signal directionnel, l'hypothèse modélisée et l'observation de terrain.
Adoption metric: Le comportement mesurable qui prouve que le concept a changé le travail réel après la mise en production.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code.

Ouvrir dans l'application →