Servicios remotos en CAP: consumir S/4HANA sin copiarte el ERP

La tentación, cuando tu app CAP necesita datos de S/4HANA, es replicarlos: un job nocturno que copia tablas a HANA Cloud y a rezar para que no se desincronicen. Casi siempre es un error. CAP tiene un mecanismo mejor: importar el servicio OData externo, proyectarlo como si fuera tuyo y delegar la consulta al backend en tiempo real.

El flujo: importar, proyectar, delegar

• Importar: cds import toma el metadata del servicio externo (el EDMX) y lo mete en tu proyecto como un modelo más.
• Proyectar: defines una entidad tuya como proyección de la entidad remota. Tu API no expone la del proveedor, expone la tuya.
• Delegar: en el handler reenvías la query al servicio remoto. El dato nunca se copia, se lee al vuelo.

flowchart TD
  I["cds import - EDMX externo"] --> P["Proyección en srv/"]
  P --> H["Handler - delega la Query"]
  H -->|"consulta en vivo"| S4["Servicio OData de S/4HANA"]
  S4 -->|"solo lo pedido"| APP["App / consumidor"]

Proyectar el servicio externo

Tras importar, declaras tu entidad como una lectura de la remota. Aquí expones Incidents a partir de IncidentsSet del servicio de S/4:

using { YSAPUI5_SRV as ext } from './external/YSAPUI5_SRV';

service RemoteService {
  entity Incidents as projection on ext.IncidentsSet;
}

Tu consumidor ve Incidents, no IncidentsSet. Eso te da una capa de aislamiento: si el proveedor renombra su entidad, tocas una línea, no toda la app.

Delegar la query, no traer todo

La clave del rendimiento está en el handler: reenvías al backend la misma query con sus filtros y su ordenación, para que S/4 devuelva solo lo pedido, no la tabla entera:

module.exports = (srv) => {
  const ext = await cds.connect.to('YSAPUI5_SRV');

  srv.on('READ', 'Incidents', async (req) => {
    // se desglosa la Query: where + orderBy viajan al backend
    return ext.run(req.query);
  });
};

El ext.run(req.query) es lo que separa esto de un proxy tonto: el $filter y el $orderby que llegan del cliente se traducen y viajan a S/4HANA. Nada de traerte diez mil incidencias para filtrar tres en Node.

El anti-patrón: replicar por comodidad

Copiar el dato a HANA Cloud “para tenerlo cerca” parece rápido y sale caro: te compras un problema de sincronización, datos rancios y una tabla que mantener. Replica solo cuando de verdad necesitas el dato offline o joins masivos locales. Para lecturas puntuales, delega.

Un servicio remoto bien proyectado es una fachada, no una copia. El día que el proveedor cambia algo, quieres tocar una proyección, no reconciliar dos bases de datos.

En el próximo post: autenticación y autorización en CAP con XSUAA, donde las anotaciones se vuelven permisos.