Data Warehouse y BBDDs – aníbal goicochea

SAP BW 7.5: cómo preparar la transición antes de 2027

La prioridad no es retirar SAP BW de inmediato, sino identificar el producto y las versiones utilizadas, establecer su horizonte real de mantenimiento y determinar qué dependencias deberán conservarse o sustituirse. A partir de ese diagnóstico, la organización puede optar o combinar las siguientes vías: (1) Ganar tiempo mediante mantenimiento extendido, (2) Evolucionar hacia SAP BW/4HANA o (3) Modernizar progresivamente con SAP Business Data Cloud y SAP Datasphere.
La decisión debe basarse en pruebas de transferencia funcional, seguridad, rendimiento y compatibilidad, no solo en la copia de los datos.

Si tu organización dispone de una plataforma SAP BW, es posible que hayas oído que “se acerca el fin de su vida útil”. Antes de tomar una decisión, identifica el producto y las versiones utilizadas, dónde están instalados y qué aplicaciones, procesos e interfaces dependen de ellos.

El fin del mantenimiento no provoca que el sistema deje de funcionar automáticamente. Implica un cambio en la cobertura de soporte, la disponibilidad de correcciones y, según el contrato, el coste y las condiciones del servicio. El impacto concreto depende del producto, la versión, los componentes instalados y las condiciones contractuales.

Fin del mantenimiento: no todas las versiones tienen el mismo horizonte

Debemos distinguir SAP BW NetWeaver independiente, SAP BW/4HANA y las implementaciones BW embebidas sobre SAP ERP ECC o SAP S/4HANA.

SAP BW 7.5 independiente: el mantenimiento principal termina el 31 de diciembre de 2027. Existe una opción de mantenimiento extendido hasta finales de 2030, sujeta a condiciones.
SAP BW/4HANA: SAP establece un horizonte general de mantenimiento hasta 2040. Este horizonte no garantiza que cada versión concreta reciba mantenimiento hasta esa fecha; es necesario comprobar el ciclo de vida de la versión instalada y planificar las actualizaciones correspondientes.
BW Embebido: su horizonte de mantenimiento depende del ciclo de vida del sistema SAP ERP ECC o SAP S/4HANA que lo contiene, por lo que debe comprobarse conjuntamente con el producto y la versión del sistema anfitrión.

SUGERENCIA: Para comprobar posibles actualizaciones de estas fechas, consulta las notas SAP 2741041, 2934895 y 2952947, así como el Product Availability Matrix (PAM) de SAP BW.

Estrategia: asegurar continuidad y definir el destino

Ante el horizonte de 2027 para SAP BW 7.5, la organización debe definir cuanto antes una estrategia que combine continuidad operativa, destino tecnológico, calendario, costes, responsables y criterios de validación.

Las rutas deben evaluarse según el tiempo disponible, el grado de reutilización requerido, el destino tecnológico, el coste de la transición y la capacidad de validar la funcionalidad transferida:

Mantenimiento extendido hasta 2030, como continuidad temporal mientras se ejecuta la transformación.
SAP BW NetWeaver en private cloud edition (PCE), previa comprobación de las condiciones de elegibilidad y cobertura de la oferta. La opción de transición para 2031–2033 está sujeta a requisitos y restricciones específicos; migrar BW a una nube privada no concede por sí solo esa cobertura. Se debe contar con un BW 7.5 SPS24 como mínimo, con base de datos SAP HANA.
Conversión a SAP BW/4HANA, cuando se quiera conservar y evolucionar sobre una arquitectura BW.
Modernización hacia SAP Business Data Cloud / SAP Datasphere, mediante coexistencia o sustitución progresiva de las funciones actuales.

SUGERENCIA: Para definir la hoja de ruta, consulta las versiones actualizadas de las notas SAP 3590297 y 3768400, así como la documentación de SAP Business Data Cloud.

Herramientas: elegir según lo que se quiere trasladar

Si el destino final es SAP Business Data Cloud / SAP Datasphere, SAP ha desarrollado varios mecanismos con objetivos diferentes:

Data Product Generator (DPG): aprovisiona datos desde proveedores BW admitidos hacia el Object Store de SAP Datasphere mediante suscripciones. Cada suscripción identifica el InfoProvider de SAP BW que se replicará en SAP Business Data Cloud, materializa sus datos en una tabla local de SAP Datasphere y, una vez activada, puede ejecutarse cuando sea necesario.
Query Template Generator (QTG): transfiere la semántica admitida de las consultas y sus dependencias, lo que puede reducir parte del esfuerzo de reconstrucción.
BW/4HANA Model Transfer e Import Entities: permiten reutilizar consultas y modelos de soporte procedentes de BW/4HANA.
Shell y Remote Conversion hacia BW Bridge: ambas opciones permiten trasladar determinados modelos y procesos BW. Shell transfiere los metadatos sin los datos existentes, mientras que Remote Conversion incorpora también la transferencia de datos.
Import Entities desde S/4HANA, tablas remotas y Replication Flows: permiten integrar datos y, según el mecanismo, semántica del origen para construir modelos en Datasphere.

Una transferencia técnica correcta no garantiza que se conserve toda la funcionalidad. Por ejemplo, QTG puede omitir funciones no admitidas y el modelo transferido no incorpora automáticamente los cambios posteriores realizados en BW. Además, las transformaciones y las rutinas ABAP requieren un análisis independiente.

BW Bridge permite conservar el procesamiento BW en un entorno cloud, pero no convierte automáticamente esa lógica en procesamiento nativo de SAP Datasphere.

Si se tiene SAP BPC o BW-IP sobre BW 7.5, soluciones de planificación y consolidación, ninguno de estos mecanismos lo traslada. El destino natural es SAC Planning o SAP Group Reporting.

SUGERENCIA: Para profundizar en estos mecanismos, consulta las guías de SAP sobre DPG y QTG, BW Bridge e Import Entities, así como las versiones actualizadas de las notas SAP 3724724 y 3774419.

Plan de transición: validar antes de retirar

El proyecto debería comenzar con un inventario de las versiones de los componentes, las fuentes de datos, las consultas, las cargas, las rutinas, las autorizaciones, las interfaces y las aplicaciones de planificación o consolidación.

Después, conviene probar flujos representativos y comparar cifras, filtros, jerarquías, unidades, procesos delta, controles de seguridad y rendimiento. Si el origen también cambia de SAP ERP ECC a SAP S/4HANA, deben comprobarse individualmente los extractores y el Business Content afectados.

Se debe tener presente que los principales elementos que se “romperán” serán los elementos de SAP Analysis for Office y SAP BusinessObjects o BEx Analyzer, si aun se utiliza. Son los consumidores directos de la consultas BW.

Aplazar esta evaluación puede dejar a la organización con menos margen para resolver incompatibilidades, sustituir interfaces o reconstruir lógicas que no se pueden transferir vía ningún mecanismo conocido.

La retirada del sistema BW original debe producirse únicamente cuando se hayan sustituido y validado sus funciones y dependencias. Una copia de los datos en SAP Datasphere no demuestra por sí sola que la migración haya concluido: también deben verificarse la lógica, la seguridad, el rendimiento y las integraciones.

SUGERENCIA: Por último revisar las versiones actualizadas de la notas SAP 2500202, 2548065 y 3774419.

SAP Datasphere no es el nuevo SAP BW, es otra forma de tratar a los datos

SAP Datasphere no debe verse como el simple sucesor de SAP BW, sino como una plataforma que exige pensar la arquitectura de datos desde el inicio de cada iniciativa. La aparente simpleza y rapidez de SAP BW no debe hacernos perder de vista el valor que se puede obtener con SAP Datasphere si se hacen bien las cosas, con modelos de datos bien estructurados y perfectamente vinculados con la capa de negocio.

Quienes trabajamos en análisis de datos dentro del mundo SAP tendemos, en ocasiones, a definir SAP Datasphere simplemente como el sucesor de SAP BW o como un nuevo data warehouse en la nube. Sin embargo, su alcance es bastante mayor. La plataforma se apoya en SAP HANA como motor de datos y combina capacidades de integración, modelado y analítica con una capa semántica orientada al negocio.

Este último concepto resulta especialmente familiar para quienes procedemos de SAP BusinessObjects y del trabajo con universos, donde uno de los objetivos principales era abstraer la complejidad técnica de las fuentes de datos y presentarla mediante conceptos, relaciones y terminología comprensibles para los usuarios de negocio.

MUCHOS TIPOS DE OBJETOS, NADA SOBRA (o casi nada)

En SAP Datasphere, tanto en Data Builder como en Business Builder, conviven distintos tipos de objetos que se relacionan entre sí y cumplen funciones complementarias. Su valor no está en usarlos de forma aislada, sino en entender cómo encajan dentro de un modelo coherente: cada componente aporta una pieza necesaria para construir soluciones más sólidas, evolutivas y reutilizables.

El recorrido típico comienza en las tablas, que pueden representar dimensiones, como datos maestros, o hechos, como movimientos. Cuando es necesario, las dimensiones se enriquecen con jerarquías y textos dependientes del idioma. A partir de ahí se construyen las vistas, que agrupan subconjuntos lógicos de información y permiten combinar hechos, jerarquías y textos en modelos analíticos. Finalmente, la información se expone mediante una capa semántica o de consulta, por ejemplo, Analytic Models o Perspectivas basadas en Consumption Models, que actúa como punto de acceso para herramientas como SAP Analytics Cloud (SAC), SAP BusinessObjects, SAP Analysis for Office u otras soluciones externas a SAP.

EN SAP BW PARECÍA TODO MÁS FÁCIL

En SAP Business Warehouse (SAP BW), construir un modelo podía resultar más directo. No era necesario crear tantos elementos ni definir tantas asociaciones entre ellos, y el margen de maniobra era mayor. En muchos casos bastaba con preparar una serie de objetos, incorporarlos a un DSO (o a un cubo en versiones más antiguas) y disponer en poco tiempo de un modelo prácticamente operativo.

En SAP Datasphere, en cambio, el modelo se descompone en más piezas y exige definir un mayor número de asociaciones. Esa separación puede ralentizar una necesidad puntual, pero también permite reutilizar componentes en escenarios posteriores. Por eso, frente a la rapidez inicial de SAP BW, el valor de SAP Datasphere aparece con más claridad a medio y largo plazo, cuando las mismas piezas sirven para responder a nuevas necesidades de negocio sin reconstruir el modelo desde cero.

CÓMO SE ESTÁN HACIENDO LAS COSAS (nuestro parecer)

En nuestra experiencia con SAP Datasphere, hemos participado en algunos proyectos y, en ocasiones, hemos encontrado desarrollos ya iniciados con una organización poco clara. Esta situación puede deberse a la cantidad de objetos disponibles en la plataforma, a la relativa novedad de la herramienta o a hábitos heredados de SAP BW y de otras tecnologías.

Lo que observamos habitualmente es un patrón parecido: se importa una fuente de datos basada en una CDS estándar, normalmente con un número elevado de columnas; en algunos casos se construyen megatablas; y desde ahí se crean vistas que se consumen directamente, sin aprovechar buena parte de los objetos y funcionalidades que ofrece la plataforma. Las fuentes de información suelen provenir directamente de sistemas SAP mediante CDS estándar, cuando podrían definirse CDS a medida para reducir el volumen de datos y concretar mejor las necesidades reales del negocio.

Como sugerencia, planteamos lo siguiente:

Identificar bien las fuentes de datos y optimizarlas en origen, por ejemplo mediante CDS personalizadas que incluyan solo las columnas necesarias para la explotación y realicen las combinaciones lógicas requeridas entre las tablas fuente. Hay que tener presente que las CDS son definiciones lógicas y que, si están bien construidas, pueden reducir los tiempos de ingesta y mejorar la claridad del modelo.
Definir estándares para la identificación técnica de la serie de objetos que se van a construir.
Hacer uso de paquetes y carpetas para organizar los objetos.
Evitar el abuso de tablas o vistas definidas directamente por importación, para mantener mayor control sobre la naturaleza de los datos que se van a tratar.
Hacer un uso adecuado de los distintos objetos disponibles para almacenar los datos, en lugar de recurrir siempre al mismo por comodidad.
Ofrecer al usuario final el acceso a los datos mediante modelos analíticos o perspectivas, y no a través de tablas o vistas técnicas. Estas últimas no están pensadas como capa de consumo final y, si se utilizan de ese modo, se desaprovechan capacidades importantes de análisis multidimensional de la plataforma.

En conclusión, SAP Datasphere no debe abordarse como una simple evolución de SAP BW, sino como una plataforma que exige plantear mejor la arquitectura desde el inicio. Su mayor valor aparece cuando se entienden sus objetos, se ordena el modelo desde el inicio y se construyen soluciones pensadas para ser reutilizadas, gobernadas y consumidas por el negocio.

Enlaces de interés:

MS Power BI con fuentes SAP BW, también limitado por la conexión MDX

Actualmente, fabricantes tales como Tableau, Qlik (antes QlikView) o MicroStrategy utilizan la misma conexión MDX y señalan similares limitaciones que reconoce MS Power BI a través de su mecanismo de conexión denominado DirectQuery, utilizando tanto su conector SAP BW Versión 1 o como el mejorado, denominado Versión 2.

CONECTIVIDAD A LOS DATOS BW

SAP ofrece dos tipos de conexión a fuentes SAP BW y BW/4HANA para la recuperación de datos para soluciones de BI y Análisis, por un lado, tenemos la conexión BICS (Business Intelligence Consumer Services) y, por otro lado, tenemos la conexión vía MDX (MultiDimensional eXpressins – Lenguaje para base de datos multidimensionales).

BICS, es considerada la alternativa más eficiente por los tiempos de respuesta y por reflejar con mayor fiabilidad/exactitud los modelos de datos SAP BW, especialmente la diversidad de características, sus atributos, variables y jerarquías.

MDX es una consulta que es procesada por otro motor distinto a BICS, por una interfaz pública denominada OLAP BAPIs. El procesador MDX de esta interfaz, brinda un resultado de datos y metadatos que casi siempre difiere de la arquitectura de la fuente SAP BW consultada.

MDX, EL VERDUGO DE LAS SOLUCIONES BI «NO-SAP»

BICS es la conexión de uso exclusivo de los productos ABI (Analytics and Business Intelligence) de SAP. MDX es la conexión que utilizan las herramientas de BI de terceros fabricantes, incluyendo MS Power BI. En las primeras versiones de BusinessObjects (especialmente con Web Intelligence) integrada a SAP, la única alternativa de conexión a BW era MDX y el resultado era muy frustrante para los usuarios al consultar o analizar sus datos.

Actualmente, fabricantes tales como Tableau, Qlik (antes QlikView) o MicroStrategy utilizan la misma conexión MDX y señalan similares limitaciones que reconoce MS Power BI a través de su mecanismo de conexión denominado DirectQuery, utilizando tanto su conector SAP BW Versión 1 o como el mejorado, denominado Versión 2.

LIMITACIONES AL ACCEDER A DATOS BW CON MDX

Entre otras, MS Power BI reconoce las siguientes limitaciones:

Cálculo de agregaciones diferentes,
Imposibilidad de uso de atributos de características,
Ningún tratamiento de jerarquías con niveles desiguales o dependientes del tiempo (sólo se utiliza la vigente o última),
Criterios de ordenación (caso meses es alfabético),
Imposibilidad de tratar las variables de texto (caso uso como variables de sustitución)
Las estructuras de despliegan en su totalidad, por ejemplo, si se tiene dos ratios (Ventas y Coste) y una estructura con dos líneas (Real y Presupuesto) se obtendrían 4 ratios desplegados (Ventas Real, Ventas Presupuesto, Coste Real y Coste Presupuesto).
En cuanto al rendimiento, Microsoft también se ve afectado por el mecanismo MDX que está obligado a utilizar. Con la Versión 2 de su conector a SAP BW de MS Power BI ha agregado opciones tales modificar el tamaño del paquete de datos que se recupera por bloque, lo cual podría ayudar a reducir la latencia o tiempos de espera, pero modificar este parámetro por defecto, debe ser controlado/alineado con los recursos del sistema.

CONCLUSION

Las limitaciones reconocidas por Microsoft al conectarse MS Power BI con fuentes SAP BW, señala como “responsable” la API pública a través de MDX, la cual, visto lo que ha sucedido con otros fabricantes, difícilmente mejore. En cuanto al rendimiento, la solución pasa por limitar el número de características o dimensiones que se recuperen y en agregar más filtros/variables obligatorias para reducir el volumen de datos que se lee.

Microsoft sugiere importar los datos, opción que se debe valorar dependiendo de cada necesidad y conjunto de datos a utilizar, por ejemplo, volumen o frecuencia de variación de datos.

Federación de fuentes de datos en SAP BusinessObjects BI

Con el término “federación” (federation) en SAP BusinessObjects BI se hace referencia a la posibilidad de combinar conjuntos de datos de proveedores o bases de datos distintas, sin la necesidad de recurrir a un repositorio físico que los agrupe. La principal ventaja que obtendríamos es que accederíamos a la información más actualizada que almacenarían las fuentes de datos de nuestro interés.

Con el término “federación” (federation) en SAP BusinessObjects BI se hace referencia a la posibilidad de combinar conjuntos de datos de proveedores o bases de datos distintas, sin la necesidad de recurrir a un repositorio físico que los agrupe. La principal ventaja que obtendríamos es que accederíamos a la información más actualizada que almacenarían las fuentes de datos de nuestro interés.

A través del Information Design Tool (IDT, traducida como Herramienta de Diseño de Información), la aplicación cliente para crear universos, podemos definir diversas conexiones a fuentes de datos relacionales tales como Microsoft SQL Server, Oracle, IBM DB2, Sybase, Teradata, SAP BW (modo relacional), ficheros de texto, XML, Excel, entre otros. Definidas las conexiones relacionales las podemos agrupar en una capa de “infraestructura de datos multifuente” (multisource data foundation) para que se puedan acceder a ellas como si de una única fuente de datos se tratase.

En la denominada “Capa de Federación” (Federation Layer) del IDT, podemos definir los flujos de combinación de las tablas de las distintas fuentes que hemos seleccionado, para dar lugar a nuevas tablas lógicas, denominada tablas federadas, en estas combinaciones señalaremos los criterios y lógicas para este fin, haciendo uso de interfaz gráfica sin apenas necesidad de escribir código SQL, de manera similar a herramientas ETL (Extracción, Transformación y Carga de datos). Si fuese necesario escribir scripts SQL para la creación de una tabla federada, se deberá utilizar un SQL estándar, sin utilizar sentencias particulares que ofreciese cada fabricante de motores de bases de datos.

Debes tener presente que las infraestructuras multifuente para la federación de datos requieren más recursos del host de SAP BusinesObjects BI, los cuales son gestionados por el servicio “Data Federation”, incluido en el servidor Adaptive Processing Server (APS), el cual, como tarea de custumización o puesta a punto de la plataforma, debería estar en funcionamiento de manera aislada, con una asignación de 2 a 8 GB de memoria, según los volúmenes de datos que se acceda.

De «powered by SAP HANA» a «edition for SAP HANA»

La arquitectura de todos los componentes o productos SAP, con futuro, vienen siendo revisados y redefinidos para que funcionen utilizando el potencial de SAP HANA Database de la mejor manera. Así, inicialmente fueron introducidos los “aceleradores”, los cuales básicamente replican las tablas más relevantes de una aplicación en HANA, obteniéndose un mejor tiempo de respuesta.

La arquitectura de todos los componentes o productos SAP, con futuro, vienen siendo revisados y redefinidos para que funcionen utilizando el potencial de SAP HANA Database de la mejor manera. Así, inicialmente fueron introducidos los “aceleradores”, los cuales básicamente replican las tablas más relevantes de una aplicación en HANA, obteniéndose un mejor tiempo de respuesta.

Posteriormente hemos venido viendo soluciones “powered by SAP HANA” o simplemente “on SAP HANA”, caracterizadas por llevar, con mínimos cambios, los modelos de datos de las aplicaciones a SAP HANA y por consiguiente, el procesamiento de los datos es ejecutado en memoria obteniéndose importantes mejoras en los tiempos de respuesta.

El cambio más disruptivo que se está dando por SAP HANA es la irrupción de una nueva generación de aplicaciones, las denominadas “edition for SAP HANA”. La cual prescinde de todos los elementos u objetos que tuviese la aplicación original e impiden que sea más eficiente y veloz en SAP HANA. El primero y más relevante representante “edition for SAP HANA” es SAP BW 7.5, del cual destacamos los siguientes cambios:

La clásica interface SAP GUI del denominado Data Warehousing Worbench es sustituida por el denominado BW Modelling tolos in Eclipse.
Las funcionalidades o herramientas para el modelado BW han sido adaptadas en el entorno de modelado SAP HANA. Por el momento, hay algunos objetos que deben ser definidos en el Data Warehousing Workbench.
Algunos objetos ya no son soportados y serán sustituidos por uevos tipos de objetos especialmente diseñados para SAP HANA. En este enlace puedes ver estos cambios: aquí.
SAP Business Explorer (BEx) ya no será soportado nunca más (esto ya lo han dicho más de alguna vez. :-I). Las consultas o queries serán definidas con las herramientas de modelado BW de SAP HANA. Para la visualización de datos se recomienda el uso de Analysis for Office o Design Studio (o SAP BusinessObjects Lumira).