SAP vuelve a cambiar nombres, esta vez en BPC 10.1


Podríamos señalar que el cambio de nombres a los productos y/o a los componentes que lo conforman, es el paso inevitable por el que transcurre la gran mayoría de productos SAP hacia su maduración. Esta vez, le ha tocado al recientemente estrenado SAP Business Planning and Consolidation 10.1 para NetWeaver.

Ventana de Gestión de Environments en el nuevo BPC 10.1 SP2 (Clásico o Estándar) - Opción Create estaría habilitada en una instalación Unified o Embedded

Tal como ya hemos comentado en alguna ocasión, en BPC 10.1 NW es posible crear entornos similares a los que conoces en la versión 10.0, a los que SAP nos enseñó, inicialmente, denominar como Clásicos (Classic). Por otro lado, en instalaciones de BPC 10.1 sobre SAP HANA, tenemos la posibilidad de crear estructuras para modelos de planificación que obtengan el máximo beneficio de la plataforma in-memory de SAP, esta otra categoría SAP nos indicó que se denominaba Unificado (Unified).

Pues bien, a través de la nota 2117885, SAP nos comunica que a partir del Support Package 3 (SP3) de BPC 10.1 NW, todo lo que conocíamos cómo Classic pasa a denominarse Standard  y todo lo que conocíamos cómo Unified, ahora se denomina Embedded.

Alternativas Cloud para SAP BusinessObjects BI


Lo más usual para implementar una plataforma SAP BusinessObjects Business Intelligence es utilizando una infraestructura propia, modalidad usualmente denominada on-premise. Pero la alternativa Cloud o en la nube va ganando mayor aceptación en casos como en una plataforma SAP BusinessObjects BI, en la que las necesidades de recursos de hardware, especialmente memoria, pueden fluctuar en el tiempo.

En la actualidad SAP brinda soporte a la instalación de SAP BO BI sobre Amazon Web Services (AWS) y en SAP HANA Enterprise Cloud, en este último caso es desplegado y gestionado por SAP. Para la propuesta cloud de Microsoft, MS Azure, por el momento no se brinda soporte, pero hay planes futuros de incluirla en esta lista (para más información consulta la nota 2106331.

AWS ofrece servicios de infraestructura que pueden ser utilizados para el despliegue de productos de SAP. En la nota 1656099 se describe los productos de SAP, combinaciones de bases de datos/sistemas operativos y los tipos de instancia AWS EC2 compatibles y soportados actualmente.

Verdades a medias sobre SAP HANA (y Parte III)


Continuamos con la última entrega de esta serie (Parte I, Parte II) sobre las verdades a medias o conceptos erróneos que circulan sobre SAP HANA (más información en el documento de referencia):

  • En escenarios de escalabilidad horizontal (scale-out) las tablas con almacenamiento columnar no se almacenan en el nodo principal (master node). Es usual que varias tablas con almacenamiento en columnas se encuentren en el nodo principal en un escenario de escalabilidad horizontal. Pero es importante que las tablas de gran tamaño y/o críticas sean movidas a los nodos auxiliares o esclavos (slave nodes). Por ejemplo, en un entorno BW, infocubos, DSOs y PSAs deberían ser movidos a nodos esclavos.
  • En un escenario de escalabilidad horizontal el almacenamiento en filas es sólo en el nodo principal. Esta afirmación es correcta desde una perspectiva de aplicaciones, pero sin embargo, los nodos esclavos tendrán una mínima implementación técnica de tablas con almacenamiento en filas.
  • La sentencia UPDATE es siempre aplicable a operaciones DML (Data Manipulation Language). Esta afirmación no es siempre cierta. SAP HANA utiliza sentencias UPDATE también en operaciones DDL (Data Definition Language). Por ejemplo, la sentencia UPDATE para optimizar la compresión del almacenamiento columnar.
  • El motor Join (Join Engine) sólo procesa sentencias join. Esta afirmación es incorrecta. El motor join (ver aquí entrada sobre los motores SAP HANA) también es utilizado por ciertas consultas sobre una única tabla que realiza agregaciones o se utiliza la cláusula GROUP BY.

Referencia: SAP Note 2100010

Verdades a medias sobre SAP HANA (Parte II)


Continuamos con la entrada anterior, sobre las verdades a medias o conceptos erróneos que circulan sobre SAP HANA:

  • SAP HANA es una base de datos en memoria pura. SAP HANA es una base de datos en memoria, sin embargo, hay una serie de operaciones de lectura y escritura en disco que tienen impacto en el rendimiento global del sistema, tales como:
    • Carga de tablas con almacenamiento en filas al iniciar el sistema
    • Carga de columnas
    • Acceso LOB (Large Objects)
    • Ejecución de savepoints y snapshots
    • Volcados a base de datos (commits)
    • Copias de seguridad (backups)
  • Todas las tablas están permanentemente en memoria. No todas las tablas SAP HANA están permanentemente y completamente en memoria. Se debe tener presente lo siguiente:

    • Las tablas con almacenamiento en filas y las columnas LOB no son cargadas en memoria.
    • Las tablas con almacenamiento columnar no son cargas sino son utilizadas o son descargadas por problemas de memoria.
    • Así mismo, la información histórica que muy rara vez se accede, no debería ser cargada en memoria
  • Las funcionalidades de almacenamiento en filas y almacenamiento en columnas están apartadas. Tradicionalmente estas dos técnicas o funcionalidades provienen de tipos distintos de bases de datos, pero en SAP HANA han sido integradas, por lo que ambos tipos de almacenamiento pueden ser combinados para procesar la información.

Verdades a medias sobre SAP HANA (Parte I)


Cuando algo nuevo surge en el mundo de tecnología el desconocimiento se hace presente en forma de mitos, verdades a medias o conceptos erróneos. En el ámbito de SAP HANA esta situación ya se está produciendo, por ello SAP ofrece una breve aclaración de los conceptos que se están tergiversando.

A continuación señalamos los siguientes conceptos o afirmaciones erróneas:

  • Todas las tablas de datos de SAP HANA se procesan con almacenamiento columnar (column-oriented). SAP HANA permite, tanto, tablas con almacenamiento en filas como en columnas. Las tablas con almacenamiento en filas son accedidas del mismo modo que las bases de datos relacionales tradicionales. Basándose en la experiencia y en el conocimiento, se puede decidir, de manera individualizada, que tipo de almacenamiento debe tener cada tabla para obtener el mejor rendimiento.
  • El almacenamiento en columnas ofrece mejor rendimiento que el almacenamiento en filas. En algunos casos es así, por ello, SAP tiende al mayor uso posible de tablas con almacenamiento en columnas, pero sin embargo, hay algunos casos en que el almacenamiento basado en filas ofrece un mayor rendimiento. (aquí tips a tener en cuenta).
  • Los índices no son necesarios. SAP HANA puede analizar grandes cantidades de datos, incluso sin la existencia de índices. Sin embargo hay situaciones en las que los índices son útiles, por ejemplo si se requiere realizar un acceso selectivo en repetidas ocasiones (para un entorno Business Suite on HANA, sugerimos la nota 1794297).
  • Los índices no se conservan en el disco. Los índices conformados por más de una columna de las tablas con almacenamiento columnar, son generalmente almacenados en disco. Los índices conformados por sólo una columna, son considerados como parte de la definición o estructura de la columna, no son almacenados en disco, se recrean automáticamente cuando la columna es cargada. Los índices de las tablas con almacenamiento en filas no se almacenan en disco, se crean cada vez que el sistema se pone en marcha.

Los Savepoints de SAP HANA


La principal técnica que utiliza SAP HANA Database para ofrecer un inmediato acceso a la información es manteniendo los datos en memoria, si la información fuese actualizada, estos cambios se reflejarían tanto en la memoria como en disco, es en este punto que interviene el concepto de Savepoints (aquí más información).

Los datos que se cargan a memoria son agrupados en “páginas”, todas las páginas que fuesen modificadas en un período de tiempo determinado, son volcadas a disco en los denominados Savepoints (el cual podríamos traducir como “puntos de sincronización” o “puntos de salvaguarda”).

Es una instalación del tipo “scale-out” conformada por más de un host, se debe tener en cuenta que cada host gestionará sus propios Savepoints.

La disponibilidad de un savepoint reciente conllevará a un reinicio del sistema más rápido porque habrá menos logs que procesar. Un Savepoin es desencadenado por las siguientes vías:

  • Intervalo predefinido. La parametrización por defecto establece que automáticamente habrá un punto de salvaguarda cada 5 minutos (global.ini >> [persistence] >> savepoint_interval_s = 300).
  • Comando del sistema. Puede utilizarse una sentencia en SAP HANA Studio para ejecutar un savepoint manualmente (ALTER SYSTEM SAVEPOINT)
  • Cierre del sistema del tipo Soft. Un “soft shutdown” ejecuta un savepoint antes de detener los servicios. Un “hard shutdown” no realiza un savepoint, lo que incrementaría el tiempo de reinicio del sistema.
  • Después de iniciar el sistema. Finalizado el reinicio del sistema, se realiza un savepoint.
  • Snapshots. Las instantáneas conllevan un savepoint que no se ven afectados por siguientes savepoints.

Para iniciar el año, “sentido de pertenencia”


Iniciamos un nuevo año y las predicciones tecnológicas son diversas y variopintas, en nuestro caso, con más ilusión de lograr mejores resultados, continuando nuestra apuesta por SAP Business Planning and Consolidation (SAP BPC), SAP BusinessObjects BI y SAP HANA. Ampliando nuestro interés por la tecnología que rodea al análisis de grandes volúmenes de información (Big Data), especialmente por el análisis predictivo/minería de datos e Internet of Things (IoT).

Incorporamos en nuestra “mochila de recursos” un concepto que hemos escuchado con bastante claridad del entrenador del Atlético de Madrid, Diego Simeone, el cual en reiteradas ocasiones señala la importancia que las personas que conforman su equipo tengan el sentido de pertenencia, del cual identificamos tres claves:

  • Saber dónde nos encontramos,
  • Querer estar en el equipo y
  • Sentirlo como nuestro

En alguna ocasión ha señalado literalmente lo siguiente: “Tengo la suerte de trabajar en un lugar al que quiero, al que me entrego y lo siento propio. Y creo que en algún punto, los jugadores también lo sienten así. Al encontrar gente dentro del grupo que está en nuestra misma línea nos facilita mucho las cosas.” (ref.)

Buen año.

Cancelar o interrumpir sesiones en SAP HANA


Un alto consumo de recursos que pudiese realizar un proceso podría afectar la estabilidad y el buen funcionamiento de cualquier infraestructura, en este aspecto, SAP HANA no es la excepción. En SAP HANA es posible definir límites globales de consumos del área de memoria, que utilizan los procesos para su ejecución (denominada Allocated memory). Hasta la actualización SPS 06, el valor predeterminado era el 90% de la memoria física, desde la actualización SPS 07 el valor por defecto es el 90% de los primeros 64 GB y el 97% del resto de la memoria física.

En el caso que se detectará un proceso/sesión con un elevado uso de recursos, este podría ser interrumpido. Una sesión en este contexto es la combinación de la conexión (es decir, enlace al proceso cliente), el hilo (thread, es decir, la ejecución real en el lado SAP HANA), Sentencia SQL y transacción.

La interrupción de la ejecución de una sesión puede afectar el funcionamiento de una aplicación, por lo que esta medida debe ser utilizada con mucho cuidado. Existen las siguientes opciones para terminar sesiones críticas en SAP HANA:

  • Cancelar sesiones. Vía SAP HANA Studio (Administration >> Performance >> Sessions) o vía sentencia SQL (ALTER SYSTEM CANCEL SESSION). La cancelación no es inmediata, el sistema puede realizar comprobaciones previas.
  • Desconectar sesiones. Vía sentencia SQL (ALTER SYSTEM DISCONNECT SESSION) es posible desconectar sesiones (e implícitamente cancelarla). Se debe tener presente que si una sesión no puede ser cancelada con el comando anterior, el uso de una desconexión empeoraría la situación, dado que podría iniciar nuevamente el funcionamiento del proceso que se desea desconectar.
  • Establecer límites de uso de memoria. A partir de la actualización SPS 08 es posible establecer la inmediata culminación de sentencias SQL que superasen ciertos límites de uso de memoria. Así mismo, es posible definir el consumo global de memoria por parte de los procesos.

Referencia: SAP Note 2092196

SAP Analysis 2.0 for MS Office, en ramp-up


La nueva versión de SAP Analysis, Edition for Microsoft Office 2.0 se encuentra en fase de ramp-up, este producto denominado “Cliente Excel Unificado” (Unified Excel Client) pretende aglutinar las funcionalidades de todos los programas tipo Add-in o complemento de SAP que se instalan sobre la plataforma Microsoft Office, especialmente sobre MS Excel. Importante relevancia tiene la inclusión de las funcionalidades del SAP EPM Add-in, actual componente cliente de SAP Business Planning and Consolidation (SAP BPC) 10.0/10.1.

SAP Analysis 2.0 for MS Office en Ramp-up

Este cliente unificado, en principio, sólo sería para usuarios que se conectaran a plataformas SAP HANA, ya sea a fuentes SAP BW on HANA y/o SAP BPC 10.1 Unified. Para usuarios que requieran utilizar fuente de datos SAP BPC Classic (modelos 10.0 o de tipo Consolidation) deberían continuar utilizando el SAP EPM Add-in.

Recomendaciones de cliente según las fuentes de datos a utilizar

La fecha prevista de disponibilidad general de esta nueva versión es de mayo de 2015. No es la primera versión de un producto SAP orientado exclusivamente para plataformas SAP HANA. Pareciera que deberíamos sugerir que si una gran empresa actualmente no tiene SAP HANA debería estar valorándolo para el corto o largo plazo, y debería tenerlo presente en su plan estratégico de desarrollo tecnológico.

Evoclución a un cliente único, pero por el momento, sólo para SAP HANA

Referencia: (aquí)

SAP BPC 10.1 para Microsoft, a la vista


Los rumores sobre la continuidad de la edición para plataformas Microsoft de SAP Business Planning and Consolidation (SAP BPC MS) han sido constantes, especialmente cuando se anunció la nueva versión 10.1 y sólo se presentaba para plataformas NetWeaver y sobre la edición Microsoft no se señalaba nada al respecto.

Hoja Ramp-up de SAP BPC 10.1 MS, liberación entre abril y junio de 2015

Desde hace unos días observamos el inicio de la fase ramp-up (período de pruebas en instalaciones cliente) de SAP BPC 10.1 MS, la cual culminaría en el segundo trimestre de 2015, por consiguiente, la liberación de la nueva versión o disponibilidad general para todos los usuarios. Al igual que la versión 10.1 de SAP BPC para plataformas NetWeaver (NW) presentación Classic, entre las características más destacadas figura la nueva interfaz basada SAP UI5 (adaptación de SAP de HTML5),

SAP BPC 10.1, configuración cliente y servidor recomendada

En el PAM (Product Availability Matrix), ficha técnica del producto sobre requerimientos, fechas de mantenimiento y soporte, se señala una vigencia hasta el 31 de diciembre de 2020, lo deja aparcada las especulaciones sobre supuestos planes de retirar esta edición de SAP BPC.