Caso práctico: delta programado de replication flows en Datasphere

Hasta hace poco, un replication flow con delta en SAP Datasphere era una tarea de larga duración: se quedaba en estado Active para siempre, revisando cambios cada X minutos. Funciona, pero tiene dos pegas que en proyecto duelen: no se podía encadenar con lo que viene después (transformaciones, persistencias) y consume horas de ejecución todo el día, aunque el negocio solo mire los datos en horario de oficina. Desde mayo de 2026 Datasphere permite ejecutar el delta a la hora que tú digas y terminar. En este caso práctico lo montamos de punta a punta.

Qué vamos a construir

Al acabar tendrás:

1. Un replication flow RF_SD_DELTA que lee dos vistas CDS estándar de S/4HANA con Initial and Delta y el nuevo modo de ejecución At Scheduled Time: procesa los cambios pendientes y se completa.
2. Un replication flow aparte, RF_SD_MASTER, con los maestros en Initial Only.
3. Una task chain TC_SD_INTRADAY que ejecuta el delta, después un transformation flow que prepara la tabla de reporting y, si algo falla, envía un aviso.
4. Una programación con cron: cada dos horas, de 6:00 a 20:00, de lunes a viernes.

La imagen de portada resume la idea: arriba, la cadena que vamos a montar; abajo, la diferencia entre un job que corre todo el día y ejecuciones cortas en las horas que importan.

Los nombres de los objetos de Datasphere (SD_INB, S4_CLOUD_PUBLIC, RF_SD_DELTA…) son de ejemplo; usa los de tu convención. Las vistas CDS, en cambio, son las estándar de SAP.

Por qué merece la pena

La documentación de SAP lo dice sin rodeos: los replication flows se facturan por la duración del job, no por el volumen de registros. Un delta que corre 24 horas consume 24 horas, cambie o no cambie nada en origen. Si tus usuarios consultan ventas por la mañana y a media tarde, pagar la madrugada no tiene sentido.

La segunda ventaja es de orquestación, y para mí es la más importante. Con un delta de larga duración, lo que va detrás (un transformation flow, una vista persistida) se programa “a ojo”, confiando en que el delta ya haya pasado. Con At Scheduled Time el replication flow termina, así que puede ir dentro de una task chain y el siguiente paso arranca cuando los datos ya están. Es lo que en BW hacíamos con una process chain y un DTP delta, y lo que echábamos de menos en Datasphere.

Paso a paso

1. Paso:Separa los objetos delta de los Initial Only

   La primera regla, y la que más tropiezos provoca: un replication flow que mezcla objetos Initial Only con objetos delta no se puede programar ni meter en una task chain. SAP pide separarlos en dos flujos: uno solo con objetos Initial Only y otro solo con objetos delta y At Scheduled Time.

   En el ejemplo:

   Replication flow	Objetos	Load type
   RF_SD_DELTA	C_SalesDocumentItemDEX_1, C_BillingDocItemBasicDEX_1	Initial and Delta
   RF_SD_MASTER	I_Customer, I_Product	Initial Only

   Si ya tienes un flujo mixto en producción, este es el momento de partirlo. Yo aprovecharía también para agrupar por frecuencia: lo que el negocio necesita cada dos horas en un flujo, lo que basta con una carga nocturna en otro.

   Un límite a tener en cuenta al agrupar: según la documentación de SAP, un replication flow admite como máximo 500 objetos. Mucho antes de llegar ahí, yo ya lo partiría por área o por frecuencia, para que un fallo o una recarga no arrastre a todo lo demás.

   Sobre qué vistas leer: la vista debe estar habilitada para extracción (anotación @Analytics.dataExtraction.enabled) y, para el delta, tener captura de cambios (CDC). Para movimientos, SAP entrega vistas específicas de extracción como C_SalesDocumentItemDEX_1 o C_BillingDocItemBasicDEX_1; para maestros suelen bastar vistas básicas como I_Customer o I_Product. Una vista Z solo tiene sentido cuando nada estándar cubre el caso, y entonces construida sobre vistas liberadas y con sus anotaciones de extracción y delta. Antes de empezar, comprueba en tu sistema que las vistas existen y que tu release las incluye.

2. Paso:Crea el replication flow delta

   En el Data Builder del espacio SD_INB, crea un replication flow nuevo:

   • Source connection: S4_CLOUD_PUBLIC (tipo SAP S/4HANA Cloud), contenedor CDS_EXTRACTION. Con el + de Source Objects añade C_SalesDocumentItemDEX_1 y C_BillingDocItemBasicDEX_1.
   • Target: SAP Datasphere. El destino es siempre una tabla local del espacio en el que estás; si no existe, se crea al desplegar.
   • Load type: Initial and Delta. Lo puedes fijar para todos en la pestaña Settings del editor o, objeto a objeto, en el panel Object Properties.

   Para este load type SAP recomienda que la tabla destino tenga Delta Capture activado. Hazme caso: actívalo. Está en la sección Settings del panel Object Properties de cada objeto, junto al Load Type, y Datasphere propone como tabla de cambios <objeto>_Delta. Es lo que permite que el transformation flow del paso 5 lea solo los cambios. Si mapeas contra una tabla que ya existe, recuerda que Delta Capture solo se puede encender antes del primer despliegue de la tabla.

   Guarda como RF_SD_DELTA y despliega.

   12

3. Paso:Cambia Delta Load Run a At Scheduled Time

   En el panel Replication Flow Properties, baja hasta la sección Run Settings. La opción clave es Delta Load Run, y se puede fijar ya en el editor, antes de desplegar. Con el flujo desplegado, la sección aparece en modo lectura con un enlace Edit; según SAP, para cambiarla ahí necesitas el rol DW Integrator.

   • On Delta Interval (valor por defecto): el comportamiento de siempre. El flujo corre sin parar y revisa cambios según la Delta Load Frequency, 60 minutos por defecto.
   • At Scheduled Time: el flujo procesa los cambios disponibles y termina. Es la que permite ejecutarlo a mano, con una programación o dentro de una task chain.

   Elige At Scheduled Time. Con esta opción la Delta Load Frequency deja de aplicar: la frecuencia la marcará la programación.

   En la misma sección revisa, bajo Thread Limit for Initial Load, los Source/Target Thread Limit (de 1 a 160; 10 por defecto). Para dos vistas CDS no hace falta tocarlos; si el flujo tuviera objetos grandes, súbelos con cabeza, porque los jobs de replicación se comparten entre todos los flujos del tenant.

   1

4. Paso:Monta el flujo de maestros Initial Only

   Repite el paso 2 con I_Customer e I_Product en RF_SD_MASTER, con load type Initial Only y Delete All Before Loading activado para que cada ejecución sustituya los datos. Despliega. Este flujo irá en una cadena nocturna independiente, así que no lo mezcles con la intradía.

5. Paso:Crea el transformation flow de reporting

   TF_SD_ORDERS lee solo los cambios de la tabla de posiciones que carga RF_SD_DELTA y los escribe en una tabla de reporting, SD_ORDERS_RPT. Así, las posiciones de pedido llegan en delta de punta a punta: de S/4HANA a la tabla de reporting.

   1. En el Data Builder del espacio SD_INB, pulsa New Transformation Flow y después Graphical View Transform.
   2. Arrastra como origen la tabla local C_SalesDocumentItemDEX_1, la que creó el replication flow con Delta Capture activado.
   3. Añade una proyección (Rename/Exclude Columns) y quédate con las columnas que necesita el reporting: SalesDocument, SalesDocumentItem, NetAmount y las que uses. Mantén las columnas de cambio (Change Type y Change Date): SAP exige mapearlas a columnas del mismo tipo en el destino.
   4. Vuelve al editor del transformation flow con Back y, en el nodo de destino, pulsa Create New Target Table. Llámala SD_ORDERS_RPT. Como el origen tiene Delta Capture, el destino lo trae activado por defecto: déjalo así. Revisa en Mappings que el auto-mapeo por nombre ha enlazado todas las columnas.
   5. En las propiedades del propio transformation flow (sección General), pon Load Type = Initial and Delta. SAP solo lo permite si Delta Capture está activado en el origen y en el destino. La primera ejecución carga todo; las siguientes, solo los cambios.
   6. Guarda como TF_SD_ORDERS y despliega.

   Lo he dejado deliberadamente simple, y no es por pereza. La documentación de SAP pone tres límites que conviene conocer antes de complicarlo:

   • Una sola tabla con Delta Capture como origen por transformation flow, y el delta no se puede leer desde vistas, solo desde tablas.
   • Sin agregaciones si el destino tiene Delta Capture, porque las columnas de cambio tienen que salir tal cual.
   • Cuidado con los joins. Con un inner join, los borrados del origen no llegan al destino. Y si cruzas con I_Customer, un cambio en el cliente no genera delta en las posiciones: tendrías que resetear el watermark para recargar.

   Por eso yo enriquecería con clientes y materiales más arriba, en una vista o en el Analytic Model que lee SD_ORDERS_RPT, y no dentro del transformation flow.

   ¿Y las facturas? RF_SD_DELTA también carga C_BillingDocItemBasicDEX_1, pero no puede entrar en este mismo transformation flow, porque solo admite un origen con Delta Capture. Necesita el suyo, por ejemplo TF_SD_BILLING → SD_BILLING_RPT, que se monta exactamente igual. En la task chain del paso siguiente va en paralelo a TF_SD_ORDERS, los dos colgando del replication flow. Para no alargar el caso, sigo solo con los pedidos.

   Un detalle útil para operar: el watermark, la marca de tiempo hasta la que se ha cargado, se ve en Monitoring > Data Integration, en la pestaña Delta Capture Settings del transformation flow. Desde ahí se puede pulsar Reset Watermark para forzar una recarga completa en la siguiente ejecución, sin redesplegar.

   1

   1

6. Paso:Crea la task chain intradía

   En el Data Builder, New Task Chain, y arrastra desde la pestaña Repository:

   1. RF_SD_DELTA, que aparece como actividad Run Replication Flow.
   2. Arrastrado sobre el anterior, con la opción Add as New Task, el transformation flow TF_SD_ORDERS del paso anterior (Run Transformation Flow). El conector por defecto es el puerto Success (✓): solo arranca si el replication flow ha terminado bien.
   3. Un Notification Task desde la barra de herramientas de la task chain (aparece como Send Notification), enlazado al puerto de error (✕) del replication flow para avisar al equipo cuando algo falla.

   Selecciona TF_SD_ORDERS y, en su panel de propiedades, activa Enable Auto-Retry (desplegable Runtime): de uno a tres reintentos, con una espera de entre 15 segundos y 5 minutos entre intentos. Ojo: según la documentación de SAP, ni los replication flows ni la tarea de notificación admiten auto-retry. Si RF_SD_DELTA falla, por ejemplo por un corte de red con S/4HANA, no se reintenta solo: para eso está el aviso.

   Guarda como TC_SD_INTRADAY y despliega. Después configura en la cadena la notificación por correo de fin de ejecución.

   

7. Paso:Programa la cadena con cron

   Antes de nada, comprueba en tu perfil (Authorized Consent Settings) que has dado el consentimiento de planificación. Sin él, las tareas programadas de las que eres propietario fallan. Dura 365 días y avisa por correo 30 días antes de caducar.

   En Monitoring > Data Integration, selecciona el espacio, abre la pestaña Task Chains, marca TC_SD_INTRADAY y pulsa Schedule > Create Schedule. En Setting Type elige Cron Expression, en Time Zone tu región (en el ejemplo, Europe/Madrid) y rellena los cinco campos (Minute, Hour, Day (Month), Month y Day (Week)) con:

   0 6-20/2 * * 1-5

   Se lee así: minuto 0, cada dos horas entre las 6 y las 20, cualquier día del mes, cualquier mes, de lunes a viernes. El panel Next Runs del propio diálogo enseña las próximas ejecuciones: úsalo para comprobar que la expresión hace lo que crees antes de pulsar Create. Datasphere usa el formato unix-cron de cinco campos y el campo de minutos solo admite un valor fijo, sin rangos ni saltos.

   Programa la cadena, no el replication flow suelto. Si programas los dos, tendrás ejecuciones duplicadas. Para RF_SD_MASTER, crea otra cadena TC_SD_NIGHTLY con su propia programación, por ejemplo 30 1 * * *.

   Un detalle de producción: en la sección Ownership del diálogo, pon como propietario de la programación un usuario técnico en lugar de tu usuario. El día que cambies de proyecto, las cargas no deberían depender de tu consentimiento.

   

8. Paso:Incluye el run setting en el transporte

   Este paso se olvida y rompe el paso a producción. Los run settings no viajan solos: en Monitoring > Data Integration > Flows, abre el detalle de RF_SD_DELTA y, en el panel Transport, marca Include Delta Load Run (o Include all settings).

   Si no lo haces, el flujo llega al tenant de producción con el valor por defecto, On Delta Interval, y no podrás programarlo ni ejecutarlo en la cadena. Además, SAP indica que los run settings solo viajan con el transporte del Transport app (ACN), no con exportación e importación de JSON sueltos.

Validación

Lanza la cadena a mano una vez (Run desde el monitor) y comprueba cuatro cosas:

1. El replication flow termina. En Monitoring > Data Integration > Flows, RF_SD_DELTA debe acabar en Completed, y en el detalle de la ejecución cada objeto debe quedar en Completed (next run will be delta). Si se queda en Active, sigue en On Delta Interval.

2. La cadena sigue. En el monitor de task chains, TF_SD_ORDERS debe arrancar después del replication flow, no a la vez.

3. Los datos cuadran. Crea una vista SQL sencilla sobre la tabla destino y compara con S/4HANA las posiciones de un pedido de prueba:

   SELECT
     "SalesDocument",
     COUNT(*)         AS "ITEMS",
     SUM("NetAmount") AS "NET_AMOUNT"
   FROM "C_SalesDocumentItemDEX_1"
   WHERE "SalesDocument" = '0000012345'
   GROUP BY "SalesDocument"

   Usa el nombre de tu tabla destino si lo has cambiado y un pedido real de tu sistema de desarrollo. Modifica una posición del pedido en S/4HANA (cantidad o precio), lanza la cadena y confirma que NET_AMOUNT cambia y que el número de posiciones sigue cuadrando. Repite la consulta cambiando el FROM por SD_ORDERS_RPT: debe dar lo mismo, porque el transformation flow ha propagado el cambio.

4. El coste baja. Tras unos días, revisa en el monitor de capacity units las horas de ejecución de replication flows del espacio. Deberías ver ejecuciones cortas en tus franjas y nada fuera de ellas.

Errores habituales

Síntoma	Causa	Solución
El flujo no aparece al añadirlo a la task chain o la programación no deja crearse	Sigue en On Delta Interval, o mezcla objetos Initial Only y delta	Cambia Delta Load Run a At Scheduled Time y separa los objetos en dos flujos
Las ejecuciones programadas fallan sin que nadie haya tocado nada	Ha caducado el consentimiento de planificación del propietario	Renueva el consentimiento y pasa la programación a un usuario técnico
Necesitas recargar un objeto y Restart Object no está disponible	Con At Scheduled Time no se puede reiniciar un objeto ni repetir el inicial	Quita el objeto del flujo, despliega, vuelve a añadirlo y despliega; o crea un flujo Initial Only para la recarga
Quieres pausar un flujo programado y no te deja	Con programación, se pausa la programación, no la ejecución	Pausa la programación (por ejemplo, antes de una parada de S/4HANA)
Errores de conexión cuando arrancan muchos flujos a la vez	Demasiados flujos en el mismo intervalo agotan las conexiones	Escalona los horarios; SAP recomienda no más de 100 flujos en el mismo intervalo
TF_SD_ORDERS no deja elegir Initial and Delta, o siempre carga todo	Delta Capture no está activado en el origen o en el destino	Actívalo en las dos tablas; en una tabla ya desplegada no se puede encender, así que recréala
En producción el flujo vuelve a correr 24/7	El transporte no incluía Delta Load Run	Marca Include Delta Load Run en el panel Transport y vuelve a transportar

Mi recomendación

Para cargas de reporting que el negocio consulta en horario laboral, el delta programado debería ser el estándar, y el delta continuo, la excepción justificada: cuadros de mando operativos, alertas o integraciones que de verdad necesiten minutos. Antes de migrar todos tus flujos, empieza por uno: mide durante una semana la duración de las ejecuciones y las horas consumidas, y enséñaselo a quien paga la factura. Después, revisa tus task chains: es muy probable que tengas persistencias programadas “a las y cuarto por si acaso” que ahora pueden colgar del replication flow.

Fuentes

• SAP Business Data Cloud – release update highlights (SAP Community, Klaus-Peter Sauer)
• Configure the Run Settings of a Replication Flow (SAP Help Portal)
• Working With Existing Replication Flow Runs (SAP Help Portal)
• Sizing, Capacity Planning, and Load Balancing for Replication Flows (SAP Help Portal)
• SAP Datasphere Targets for Replication Flows (SAP Help Portal)
• Capturing Delta Changes in Your Local Table (SAP Help Portal)
• Creating a Task Chain (SAP Help Portal)
• Scheduling Data Integration Tasks (SAP Help Portal)
• Schedule a Data Integration Task (with Cron Expression) (SAP Help Portal)
• Creating a Transformation Flow (SAP Help Portal)
• Create a Graphical View in a Transformation Flow (SAP Help Portal)
• Create or Add a Target Table to a Transformation Flow (SAP Help Portal)
• Watermarks (SAP Help Portal)