Tips de una implementación SAP HANA


En los blogs de SAP SCN hallamos muchas entradas, algunas muy útiles desde el punto de vista técnico, sobre SAP HANA, encontramos un breve relato sobre la experiencia de la Universidad de Amsterdam al adoptar esta plataforma para sus sistemas de BW (BW on HANABWoH) y ECC (Suite on HANASoH).

Fases de un proyecto de Migración SAP HANA

A continuación algunos tips que extraemos del post de referencia:

  • Motivo: El hardware de la organización era obsoleto y de muy costoso mantenimiento.
  • Situación: Como consecuencia del punto anterior, el rendimiento de los sistemas era pésimo.
  • Otras alternativas que se valoraron: En una comparativa de costos de licencias entre Oracle y HANA puede resultar más atractiva la primera, pero aspectos tales como la integración de los sistemas ECC y BW sobre la base de datos HANA fue el principal aspecto que primó sobre el precio.
  • Papel de SAP: Al parecer: La colaboración de los representantes de SAP sólo se enfocaron en aspectos técnicos, no ayudaron a construir el “business case” desde el punto de vista funcional requeridos en estos casos (este comentario ya lo hemos escuchado más de una vez).
  • Expectativas: Además de la implementación de los sistemas en una plataforma in-memory, las posibilidades de adoptar SAP HANA Live for Business Suite (el sistema de análisis y reporting en tiempo real para ECC) causó gran expectativa entre los usuarios de negocio.
  • Enlaces de referencia: SuiteOnHANA y ExperienceSAPHANA
  • Dimensionamiento: SAP ofrece recursos tales como informes que ayudan a estimar el tamaño requerido de la infraestructura SAP HANA. Como es conocido, las necesidades de disco se reducen significativamente con SAP HANA. En esta experiencia puntual, la base de datos de BW pasó de 1.8 TB a 300 GB y la de ECC de 550 GB a 250 GB.
  • Hardware: Esperar hasta el último momento la compra del hardware, debido a la competencia entre los proveedores, las mejoras y precios pueden cambiar drásticamente en tan sólo unas semanas.
  • Actualización y Migración: Según SAP la actualización y migración se podría efectuar en un solo paso (Data Migration Option of SAP Upgrade Manager – DMO of SUM), pero por motivos de seguridad se optó por realizar esta operación en dos pasos. Se sugiere optar por la última versión y actualización disponible de los componentes, así mismo, verificar el nivel de revisión del software. La migración no es muy distinta a cualquier otra migración SAP. Además del uso de los clásicos entornos que puede tener una organización, se sugiere un primer paso a través de un Sandbox con la finalidad de hacer pruebas, comprobaciones y comprender el proceso.
  • Código: Un factor positivo es el poco código personalizado que se tuviese, sin embargo, SAP provee informes que analizan tanto código SAP y código personalizado con el fin de brindar sugerencias para que funcione mejor en una plataforma SAP HANA.
  • Contratiempos: No se encontraron problemas significativos al realizar el proceso de actualización y migración, salvo con tablas que tenían un gran tamaño, contratiempo que se superó “truncándolas”.
  • Resultado: El rendimiento de BW y ECC ha mejorado de manera significativa y no ha habido problemas con las bases de datos o la plataforma HANA. Sin embargo, hay algunas transacciones que funcionan peor, que están siendo revisadas por SAP.
  • La Prueba: …Hemos experimentado con sólo “tirar del enchufe” para simular una desconexión inmediata, inesperada de HANA. Después de arrancar, no notamos ninguna pérdida o corrupción de datos.

Referencia: Blogs SAP SCN

Precios de SAP Lumira


La herramienta de visualización de SAP, denominada SAP Lumira, dirigida a los usuarios de negocio, tiene una estrategia de precios que viene mostrando algunos cambios, para estar al tanto al respecto, sugerimos consultar la nota SAP 2050849 o visitar la Web de SAP Lumira (en esta misma web se puede descargar la edición gratuita).

Precios SAP Lumira

Por el momento, la denominada edición “Personal” es gratuita, la cual se diferencia con la edición de pago (“Standard”) por la mayor posibilidad de acceso a fuentes de datos que tiene esta última. La edición Standard asciende a 995 dólares, pero quizás, consultando al representante comercial correspondiente, este precio podría incrementarse.

¿Lumira add-on?


SAP BusinessObjects BI add-on for SAP Lumira (Lumira add-on) es el componente que se debe utilizar para permitir publicar, visualizar y compartir Conjuntos de datos (datasets) e Historias (Stories) de SAP Lumira en BI Launchpad, el portal de SAP BusinessObjects BI (BI4, se requiere BI 4.1 SP3 o superiores). Esta integración permitirá aplicar la seguridad, categorización y otras características propias de BI4 sobre los objetos diseñados en Lumira.

  • Datasets: definición para recopilar datos que se utilizarán para diseñar visualizaciones.
  • Stories: Agrupación de visualizaciones organizadas en un tablero

Por el momento, para utilizar este componente ser requiere SAP Lumira Server (versión 1.17 o superior), por consiguiente este Add-on sólo es aplicable para instalaciones con SAP HANA Database (SPS 08 Revisión 80 o superior).

Lumira add-on incluye cuatro servidores, los cuales controlan distintas funcionalidades para que los objetos Lumira puedan ser utilizados en la plataforma de BI. Como parte del trabajo de configuración y monitorización, los servicios que incluyen estos servidores podrían ser activados, desactivados o replicados, dependiendo de las características de estos elementos y las necesidades de los usuarios:

  • Lumira add-on server tier: Contiene dos servicios, uno de ellos controla la comunicación entre la plataforma BI y HANA (Lumira add-on service). El otro servicio controla la actualización de datasets sobre universos (Lumira add-on load refresh service)
  • Lumira add-on web tier. Contiene las capacidades para que la visualizaciones Lumira sean presentadas desde la plataforma web.
  • Lumira add-on web services. Incluye APIs web services RESTful adicionales.
  • Lumira add-on mobile integration. Incluye capacidades adicionales para que las historias de Lumira puedan ser accedidos desde dispositivos móviles.

SAP reduce las herramientas cliente de SAP BusinessObjects BI Suite


El amplio abanico de herramientas que ofrece la plataforma de Business Intelligence de SAP, ha significado un generador de dudas para los usuarios finales, más de una decena de componentes posibles y más de una alternativa en las distintas capacidades BI, ha dado lugar a que el usuario cuestione si estaba haciendo la elección correcta.

Simplificación del portfolio Business Intelligence de SAP, ahora denominado SAP BusinessObjects BI Suite

Bajo la máxima “Run Simple”, SAP, en los últimos meses, ha ido aclarando el mensaje en cuanto a su propuesta de BI, a la que denomina por ahora, SAP BusinessObjects BI Suite. SAP señala que desea “ofrecer un menor número de herramientas de BI” y “simplificar la cartera de herramientas de BI, respetando las inversiones que hubieran realizado los clientes”.

SAP Design Studio la herramienta de Dashboarding, en camino de cubrir las funcionalidades de Xcelsius

De este modo, las capacidades BI de SAP quedarían representadas por las siguientes herramientas cliente:

  • Reporting Analítico. Esta capacidad de BI queda representada por el indiscutible e imprescindible Web Intelligence (WebI). En cuanto al veterano Desktop Intelligence se seguirá brindando compatibilidad, pero para cualquier nuevo proyecto la alternativa debería ser WebI.
  • Reporting Operativo y para Impresión. La recomendación es SAP Crytsla Reports for Enterprise (CRE o también referida como la versión Java), al margen queda la clásica versión denominada Crystal Reports 2013 o Crystal Reports 2011, seguirán siendo soportadas, pero la recomendación de SAP es que para nuevos proyectos se utilice CRE, e inclusive, se debería valorar proyectos de migración.
  • Cuadros de mando. El mensaje fue transmitido hace algún tiempo, y no ha variado, la herramienta para nuevos proyectos de cuadros de mando o tableros debería ser Design Studio, en detrimento de Xcelsius (ahora denominado Dashboards), a pesar, como señala SAP, que Design Studio cubre el 70% de la funcionalidades de Xcelsius. A futuro, como en todos los casos, SAP ofrece compatibilidad para los trabajos actuales con los componentes que ha decidido interrumpir su evolución.
  • Descubrimiento y Análisis. Lumira (antes Visual Intelligence) surgió como una herramienta de visualización pero al final ha provocado la extinción del pesado mastodonte que significaba BusinessObjects Explorer, hecho muchas veces negado por SAP. Lumira ha evolucionado en muchos aspectos, además de su mayor integración con otros componentes de BI, ofrecerá capacidades predictivas.
  • Integración con MS Office. La integración con los productos MS Office, en especial con MS Excel, es responsabilidad de Analysis for MS Office, a estas alturas no debería quedar duda que BEx Analyzer es mantenido por compatibilidad y ya no tendría mayor evolución.

SAP Crystal Reports Enterprise como herramienta de reporting operativo e impresión, en lugar de la versión clásica 2013 o 2011

Referencia: SAP.com

Notas para utilizar SAP BPC como fuente de datos en SAP BusinessObjects BI


Poco a poco va mejorando la conectividad entre SAP Business Planning and Consolidation (SAP BPC) y SAP BusinessObjects BI (BI4.*). En el documento de referencia se recopila la serie de notas SAP que explican cómo conectar componentes BI o diseñar universos BusinessObjects utilizando como fuentes datos a modelos BPC.

  • 1731626 – Connectivity options between various BusinessObjects BI tools and BPC
  • 1835142 – Cannot connect to BPC 7.5 from BI 4.0
  • 1613548 – How to troubleshoot the BPC ODBO driver connectivity issues
  • 1690965 – How to test ODBO connectivity on 64-bit editions of Windows
  • 1613532 – Error “Could not find provider BPCMDX.4″ when creating a Universe connection
  • 1797313 – Authentication error when creating an IDT connection to BPC 7.5 using XMLA
  • 1632820 – How to debug and trace Xcelsius dashboards connected to a web service
  • 1784015 – BPC MS: What are the required components for BPC and Xcelsius Integration
  • 1909019 – How to troubleshoot connectivty issues between BI and BPC data sources with Fiddler
  • 1709467 – Trouble shooting BPC ODBO / XMLA issues

Referencia: SAP Note 1835213

“Promover” objetos con LCM_CLI en BI4.*


En SAP BusinessObjects BI 4.* (BI4.1 o BI4.0), se conoce con el termino “Promover” a la acción de transportar o copiar los objetos de un entorno a otro, por ejemplo, de “Desarrollo” a “Producción”. Para este fin SAP Businessbjects BI 4.* incluyen la funcionalidad “Promotion Management”, la que en algún tiempo se denominó Lifecycle Management, de ahí que la iniciales LCM estén presentes en algunos componentes de esta herramienta.

Para “Promover” objetos tenemos la interfaz web, pero con la limitación que sólo podemos definir o configurar tareas (Jobs) con un máximo de 100 objetos, por otro lado, este proceso puede realizar comprobaciones de dependencias entre los objetos y con la seguridad definida, y según la complejidad de la implementación, esta tarea de comprobación podría interrumpirse si superase los 20 minutos que restringe el servidor de aplicaciones web para estos procesos.

LCM Command line interface (LCM_CLI) de BI4.1 y BI4.0

Debido a los dos posible contratiempos señalados en el párrafo anterior, existe “LCM Command Line Interface” (LCM_CLI.bat o lcm_cli.sh), una opción para promover gran cantidad de objetos entre plataformas SAP BI 4.1 o SAP BI 4.0. El uso de esta herramienta se recomienda en grandes implementaciones con una gran cantidad de objetos, su uso requiere una adecuada configuración, así como el seguimiento de algunas buenas práctica para evitar la pérdida de rendimiento o que el proceso no finalice o se interrumpa. Documentación reciente señala el uso de esta funcionalidad a partir de la actualización BI 4.1 SP02 o superiores, para lograr buena performance.

Referencia: SAP Note 1969259

Los sesgos en la toma de decisiones


En la toma de decisiones no basta un buen sistema de información, como señalamos en una entrada anterior, el adecuado control de nuestras emociones puede encaminarnos a decisiones más acertadas. Hay varios artículos sobre el proceso decisional, por ejemplo, en el artículo de referencia se señala cuatro “sesgos” en la toma de decisiones, para lo cual se mencionan sugerencias al respecto, esta publicación se basado en la teoría WRAP (acrónimo formado por las iniciales de las soluciones para evitar estos sesgos).

Los sesgos en la toma de decisiones son los siguientes:

  1. Los marcos estrechos. Son la tendencia común que tenemos al definir nuestras opciones de un modo demasiado acotado, con el fin de verlas en términos binarios. Por ejemplo, nos preguntamos: ¿Deberíamos hacer esto o esto otro? En lugar de platearnos de este modo una situación, deberíamos preguntarnos: ¿Hay alguna manera de hacer esto y esto otro? Con frecuencia nos encontramos atrapados en un marco estrecho en el que se destaca una alternativa a expensas de las otras.
  2. Sesgo de confirmación. Un hábito normal en nuestras vidas es desarrollar una creencia precipitada acerca de una situación y luego buscar información que refuerce esa creencia. Cuando la gente tiene la oportunidad de recopilar información, es más probable que seleccione aquella información que respalda su actitud, sus creencias y sus acciones preexistentes.
  3. Las emociones a corto plazo. Cuando debemos tomar una decisión difícil, nuestros sentimientos se agitan. Repetimos los mismos argumentos en nuestra cabeza. Nos desesperamos por nuestras circunstancias. Cambiamos de opinión de un día para otro… Levantamos tanta polvareda que no podemos ver el camino a seguir.
  4. El exceso de confianza. La gente cree saber más de lo que en realidad sabe sobre el futuro. Tenemos demasiada confianza en nuestras propias predicciones debido a que, centramos nuestra atención en la información que tenemos a mano, y luego sacamos conclusiones a partir de esa información.

Cómo contrarrestar nuestros sesgos

Un proceso normal de toma de decisiones, habitualmente se lleva a cabo en cuatro pasos, cada uno de estos pasos puede verse influenciada por algún sesgo. A continuación, se señalan estos pasos con la posible solución que evite la influencia de los sesgos:

  1. Nos encontramos con una elección. Pero un marco estrecho hace que no tengamos en cuenta algunas opciones. Sugerencia: Ampliemos nuestras opciones (Widen your options).
  2. Analizamos nuestras opciones. Pero el sesgo de información nos lleva a recopilar información interesada. Sugerencia: Pasemos nuestros supuestos por la prueba de la realidad (Reality-test your assumptions).
  3. Tomamos una decisión. Pero las emociones a corto plazo, a menudo, nos tentarán a tomar la decisión equivocada. Sugerencia: Tomemos distancia antes de decidir (Attain distance before deciding).
  4. Luego vivimos con ella. Pero, a menudo, confiaremos demasiado respecto a lo que deparará el futuro. Sugerencia: Preparemonos para estar equivocados (Prepare to be wrong).

Referencia:Harvrd Deusto (Nro. 232 – Marzo 2014)

Particionado de Tablas en SAP HANA (y III) – Buenas Prácticas


A continuación señalamos algunas buenas prácticas (best practices) al definir particiones en SAP HANA Database. Cabe señalar que para los objetos BW on SAP HANA, la técnica de particionamiento es distinta (ver entradas anteriores: aquí y aquí):

  • Sólo aplicar el particionado de tablas cuando sea necesario y se observa un beneficio claro de esta técnica. Una alta cantidad de particiones innecesarias ocasionaría una sobrecarga en el sistema al ejecutar consultas, al tener que acceder a múltiples particiones para encontrar los datos solicitados.
  • Si se particiona por el límite de tamaño de tabla de los dos mil millones de registros, es aceptable si el tamaño de las particiones contienen hasta los 500 millones de registros.
  • Si el criterio de partición es por fecha, se debe evitar utilizar criterios granulares tales como día o semana, dado que generaría un gran número de particiones.
  • Si se utiliza el tipo de partición RANGE sobre una columna cuyo contenido no se distribuye uniformemente, se deben verificar la distribución de sus valores reales para definir los límites de los rangos en consecuencia
  •  Utilizar el menor número de columnas para definir el criterio de particionamiento. En el caso del tipo de partición HASH, a menudo es útil emplear sólo la columna clave más selectiva, para que las solicitudes de datos que incluye esta columna sólo accedan a una partición.
  •  Las buenas prácticas de los documentos de referencia, señalan que las particiones de una misma tabla estén contenidas en el mismo host si es que se cuenta con una estrategia scale-out (despliegue/escalabilidad horizontal)
  • Si se va a reparticionar una tabla, para lograr mayor eficiencia, elija un número múltiplo o divisor del número de particiones con respecto al actual.
  • Evitar la definición de particiones con restricciones únicas adicionales, por ejemplo índices secundarios, dado que las verificaciones posteriores significarían una sobrecarga importante.

Particionado de Tablas en SAP HANA (II) – Tipos de Partición


Seguimos señalando las características básicas sobre el particionamiento de los datos en SAP HANA Database (ver entrada anterior)

Tipos de particionamiento

HASH. Los registros son asignados a particiones basados en un algoritmo hash, por lo que no se requiere un conocimiento profundo del contenido de la tabla (no hay una separación lógica de los datos). En la configuración de esta tipo de partición se debe indicar las columnas cuyos valores se utilizarán para determinar el valor hash. Si las tablas tienen columnas índices, estas deben ser utilizadas en este proceso. De fácil configuración, no requieren mantenimiento. Durante las consultas todas las particiones deben ser exploradas a menos que se indique explícitamente las particiones a consultar (parámetros “=” o “IN” de la cláusula “WHERE”).

ROUND-ROBIN. Se utiliza para lograr una distribución uniforme de los datos en las particiones, a diferencia del caso anterior, no es necesario especificar columnas para definir el criterio de este proceso. Los nuevos registros de van asignando rotativamente. Las tablas no deben tener claves primarias. Son de fáciles configuración, no requieren mantenimiento. En consultas, todas las particiones deben ser exploradas. No hay separación lógica de los datos.

RANGE. Los registros son asignados a particiones utilizando los rangos de particiones definidos. Es la única que define la asignación de particiones bajo un criterio lógico, en consecuencia, es la mejor vía para optimizar el acceso a los datos. Para una adecuada configuración, es necesario conocer los datos y sus aplicaciones. Es necesario un regular mantenimiento (p.e. para definir nuevas particiones o eliminar otras cuyos datos han sido archivados). Es necesario el uso de una clave principal. Sólo es aplicable para tipos de datos (cadenas, enteros y fechas).

Particionamiento multinivel en SAP HANA Database

Cualquier definición de partición utilizando uno de los métodos anteriores, dará lugar a un particionamiento simple (single-level partioning). Si cada partición es particionada nuevamente por otros criterios, estaríamos hablando un particionamiento multinivel (multi-level partitioning).

Particionado de Tablas en SAP HANA (I) – Definiciones


En ocasiones, los problemas de rendimiento de muchos sistemas de información pasan por una falta de particionamiento de los datos o una mala adopción de esta técnica, SAP HANA no es una excepción, a pesar de los grandes recursos disponibles que puede tener la plataforma in-memory de SAP, está medida en ocasiones es necesaria.

A continuación, una breve relación de respuestas a preguntas frecuentes sobre este tema en SAP HANA:

Que es el Particionado de tablas de datos

  • El particionamiento significa que las tablas son divididas en sub-tablas denominadas particiones según un criterio específico.
  • Sólo es aplicable en tablas con almacenamiento columnar (column store), en tablas con almacenamiento en filas (row store) no soportan particionamiento.
  • El particionamiento es transparente para que las aplicaciones funcionen correctamente. Sin embargo la partición puede tener un impacto en el rendimiento, positivo o negativo, que pueden percibir los usuarios en la carga de los sistemas, depende de la estrategia implementada.

Cuando Particionar las tablas de datos

  • Por lo general, el particionado es muy útil en tablas de gran tamaño, por otro lado, debe tener presente que las tablas columnares no pueden superar los dos mil millones de registros.
  • Además del procesamiento paralelo, en un despliegue scale-out (escalabilidad horizontal, uso de más de un host), en consultas complejas, accediendo a particiones distribuidas en distintos nodos, se obtendría un alto rendimiento, más no en consultas simples.
  • Si las tablas tienes conjuntos de datos de uso frecuente, y otros conjuntos de menos uso, deberían ser particionados según este criterio (partition prune).
  • Si una región de datos sólo es actualizada y la otra no, los procesos de actualización serán más eficientes.