Saber cuáles son los patrones de integración de SAP disponibles es una cosa. Saber cuál es el adecuado para un escenario específico es otra.

La mayoría de los problemas de la arquitectura de integración no surgen del desconocimiento de las opciones, sino de la aplicación de una opción familiar o conveniente a una situación para la que no fue diseñada.

Esta publicación proporciona un marco estructurado para tomar esa decisión deliberadamente. Cubre cinco preguntas que, cuando se resuelven en orden, eliminan la mayoría de las opciones incorrectas antes de llegar a una comparación de herramientas o una decisión de configuración. También incluye una tabla de comparación de patrones para una referencia rápida y una descripción general de la Metodología de asesoramiento de soluciones de integración (ISA-M) de SAP para organizaciones que trabajan a nivel de paisaje en lugar de a nivel de escenario individual.

Esta es la tercera publicación de una serie sobre patrones de integración de SAP. La primera Cubre qué son los patrones de integración y por qué la elección conlleva consecuencias posteriores.. el segundo cataloga la gama de patrones disponibles en los entornos SAP actuales. Si ya está familiarizado con las opciones de patrones y está listo para evaluarlas en un escenario específico, aquí es por donde comenzar.

Un marco de decisión para la selección de patrones

Ninguna decisión de integración existe de forma aislada. Cada uno de los patrones tratados anteriormente tiene casos de uso legítimos y la mayoría de ellos tienen escenarios en los que claramente son la elección equivocada. Lo que marca la diferencia no es la familiaridad con las opciones sino una forma estructurada de evaluarlas frente al escenario específico en cuestión. El siguiente marco no reemplaza el juicio arquitectónico sino que lo organiza. Resuelva estas cinco preguntas en orden antes de evaluar cualquier patrón o herramienta específica.

5 preguntas que debes hacerte antes de elegir un patrón

1. ¿Cuál es el desencadenante? La naturaleza del desencadenante es la característica más fundamental de un escenario de integración y se relaciona directamente con la división proceso/datos. Un evento empresarial apunta hacia patrones de integración de procesos. Un cronograma apunta hacia patrones de integración de datos. Una acción del usuario en una interfaz de usuario apunta hacia una integración sincrónica basada en API de solicitud/respuesta. Un cambio de datos detectado en el nivel de la base de datos apunta hacia una extracción basada en CDS o patrones controlados por eventos. Obtener esta respuesta incorrecta se refleja en cada decisión posterior.
2. ¿Cuál es el volumen y la frecuencia de los datos? Un único registro transaccional intercambiado en tiempo real tiene requisitos de infraestructura completamente diferentes a los de un millón de registros extraídos cada noche o un flujo continuo de eventos de IoT. Los escenarios de lotes poco frecuentes y de gran volumen favorecen los patrones de replicación de datos con extracción completa o delta. Los escenarios transaccionales de bajo volumen y alta frecuencia favorecen los patrones basados ​​en API o en mensajes. Los flujos continuos de gran volumen favorecen la arquitectura basada en eventos con un corredor como SAP Event Mesh. Aplicar un patrón diseñado para un perfil de volumen a un escenario con otro diferente es una de las formas más confiables de producir una integración que funcione en desarrollo y falle en producción.
3. ¿Cuáles son los requisitos de latencia? Aquí es donde la dimensión de tiempo sincrónico/asincrónico entra en la decisión. Si el sistema emisor necesita una respuesta inmediata, la integración debe ser sincrónica y el patrón debe admitir eso. Si el remitente puede enviar un mensaje y continuar sin esperar confirmación, los patrones asincrónicos estarán disponibles y, a menudo, serán preferibles, ya que reducen el acoplamiento y mejoran la resiliencia. El error a evitar es asumir que asíncrono siempre es más escalable y por tanto siempre mejor. En escenarios con requisitos genuinos de confirmación en tiempo real, un patrón asincrónico no escala mejor: falla de manera diferente.
4. ¿Cuál es su modelo de implementación? El modelo de implementación no es sólo un contexto técnico. Restringe activamente qué patrones están disponibles. SAP Cloud ERP elimina por completo la integración basada en IDOC. Los entornos locales admiten toda la gama de patrones, pero conllevan la consideración adicional de que SAP Process Orchestration se acerca al final de la fecha límite de mantenimiento. Los paisajes híbridos requieren un pensamiento de patrones compuestos, ya que los lados local y en la nube de la misma integración pueden necesitar diferentes enfoques conectados a través de una capa de traducción. Esta pregunta debe responderse antes de que comience la evaluación del patrón, no descubrirse durante la implementación.
5. ¿Quién es el propietario del sistema receptor? La propiedad y la naturaleza del sistema objetivo conlleva implicaciones de protocolo directas. La integración de SAP a SAP dentro de un panorama administrado abre la gama completa de opciones de integración nativa de SAP. La integración de SAP a terceros normalmente requiere OData o REST, ya que los sistemas de terceros no hablan IDoc ni RFC. La integración de SAP con socios externos (proveedores, clientes, proveedores de logística) a menudo implica estándares EDI y protocolos B2B, que es donde las capacidades de Integration Advisor y Trading Partner Management de SAP Integration Suite se vuelven relevantes. Asumir que lo que funciona para la integración interna de SAP a SAP se transferirá directamente a la integración de socios externos es un error de alcance común y evitable.

El papel de ISA-M

La Metodología de asesoramiento de soluciones de integración (ISA-M) es el marco de SAP para ayudar a los arquitectos empresariales y de integración a definir e implementar estrategias de integración. Mientras que las cinco preguntas de la sección anterior ayudan a evaluar un escenario de integración individual, ISA-M opera a nivel de paisaje, proporcionando una forma estructurada de asignar la gama completa de requisitos de integración en una organización a las tecnologías apropiadas.

El núcleo práctico de ISA-M para la selección de patrones es su enfoque de mapeo tecnológico. Clasifica los requisitos de integración en tres dimensiones: dominios de integración (de local a local, de local a nube, de nube a nube, B2B, orientado al usuario e IoT), estilos de integración (integración de procesos, integración de datos y otros) y casos de uso dentro de esos estilos. Trabajar a través de estas dimensiones produce sistemáticamente un mapeo tecnológico que alinea cada dominio tanto con una tecnología del estado actual como con una recomendación del estado objetivo. Para la mayoría de los dominios de integración, Cloud Integration es la recomendación de futuro, con SAP Process Orchestration reservado para implementaciones existentes que se mantienen o adaptan en lugar de desarrollos nuevos.

ISA-M también proporciona planos de arquitectura; Estas son arquitecturas de referencia introducidas en la versión 3.3 que traducen el mapeo tecnológico en una guía de implementación concreta. Estos son particularmente útiles para las organizaciones que crean o actualizan una estrategia de integración, ya que proporcionan un punto de partida que se puede ampliar con recomendaciones de selección específicas del paisaje en lugar de requerir que los equipos deriven la arquitectura a partir de los primeros principios.

Una nota práctica: el mapeo tecnológico completo de ISA-M puede ser más complejo de lo que requiere el trabajo de integración diario. Para decisiones de patrones individuales, el marco de cinco preguntas anterior es la herramienta adecuada. ISA-M es más valioso cuando la pregunta no es «qué patrón se ajusta a este escenario» sino «cómo gobernamos las decisiones de integración de manera consistente en todo el panorama».

Conclusión

Elegir un patrón de integración de SAP no es principalmente una decisión técnica. Es una decisión arquitectónica y, como todas las decisiones arquitectónicas, sus consecuencias se dejan sentir mucho después de que se haya hecho la elección inicial. Los patrones en sí no son complicados. Lo que es complicado es la disciplina para aplicarlos correctamente: comenzar con los requisitos del negocio en lugar de la herramienta familiar, distinguir la integración de procesos de la integración de datos antes que cualquier otra cosa y tratar el modelo de implementación como una restricción en lugar de una idea de último momento.

El marco analizado en esta serie no tomará la decisión por usted. Lo que hará es garantizar que la decisión se tome deliberadamente, con las variables correctas sobre la mesa, antes de que comience la implementación. Ahí es donde la mayoría de las arquitecturas de integración fallan: no en la ejecución, sino en los supuestos que nunca fueron examinados porque el equipo pasó a utilizar herramientas antes de haber terminado de pensar en el problema.

La cuarta publicación de esta serie cubre en detalle las restricciones del modelo de implementación. Cómo la nube pública, la nube privada, los entornos locales e híbridos determinan qué patrones están disponibles y qué errores evitar en cada contexto.

Esta publicación se publicó originalmente el 5/2026.