El uso de CPUs y las licencias de SAP BusinessObjects BI

El sistema de licenciamiento de SAP BusinessObjects BI no es nada exacto o uniforme, todo depende según las necesidades del cliente. Las licencias del uso de CPU, en teoría, responden a los siguientes criterios:


El sistema de licenciamiento de SAP BusinessObjects BI no es nada exacto o uniforme, todo depende según las necesidades del cliente (ver entrada anterior). Las licencias del uso de CPU, en teoría, responden a los siguientes criterios:

  • Cada CPU core de un host SAP BI requiere una licencia.
  • El primer CPU core requiere una licencia de CPU. Cada core del mismo CPU requiere un 0.5 de licencia.
  • Si el resultado del cálculo no es número entero, este deberá redondearse.
  • En teoría, SAP no impone limitaciones en el uso de CPUs, la contratación de licencias necesarias es una formalización que debe realizarse.

Por ejemplo, para una instalación de un host con dual CPU quad-core, el cálculo de licencias de CPU sería el siguiente:

1 Server x 2 CPUs x (1 + 0.5 + 0.5 + 0.5) = 5 Licencias de CPU

Pero bueno, cada caso tiene un tratamiento particular, la última palabra la tendrá SAP.

Referencias: Notas SAP 1285639 y 1344387

Licencias de SAP BusinessObjects BI, tan diverso y difuso como clientes pudiesen existir

Difícilmente encontraremos dos clientes que hayan pagado lo mismo por un producto SAP y mucho menos probable si de SAP BusinessObjects BI hablamos. SAP podría decir en su descargo que responde a las necesidades singulares de cada cliente,… Pero bueno, sea cual fuera el motivo, en el sistema de licenciamiento de SAP BO BI entran en juego las siguientes variables:


Difícilmente encontraremos dos clientes que hayan pagado lo mismo por un producto SAP y mucho menos probable si de SAP BusinessObjects BI hablamos.  SAP podría decir en su descargo que responde a las necesidades singulares de cada cliente,… Pero bueno, sea cual fuera el motivo, en el sistema de licenciamiento de SAP BO BI entran en juego las siguientes variables:

  • Usuarios nominales (Named user license).  La licencia determina un número máximo de usuarios que se pueden definir en la plataforma.
  • Licencia por concurrencia (Concurrent license).  Determina el número de sesiones que se pueden conectar simultáneamente. Un usuario puede consumir más de una sesión, por ejemplo un usuario puede estar conectado vía navegador Web y la aplicación mobile de SAPBI.
  • Licencia por CPU (CPU License).  Determina el número máximo de CPUs (cores) que se podrían utilizar en un BusinessObjects Server Enterprise.

Como propuesta de licencia podemos recibir una basada en alguna de estas variables, generalmente en función de la tercera combinada con cualquiera de los dos primeras variables.

Referencia: SAP Note 1285639

¿Mayores causas de pérdida de rendimiento en BPC 10.0 que en BPC 7.5?

Comparando las guías de Sizing o dimensionamiento de las necesidades de hardware de SAP Business Planning and Consolidation NW (SAPBPC NW) de las versiones 7.5 y 10.0, vemos un aumento considerable de las posibles causas de pérdida de rendimiento en la última versión.


Comparando las guías de Sizing o dimensionamiento de las necesidades de hardware de SAP Business Planning and Consolidation NW (SAPBPC NW) de las versiones 7.5 y 10.0, vemos un aumento considerable de las posibles causas de pérdida de rendimiento en la última versión.

Factores que influyen en la pérdida de rendimiento en SAP BPC 7.5 NW

No creemos que se deba a un aumento de complejidad de BPC, más pensamos que SAP ha aprendido de la experiencia y señala casi absolutamente todo como posible causante de pérdida de rendimiento.

Factores que influyen en la pérdida de rendimiento en SAP BPC 10.0 NW

Nuestra sugerencia es que se debe tener en cuenta, desde el punto de partida, que BPC es una herramienta transaccional ´para las tareas relacionadas a la planificación y consolidación financiera.  Si se desea analizar grandes volúmenes de información,  SAP BPC no es la herramienta analítica que cubrirá tus expectativas, quizás, además de BPC, deberías pensar en SAP BusinessObjects BI.

Actualizaciones 4.0 y 4.1 de SAP BI, un dolor de cabeza para los usuarios

Utilizar la última versión delos productos no siempre es posible y algunas veces no resulta recomendable si se pierde funcionalidades implementadas o compatibilidad con otros productos. SAP BusinessObjects BI tiene actualmente dos versiones de la era 4.*, la 4.0 y la 4.1,


Utilizar la última versión delos productos no siempre es posible y algunas veces no resulta recomendable si se pierde funcionalidades implementadas o compatibilidad con otros productos.  SAP BusinessObjects BI tiene actualmente dos versiones de la era  4.*, la 4.0 y la 4.1, cada una con un planning de actualizaciones independiente. A continuación compartimos las próximas fechas en que se liberarán actualizaciones del tipo Service Pack y actualizaciones de menor nivel, denominadas Patchs.

Progrma de mantenimiento de productos SAP BI, Analytics y Data Services(doble clic para ampliar)

 

Expectativas de los usuarios en la monitorización de un sistema

Una implementación de una solución informática no culmina con el denominado “pase a producción” y menos aún, todo lo hecho, será “para siempre”. No hay deseo más absurdo, tanto para las personas como para los sistemas, aquel que se repite sin meditar: “nunca cambies”. La maduración y evolución son indispensables en un sistema para que siempre cubra las expectativas y necesidades de los usuarios. Expectativas y necesidades que variarán en el tiempo porque los entornos evolucionan constantemente.


Una implementación de una solución informática no culmina con el denominado “pase a producción” y menos aún, todo lo hecho, será “para siempre”. La maduración y evolución son indispensables en un sistema para que siempre cubra las expectativas y necesidades de los usuarios.  Expectativas y necesidades que variarán en el tiempo porque los entornos evolucionan constantemente.

Expectativas de los usuarios en la monitorización de los sistemas informáticos

Para encaminar la maduración de un sistema se debe contar con un plan de monitorización y optimización, calendarizado por diferentes períodos de tiempo, plan que no tan sólo cubra el aspecto técnico, sino que también contemple los feedbacks funcionales.

El gran objetivo es cubrir, constantemente, las expectativas de los usuarios, las cuales podrían circunscribirse en las siguientes categorías:

  • Disponibilidad. Asegurar la accesibilidad cuando se lo necesite, garantizando la comunicación entre los componentes y controlando que las aplicaciones no produzca errores graves que impidan las entradas o consultas de datos.
  • Rendimiento. Se debe controlar tanto en la introducción de datos como la ejecución de los procesos en segundo plano. Cada uno de estos dos aspectos requiere un control por separado.
  • Integridad.  Asegurar la integridad de datos, la cual puede perderse por errores en la conexiones, fallos en el hardware o redes, software desactualizado, etc.  Así mismo se debe contemplar un plan de recuperación ante fallos y copias de seguridad.
  • Seguridad. Brindar garantías que las personas indicadas accedan a los datos de su responsabilidad para realizar las tareas que le corresponden. Informar y auditar.