Saltar al contenido
Caso prácticoSAP Datasphere

Caso práctico: Analytic Model apilado con variables en Datasphere

Paso a paso para reutilizar un Analytic Model como fuente de otro en SAP Datasphere: Inherit, Map To y Set Value, variables renombradas y validación.

Por 12 min de lectura
Diagrama de una vista Fact que alimenta un Analytic Model base con dos variables; una se mapea con Map To y otra se fija con Set Value en un Analytic Model derivado que consume SAP Analytics Cloud
Índice del artículo

En casi todos los proyectos con SAP Datasphere acaba pasando lo mismo: el equipo central publica un Analytic Model de ventas bien hecho y, a las pocas semanas, cada área pide “el suyo” con un par de medidas más y sin las variables que no entiende. Si cada área copia el modelo, en seis meses tienes cinco versiones de la misma lógica. En este caso práctico construimos la alternativa: un Analytic Model derivado que usa el modelo central como fuente y personaliza sus variables, algo que SAP completó en mayo de 2026.

Qué vamos a construir

Al acabar tendrás:

  1. Un Analytic Model base, AM_SALES_CORE, sobre la vista Fact FV_SALES, con dos variables: P_FISCAL_YEAR (ejercicio) y P_DATA_CATEGORY (real, presupuesto…).
  2. Un Analytic Model derivado, AM_SALES_RETAIL, que usa AM_SALES_CORE como fuente y:
    • mapea el ejercicio a una variable propia, P_REPORT_YEAR, con otro nombre de negocio y otro valor por defecto;
    • fija la categoría de datos a ACT (real), para que el usuario de retail no vea esa pregunta;
    • añade sus propias medidas: ventas del canal retail y su peso sobre el total.
  3. Una validación que demuestra que los dos modelos devuelven lo mismo cuando reciben los mismos valores.

Para que puedas reproducirlo tal cual, el caso parte de un CSV de ejemplo con datos ficticios: T_SALES_ITEMS.csv (1.890 filas, 90 KB). Tiene los ejercicios 2025 completo y 2026 hasta el periodo 9, tres sociedades (ES01, PT01, FR01), tres canales (RETAIL, ONLINE, WHOLESALE), cinco productos y las categorías ACT (real) y BUD (presupuesto), todo en euros.

La portada resume el montaje. Todos los nombres técnicos (FV_SALES, AM_SALES_CORE, CHANNEL…) son de ejemplo: usa los de tu convención.

Por qué merece la pena

Viniendo de BW, piensa en una query que reutiliza una estructura global: la lógica vive en un sitio y quien consume solo añade lo suyo. Antes de este cambio, al apilar modelos las variables del modelo base venían “tal cual”: o las heredabas con su nombre y su valor por defecto, o las resolvías con un valor fijo. Si el área de retail quería que el ejercicio se llamase de otra forma, o que arrancase en otro año, tocaba copiar el modelo entero.

Ahora tienes tres opciones por cada variable del modelo fuente, y elegir bien es la mitad del caso:

Opción Qué pasa Cuándo la uso
Inherit Se usan las propiedades de la variable del modelo base. No se puede cambiar en el derivado Variables “de empresa” que deben comportarse igual en todos los modelos
Set Value Resuelves la variable con un valor. El usuario del modelo derivado ya no la ve Filtros que definen el propio modelo (solo real, solo una sociedad)
Map To La variable pasa a una variable del modelo nuevo, que sí puedes renombrar y ajustar Variables que el área necesita ver con su nombre, su default o en sus medidas

Paso a paso

  1. Paso:Importa el CSV de ejemplo como tabla local

    Descarga T_SALES_ITEMS.csv. En el Data Builder elige Import → Import CSV File, selecciona el archivo con Select Source File y pulsa Upload. Se abre el editor de importación con la vista previa de los datos.

    El editor solo maneja tipos genéricos (String, Integer, Number, Date…). Selecciona una columna y abre la pestaña Details para ver el suyo. Aquí solo hay que tocar una cosa: Datasphere infiere FISCAL_YEAR como Integer, así que cámbialo a String. El ejercicio va como texto porque el parámetro de entrada IP_FISCAL_YEAR también lo es. Comprueba de paso que NET_REVENUE aparece como Number. Pulsa Deploy y deja T_SALES_ITEMS como nombre de negocio y técnico.

    Editor de importación de CSV de SAP Datasphere con la vista previa de T_SALES_ITEMS y la pestaña Details de la columna NET_REVENUE con tipo Number
    Editor de importación: vista previa de los datos y, en la pestaña Details, la columna NET_REVENUE como Number.

    La precisión no se elige en la importación. La tabla se crea con tipos muy holgados: String(5000), Integer64 y Decimal(38,19). Para ajustarlos, abre la tabla, ve a la pestaña Columns, haz clic en el tipo de la columna y vuelve a desplegar. Yo los dejaría así:

    Columna Tipo tras importar Tipo ajustado
    FISCAL_YEAR String(5000) String(4)
    FISCAL_PERIOD, QUANTITY Integer64 Integer64
    COMPANY_CODE, CHANNEL, PRODUCT_ID, DATA_CATEGORY, CURRENCY String(5000) String(5000)
    NET_REVENUE Decimal(38,19) Decimal(15,2)

    Lo importante es que el importe quede como decimal exacto y no como coma flotante: SAP avisa de que los valores hana.REAL se convierten (1.1 pasa a 1.100000023841858) y luego no cuadran al céntimo.

    Si prefieres usar tus propios datos, sáltate este paso y adapta los nombres de columna en el siguiente.

  2. Paso:Prepara la vista Fact con parámetros de entrada

    Crea en el Data Builder una vista SQL FV_SALES con uso semántico Fact sobre T_SALES_ITEMS. En el panel de propiedades, abre la sección Input Parameters con el icono del lápiz y crea dos parámetros: IP_FISCAL_YEAR (String, longitud 4) e IP_DATA_CATEGORY (String, longitud 3, valor por defecto ACT).

    FV_SALES.sql
    SELECT
      "FISCAL_YEAR",
      "FISCAL_PERIOD",
      "COMPANY_CODE",
      "CHANNEL",
      "PRODUCT_ID",
      "DATA_CATEGORY",
      "CURRENCY",
      "NET_REVENUE",
      "QUANTITY"
    FROM "T_SALES_ITEMS"
    WHERE "FISCAL_YEAR" = :IP_FISCAL_YEAR
      AND "DATA_CATEGORY" = :IP_DATA_CATEGORY

    Valida el SQL para que aparezcan las columnas. Después, en el menú ⋯ de NET_REVENUE y de QUANTITY, elige Change to Measure y despliega. Filtrar por ejercicio y categoría dentro de la vista, y no solo en el modelo, es deliberado: así el filtro llega lo antes posible a la base de datos.

  3. Paso:Crea el Analytic Model base AM_SALES_CORE

    En el Data Builder, elige New Analytic Model y arrastra FV_SALES al lienzo. Se abre un diálogo con dos casillas ya marcadas (añadir todos los atributos y todas las medidas) y, como la vista tiene parámetros de entrada, una tabla para decidir qué hacer con cada uno: deja Map to → New Variable para los dos y pulsa Add.

    Datasphere crea dos variables estándar con el mismo nombre que los parámetros. Ábrelas desde la sección Variables del panel de propiedades y renómbralas a P_FISCAL_YEAR y P_DATA_CATEGORY (recuerda: en el Analytic Model los parámetros de entrada se llaman variables). El valor por defecto ACT del parámetro llega a la variable.

    Las medidas NET_REVENUE y QUANTITY y las siete dimensiones ya están en el modelo. Guarda y despliega. Este es el modelo “de empresa”: lo mantiene el equipo central y es el que conviene proteger.

    Editor de Analytic Model de AM_SALES_CORE con FV_SALES en el lienzo y las variables P_DATA_CATEGORY y P_FISCAL_YEAR en el panel de propiedades
    AM_SALES_CORE: la vista Fact en el lienzo (1) y las dos variables ya renombradas (2).

  4. Paso:Crea AM_SALES_RETAIL usando el modelo base como fuente

    Crea otro Analytic Model, AM_SALES_RETAIL. En el repositorio del editor solo aparecen objetos válidos como fuente: facts y Analytic Models. Arrastra AM_SALES_CORE al lienzo.

    Al soltarlo se abre el diálogo Add “AM_SALES_CORE” In Your Model. Arriba eliges qué traer: todos los atributos, todas las medidas y las dimensiones asociadas que tenga el modelo fuente. Abajo aparece la tabla de variables, con el aviso de que las variables del modelo fuente se heredan y una columna Action que viene en Inherit. Para este caso, deja marcadas las dos casillas. Si te dejas algo, puedes traerlo después: selecciona el nodo AM_SALES_CORE en el lienzo y marca la medida o la dimensión en su panel.

    Diálogo Add AM_SALES_CORE In Your Model con las casillas de atributos y medidas marcadas y las variables P_DATA_CATEGORY y P_FISCAL_YEAR con la acción Inherit
    Diálogo al soltar AM_SALES_CORE: qué elementos se traen y, abajo, la acción de cada variable (por defecto, Inherit).

    No pulses Add todavía: las variables se deciden en este mismo diálogo, en el paso siguiente.

    En el panel de propiedades del modelo, Show Inherited Elements viene activado. Déjalo así: ves de un vistazo qué viene del modelo base y qué es propio del derivado, algo que agradecerás cuando el modelo crezca.

  5. Paso:Decide qué hacer con cada variable

    En la columna Action del diálogo eliges Inherit, Set Value o Map to para cada variable del modelo fuente:

    • P_DATA_CATEGORY → Set Value con ACT. El modelo de retail solo muestra datos reales, así que la pregunta sobra. El campo Value aparece ya relleno con el valor por defecto de la variable (ACT) y se puede editar.
    • P_FISCAL_YEAR → Map to → New Variable. Datasphere crea en el modelo derivado una variable con el mismo nombre.

    Pulsa Add y guarda el modelo como AM_SALES_RETAIL. Hazlo ya: si el editor se recarga antes del primer guardado, pierdes el modelo.

    ¿Por qué no Inherit para el ejercicio? Porque una variable heredada no se puede cambiar en el modelo nuevo. Solo las variables mapeadas admiten cambios. Si el área no necesita nada distinto, Inherit es la opción más limpia; aquí sí lo necesita.

    Si más adelante cambias de idea, no hace falta repetir el arrastre. Selecciona el nodo AM_SALES_CORE en el lienzo y baja hasta Variables: ahí ves cómo está resuelta cada una y, en su menú ⋯, puedes pasarla a Set Value, Map to o Inherit.

    Panel Fact Source de AM_SALES_CORE dentro de AM_SALES_RETAIL: P_DATA_CATEGORY con Value ACT y P_FISCAL_YEAR mapeada a Ejercicio de reporting
    Variables del modelo fuente vistas desde el derivado: P_DATA_CATEGORY fijada a ACT y P_FISCAL_YEAR mapeada a la variable propia (1).

  6. Paso:Personaliza la variable mapeada

    En el panel de propiedades del modelo, abre la variable mapeada desde la sección Variables y ajusta:

    • Nombre de negocio: “Ejercicio de reporting”. Es lo que verá el usuario en el prompt de SAP Analytics Cloud.
    • Nombre técnico: P_REPORT_YEAR. Decídelo ahora: con el modelo ya guardado, Datasphere muestra un aviso de que cambiar el nombre técnico puede afectar a stories y a modelos existentes.
    • Valor por defecto: el ejercicio con el que quiere arrancar el área (por ejemplo, 2026).

    Si el modelo tiene más de una variable, ordénalas arrastrándolas en el editor: ese orden es el que se respeta en la vista previa y en el prompt de SAC.

  7. Paso:Añade las medidas propias del área

    En el panel de propiedades del modelo, abre el menú + de la sección Measures:

    1. Restricted Measure NET_REVENUE_RETAIL: medida fuente NET_REVENUE, expresión CHANNEL = 'RETAIL'.
    2. Calculated Measure RETAIL_SHARE: NET_REVENUE_RETAIL / NET_REVENUE. En Formatting, pon Scale en Percent y Decimal Places en 2.

    Estas medidas viven solo en el modelo derivado. El equipo central no tiene que saber que existen, y el área no puede romper NET_REVENUE aunque quiera.

  8. Paso:Despliega y conecta SAC

    Guarda y despliega AM_SALES_RETAIL. Antes de salir de Datasphere, pulsa Preview: el diálogo Set Variables solo debe preguntar por “Ejercicio de reporting”, con el valor por defecto que has definido.

    Diálogo Set Variables for AM_SALES_RETAIL en la vista previa de SAP Datasphere: solo aparece Ejercicio de reporting con el valor 2026
    Vista previa de AM_SALES_RETAIL: una sola variable, con su nombre de negocio y el valor por defecto 2026.

    Después, en SAP Analytics Cloud, crea una story sobre el modelo: el prompt debe mostrar esa misma variable y ninguna más.

Validación

No des el modelo por bueno hasta comprobar tres cosas:

  1. Mismos números con mismos valores. Abre la vista previa de AM_SALES_CORE con P_FISCAL_YEAR = 2026 y P_DATA_CATEGORY = ACT, y la de AM_SALES_RETAIL con P_REPORT_YEAR = 2026. El total de NET_REVENUE por sociedad debe coincidir al céntimo. Si no coincide, revisa el valor fijado en Set Value. Con el CSV de ejemplo, esto es lo que debes ver (2026, real):

    Sociedad NET_REVENUE NET_REVENUE_RETAIL RETAIL_SHARE
    ES01 1.460.407,23 486.708,42 33,33 %
    FR01 1.240.047,24 375.044,99 30,24 %
    PT01 670.851,45 208.915,85 31,14 %
    Total 3.371.305,92 1.070.669,26 31,76 %

  2. La medida restringida cuadra con SQL. Crea una vista SQL de prueba y contrasta NET_REVENUE_RETAIL con lo que devuelve la vista Fact resolviendo sus parámetros con valores:

    check_retail.sql
    SELECT "COMPANY_CODE", SUM("NET_REVENUE") AS "NET_REVENUE_RETAIL"
    FROM "FV_SALES"(IP_FISCAL_YEAR: '2026', IP_DATA_CATEGORY: 'ACT')
    WHERE "CHANNEL" = 'RETAIL'
    GROUP BY "COMPANY_CODE"

  3. El prompt es el que esperas. En la vista previa y en SAC solo debe aparecer la variable mapeada, con su nombre nuevo. Si aparece también la categoría de datos, la has dejado en Inherit o en Map To.

Una prueba más, para el día que alguien toque el modelo base: cambia algo en AM_SALES_CORE (por ejemplo, quita una medida que use el derivado) y guarda. SAP muestra un aviso de que el cambio puede afectar a otros modelos, y AM_SALES_RETAIL pasa a Changes to Deploy o a Design Time Error, según el cambio. Es mejor descubrirlo en desarrollo que en la reunión de cierre.

Errores habituales

Síntoma Causa Solución
No puedo renombrar ni cambiar el default de la variable La dejaste en Inherit: las heredadas no se pueden cambiar Cámbiala a Map To y personaliza la variable nueva
El usuario de SAC sigue viendo la categoría de datos P_DATA_CATEGORY no está resuelta con Set Value Fíjala a ACT en el modelo derivado y vuelve a desplegar
Falta una medida del modelo base en el derivado Es una medida auxiliar: no se copian al usar el modelo como fuente Hazla visible en el base si de verdad la necesitas, o recrea el cálculo en el derivado
El modelo derivado aparece en Design Time Error Alguien cambió medidas, variables o atributos del modelo base Revisa el aviso al desplegar el base, ajusta el derivado y despliega los dos
Una story deja de funcionar tras “ordenar” nombres Se cambió el nombre técnico de una variable o medida después de guardar Fija los nombres técnicos antes del primer despliegue y no los toques después

Siguiente paso

Si tienes varios equipos consumiendo ventas, haz inventario: cuántos Analytic Models son copias de otro con dos medidas más. Esos son candidatos claros a convertirse en modelos derivados. Mi recomendación es empezar por uno, con el equipo central como dueño del modelo base y una regla escrita sobre qué variables se heredan, cuáles se fijan y cuáles se mapean. Y, antes de tocar el modelo base en producción, mira siempre quién depende de él.

Fuentes

Sigue leyendo