aníbal goicochea

SAP, tengo una «sospecha», los Environments de BPC tienen limitaciones

Con las experiencias o padecimientos de los usuarios se logra la madurez de un producto, lo que se puede corregir el fabricante lo corrige y lo que no, se señala como restricciones, limitaciones o fuera de alcance. Hay muchos cambios que hemos visto en productos tan nuevos como SAP BusinessObjects BI 4.0 y SAP Business Planning and Consolidation (SAP BPC) 10.0, algunos cambios de funcionamiento y también advertencias y restricciones. Indudablemente estos cambios han sido gracias a los primeros usuarios que «descubrieron» alguna anomalía y lo comunicaron al equipo de soporte de SAP, que al final deriva en una nota para el resto de los usuarios.

En el caso de SAP BPC 10.0 NW, tenemos una «sospecha», nos referimos así porque no hay documentación o nota que niegue o afirme nuestra «hipótesis». Cuando trabajamos con SAP BPC NW por cada «Environment» (antes Application Set) se crea una InfoArea en SAP NW BW, en este espacio se van guardando la serie de objetos que vamos definiendo, necesarios para nuestros proyectos (dimensiones, modelos – cubos -, lógicas e inclusive ficheros temporales). Nuestra «sospecha» es que, al igual que otros objetos de BPC que se reflejan en BW, no pueden ser tratados del mismo modo.

Es decir, creemos que las InfoAreas creadas por la definición de un Environment de BPC tienen limitaciones, tales como la cantidad de objetos que puedan contener o inclusive, su origen, por ejemplo que no pueda contener cubos creados desde BW. Seguro que por el momento son muy pocos los que superen los 35 modelos en un Environment de BPC para que hasta la fecha no exista una nota con «restricciones» al respecto. Algunas veces no es necesario esperar una «comunicación oficial», si vemos los contratiempos, podemos actuar. La nota de referencia refuerza un poco nuestra sospecha.

Referencia: (aquí)

La Escalabilidad en SAP HANA (II). Enfoque Scale-up

La capacidad de ampliación Scale-up de un sistema SAP HANA, no tiene mayor complejidad, viene determinada por las configuraciones disponibles que ha definido SAP (SAP HANA T-shirt sizes) y los modelos que ofrece el partner de hardware de SAP HANA que se ha elegido. SAP recomienda adquirir la máxima recomendación que nos puedan brindar las estimaciones de las herramientas de sizing (notas relacionadas al sizing: aquí, aquí y aquí)

Por ejemplo, tomando como referencia la tabla anterior, para mejorar la capacidad de un appliance SAP HANA con una configuración “XS” a una configuración “S”, bastaría con incrementar la memoria principal a 128 GB.

Compatibilidad de SAP BPC con Windows 8 y Office 2013

A través de la nota 1823786 SAP ha comunicado que tiene planes para el 2013 incluir en SAP Business Planning and Consolidation (SAP BPC) versión 10.0 compatibilidad con los nuevos productos de Microsoft,

A través de la nota 1823786 SAP ha comunicado que tiene planes para el 2013 incluir en SAP Business Planning and Consolidation (SAP BPC) versión 10.0 compatibilidad con los nuevos productos de Microsoft, tal como Windows 8, Office 2013 y Internet Explorer 10. Para la versión 7.5 sólo se prevé compatibilidad con Windows 8 e Internet Explorer 10. Para la versión 7.0 no habría novedades en este sentido.

Referencia: (aquí) y revisar post relacionado

La Escalabilidad en SAP HANA (I)

Escalabilidad es la capacidad que tiene un sistema para gestionar una cantidad creciente de tareas o su capacidad para ser ampliado para ajustarse a ese crecimiento. Un sistema cuyo rendimiento mejora después de la adición de hardware, proporcionalmente a la capacidad añadida, se dice que es un sistema escalable, por otro lado, si el sistema falla después de este incremento de hardware, esto significa que no es un sistema escalable

Escalabilidad es la capacidad que tiene un sistema para gestionar una cantidad creciente de tareas o su capacidad para ser ampliado para ajustarse a ese crecimiento. Un sistema cuyo rendimiento mejora después de la adición de hardware, proporcionalmente a la capacidad añadida, se dice que es un sistema escalable, por otro lado, si el sistema falla después de este incremento de hardware, esto significa que no es un sistema escalable (Referencia).

En SAP HANA, al igual que en otras arquitecturas, la escalabilidad tiene dos enfoques o criterios:

Escalabilidad vertical (scale up): Consiste en incrementar los recursos de un único nodo del sistema, por ejemplo, la cantidad de memoria RAM.
Escalabilidad horizontal (scale out): También llamado “sistema distribuido”, consiste en agregar más nodos a un sistema, para que trabajen como uno sólo (cluster).

Ninguna de las dos estrategias es mejor que la otra, ambas obedecen a necesidades o circunstancias distintas. Por ejemplo, para aumentar la capacidad de procesamiento puede ser necesario ampliar la memoria RAM (scale up) o para mejorar la eficiencia de procesamiento podría ser necesario distribuir la capacidad de procesamiento en más de un host (scale out), complementando esta medida con acciones tales como el particionado de las tablas o la distribución de las tablas de datos entre los hosts que conforman el sistema.

Referencia: Documentación SAP

VMWare para una estrategia de entornos en SAP HANA

Contar con más de un Appliance SAP HANA para desplegar una arquitectura clásica de tres ambientes o entornos, tales como “Desarrollo”, “Integración” y Producción”, sería una “locura millonaria” imposible de aplicar. En principio, un Sistema SAP HANA es desarrollo y producción,

Contar con más de un Appliance SAP HANA para desplegar una arquitectura clásica de tres ambientes o entornos, tales como “Desarrollo”, “Integración” y Producción”, sería una “locura millonaria” imposible de aplicar. En principio, un Sistema SAP HANA es desarrollo y producción, para este doble papel se han barajado varias “soluciones”, teniendo en el horizonte la promesa de SAP de brindar mejores mecanismos para definir una estrategia de entornos como se desarrolla con otras arquitecturas.

Hasta la fecha, los “mecanismos” que ha ofrecido SAP, para este fin, han sido algo complejos y podrían afectar el rendimiento del sistema. Nos referimos a soluciones como la creación de una segunda base de datos o el uso SAP HANA One de Amazon Web Services para cubrir las necesidades de un entorno de desarrollo.

La alternativa que nos parece más “limpia” y segura es la que consiste en la creación de entornos virtualizados con VMware vSphere sobre un Appliance SAP HANA, al cual se le asignaría una porción (balanceada) de CPU y memoria para su configuración. Por el momento, esta solución es posible sólo en despliegues mono-nodo y aplicable con fines distintos a un entorno de producción.

Referencia: Alternativa VMWare (aquí y aquí) Otras alternativas (aquí y aquí)