Un DataSource no es un API: cómo validar una extracción de SAP ECC hacia la nube

Primero se valida en el sistema, no en la presentación

La existencia de un nombre técnico en SAP Business Content no demuestra que el extractor esté disponible y activo en una instalación concreta. La versión de ECC, los componentes instalados, las activaciones realizadas y las ampliaciones propias pueden cambiar el resultado.

Por eso, antes de discutir plataformas cloud, APIs o frecuencias de carga, validaría los candidatos en RSA5 y RSA6 —y, cuando corresponda, en ROOSOURCE— y ejecutaría una prueba controlada con RSA3. En CO-PA, además, el nombre 1_CO_PA_* depende del área operativa; no debería tratarse como un identificador universal.

• Nombre técnico exacto, estado y componente de origen.
• Campos disponibles, semántica y filtros de selección.
• Resultado de una extracción de prueba con volumen representativo.
• Capacidad de delta, inicialización y comportamiento ante cambios.
• Impacto esperado sobre el ERP y ventana de ejecución.

ODP y OData pueden trabajar juntos, pero requieren una capa real

SAP documenta la extracción de datos ODP mediante OData. El enfoque conecta OData con la API de replicación ODP y puede soportar paquetes y delta cuando el proveedor operacional lo permite.

El punto importante es que la propia documentación exige generar el servicio en SAP Gateway Service Builder, seleccionar el contexto ODP y los proveedores que formarán el escenario, generar los artefactos y registrar el servicio. Es decir: existe un camino estándar, pero no es una exposición automática de cualquier DataSource.

En cualquier entorno SAP ECC se debe confirmar que la combinación de versión, componentes, SAP Gateway, contexto ODP y extractor cumple los prerrequisitos. Si no los cumple, la propuesta necesita declarar otra capa de exposición en lugar de dar por resuelto el salto técnico.

La pregunta de arquitectura que cambia la conversación

Ante una propuesta de este tipo, la pregunta concreta es: ¿qué componente toma el extractor, conserva su semántica y su delta, y lo publica como una entidad OData consumible por la plataforma externa?

La respuesta podría ser un servicio ODP/OData generado y registrado, un servicio OData desarrollado para el caso, o una herramienta de integración que consuma ODP/RFC y entregue los datos al destino. Las tres posibilidades son distintas en esfuerzo, soporte, seguridad, rendimiento y operación. La arquitectura debe escoger una y demostrarla; no mezclarlas en una sola flecha.

Cuando el dato proviene de una tabla propia

Si un indicador ya se consolida en una tabla de staging propia, crear un DataSource Z puede ser una opción razonable. Pero también allí deben definirse la clave, la marca de cambio, el criterio de delta, la recuperación ante fallas y el responsable funcional del dato.

Exponer directamente una tabla puede parecer más rápido, pero traslada al consumidor la lógica que debería permanecer gobernada. Prefiero que la interfaz publique un contrato estable y deje la estructura física encapsulada, para que una modificación interna no rompa la analítica externa.

Los controles forman parte de la arquitectura

Una extracción empresarial no termina cuando el destino recibe una respuesta HTTP. La propuesta debería incluir, como mínimo:

• Usuario técnico con privilegios mínimos y comunicación cifrada.
• Paginación, límites de volumen y ventanas de carga.
• Delta, checkpoint y forma de reiniciar sin duplicar ni perder registros.
• Errores funcionales y técnicos, reintentos controlados y cola de reproceso.
• Conciliación por conteos, importes o períodos entre origen y destino.
• Monitoreo de última carga, latencia, registros rechazados y salud del flujo completo.

La arquitectura que recomendaría evaluar

Separaría la solución en tres responsabilidades. SAP ECC conserva los extractores y la lógica del dato; una capa gobernada valida si corresponde usar ODP/OData estándar o un servicio propio; y la plataforma cloud administra la ingesta, la zona de aterrizaje, la calidad y el consumo analítico.

La conciliación cierra el ciclo desde el destino hacia el origen. Así, una carga no se considera exitosa únicamente porque terminó técnicamente, sino porque los datos recibidos son completos, trazables y recuperables.

El diagrama presentado es conceptual. La decisión final solo puede tomarse después de validar los objetos y capacidades del sistema real.

Qué pedir antes de aprobar una propuesta

Mi aprendizaje es simple: una propuesta no se valida por la cantidad de términos correctos que contiene, sino por la claridad con la que conecta cada componente, cada responsabilidad y cada control.

OData puede ser parte de la solución. El trabajo de arquitectura consiste en demostrar qué hay detrás de ese endpoint y cómo se protegerá al ERP mientras el dato recorre el camino completo.

• Evidencia de que cada DataSource existe y extrae correctamente en el ECC objetivo.
• Nombre del contexto ODP y confirmación de compatibilidad.
• Nombre, modelo y responsable del servicio OData que se generará o desarrollará.
• Diseño de carga inicial, delta, paginación y reinicio.
• Estimación de volumen, frecuencia e impacto sobre SAP.
• Modelo de autorizaciones, cifrado y gestión de credenciales.
• Mecanismo de monitoreo, alertas, reproceso y conciliación.
• Prueba de concepto con un extractor estándar y el objeto Z antes de escalar.