Tipos de aDSO en SAP BW/4HANA: cuál elegir y por qué
Standard, Staging, Data Mart o Direct Update: qué tablas genera cada tipo de aDSO en SAP BW/4HANA, cómo se comporta la activación y cuándo usar cada uno.
Índice del artículo
El DataStore Object (advanced), o aDSO, es la pieza central de cualquier modelo en SAP BW/4HANA. Sustituye a los antiguos DSO clásicos, InfoCubes, PSA y tablas de escritura directa. El truco está en que el mismo objeto se comporta de forma muy distinta según la plantilla de modelado que elijas al crearlo.
En esta píldora repasamos los cuatro tipos, qué tablas genera cada uno y en qué capa de la arquitectura encaja.
Las tres tablas de un aDSO
Antes de comparar, conviene tener claro el esqueleto. Un aDSO puede generar hasta tres tablas en la base de datos:
| Sufijo | Tabla | Para qué sirve |
|---|---|---|
1 |
Inbound table | Recibe los datos tal cual llegan del DTP, request a request. |
2 |
Active data | Datos ya activados (o comprimidos), listos para leer. |
3 |
Change log | Imagen anterior/posterior de cada cambio para servir deltas. |
Por ejemplo, un aDSO llamado ZSALES01 generará /BIC/AZSALES011, /BIC/AZSALES012 y /BIC/AZSALES013. Qué tablas existen y cómo se mueven los datos entre ellas es exactamente lo que cambia entre tipos.
Standard DataStore Object
Es el equivalente al DSO clásico y el tipo que más vas a usar en la capa de propagación/armonización.
- Usa las tres tablas: inbound, active y change log.
- En la activación, los registros se sobrescriben o se suman en la tabla activa según la clave, y el cambio queda registrado en el change log.
- Sirve deltas limpios a los objetos que tenga por encima.
Staging DataStore Object
Pensado para la capa de entrada, donde en BW 7.x tendrías la PSA o un DSO de escritura optimizada. Tiene tres variantes:
- Inbound Data Only: solo tabla de entrada. No hay activación; es un simple buffer del origen.
- Compress Data: al activar, los datos pasan de la inbound a la tabla activa y se liberan de la primera. Ideal para reducir volumen cuando los objetos siguientes ya han leído el delta.
- Reporting-Enabled: como el anterior, pero los datos activados son consultables desde una query.
Úsalo cuando necesites conservar el dato de origen sin transformar y tener capacidad de recarga sin volver al sistema fuente.
Data Mart DataStore Object
Es el sucesor del InfoCube y el tipo natural para la capa de reporting cuando trabajas con ratios que se agregan.
- Todas las características forman parte de la clave; los ratios se agregan (normalmente con suma).
- Tiene inbound y active table, pero no change log: la “activación” equivale a la compresión de un cubo.
- Las queries leen tanto la inbound como la active table, así que los datos son visibles en cuanto se cargan, aunque no hayas activado.
Direct Update DataStore Object
El heredero del DSO de escritura directa. Tiene solo la tabla activa y no se carga con el flujo habitual de requests, sino que se escribe desde programas: APD, planificación o APIs (módulos de función RSDSO_DU_*).
Es útil para datos maestros de negocio mantenidos a mano, tablas de mapeo o resultados de procesos analíticos. No lo uses como sustituto perezoso de un flujo ETL: pierdes trazabilidad de requests.
Resumen rápido
| Tipo | Tablas | Capa típica | Delta hacia arriba |
|---|---|---|---|
| Standard | 1 + 2 + 3 | Propagación | Sí (change log) |
| Staging | 1 (+ 2) | Entrada / Acquisition | Sí (desde inbound) |
| Data Mart | 1 + 2 | Reporting | Sí (desde inbound) |
| Direct Update | 2 | Datos auxiliares | No (full) |
La regla que aplico en proyecto: Staging para entrar, Standard para armonizar y guardar la verdad, Data Mart solo cuando la query se beneficia de la agregación y Direct Update para lo que no viene de ningún sistema.
¿Usas alguna combinación distinta en tus modelos? Escríbeme por LinkedIn y lo comentamos.
