Solución de problemas de red en una plataforma SAP HANA


Si se percibe un problema de rendimiento en una plataforma SAP HANA, identificándose aumento de tiempos de acceso a los datos, quizás el problema no este centrado en SAP HANA sino en la red. SAP señala las causas que originarían problemas en la red y las acciones que podríamos realizar para comprobar y superar estos inconvenientes. Esta información, contenida en la nota 2081065, es aplicable a instalaciones SAP HANA SPS 08 (Revisión 80 – SPS = Support Package Stack) o con actualizaciones superiores.

Los aspectos que intervienen en el rendimiento de red, son los siguientes:

  • Latencia. Es el tiempo que tarda un paquete de cruzar una conexión de red, del emisor a receptor.
  • Ancho de banda (Bandwidth). Se refiere a la cantidad de datos que se puede llevar de un punto a otro en un período de tiempo (bps).
  • Pérdida de paquetes (Packet loss). Se refiere al fallo de uno o más paquetes transmitidos para llegar a su destino. De producirse, ocasionaría que el punto origen debería retransmitir el dato, percibiendo el usuario final un mal desempeño y retrasos.

Los problemas en la red, podrían repercutir en los siguientes aspectos en una instalación SAP HANA:

  • Comunicación entre los host SAP HANA (arquitectura Scale out u horizontal).
  • Comunicación entre SAP HANA Database y las aplicaciones cliente.
  • Replicación de base de datos SAP HANA.

Para encontrar las posibles soluciones a estos inconvenientes sugerimos la revisión de la nota de referencia.

Referencia: SAP Note 2081065

Controlar el tamaño de la fuente al exportar informes Crystal Reports


Los planes que tiene SAP para simplificar los componentes que conforman en su portfolio de herramientas de Business Intelligence (SAP BusinessObjects BI) incluye la sugerencia de utilizar Crystal Reports for Enterprise en lugar de las ediciones 2013, 2011 y 2008 de Crystal Reports. Pero sin embargo, son muchas las implementaciones y usuarios fieles a las ediciones clásicas de la herramienta de reporting operativo.

Si eres usuario de esta herramienta y al exportar estos informes en formato RTF o Word y se observa que el tamaño de la fuente no es igual al utilizado en el informe original, la aplicación del siguiente procedimiento podría evitar este comportamiento:

Crystal Reports, controlar el tamaño de la fuente de las letras en la exportación

Referencia: Nota SAP 1810847

Comprobación de una instalación SAP BPC


Al finalizar una instalación de SAP BPC (SAP Business Planning and Consolidation) nos puede surgir la inquietud si ha sido realizada correctamente, por experiencia, podemos señalar que esta preocupación no sería infundada, porque podría ocasionar importantes contratiempos. Para detectar oportunamente cualquier potencial problema podríamos, simular tareas básicas como las siguientes:

  • Copiar y eliminar un environment
  • Copiar, eliminar y crear una dimensión
  • Agregar, modificar y eliminar miembros de dimensión
  • Diseñar un formulario de entrada en el EPM Add-in,
  • Agregar datos transaccionales,
  • Diseñar un informe EPM Add-in

Estas y otras tareas podrían ayudar, pero quizás podríamos considerar iniciar estas comprobaciones cerciorándonos si se han aplicado las indicaciones post-instalación que señala la documentación del producto. SAP afirma que algunos errores reportados son originados porque no se ha seguido rigurosamente el proceso de instalación. En la nota 2069510 se destaca los “olvidos” más comunes:

  • BI Content no activado.
  • Perfiles de autorización ABAP no han sido activados.
  • Conexiones RFC no definidos o con configuración incorrecta.
  • Usuario BPC Service no se ha creado o sin perfiles de autorización.
  • Environment básico (ENVIRONMENTSHELL) no ha sido activado correctamente o ha sido activado antes del BI Content o de los perfiles básicos.

Aun todo esto, no podremos asegurar que no habrán “sorpresas”, porque estas se puede encontrar por aplicar una reciente actualización o seguir un procedimiento poco habitual al utilizar alguna funcionalidad, pero seguro que no reportaremos una incidencia conocida.

Quién es Quién 2014, (Consultoría e Informática) – 2da. edición


En mayo compartíamos el extracto sobre los rubros Informática y Consultoría del directorio de empresas “Quién es Quién” del Diario Expansión y la revista Actualidad Económica, hoy compartimos una segunda edición de este informe.

Destacamos de esta edición el reclamo de la Asociación Española de Consultoría (AEC) que señala que para que la consultoría se siga potenciando y continúe contribuyendo al desarrollo de las organizaciones, es necesaria una normativa adecuada que propicie la calidad de los servicios y la consolidación del empleo en las empresas de consultoría tecnológica.

Referencia: (aquí)

Sobre las actualizaciones de SAP HANA


Las actualizaciones del software de SAP HANA son liberadas bajo dos modalidades o categorías que difieren en su denominación con respecto a otros productos SAP a los que estamos más habituados. Estos paquetes de actualización se denominan Support Package Stacks (SPS) y Revisions.

 Los SPS son las actualizaciones principales de SAP HANA los cuales incluyen nuevas funcionalidades y significativos cambios. Las Revisiones son parches al software con el fin de corregir errores o brindar pequeñas mejoras. En ambos casos, SAP recalca que los cambios y mejoras no son disruptivos. Comparando el sistema de actualización del software de SAP HANA con SAP BusinessObjects BI (BI4), podríamos señalar que los SPS de HANA equivalen a los SP de BI4 (Support Pack) y una “Revision” equivale a un ”Patch”.

Revisones y SPSs de sistema de actualización del Software de SAP HANA y sus componentes

No hay un ciclo definido de liberación de las actualizaciones del software de SAP HANA, pero se estiman dos actualizaciones del tipo SPS al año, y usualmente una antes de mayo y la otra antes de noviembre, aproximadamente. Meses después de la liberación de un paquete, SAP podría finalizar el ciclo de vida de una actualización anterior, por lo que la aplicación de las actualizaciones no debería postergarse demasiado.

SAP HANA Revision (Ref 1948334)

En cuanto a las “Revisions”, también denominadas Support Package (SP), se liberan sin seguir ningún patrón de frecuencia, son publicadas cuando SAP lo vea necesario. Hay dos tipos de revisiones: “SAP HANA Datacenter Service Points”, revisiones comprobadas en los sistemas de producción de SAP y “SAP HANA Maintenance Revisions” las cuales pueden contener un mayor número de corrección de errores pero suelen basarse en SPS antiguos, por ejemplo, revisiones en base al código del SPS 07 cuando ya se ha liberado el SPS 08.

“SAP HANA System Replication” no es lo mismo que “SAP HANA LT Replication Server”


En cada actualización de SAP HANA, además de nuevas funcionalidades también va madurando y mejorando los aspectos de seguridad dad y estabilidad del dato. Con respecto a la alta disponibilidad (High Availability) y Recuperación ante desastres (Disaster Recovery), SAP HANA brinda un sistema de replicación, denominado SAP HANA System Replication.

Esquema general de un sistema de replicación Single Nodes

SAP HANA System Replication ofrece la posibilidad de copiar y sincronizar continuamente una base de datos HANA a una ubicación secundaria, en el mismo u otro data center. Por el nombre de esta técnica se podría confundir con SAP HANA LT Replication Server (SLT. LT = Landscape Transformation), técnica que permite cargar datos desde sistemas ABAP y no ABAP a SAP HANA Database.

Consideraciones un sistema de replicación en SAP HANA Database:

  • Tanto el sistema primario como el secundario deben estar en funcionamiento, independientes y deben tener igual número de nodos activos.
  • Toda la configuración se realiza en nodo maestro.
  • La versión y actualización del sistema secundario debe ser igual o superior al del sistema primario.
  • El sistema secundario debe tener el mismo SID y número de instancia del sistema principal.
  • Los cambios en ficheros INI en un sistema deben ser efectuados en el otro sistema de manera manual.
  • Se recomienda realizar una copia de seguridad antes de activar el sistema de replicación
  • Es posible que el sistema secundario tenga un fin propio de un entorno de desarrollo o pruebas, mientras que el primario sea un entorno de producción. Si este fuera el caso, se debe tener en cuenta que el 10% de los recursos del sistema secundario se dedican al sistema de replicación.
  • La distancia entre los data centers determinará el métodos de replicación que se utilice.

Modos de replicasión en SAP HANA hasta SPS 08Referencia: SAP Note 1999880

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