Fiche concept

Types d'aDSO BW/4HANA (standard, write-optimisé, direct-update)

À 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 Types d'aDSO BW/4HANA (standard, write-optimisé, direct-update) ?

Choisir le mauvais type d'aDSO est l'erreur BW/4HANA la plus fréquente — un aDSO Standard de 500M lignes activé chaque jour est lent et cher, là où un staging Write-Optimisé alimentant un Standard métier serait rapide et économe.

De quoi il s'agit

L'aDSO (Advanced DataStore Object) est le seul InfoProvider physique dans SAP BW/4HANA — le remplaçant moderne de la prolifération DSO, InfoCube, PSA de BW 7.x. Chaque aDSO est une table côté HANA; ce qui le fait se comporter comme un DSO, un cube ou une zone de staging, c'est le réglage de type choisi à la création. Trois types opérationnels comptent en pratique, et choisir le mauvais est l'erreur de modélisation BW/4HANA la plus fréquente d'un consultant junior.

Les trois types. L'aDSO Standard est le cheval de trait par défaut : il porte une file d'entrée (enregistrements nouveaux et modifiés), une table active (l'état courant correct, dédupliqué par clé), et un journal de changements (l'historique delta pour propagation aval). Il supporte l'activation, les deltas before/after-image, et le rollback. C'est ce dont 80 % de la modélisation couche métier a besoin. L'aDSO Write-Optimisé n'a que la file d'entrée — pas d'activation, pas de journal, pas de vérification d'unicité de clé; les enregistrements sont ajoutés à l'arrivée. C'est le pattern zone de staging : charger vite, transformer en aval. L'aDSO Direct-Update n'a qu'une table active inscriptible via l'API de planification; c'est la couche de persistance des applications de planification, écrite par SAC Planning ou IBP, pas par ETL.

Pourquoi c'est important

L'aDSO Standard (activation, deltas, rollback) couvre 80 % des besoins de modélisation couche métier ; le Write-Optimisé est un pur pattern de staging, sans activation ni vérification de clé.
L'aDSO Direct-Update n'existe que pour la persistance de planification écrite par SAC Planning ou IBP — le modéliser en Standard casse entièrement la boucle d'écriture en retour.
Le grief de performance qu'« aucun tuning HANA ne corrigera » remonte presque toujours à l'usage du Standard là où le Write-Optimisé s'imposait.

Points clés

aDSO Standard — file d'entrée + table active + journal de changements ; activation, deltas before/after, rollback ; défaut couche métier (80 % des cas).
aDSO Write-Optimisé — file d'entrée uniquement ; pas d'activation, pas de journal, pas d'unicité de clé ; zone de staging / remplacement PSA.
aDSO Direct-Update — table active uniquement, inscriptible via API planification ; persistance SAC Planning / IBP ; pas pour ETL.
Coût du mauvais type — Standard en staging = activation lente et chère ; Standard en planification = casse l'écriture ; choisir au design, douloureux à refactorer.
Une table HANA physique par aDSO — le type est configuration métadonnées, pas des objets séparés ; structure de champs et stratégie de partition toujours choisies par objet.

Termes employés sur cette page

aDSO: Advanced DataStore Object — la classe d'InfoProvider unifiée de BW/4HANA qui remplace les DSO/InfoCube/PSA de BW 7.x ; une table HANA par objet, dont le comportement est configuré par type.
Inbound queue: Le buffer de staging des enregistrements nouveaux et modifiés avant activation ; persiste la sortie de chargement brute ; la seule couche physique présente dans un aDSO Write-Optimised.
Activation: L'opération de l'aDSO Standard qui consolide les enregistrements de l'inbound queue dans la table active par clé, calcule les deltas et écrit le change log ; l'étape coûteuse du chargement BW/4HANA.
Change log: La table d'historique des images avant/après au sein d'un aDSO Standard ; la source de la propagation des deltas en aval ; ce qui fait fonctionner la chaîne de delta de BW.
Decision owner: La personne responsable qui assume l'arbitrage et finance l'action suivante.
Semantic contract: La définition partagée des termes métier, métriques, entités et règles d'accès utilisée par les outils et les équipes.
Control plane: La couche qui applique la politique, l'accès, le lineage, le monitoring et l'escalade à travers le modèle opérationnel.
Evidence grade: Un libellé qui distingue le fait vérifié, le signal directionnel, l'hypothèse modélisée et l'observation de terrain.

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 →