Resumiendo Q&A de Webinar sobre SAP BPC (#SAPBPC o #BPC)

Ha transcurrido casi medio año desde que se liberó SAP Business Planning and Consolidation 10.0 para Netweaver (SAP BPC NW) y no nos queda duda que sucederá lo mismo que sucedió con la versión 4.0 de SAP BusinessObjects BI 4.0 (BI4), será necesario un año desde su liberación para contar con un producto estabilizado, BI4 ya lo ha logrado, con SAP BPC seguro que en medio año más tendremos menos problemas para implementarla.


Ha transcurrido casi medio año desde que se liberó SAP Business Planning and Consolidation 10.0 para Netweaver (SAP BPC NW) y no nos queda duda que sucederá lo mismo que sucedió con la versión 4.0 de SAP BusinessObjects BI 4.0 (BI4), será necesario un año desde su liberación (General Availability, GA) para contar con un producto estabilizado, BI4 ya lo ha logrado, con SAP BPC seguro que en medio año más tendremos menos problemas para implementarla.

SAP BPC NW 10.0, desde su liberación se han publicado dos actualizaciones para su servidor BPC (actualmente en el SP08) y para el componente cliente, denominado SAP EPM Add-in 10.0, más de una docena de actualizaciones (entre SPs y patchs, actualmente en SP12 Patch 6), componente en dónde se han encontrado la mayor cantidad de errores o temas por mejorar.

En un reciente webinar de SAP Insider se contestaron algunas preguntas, destacamos las que nos parecen más relevantes:

  • Sobre la migración de BPC NW 7.5 a 10.0 se señala dos técnicas: Actualización desde un servidor 7.5 e Instalación de un nuevo servidor 10.0 con importación de datos (aquí y aquí nuestros posts sobre este tema).
  • Es posible cargar datos maestros desde ECC a BPC utilizando una cadena de proceso (nota: es incluida en el estándar, debe ser habilitada a través del organizador de paquetes de BPC).
  • Se puede activar la funcionalidad de reconocimiento de miembros de dimensión para la construcción rápida de informes (nota: Esta funcionalidad del EPM Add-in es muy probable que todos quieran desactivarla, interrumpe el  trabajo si se desea trabajar con otros libros sin conexión a BPC y exige definir un único ID a nivel de un modelo para evitar el menú consultando a que dimensión pertenece ante una ambigüedad).
  • Si es posible utilizar SAP BPC 7.5 sobre SAP HANA (aquí nuestro post) pero realmente es en BPC 10.0, a través del componente HANABPC , donde se logrará un mejor rendimiento de HANA para el procesamiento de modelos BPC, en gran medida esto se logra porque se utilizan los denominados InfoCubos “HANA Optimized”.
  • Sobre los grandes cambios de la versión 10.0 de SAP BPC se destaca lo siguiente:  
    • Cambio del editor del perímetro de consolidación del Dynamic Hierarchy Editor (Basado en plantillas MS Excel-) al Ownership Manager (basado en interfaz Web),
    • Monitor de Consolidación (alternativa sólo disponible en entornos Netweaver).
    • Las reglas de negocio (business rules) no han cambiado, lo que ha variado es el entorno dónde se definen (en la edición Microsoft es similar a la versión anterior).
    • En cuanto a los Journals (formularios especiales para realizar ajustes como parte del proceso de consolidación) se han realizado algunos cambios en ambas ediciones.
  • En la edición para Microsoft (MS) las novedades más destacables es el soporte de MS SQL Server 2012 (desde el SP07) y mejora del rendimiento y en la edición para SAP Netweaver (NW) se  destaca el soporte de SAP HANA (desde la SP06) … ¿alguien duda que SAP BPC MS y SAP BPC NW son dos productos distintos, cada vez más?
  • SAP BPC powered by SAP HANA permite la manipulación de grandes volúmenes de información y al tener el procesamiento a nivel de base de datos, posibilita un mayor uso de las fórmulas a nivel de miembros de dimensión (Member Formulas, generalmente definidas en la dimensión de tipo Account), una característica a utilizar con moderación en otros entornos para no afectar el rendimiento.
  • Las soluciones cloud de SAP EPM (EPM on-demand solution from SAP) son complementarias a la solución estándar.

Referencias: aquí y aquí

Fórmulas para el “sizing” en SAP HANA

Según SAP, la vía “más segura” o recomendable para estimar las necesidades de hardware de un nuevo producto como puede ser SAP HANA, es el uso del Quick Sizer. Pero además de los resultados que se pudieran obtener con esta herramienta, para el caso de SAP HANA, existen unas fórmulas que brindan valores preliminares que no se alejarían de los valores definitivos.


Según SAP, la vía “más segura” o recomendable para estimar las necesidades de hardware de un nuevo producto como puede ser  SAP HANA, es el uso del Quick Sizer.  Pero además de los resultados que se pudieran obtener con esta herramienta, para el caso de SAP HANA, existen unas fórmulas que brindan valores preliminares que no se alejarían de los valores definitivos.

El sizing consiste en estimar las necesidades de memoria, almacenamiento en disco y la capacidad de procesamiento (CPU).  Las fórmulas son las siguientes:

  • Memoria. Para el cálculo de este valor se toma como referencia el tamaño utilizado actualmente, ya sea por el actual SAP NW BW y/o SAP ERP, considerando que no se debería incluir el espacio utilizado por logs, temporales y agregados (en el caso de BW).  Toda la información será cargada en memoria, pero para este fin SAP HANA utiliza mecanismo de compresión que por norma general equivalen a la quinta parte.  Así mismo, para procesos internos, HANA necesita espacio, que se estiman igual al tamaño utilizado por los datos, una vez cargados en memoria.

Memoria = ((Espacio actual) / 5) * 2

  • Disco. Se estima en función del valor obtenido en el cálculo de las necesidades de memoria. Se calcula tanto para datos, como para los logs de transacciones, cada uno de estos datos se obtienen en cada factor de la siguiente fórmula:

Disco = (Memoria * 4) + (Memoria)

  • CPU (basado sobre el número de cores que incluyen) se debe estimar en función del número de usuarios activos, los cuales pueden fluctuar entre 20% y 40% del número de usuarios nominales.  Se estima que para gestionar un usuario activo se requiere 0,2 de un core de CPU:

CPU = 0,2 * (Usuarios activos)

Information Composer para el «self service» en SAP HANA

Tener la base de datos más veloz del mundo sirve de muy poco si los usuarios de negocio contaran con datos adicionales, necesarios para su análisis, y tuviesen que esperar que el equipo técnico responsable los cargue y los prepare para que los puedan utilizar. Para evitar este tipo de situaciones, SAP ofrece una aplicación Web como parte de su plataforma SAP HANA para que los usuarios de negocio “avanzados”, con la debida autorización, puedan hacer básicamente dos cosas: Cargar ficheros de datos personales (Upload) y preparar vistas de información HANA para procesar sus datos (Compose).


Tener la base de datos más veloz del mundo sirve de muy poco si los usuarios de negocio contaran con datos adicionales, necesarios para su análisis, y tuviesen que esperar  que el equipo técnico responsable los cargue y los prepare para que los puedan utilizar. Para evitar este tipo de situaciones, SAP ofrece, Information Composer, una aplicación Web como parte de su plataforma SAP HANA para que los usuarios de negocio “avanzados”, con la debida autorización, puedan hacer básicamente dos cosas: Cargar ficheros de datos personales (Upload) y preparar vistas de información HANA para que puedan procesar sus datos (Compose).

Evidentemente no hay punto de comparación entre SAP HANA Studio y SAP HANA Information Composer (IC), lo único en común, es que ambas son aplicaciones cliente, por lo demás, sobran las diferencias, Studio es la herramienta completa que utilizarán los usuarios técnicos encargados del modelado de datos.

En Information Composer se pueden cargar ficheros MS Excel (.xls o .xlsx) ficheros delimitados por comas (.csv) o lo que hubiese en el portapapeles (clipboard).  Luego de seleccionar la fuente origen, los datos podrían ser “depurados” (modificación y eliminación de valores o combinación de columnas) y luego clasificados (identificación de las columnas que serán tratadas como atributos  y cuales como medidas), para finalmente guardar los datos en la base de datos SAP HANA.

No siempre el usuario deberá cargar datos, podría utilizar directamente la funcionalidad para diseñar vistas de información.  La funcionalidad Compose permite diseñar una nueva vista a partir de otras dos vistas o de los datos que hubiese cargado el usuario.  La vista resulta, al igual que los datos, podrían ser compartidos con otros usuarios.

Referencias: (aquí, aquí y aquí)

SAP HANA Database, una base de datos que procesa en memoria y también almacena en disco

Cuando se señala que SAP HANA es una base de datos in-memory computing (procesamiento en memoria) o cuando se explica que los datos constantemente están en la memoria principal, la primera preocupación que surge en forma de pregunta es ¿qué sucede si se produce un corte de energía?


Cuando se señala que SAP HANA es una base de datos in-memory computing (procesamiento en memoria) o cuando se explica que los datos constantemente están en la memoria principal, la primera preocupación que surge en forma de pregunta es ¿qué sucede si se produce un corte de energía?

La principal razón que explica la rapidez de SAP HANA en sus tiempos de respuesta, es que los datos siempre se encuentran en la memoria principal, la cual por sus características, libre de piezas mecánicas como las que tienen los disco duros (dispositivos utilizados en las tradicionales bases de datos), permite alcanzar tiempos de acceso hasta 100.000 veces menores que la denominada memoria secundaria o discos duros.

La memoria utilizada en la memoria principal es volátil, es decir, ante un fallo o corte en el suministro eléctrico, todos los datos cargados en memoria se pierden, por este motivo SAP HANA también almacena los datos en disco, pero como una operación en segundo plano, con una frecuencia por defecto de 5 minutos, HANA graba en disco los cambios realizados a los datos, sin interrumpir o ralentizar el procesamiento de la información.  

En HANA los datos en memoria son agrupados en páginas, cuando una transacción cambia los datos, la página que contiene las modificaciones es «marcada» para luego guardarla en disco en los intervalos regulares que se hallan definido.  Por otro lado,  todas las operaciones con los datos son guardado en logs contenidos en dispositivos no-volátiles. De este modo, si ocurriese un fallo en el suministro eléctrico, SAP HANA podría reiniciarse cargando todas sus páginas de datos con los últimos cambios realizados.  Quizás al hablar sobre SAP HANA, además de señalar que es “in-memory Computing” a continuación deberíamos señalar “with hard disk storage” o algo similar que haga hincapié que los datos también se guardan en disco.

Revisando el «road map» de «SAP NW BW powered by SAP HANA»

Nos guste o no, el futuro de SAP Netweaver BW o del Data Warehouse de SAP se cimentará en SAP HANA. Al igual que puntos de vista similares, habíamos escrito en anteriores entradas que no estábamos convencidos que SAP BW se llevará, casi tal cual, sobre SAP HANA, esperábamos una solución puramente HANA como una nueva generación de repositorio de datos. Pero dejamos al margen nuestras “lógicas” perspectivas y nos “aferramos” al futuro revisando el Road map de “SAP NW BW powered by SAP HANA” (no confundir con el road map de SAP HANA).


Nos guste o no, el futuro de SAP Netweaver BW o del  Data Warehouse de SAP se cimentará en SAP HANA.  Al igual que puntos de vista similares, habíamos escrito en anteriores entradas que no estábamos convencidos que SAP BW se llevará, casi tal cual, sobre SAP HANA, esperábamos una solución puramente HANA como una nueva generación de repositorio de datos.  Pero dejamos al margen nuestras “lógicas” perspectivas y nos “aferramos”  al futuro revisando el road map de “SAP NW BW powered by SAP HANA” (no confundir con el road map de SAP HANA).

Con respecto a la plataforma de procesamiento en memoria de SAP, con frecuencia nos encontramos con argumentos tales como que económicamente  es una tecnología poco asequible, pero además de los planes que tiene SAP de reducir sus precios en la medida siga siendo implementada, SAP HANA debe ser vista como la plataforma tecnológica capaz de cambiar la cultura de una organización, el modo de comunicarse, obtener y analizar la información, y por consiguiente, sin temor a exagerar, SAP HANA es sinónimo de transformación de los negocios.

Actualmente, para las empresas que han adquirido una plataforma SAP HANA, y tuviesen SAP NW BW 7.30, SAP ofrece “SAP NW BW powered by SAP HANA”, la mejor vía para mejorar el procesamiento de información con una reducción abismal de los tiempos, esto se logra, en gran medida,  porque los elementos que conforman BW (ODS o DSO DataStore Objects), así como la lógica que las procesa, residen en la base de datos en memoria de SAP HANA.

Actualmente SAP BW sobre SAP HANA ofrece una estructura de datos simplificada, dónde algunas tareas de administración ya no son necesarias, tales como la creación/actualización de índices, ofrece compatibilidad completa con BEx Query, seguridad gestionada por SAP NW BW, entre otras cosas.

Pero el futuro de SAP NW BW powered by SAP HANA tiene aspectos aún más interesantes como la posibilidad de diseñar vistas analíticas (Analytical Views) en SAP NW BW con interfaces nativas HANA, acceso a datos BW en SAP BusinessObjects Explorer vía SAP HANA, optimización de carga de datos en BW y para más largo plazo se uniformizarían las interfaz de usuario, simplificación de la arquitectura con la reducción de los tipos de infoproviders.

Referencia: (aquí)