Cómo tomar la decisión de actualizar: SAP PI frente a CPI
Con SAP finalizando el soporte para la mayoría de las versiones de PI excepto la 7.5 a finales de 2020, los clientes de las versiones 7.31 y 7.4 se enfrentan a una elección crucial. En el debate SAP PI frente a CPI, decidir si actualizar a SAP PI 7.5 o pasar a la nube con SAP CPI implica considerar el impacto económico de las licencias y el uso. La concesión de licencias para SAP CPI suele ser más sencilla, lo que la convierte en una opción transparente para los clientes. Nuestra simulación con el paquete Integration Suite ofrece una idea más clara de los costes basada en bloques de mensajes, lo que ayuda en este proceso crítico de toma de decisiones.
Análisis económico de licencias
Las consideraciones económicas siempre subyacen a la decisión entre las diferentes herramientas de middleware y los costes de licencia. Los clientes deben evaluar el impacto financiero de sus elecciones en el uso de middleware.
El sistema de licencias de PO era complejo e implicaba tres parámetros: número de procesadores, volumen de transacciones y, anteriormente, recuento de usuarios. Esta complejidad suele ocultar el coste total, cómo se cobra y cuál es la mejor opción de licencia.
El coste de las licencias de SAP PI 7.5 debería ser similar al de las versiones anteriores, como 7.31/7.4. El coste puede aumentar si se opta por las licencias de SAP PI 7.5 o SAP PO 7.5, que incluyen BPM y BRM.
SAP CPI ofrece cálculos de licencias más sencillos, un paso significativo de SAP hacia una mayor transparencia sobre los costes de los productos con sus clientes. Este paso marca un claro cambio en su enfoque.
En nuestro análisis con el paquete Integration Suite, realizamos una simulación para comprender mejor los costes de las licencias SAP CPI.
https://www.sap.com/products/cloud-platform/pricing/estimator-tool.html
El precio de los mensajes en bloque es decreciente dependiendo de cuántos mensajes adicionales estés comprando con un rango entre 7,00 EUR para los primeros 50 bloques (Un bloque son 10K mensajes) y decreciendo a 2,80 EUR para los bloques cuando consigas más de 25000 bloques.
Por supuesto, los clientes pueden obtener mejores precios si hablan con sus socios distribuidores de SAP.
Coste/esfuerzo de aplicación
El enfoque de implementación es completamente diferente entre continuar con SAP PI y decidir innovar con SAP Cloud Platform Integration.
Si decidimos continuar con SAP PI 7.5, por ahora, tendremos tiempo suficiente para migrar a la nube en futuras versiones. Eventualmente, SAP CPI soportará una forma más fácil de migrar y no requerirá un proceso de reingeniería para transformar nuestras integraciones on-premise en integraciones Cloud.
Veamos a qué escenarios podemos enfrentarnos en ambas actualizaciones:
A SAP PI/PO 7.5
La migración a SAP PI/PO 7.5 implica principalmente actualizaciones técnicas, con una necesidad mínima de reconstrucción de la interfaz, a pesar de las diferencias con versiones anteriores como 7.31 o 7.4.
SAP PI/PO 7.5 funciona únicamente con una única pila Java. Para mantener una pila ABAP, se hace necesaria una instalación separada.
La utilización de una única pila en SAP PI/PO 7.5 reduce significativamente el uso de recursos del sistema, lo que permite mejorar el rendimiento o reducir el tamaño para ahorrar costes, especialmente en grandes implantaciones.
El abandono de la doble pila exige convertir las interfaces basadas en ccBPM en soluciones BPM, lo que ofrece la oportunidad de reevaluar y, potencialmente, innovar las estrategias de implantación.
Es esencial garantizar que nuestras UDF, asignaciones Java y módulos adaptadores sean compatibles con Java 1.8, ya que la mayoría de las adaptaciones implican actualizaciones de componentes obsoletos.
Este proyecto requiere una consultoría funcional mínima, ya que la lógica de mapeo permanece inalterada. Basta con una prueba de regresión exhaustiva posterior a la verificación de la conectividad.
Consideramos esta migración como un paso estratégico hacia la adopción de la nube, por lo que instamos a los clientes a convertir las configuraciones de Integration Builder en Iflows para facilitar la futura migración a la nube. Ignorar este paso solo retrasa las inevitables complejidades de la transición a la nube.
Para los clientes con interfaces ABAP, sugerimos la transición a Graphical Mappings, Java Mappings o XSLT. Otra opción es instalar una pila ABAP independiente, pero nosotros abogamos por modernizar las prácticas de integración.
A SAP CPI
Hoy en día la migración de interfaces existentes en SAP PI a SAP CPI es posible pero tiene muchas limitaciones.
La primera aproximación debería ser tener Iflows para sus interfaces SAP PI que la mayoría de los clientes que están ejecutando 7.31 o 7.4 no tienen, también desafortunadamente, hay muchos clientes que no usan Iflows en su 7.5. Pero este problema es fácil de resolver, ya que podemos importar los objetos ESR y crear los Iflows en SAP CPI.
Los mayores problemas son todas las funcionalidades no soportadas en SAP CPI. Analicémoslas objeto por objeto:
- Mapeo Gráfico: Existe una gran limitación con los UDFs de Java, ya que no son compatibles con SAP CPI en este momento, por lo que tendremos que reconstruir los mapeos que contienen UDFs en otros nuevos utilizando el script Groovy.
Vemos esta limitación como uno de los principales obstáculos en la migración completa de SAP PI a CPI, pero según nuestras conversaciones con SAP, la migración completa de Message Mappings con UDF estará disponible a finales de 2021.
- Mapeo Java: Necesitamos incrustar la llamada al JM en el script Groovy, para ello necesitamos ajustar la ejecución del JM, cambiando los parámetros InputStream y OutputStream a tipo String.
He aquí un interesante blog sobre este tema. Enlace
Según las conversaciones que hemos mantenido con SAP, parece que a finales de 2021 CPI dispondrá de Mappings Java nativos.
- Transformaciones XSL: Ningún problema, funcionan como en SAP PI
Problemas adicionales que vemos:
- Proxies ABAP, utilizados en SAP PI, no son soportados de la misma manera en SAP CPI. Existe una solución alternativa en la que los servicios se consumen o publican a través de SE80. Sin embargo, este método renuncia a ventajas como la generación automática de proxy en SPROXY y la creación de estructuras en el diccionario ABAP. SAP pretende solucionar esta limitación para finales de 2021.
- Módulos adaptadores estándar de SAP y las de terceros o personalizadas son incompatibles con SAP CPI. Aunque algunas funcionalidades puedan encontrar alternativas en SAP CPI, no se aplicará universalmente. En los casos en los que se deba replicar la funcionalidad de SAP PI, puede ser necesario desarrollar conectores personalizados.
Conclusión
Creemos que es prematuro para una migración a la nube. Estamos impacientes por ver las mejoras de CPI de SAP en 2021, destinadas a simplificar los proyectos de migración.
Recuerde que es posible ejecutar ambos sistemas simultáneamente. Para los nuevos proyectos, considere SAP CPI, y conserve SAP PI para las integraciones personalizadas.
La filosofía de CPI es intrigante, ya que ofrece contenidos preconfigurados para integraciones más sencillas. Algunos ejemplos son las integraciones con agencias tributarias y plataformas como Success Factors, Concur y Ariba, en constante expansión.
Para prepararse para futuras integraciones sin mayores riesgos, aconsejamos actualizar a SAP PI 7.5 y empezar a experimentar con SAP CPI.
Si necesita Actualizar su SAP PI a SAP PI/PO 7.5 o quiere empezar a utilizar SAP CPI no dude en Contacto (info@code10it.com)
