SAP Datasphere: por qué exponer a SAC con un Analytic Model

Cuando empiezas con SAP Datasphere viniendo de BW, la tentación es crear una vista, marcarla como consumible y conectar SAP Analytics Cloud directamente. Funciona… hasta que necesitas ratios restringidos, variables o conversiones de moneda. Ahí es donde entra el Analytic Model.

El uso semántico lo cambia todo

En el Data Builder, cada vista gráfica o SQL tiene un uso semántico (semantic usage). Los que más vas a usar:

• Relational Dataset: una tabla o vista “normal”, sin semántica analítica.
• Dimension: datos maestros con atributos, textos y jerarquías asociadas.
• Text y Hierarchy: textos dependientes de idioma y jerarquías padre-hijo.
• Fact: el conjunto de datos transaccional con medidas y asociaciones a dimensiones.
• Analytical Dataset: el tipo antiguo para exponer directamente a SAC.

Qué aporta el Analytic Model

El Analytic Model se construye encima de una vista Fact y es, en la práctica, lo más parecido a una query de BW:

• Medidas calculadas y restringidas, igual que los ratios calculados/restringidos de BEx.
• Count distinct y agregación de excepción.
• Variables: de filtro, para medidas restringidas o de fecha de referencia.
• Conversión de moneda y unidades declarativa.
• Selección de qué dimensiones y atributos se exponen, sin tocar las vistas de abajo.
• Vista previa de datos integrada para validar antes de llegar a SAC.

Una arquitectura por capas que funciona

La organización que mejor me está funcionando en proyecto:

1. Inbound: tablas remotas o replicadas desde S/4HANA o BW/4HANA, sin lógica.
2. Harmonization: vistas Relational Dataset que limpian, unifican y aplican reglas de negocio.
3. Reporting: vistas Fact y Dimension con asociaciones bien definidas.
4. Consumption: uno o varios Analytic Models por caso de uso, que son lo único que ve SAC.

Así cambiar un modelo de consumo no rompe nada de lo que hay debajo, y cada capa tiene una sola responsabilidad.

Ejemplo: vista Fact en SQL

Una vista SQL sencilla que después marcaríamos como Fact y asociaríamos a las dimensiones de hotel y fecha:

SELECT
  "HOTEL_ID",
  "STAY_DATE",
  "MARKET_SEGMENT",
  "CURRENCY",
  SUM("ROOM_NIGHTS")  AS "ROOM_NIGHTS",
  SUM("ROOM_REVENUE") AS "ROOM_REVENUE"
FROM "V_HARM_RESERVATIONS"
WHERE "STATUS" <> 'CANCELLED'
GROUP BY "HOTEL_ID", "STAY_DATE", "MARKET_SEGMENT", "CURRENCY"

En el Analytic Model añadiríamos después el ADR como medida calculada (ROOM_REVENUE / ROOM_NIGHTS) con agregación correcta, y una variable de rango de fechas de estancia.

Checklist antes de publicar a SAC

• La vista Fact tiene medidas con su tipo de agregación y asociaciones a todas las dimensiones.
• Las dimensiones tienen textos y, si procede, jerarquías.
• El Analytic Model expone solo los atributos que el usuario necesita.
• Las medidas restringidas y variables están probadas con la vista previa.
• Los permisos (Data Access Controls) se aplican en las vistas de reporting, no en SAC.

Con esto, SAC se convierte en una capa de visualización y planificación, y la lógica vive donde debe: en Datasphere.