Dos MDUS, un IS-U: cómo enrutar los servicios empresariales
Guía funcional para estructurar el enrutamiento de servicios empresariales en SAP IS-U cuando conviven dos o más sistemas MDUS de distintos fabricantes.
· 12 min de lectura
La conexión entre SAP IS-U y un sistema MDUS es un escenario resuelto: la comunicación entre las aplicaciones SAP y el sistema de unificación y sincronización de datos de medición se realiza mediante servicios empresariales, y ese camino está documentado desde hace años (SAP Learning, consultado 2026). El problema aparece en el segundo rollout de medición, cuando la utility adjudica el siguiente lote a otro fabricante y el paisaje pasa a tener dos sistemas de cabecera conectados al mismo núcleo comercial.
Ahí la pregunta deja de ser “cómo conecto” y pasa a ser “cómo decido a quién le hablo”. Es una pregunta de diseño de enrutamiento, no de conectividad. Y se responde antes de mover el primer mensaje productivo.
Un solo puerto lógico no sabe elegir destino
Cuando existe un único MDUS, todos los servicios empresariales salientes usan el puerto lógico estándar configurado en SOAMANAGER. Con dos sistemas conectados, ese comportamiento deja de ser una comodidad y se convierte en una restricción: el sistema sigue eligiendo el destino por defecto aunque el dispositivo pertenezca al otro fabricante (discusión técnica en SAP Community, 2012, sobre instalaciones ECC; conviene revalidar el comportamiento contra la versión de SAP S/4HANA Utilities en uso).
La complicación real no es que haya que redirigir, sino que la capacidad de redirigir no es uniforme. En algunos servicios salientes es posible intervenir la implementación y crear la instancia del proxy apuntando a otro puerto lógico; en otros —típicamente los mensajes de confirmación que el sistema envía de forma automática ante un resultado entrante— solo se ofrece la posibilidad de modificar el contenido del mensaje, no el receptor (SAP Community, 2012).
Esa asimetría es el hecho de diseño que ordena todo lo demás. Un enrutamiento que dependa de intervenir servicio por servicio dentro del núcleo funciona hasta que aparece el primer servicio que no lo permite, y para entonces la arquitectura ya está comprometida.
La llave de enrutamiento ya vive en el dato
La buena noticia es que la información para decidir el destino no hay que inventarla. El paisaje AMI está descrito con precisión en la documentación: a la izquierda los sistemas de medición avanzada (AMS), los dispositivos y los concentradores; en el centro el MDUS como interfaz; a la derecha el sistema SAP como back office (SAP Learning, consultado 2026). El dispositivo pertenece a un AMS, y ese vínculo puede acompañar al mensaje —por ejemplo, en el identificador del sistema de medición avanzada asociado a la operación (SAP Community, 2012).
El interfaz publicado de MDUS existe justamente para eso: permite que los sistemas SAP accedan a datos de uso y a capacidades de infraestructura de medición avanzada desde un sistema unificado capaz de interactuar con múltiples sistemas de medición distintos dentro de la red de la utility (Oracle Utilities, consultado 2026).
Antes de escribir una sola regla, el equipo debe cerrar cuatro decisiones:
- Qué atributo del maestro de dispositivo determina, sin ambigüedad, el sistema de medición al que pertenece cada punto.
- Qué ocurre con un punto de medición que cambia de fabricante durante una reposición.
- Quién es el dueño funcional del catálogo de sistemas de medición y de su correspondencia con destinos técnicos.
- Qué hace la plataforma cuando llega un mensaje cuyo sistema de origen no se puede resolver.
Las tres primeras son de gobierno del dato y se apoyan en el trabajo de prerrequisitos que ya debía estar cerrado antes de sincronizar el maestro de dispositivos. La cuarta es de diseño de excepción, y es la que más se olvida.
Dónde debe vivir la decisión de enrutamiento
Hay dos lugares posibles para alojar la lógica de “a quién le hablo”: el núcleo o la capa de integración. En AGT recomendamos la segunda, y la razón es de mantenibilidad, no de moda tecnológica.
SAP Cloud Integration, dentro de SAP Integration Suite, soporta transformaciones y enrutamiento basado en contenido, que dirige los mensajes según criterios definidos sobre el propio mensaje (SAP Learning, consultado 2026). Si la llave de enrutamiento viaja en el mensaje, la decisión puede tomarse una sola vez, en un punto observable, en lugar de replicarse dentro de cada servicio del núcleo.
El camino de retorno es el que rompe
El envío hacia el núcleo suele resolverse rápido. Lo que descarrila los proyectos multi-fabricante es la vuelta. La documentación es explícita: ante una lectura entrante siempre se envía un mensaje de confirmación al MDUS, positiva o negativa según el resultado del registro, y ese envío se ejecuta dentro de un BAdI en el lado SAP (SAP Learning, consultado 2026).
Con dos sistemas conectados, esa confirmación tiene que volver al remitente correcto. Y como el receptor de ese mensaje no siempre es configurable servicio por servicio, la respuesta no puede ser “lo parametrizamos”: tiene que ser correlación. La capa de integración conserva el origen del mensaje, lo asocia al identificador de la operación y usa esa correlación para devolver la confirmación al sistema que la originó.
---
config:
theme: base
fontFamily: 'Inter Variable, system-ui, sans-serif'
themeVariables:
darkMode: true
fontFamily: 'Inter Variable, system-ui, sans-serif'
fontSize: '15px'
background: '#111113'
primaryColor: '#1A1A1D'
primaryTextColor: '#F4F5F8'
primaryBorderColor: '#00C2FF'
secondaryColor: '#242428'
tertiaryColor: '#1A1A1D'
mainBkg: '#1A1A1D'
secondBkg: '#242428'
tertiaryBkg: '#2E2E33'
lineColor: '#00C2FF'
textColor: '#F4F5F8'
titleColor: '#F4F5F8'
nodeBorder: '#00C2FF'
clusterBkg: '#1A1A1D'
clusterBorder: '#2E2E33'
edgeLabelBackground: '#242428'
pie1: '#00C2FF'
pie2: '#f59e0b'
pie3: '#22c55e'
pie4: '#59d7ff'
pie5: '#f97316'
pie6: '#ef4444'
pieTitleTextColor: '#F4F5F8'
pieSectionTextColor: '#F4F5F8'
pieLegendTextColor: '#F4F5F8'
pieStrokeColor: '#111113'
pieOuterStrokeColor: '#111113'
---
flowchart TD
A([Lectura entrante desde un MDUS]) --> B[La capa de integración conserva el origen del mensaje]
B --> C[Asocia el origen al identificador de la operación]
C --> D{¿El registro fue exitoso?}
D -->|Sí| E[Confirmación positiva hacia el MDUS]
D -->|No| F[Confirmación negativa hacia el MDUS]
E --> G([Retorno al sistema que originó el mensaje])
F --> G
class A inicio
class D decision
class B,C,E,F proceso
class G bueno
classDef inicio fill:#113d4f,stroke:#00C2FF,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff
Para el tráfico asíncrono de alto volumen, el desacople por eventos evita que un sistema con transmisión irregular contamine al resto. SAP documenta el camino desde el plan por defecto de SAP Event Mesh hacia SAP Integration Suite, advanced event mesh para arquitecturas orientadas a eventos (SAP Community, 2026). Colas separadas por fabricante son una decisión barata que se agradece el día que un concentrador se atrasa.
El enrutamiento es un objeto de gobierno, no un ajuste
Una vez en producción, el enrutamiento deja de ser configuración y pasa a ser un activo que se versiona, se prueba y se monitorea. Tres prácticas concretas:
- Monitorear por fabricante y no en agregado: un indicador consolidado esconde exactamente el problema que el modelo multi-vendor busca controlar.
- Tratar el catálogo de sistemas de medición y su correspondencia con destinos como objeto de cambio controlado, con dueño funcional identificado.
- Ejecutar regresión sobre el fabricante existente cada vez que entra uno nuevo. El tercer proveedor no es una repetición del segundo.
El marco regulatorio empuja en la misma dirección. En Colombia, la resolución que fija las condiciones de implementación de la infraestructura de medición avanzada en el Sistema Interconectado Nacional establece requisitos de comunicaciones y seguridad y señala que no se acepta el uso de soluciones que transformen el esquema basado en protocolos abiertos a protocolos cerrados o propietarios (CREG, 2022). Una capa de integración que impone un contrato único sobre distintos fabricantes es, en la práctica, la expresión técnica de ese principio.
En AGT acompañamos a distribuidoras y comercializadoras de la región a definir esta capa antes de que el segundo rollout la defina por inercia. La siguiente pieza de esta serie aborda el paso lógico posterior: ejecutar la convivencia de fabricantes sin duplicar el dato de medición.
Fuentes
- SAP Learning — Understanding Advanced Meter Infrastructure (curso Configuring Device Management in SAP S/4HANA Utilities): https://learning.sap.com/courses/configuring-device-management-in-sap-s-4hana-utilities/understanding-advanced-meter-infrastructure
- SAP Community — How to connect IS-U with more than one MDUS (2012): https://community.sap.com/t5/sap-for-utilities-discussions/how-to-connect-is-u-with-more-than-one-mdus-meter-data-unification-and/td-p/8682820
- Oracle Utilities — Meter Data Management Integration to SAP MDUS Implementation Guide: https://docs.oracle.com/cd/E28256_02/PDF/MDM_SAP_MDUS_Implementation_Guide.pdf
- SAP Learning — Exploring API Management, Event Mesh, and Cloud Integration: https://learning.sap.com/courses/administering-sap-integration-suite/exploring-api-management-event-mesh-and-cloud-integration
- SAP Community — Q1/2026 Product Highlights, SAP Integration Suite: https://community.sap.com/t5/integration-blog-posts/q1-2026-product-highlights-sap-integration-suite/ba-p/14376750
- CREG — Resolución 101 001 de 2022, condiciones para la implementación de la infraestructura de medición avanzada en el SIN: https://gestornormativo.creg.gov.co/gestor/entorno/docs/resolucion_creg_101-1_2022.htm
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
