Migración de Oracle SOA Suite a Oracle Integration 3: inventario, equivalencias y secuencia

Muchas organizaciones mantienen integraciones en Oracle SOA Suite que funcionan, pero cuyo costo de operación crece: servidores propios, parches, versiones de WebLogic y conocimiento concentrado en pocas personas. Oracle Integration 3 (OIC), un servicio administrado, elimina buena parte de esa carga de infraestructura. El beneficio, sin embargo, depende de tratar la migración como un proyecto de integración y no como una copia.

Este artículo propone un método en cuatro fases: inventario, clasificación por estilo, revisión de equivalencias técnicas y migración por oleadas. Los criterios son generales; cada instalación de SOA Suite tiene particularidades que deben verificarse en el inventario.

Inventario de la plataforma actual

La primera fase produce una lista completa de lo que existe: compuestos SOA, procesos BPEL y Mediator, y servicios de Oracle Service Bus. Para cada elemento se registra qué sistema inicia la integración, cuáles reciben datos, con qué frecuencia se ejecuta (en línea, programada o por archivo) y qué proceso de negocio depende de ella.

El inventario cumple una segunda función: identificar integraciones que ya nadie usa. Retirarlas antes de migrar reduce el alcance sin costo de construcción. Por eso conviene contrastar la lista con registros de ejecución recientes y con los responsables de negocio, en lugar de inferir el uso a partir del código.

Para cada integración vigente se documentan también su comportamiento ante fallas (qué ocurre y cómo se reprocesa) y sus dependencias de seguridad. Ambos aspectos son los que más difieren entre plataformas y los que menos aparecen en la documentación existente.

Clasificación según el estilo de Oracle Integration

Oracle Integration 3 organiza las integraciones por aquello que inicia su ejecución: Application, Schedule o Event, según la guía de estilos de integración. Asignar un estilo a cada elemento del inventario es la base de la estimación, porque cada estilo implica un diseño y unas pruebas distintas.

La clasificación permite agrupar integraciones parecidas y reutilizar entre ellas el diseño, las conexiones y los casos de prueba. Un proceso BPEL invocado por una aplicación suele corresponder a una integración Application; un proceso que consulta una base de datos cada noche, a una Schedule. Los casos que no encajan con claridad deben marcarse para revisión, no forzarse en una categoría.

Equivalencias técnicas: adaptadores, red, transformaciones y seguridad

OIC ofrece adaptadores para aplicaciones de Oracle y de terceros, bases de datos, transferencia de archivos y servicios REST y SOAP; el catálogo oficial de adaptadores es la referencia. Para cada integración debe confirmarse que existe un adaptador adecuado o definirse la alternativa, típicamente una llamada REST o SOAP genérica.

Los sistemas que permanecen dentro de la red corporativa se alcanzan mediante el Connectivity Agent, que se instala en un servidor propio e inicia la comunicación hacia OIC con solicitudes salientes. Su ubicación, su salida a internet y su disponibilidad son decisiones de arquitectura de la primera fase, no detalles de la construcción.

Las transformaciones XSLT existentes son un activo, pero no se trasladan de forma automática: cada una debe revisarse, y las que dependen de funciones propias de la plataforma SOA requieren rediseño. Con la seguridad ocurre algo similar. Las políticas de Oracle Web Services Manager no tienen una correspondencia directa, por lo que cada conexión necesita un esquema de autenticación definido en OIC (OAuth, certificados o usuario técnico) y un responsable de sus credenciales, según los patrones de autenticación del REST Adapter.

El manejo de errores es la equivalencia que más se subestima. El comportamiento documentado en la fase de inventario debe reproducirse con los mecanismos de OIC, descritos en About Error Management. Una integración migrada que funciona en el caso normal pero no se puede reprocesar ante una falla no está terminada.

Migración por oleadas

Una secuencia que reduce el riesgo comienza con una integración sencilla, cuyo propósito es validar en todo su recorrido la conectividad, la seguridad y el monitoreo. Le siguen grupos de integraciones con el mismo estilo y, al final, las integraciones críticas, cada una con un periodo de operación en paralelo y un plan de vuelta atrás.

El periodo en paralelo requiere un criterio de comparación definido de antemano: qué resultados deben coincidir entre la versión SOA y la versión OIC, y durante cuánto tiempo. Sin ese criterio, el paralelo se prolonga sin una decisión clara de corte.

La migración concluye cuando se apaga el último servidor de SOA Suite. Mientras haya integraciones en ambas plataformas, la organización paga la operación de las dos, y el plan debe tener una fecha objetivo para ese apagado.

Primer entregable y criterios de decisión

El primer entregable útil de una migración es el inventario clasificado, con una estimación por grupo y las equivalencias pendientes de resolver. Con ese documento se decide el orden y el alcance con información verificable.

• Inventario completo, contrastado con registros de ejecución y responsables de negocio.
• Integraciones en desuso identificadas y aprobadas para retiro.
• Estilo de OIC asignado a cada integración, con los casos dudosos señalados.
• Adaptador o alternativa definida por conexión, y ubicación del Connectivity Agent decidida.
• Esquema de autenticación y responsable de credenciales por conexión.
• Comportamiento ante fallas documentado y criterio de paralelo definido para las integraciones críticas.

Xterra Engine elabora inventarios y planes de migración de SOA Suite a Oracle Integration, con la clasificación y las equivalencias resueltas antes de construir.