APIs REST en Datasphere: conexiones personalizadas ya en GA

¿Cuántas veces has montado un flujo de integración solo para traer a Datasphere los datos de una aplicación SaaS sin conector estándar? Desde la wave 2026.22 (What’s New del 20 de octubre de 2026), SAP Datasphere permite definir tipos de conexión personalizados contra cualquier API REST y cargar su JSON en el object store con replication flows. Te cuento qué exige a la API, cómo funciona el delta y sus límites.

Qué ha cambiado y cuál es su estado

La función no es nueva del todo. En los highlights de julio de 2026 de SAP Business Data Cloud aparecía como restricted release, solo en landscapes EU10 y bajo petición de activación (SAP Note 3696110). En los de octubre, SAP la da por generalmente disponible en todos los landscapes: la restricción a EU10 desaparece. El What’s New de Datasphere la recoge como novedad de la versión 2026.22.

Cómo funciona: tipo de conexión, conexión y replication flow

El diseño tiene tres piezas:

1. Tipo de conexión personalizado (pestaña Custom Connection Types de Connections). Es la plantilla. Defines los recursos (endpoints, siempre GET), sus parámetros, los esquemas de respuesta y, por recurso, paginación, límite de peticiones y códigos que se reintentan. También las acciones: qué recurso llamar, con qué valores de parámetros, dónde están los registros (records locator) y qué atributos son clave. Los recursos se pueden importar de un JSON basado en OpenAPI, pero solo si el tipo aún no tiene ninguno.
2. Conexión. Se crea a partir del tipo: URL base, autenticación y qué acciones se ofrecen a los replication flows.
3. Replication flow. Eliges una acción como contenedor de origen y el destino SAP Datasphere (HDL_Files). Cada entidad de la acción es un objeto de replicación con su tabla destino generada.

Cada nivel anidado del JSON con su clave genera una entidad hija, relacionada con la padre por clave externa. Un ejemplo con una API inventada:

{
  "orders": [
    {
      "orderId": "P-1001",
      "updatedAt": "2026-10-28T09:15:00Z",
      "lines": [{ "lineNo": 1, "sku": "A-01", "qty": 3 }]
    }
  ],
  "next": "https://api.example.com/orders?page=2"
}

Aquí el records locator sería $.orders, con clave orderId. Si marcas lineNo como clave dentro de lines, obtienes una segunda entidad de líneas. Las claves se definen de fuera hacia dentro. Y next encajaría con la paginación Next URL.

Checklist: ¿tu API es compatible?

Yo lo revisaría con el equipo dueño de la API:

SAP desaconseja la autenticación custom con parámetros en la query string, porque esos valores pueden acabar en los logs del sistema externo.

El delta y los límites que hay que conocer

El único tipo de carga es Initial and Delta, y la carga es un upsert (inserta y actualiza). El delta real depende de la API: tienes que usar un parámetro de filtro que ella admita con el marcador ${lastRunTime:<formato>}, por ejemplo updatedSince=${lastRunTime:ISO}. En la primera ejecución el marcador resuelve a una fecha del año 2000, para traer el histórico; después, a la última ejecución correcta. Sin ese marcador, cada ejecución delta vuelve a procesar todos los registros.

Los límites, según la documentación:

• Los borrados no llegan: lo que se borra en la API no se borra en Datasphere.
• No puedes renombrar las tablas destino ni usar una existente. El nombre es <conexión>_<acción>_<entidad>, con 15, 45 y 40 caracteres como máximo para cada parte. Si se trunca y salen nombres duplicados, el despliegue falla.
• Sin filtros, mapeos ni source settings; sin cambios de esquema tras el despliegue; y no se pueden pausar, reanudar o reintentar objetos sueltos.
• Sin clave primaria no hay replicación. Los tipos no soportados (time, timeofday, geometrías, cadenas de más de 5.000 caracteres) se saltan, y los arrays de tipos simples no se replican.
• Si activas validación de formato o de valores permitidos en un atributo y un valor falla, se descarta la fila entera.
• No hay validación de conexión, ni gestión por CLI o API de conexiones.
• Si el file space ya existía, hay que volver a desplegarlo antes de crear y usar una conexión de este tipo.

Cómo lo usaría en un proyecto

Para mí encaja como capa de aterrizaje de datos SaaS: el replication flow deja el JSON aplanado en tablas locales (file) y un transformation flow lo prepara para el modelo. No sustituye a Integration Suite si hay orquestación o escritura de vuelta, pero evita una pieza intermedia en el caso más común: leer y cargar.

Tres consejos:

• Nombres cortos desde el diseño: los técnicos no se pueden cambiar después.
• Plan para los borrados: si la API borra registros, programa una recarga completa periódica o pide a la API un indicador de borrado lógico.
• Permisos: para crear tipos y conexiones hace falta el privilegio Data Warehouse Connection (CRUD) y Space Files (CRUD) en el espacio. Las plantillas DW Space Administrator y DW Integrator los incluyen.

Sobre costes: la documentación pide recursos asignados al object store, pero no he encontrado información comercial específica de esta función. Pregúntalo a SAP antes de dimensionar.

Conclusión

Es una novedad poco vistosa que ahorra infraestructura. Si tienes fuentes SaaS que hoy entran por ficheros o por flujos de integración solo de lectura, pasa el checklist a una de ellas y prueba en un file space de desarrollo. Valida sobre todo el delta y los borrados antes de producción.

Fuentes

• What’s New in SAP Datasphere (SAP Help)
• SAP Business Data Cloud – release update highlights (SAP Community)
• Creating a Custom Connection Type (SAP Help)
• Define Resources (SAP Help)
• Define Resource Settings (SAP Help)
• Define Actions (SAP Help)
• Use Dynamic Placeholders in Request Parameter Values (SAP Help)
• Create a Connection from a Custom Connection Type (SAP Help)
• Edit a Custom Connection Type (SAP Help)
• Rest API Custom Connection Sources for Replication Flows (SAP Help)
• Create a File Space to Load Data in the Object Store (SAP Help)