Blog

Migración a SAP PO 7.5 ¿Riesgo u oportunidad?

[fa icon="calendar"] 13/12/2018 por Xavier San Sebastián

Xavier San Sebastián

Migracion-a-SAP-PO-7.5

A finales del 2020 dejan de tener soporte las instalaciones de SAP Netweaver  desde la 7.1 a la 7.4, tanto para ABAP como Java, sin la posibilidad de tener mantenimiento extendido (sapnote 1648480). Es por ello que una de las actividades a realizar dentro del roadmap de operaciones / infraestructura es migrar nuestros sistemas PI / PO a un entorno 7.5 teniendo en cuenta que  ya no soporta dual stack.

Descargar Optimiza tus costes de SAP en AWS en 5 pasos

Nuevas funcionalidades de SAP PO 7.5

Antes de nada, veamos que nos ofrece de nuevo SAP PO y en que puntos puede ser una oportunidad:

  • Al ser Single Stack el procesamiento de mensajes es mucho más alto permitiendo aumentar la capacidad de envíos de mensajes por hora sin necesidad de aumentar recursos. Esto es debido a que hasta ahora los mensajes se grababan tanto en la BBDD de ABAP como en la de Java, envío entre ambas instancias vía http / jco.
  • Herramientas de monitorización centralizadas en un único punto, evitando tener que revisar SM58, SMQ2, SXI_MONITOR, etc.
  • Alertas mejoradas pudiendo incluso filtrar por contenido de mensaje
  • Soporte con HANA / HANA2
  • Evolución de los conectores con las necesidades del mercado
  • Disponibilidad de NW BPM para realizar flujos hombre-máquina usando SAP Fiori dando soporte tanto para ordenadores, tablets, teléfonos
  • Uso de Java 1.8
  • Más flexibilidad y facilidad para optimizar el rendimiento del sistema
  • Simplificación en las operaciones de mantenimiento
  • Posibilidad de uso de escenarios pre-paquetizados del cloud
  • Uso de NWDS y de iFlows

 

¿Cuáles deben ser los pasos a seguir?

Hay que ver en que modalidades podemos instalar nuestro SAP PO y a nivel de arquitectura que podemos realizar para mejorar.

 

Modalidades de Instalación de SAP PO 7.5

Por un lado, al dejar de existir ya el dual stack tenemos varias opciones, siendo las más usadas:

  • Realizar un dual split
  • Instalación nueva y migrar las integraciones: fresh install 

 

Dual Split

Implica separar los stacks en instalaciones separadas, cada uno con un SID propio. Esta opción debería solamente usarse en aquellos casos con un gran número de integraciones con ccBPMs y Abap-Mappings.  En este caso no habría que adaptar ningún desarrollo con lo que el impacto a nivel de equipo de desarrollo sería prácticamente nulo.

En cambio, al añadir un stack de ABAP implica más costes tanto de infraestructura como de mantenimiento operacional y a nivel de solución nos limita las ventajas que nos ofrecería una instalación Java standalone.

 migration-to-SAP-PO-7.5

Fuente: Linke

 

Fresh Install

Otra opción sería una instalación nueva single stack y migrar las integraciones. Esta es la opción que va alineada con la estrategia de SAP. Hay que tener en cuenta que para migrar las instalaciones de un sistema a otro SAP PO dispone de la herramienta Migration Tool for Integration Directory Objects que permite realizar el volcado de los escenarios dual stack a single stack. Teniendo en cuenta el cambio de adaptadores de abap proxy y idocs de stack abap a su equivalente en el stack Java.

Sin embargo, esta opción nos limita en el hecho de que no es compatible con abap mappings ni con ccBPMs con lo que  en el caso de que dispongamos de integraciones que usen será necesario hacer un refactoring de estas integraciones con NWBPM o buscar otra alternativa. Hay que tener en cuenta que en muchas ccBPMs, su uso es para satisfacer patrones de integración que hoy en día ya están soportados en SAP PO con lo cual el coste a priori no debería ser muy elevado.

 

Mejoras a nivel de Arquitectura

Aprovechando la migración es un buen momento para plantearse un upgrade de la arquitectura siguiendo una serie de recomendaciones:

  • Redimensionar máquina
  • Agregar nodos por instancia
  • Clusterizar el servidor
  • DR ya sea con Backup Restore / Hana Replication
  • Reestructuración del SLD / Sincronización
  • Poner un balanceador como Webdispatcher por delante de la instancia

Con todo ello, el esquema de nuestra nueva instalación podría ser el siguiente:

 migration-to-SAP-PO-7.5-linke

 

Fuente: Linke

 En el caso de que se hiciera una migración por fases en entornos AWS, el entorno de origen podría ir reduciendo su tamaño conforme se fuesen liberando integraciones, disminuyendo así el consumo de créditos. Esta acción por eso necesitaría de una ventana de unos 30 minutos para reiniciar la instancia EC2.

 

¿Es esta migración un riesgo para el negocio?

La respuesta es no. Por lo anteriormente comentado creemos que es una oportunidad para realizar una mejora en el sistema, tanto a nivel de procesos como de robustez y seguridad. Al disponer de los sistemas de origen y destino, se puede realizar un cambio de servidor totalmente transparente y por fases / escenarios. Asegurando así una transición controlada y éxitosa hacia la nueva plataforma de integración de nuestro negocio.

 

Quizás te interese este ebook gratuito en PDF:

Linke SAP en AWS

Categorías: SAP

Xavier San Sebastián

Escrito por Xavier San Sebastián

SAP Integration Consultant at Linke

¡Suscríbete al blog!

Linke SAP en AWS
Descarga la Guía de Pricing de SAP en AWS
Descarga la guía: Todo lo que necesitas saber sobre SAP en AWS
Guia HD & DR para SAP en AWS