Prueba de entrega
Módulo 3 de 4 del capítulo Integración y movimiento de datos, capítulo 9 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Claves y propiedad de la escritura · Siguiente: El contrato de datos de la integración
La pregunta que responde este módulo: ¿quién demuestra que llegaron los datos, y quién recupera?
El ERP envía 20.000 actualizaciones de clientes. Salesforce las procesa. ¿Listo? ¿Cuántas llegaron: 20.000 o 19.997? ¿Fallaron tres en la validación? ¿Se cortó la conexión en el registro 12.417? ¿Reintentó el ERP, y el reintento creó duplicados? ¿Las procesó Salesforce mientras la respuesta nunca volvía? ¿Se detuvo la integración en silencio hace tres días? Enviar datos no es demostrar que llegaron.
Los equipos de Steve Trucking lo saben mejor que nadie. No dejan un lavavajillas en el porche y se van. Le hacen una foto, consiguen la firma del destinatario y cierran la parada: prueba de entrega. Las integraciones necesitan lo mismo. Este módulo trata de quién consigue la firma.
Esta vez envía Salesforce
Sección titulada «Esta vez envía Salesforce »En el módulo 1, Redrock empujaba manifiestos hacia Salesforce y la capa de integración se quedaba preguntándose si se habían guardado. Ahora mira el mismo panorama desde el otro lado. Cada vez que cambia el estado de una entrega, Salesforce lo publica y la capa de integración lo entrega al webhook de Redrock, porque Redrock muestra esos estados a sus propios clientes. Esta noche, el endpoint de Redrock estuvo caído una hora.
Esta vez Salesforce es quien envía, así que Salesforce tiene que saber qué llegó.
¿Qué estados llegaron a Redrock y cuáles no? Redrock no puede decírtelo: nunca supo de los que se perdió. Esta vez la respuesta está de nuestro lado.
¿Quién demuestra que llegó?
Sección titulada «¿Quién demuestra que llegó? »Volvamos al módulo 1: el cliente inicia la conversación, y solo el cliente ve el viaje de ida y vuelta completo. Así que el cliente es siempre dueño de la conversación: los tiempos de espera, los reintentos, saber si cada llamada recibió respuesta. En clase lo digo de forma sencilla: quien se conecta, quien es el cliente, se responsabiliza de los errores de conexión.
But completeness is a different question: did everything that should have moved actually move? Only the side that knows what should have moved can answer it. The receiver can’t know “you meant to send me 3,300 statuses today” unless someone tells it. So the rule is: ⟲
El cliente es dueño de la conversación. Quien sabe lo que debería llegar demuestra que llegó.
Normalmente es el mismo lado. Cuando Redrock envía un manifiesto, Redrock es el cliente y Redrock sabe lo que envió. A veces no lo es, y esas son las flechas que hay que vigilar.
Quien se conecta no siempre es quien demuestra que llegó.
Mira la tercera fila. Para el estado hacia Redrock, el suscriptor de la capa de integración es el cliente: se conecta al bus de eventos de Salesforce. Pero Salesforce es quien sabe qué estados deberían llegar a Redrock, así que Salesforce tiene que demostrar que llegaron. Más adelante en este módulo, para eso sirve el acuse de recibo. Y la cuarta fila: un archivo tiene dos saltos y dos clientes, así que la prueba viaja dentro del archivo, como un recuento de filas que comprueba el cargador.
¿Y el servidor? El servidor cumple sus propias promesas e informa de lo que recibió. Salesforce puede procesar una solicitud de todo o nada, rechazar una clave duplicada, conservar los eventos 72 horas y devolver un resultado por cada registro. Solo puede comprobar la integridad cuando el remitente le dice qué esperar: un recuento, un número de secuencia, un total del archivo. Entonces confirma lo que encontró, y el lado que conoce la intención compara.
Por eso, en clase, hago que cada arquitecto responda las mismas preguntas para cada flecha. En cada flecha saliente: ¿dónde lo registro, qué les digo a los usuarios y cómo reintento? Y la recíproca, en cada flecha entrante: si reciben un error, ¿cómo reintentarán y cómo se recuperarán? Los errores ocurrirán. No te preguntes si ocurrirán; planifícalos.
“Sin errores” no es integridad
Sección titulada «“Sin errores” no es integridad »El registro dice cero errores. Excelente. ¿Cuántos esperaba el receptor? Si el trabajo envió por accidente 17.000 y el destino procesó los 17.000 perfectamente, son cero errores y 3.000 registros que faltan. El éxito técnico y la integridad de negocio son cosas distintas. Así que quiero conciliación: previstos 20.000, enviados 20.000, aceptados 19.997, rechazados 3. Ahora hay algo sobre lo que razonar.
Los recuentos son el principio, no siempre bastan. Cada noche Steve Trucking envía al ERP de finanzas los recuentos de entregas de ayer para facturar: pongamos 3.212 entregas por un valor de 412.560 $ en tarifas. Si el ERP recibió 3.212 entregas por valor de 398.140 $, los recuentos coinciden y algo sigue estando mal. Según la integración, concilia con recuentos de registros, totales financieros o de control, marcas de tiempo mínimas y máximas, números de secuencia, ID de lote, sumas de comprobación, totales de negocio. No toda llamada a la API necesita un sistema contable alrededor; ajusta la verificación a la consecuencia. Las facturas merecen más que una preferencia de marketing.
Sabe dónde estás, y reanuda con elegancia
Sección titulada «Sabe dónde estás, y reanuda con elegancia »El trabajo muere en el 12.417. ¿Reanudar desde el registro 1? ¿Desde el 12.418? ¿Desde el último lote correcto? ¿Cómo lo sabrías? Una integración robusta tiene alguna noción de su avance: un punto de control, una marca de agua, un cursor, una marca de tiempo, un ID de lote, una posición de reproducción, algo que diga sé hasta dónde llegué. Sin eso, la recuperación se convierte en “ejecútalo todo otra vez y a ver qué pasa”, y la esperanza no es una estrategia de recuperación.
Me importa si una integración puede arrancar limpiamente, detenerse limpiamente y reanudarse limpiamente. Si recuperarse significa “borrar todo, reiniciar tres tablas, llamar a cuatro personas, editar a mano una marca de tiempo, ejecutar un script misterioso que alguien escribió hace cinco años y cruzar los dedos”, no está diseñada. La recuperación necesita claves estables, un progreso conocido, reintentos seguros, estados de fallo claros, una forma de apartar los registros erróneos y suficiente observabilidad para saber qué pasó. El camino feliz es fácil. La arquitectura se ve en la reanudación.
Registra cada llamada
Sección titulada «Registra cada llamada »Entonces, ¿dónde lo registras? En proyectos en los que éramos dueños de la interfaz de entrada a Salesforce, registrábamos cada llamada entrante en un objeto personalizado, un registro de integración: cuándo llegó, cuánto tardó, la carga útil y cómo terminó. Lo escribíamos de forma asíncrona para no ralentizar la transacción, y nos permitía hacer seguimiento de todo y reproducirlo. Incluso pasábamos un identificador único en cada solicitud, para que durante las pruebas de carga pudiéramos cruzar nuestro registro con los registros de rendimiento del equipo de middleware. Las llamadas salientes pueden escribir en el mismo registro, y un administrador obtiene una vista de lista de lo que falló.
El marco Well-Architected de Salesforce da el mismo consejo con sus propias palabras: “Registra todas las llamadas de integración con el ID de solicitud, el endpoint, el código de respuesta y la duración” (Reliability (se abre en una pestaña nueva), consultado el 2026-10-27).
Pero un registro también son datos, y crece. Planifica su limpieza desde el primer día. Yo uso una purga en dos fases: un lote semanal, el día más tranquilo, borra los éxitos al cabo de unos días y los errores al cabo de un mes más o menos, con los plazos en configuraciones personalizadas y un indicador de no borrar para todo lo que esté en investigación. Prepárate para explicar por qué limpias lo tuyo y no gastas el almacenamiento de datos del cliente.
Los reintentos son normales; hazlos seguros
Sección titulada «Los reintentos son normales; hazlos seguros »Las redes fallan, los servidores agotan el tiempo de espera, los tokens caducan, los servicios se caen, se alcanzan los límites. Un reintento no es la prueba de que la arquitectura falló. El problema es un sistema que no puede reintentar con seguridad. En el módulo 2, las claves hicieron seguro el reenvío de un manifiesto que agotó el tiempo: un upsert emparejó lo que ya se había guardado. Eso es la idempotencia: una operación que se puede repetir sin efectos adicionales no deseados. En los sistemas distribuidos la ambigüedad es normal: ¿falló la solicitud o la respuesta? Para el cliente parecen idénticas. Así que cada integración importante debería preguntarse: ¿qué pasa si este mensaje se procesa dos veces? Tarde o temprano, alguno lo hará.
¿Y cómo reintentas más tarde, cuando el usuario ya ha seguido con lo suyo? He visto funcionar dos diseños. Pon un estado de envío y un contador de reintentos en el registro que envías, y haz que un lote programado recoja los fallos que están por debajo del máximo de reintentos y los vuelva a enviar, y que avise a un administrador cuando se rinda. O guarda el estado y el contador en el registro de integración, con un enlace a lo que lleva. Programar un reintento puntual para cada fallo parece más sencillo, pero con volumen es frágil: diez mil fallos se convierten en diez mil trabajos programados.
Qué errores merecen un reintento, y cuánto esperar entre uno y otro, es tarea del capítulo 11 (Safe to Retry). La versión corta de Well-Architected: reintenta los tiempos agotados y los errores del servidor con espera progresiva, espera lo que te indiquen tras un límite de frecuencia, y nunca reintentes una solicitud que el servidor rechazó por no válida; corrígela.
El acuse de recibo
Sección titulada «El acuse de recibo »Volvamos ahora al estado hacia Redrock. Los eventos de plataforma son una buena forma de empujarlo: Salesforce publica y sigue adelante, y el suscriptor de la capa de integración lo entrega. Y el bus de eventos te da una red de seguridad. Salesforce conserva los eventos de plataforma 72 horas, y cada evento entregado lleva un Replay ID, así que un suscriptor que estaba desconectado pide todo lo posterior al último que vio (Event Message Durability (se abre en una pestaña nueva), Pub/Sub API, consultado el 2026-10-27).
Pero lee la letra pequeña. Salesforce publica los eventos de forma asíncrona, y en casos poco frecuentes un evento no se persiste; en palabras de Salesforce, esos eventos “no se entregan a los suscriptores y no se pueden recuperar”. La publicación además es de al menos una vez, así que el mismo evento puede publicarse de vez en cuando dos veces (Considerations for Defining and Publishing Platform Events (se abre en una pestaña nueva), consultado el 2026-10-27). Poco frecuente no es nunca. Entonces, ¿cómo consigue Salesforce su prueba de entrega?
El diseño más fiable que he construido es el acuse de recibo. Piensa en una carta certificada: te quedas una copia de lo que enviaste, y correos te devuelve una tarjeta firmada por la persona que la recibió.
Enviar: guarda tu propio registro y luego publica.
Cuando cambia el estado, Salesforce escribe un registro de notificación local y luego publica el evento de plataforma. El suscriptor lo recoge, desde su posición de reproducción si estaba desconectado, y llama al webhook de Redrock.
Firmar: el suscriptor devuelve el acuse.
Cuando Redrock lo acepta, el suscriptor llama de vuelta a Salesforce mediante la API estándar y marca la notificación como entregada. Fíjate en que los patrones se mezclan: eventos que salen, una llamada normal a la API que vuelve.
Barrer: lo que no tiene acuse se vuelve a enviar.
A small batch job sweeps the notifications: anything without a receipt after, say, three hours is published again. Because that can send a status twice, the subscriber keeps track of what it has already delivered and ignores repeats. Tonight’s hour of downtime is now an answer, not a mystery: 26,400 statuses published today, 26,397 receipts, three sent again. The receipts are the completeness check. And the notifications are a log like any other: purge them in two phases. ⟲
Conocimiento para el examen. Los eventos de plataforma y los eventos de Change Data Capture permanecen en el bus de eventos 72 horas, y cada evento entregado tiene un Replay ID desde el que un suscriptor puede reanudar. Los suscriptores deben esperar algún duplicado ocasional y gestionarlo. Para una entrega que tengas que poder demostrar, añade tu propio seguimiento: un registro de lo que se envió y una confirmación de vuelta.
El fallo parcial, y el aterrizaje suave
Sección titulada «El fallo parcial, y el aterrizaje suave »El fallo total suele ser más fácil: no pasó nada, arréglalo, vuelve a intentarlo. El fallo parcial es donde la arquitectura se pone interesante. 19.997 tienen éxito, 3 fallan. ¿Deshacer los 19.997? ¿Reintentar los tres? ¿Apartarlos para corregirlos? Depende de la transacción de negocio, pero “algunos fallaron” tiene que ser un estado que la arquitectura entienda, o las integraciones caen en uno de dos malos hábitos: ignorar los fallos o volver a ejecutarlo todo.
Para muchas integraciones de datos quiero separar los registros válidos de los no válidos: dejar que aterricen los buenos, capturar los malos con el motivo, corregirlos o enrutarlos y reintentar con seguridad. Lo llamo un aterrizaje suave. Un código postal erróneo no debería impedir que se actualicen 19.999 clientes que no tienen nada que ver. Pero los límites de la transacción importan: si esos 20.000 registros son una única transacción de negocio atómica, un éxito parcial puede ser inaceptable. Entiende el significado de negocio, no solo lo que permite la API.
Envía el incremento, no el universo
Sección titulada «Envía el incremento, no el universo »Cinco millones de clientes; diez mil cambiaron hoy. ¿Por qué enviar cinco millones esta noche? Envía el incremento: menos tráfico, procesamiento, bloqueos, automatización, superficie de error y conciliación, una recuperación más rápida y menos valores sin cambios sobrescritos. Pero incremental no es “LastModifiedDate y esperar que vaya bien”. ¿Qué significa “desde la última ejecución”: cuando empezó o cuando terminó? Se ejecutó de 1:00 a 1:20, un registro cambió a la 1:19, el trabajo falló a la 1:18; los relojes de dos sistemas no coinciden; los registros llegan tarde. Lo incremental necesita una marca de agua y un modelo de recuperación deliberados. El principio no cambia: sabe qué se ha procesado con seguridad antes de avanzar el punto de control. (Se aplica lo dicho sobre SystemModstamp en el capítulo 8.)
Cuatro formas de integración
Sección titulada «Cuatro formas de integración »Aquí entramos, brevemente, en el terreno del arquitecto de integración, porque el patrón mueve el punto de recuperación (Integration Patterns (se abre en una pestaña nueva), Salesforce Architects, consultado el 2026-10-27).
Cuatro formas, cuatro puntos de recuperación.
- Solicitud y respuesta: quien llama envía y espera. Intuitivo, pero un tiempo agotado deja igualmente a quien llama sin saber si el servidor confirmó los cambios.
- Disparar y olvidar: quien llama envía sin esperar el resultado posterior. Mejor desacoplamiento, pero ¿cómo sabe ahora alguien que el procesamiento acabó saliendo bien? Eso es lo que responde el acuse de recibo.
- Lotes: grupos de registros según una programación o como un trabajo, con lugares naturales para recuentos, totales de control, puntos de control y resultados por registro, y con el problema del fallo parcial a la vista.
- Eventos: un publicador anuncia que algo ocurrió; los suscriptores reaccionan. Puede que el publicador no conozca a todos los consumidores. Es dueño de la publicación; cada suscriptor es dueño del consumo, de su posición de reproducción y de sus duplicados.
Por eso veo los eventos de plataforma como una columna vertebral de la integración moderna con Salesforce: menos acoplamiento, consumidores que evolucionan de forma independiente. Pero los eventos no eliminan los problemas de fiabilidad; los desplazan. Change Data Capture aplica el mismo modelo a los cambios de los registros de Salesforce, publicando eventos de cambio para los objetos que elijas en lugar de obligar a alguien a preguntar “¿qué cuentas cambiaron?” (Change Data Capture Developer Guide (se abre en una pestaña nueva)). Potente para los incrementos. No entiendas “CDC resuelve la integración”; entiende “CDC cambia cómo se detectan y distribuyen los cambios”. Sigues necesitando claves para identificar los registros, autoridad, recuperación del consumidor, gestión de errores y observabilidad.
Mensajería saliente: conócela, no empieces por ahí
Sección titulada «Mensajería saliente: conócela, no empieces por ahí »Salesforce también tiene la mensajería saliente (outbound messaging), más antigua y todavía admitida. Salesforce dice que seguirá dándole soporte “within current functional capacities”, pero no prevé más inversión y aconseja prudencia al construir con ella (Data Integration with Salesforce (se abre en una pestaña nueva)). Además, cambió hace poco: desde Spring ‘26, los mensajes salientes ya no incluyen un ID de sesión, así que un receptor que llama de vuelta a Salesforce debe autenticarse con OAuth (Sending Session IDs in Outbound Messages Is Being Removed (se abre en una pestaña nueva)). Así que, para los diseños nuevos, pienso en eventos de plataforma, Change Data Capture, callouts desde Flow o Apex, API y los mecanismos masivos adecuados. La idea no es “tecnología antigua, mala”. Conoce lo que existe, entiende lo que heredas y diseña los sistemas nuevos sobre aquello en lo que Salesforce está invirtiendo.
Conocimiento para el examen. La mensajería saliente tiene soporte pero es heredada: sin más inversión, y sin ID de sesión en el mensaje desde Spring ‘26. Para los diseños nuevos de disparar y olvidar desde Salesforce, espera eventos de plataforma.
La monitorización forma parte de la integración
Sección titulada «La monitorización forma parte de la integración »Si una integración puede fallar en silencio, no está terminada. ¿Se está ejecutando? ¿Cuándo salió bien por última vez? ¿Cuántos registros procesó, cuántos fallaron y por qué, hasta dónde llegó, qué espera para reintentarse, a quién se avisa, cómo investigan y reanudan? No son preguntas de operaciones para más adelante. Una integración que se detuvo hace tres días es ya un problema de calidad de datos.
El modelo de salud de Well-Architected lo concreta. Junto a la salud del servicio, de la integración y de la capacidad, enumera la salud de los datos: trabajos de sincronización “todos al día” en verde, “con retraso” en amarillo, “fallidos o desfasados” en rojo. Y para las integraciones asíncronas vigila la profundidad de la cola: una cola que crece significa que el procesamiento se está quedando atrás (Reliability (se abre en una pestaña nueva), consultado el 2026-10-27). Para Steve Trucking, son dos cifras en un panel: las notificaciones sin acuse, y la antigüedad de la más antigua. Cuando se agotan los reintentos, el registro va a un lugar donde lo mira una persona, con una alerta, no al silencio.
Y la observabilidad también crea datos: registros, cargas útiles de error, colas de reintento, notificaciones, historial de auditoría. Guarda lo suficiente para investigar, conciliar, auditar y recuperar, y luego dale su propio ciclo de vida. No resuelvas un problema de datos creando otro en silencio.
Confía, pero verifica
Sección titulada «Confía, pero verifica »Confía en la API, en el middleware, en el bus de eventos, en el origen, en el destino. Luego verifica. ¿Llegaron los datos previstos? ¿Cambiaron los registros correctos? ¿Se capturaron los fallos? ¿Podemos dar cuenta de cada lote, reanudar tras una interrupción, demostrar el resultado? Eso no es pesimismo. Son los sistemas distribuidos.
Más allá del examen: lo que cambia la IA. “Agente, crea el cliente en el ERP.” La llamada agota el tiempo de espera; el agente reintenta. Si la acción no es idempotente, puedes acabar con dos clientes. O un proceso de agente de varios pasos crea un cliente, crea un pedido y luego falla al actualizar Salesforce: ¿en qué estado estamos? Los agentes inician y reintentan acciones distribuidas por su cuenta. El agente puede ser probabilístico; el contrato de integración no puede serlo. Da a las acciones de los agentes claves estables, idempotencia, un registro de lo que enviaron, una autoridad de escritura estrecha y observabilidad.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- En cada flecha, quién es el cliente y es dueño de la conversación, y quién sabe lo que debería llegar y se encarga de demostrar que llegó.
- Qué conciliación (recuentos, totales, acuses, puntos de control, controles de negocio) está a la altura del coste de unos datos que faltan o son erróneos.
- Dónde se registra cada llamada, qué se les dice a los usuarios, cómo se hacen los reintentos y cómo se purga el registro.
- Cómo se detiene, se reanuda y reintenta la integración sin duplicados, pérdidas ni avanzar su punto de control demasiado pronto.
- Si la solicitud y respuesta, disparar y olvidar, los lotes o los eventos encajan mejor con las necesidades de fiabilidad y de frescura, y dónde empieza la recuperación de cada uno.
- Qué monitorización (salud de los datos, profundidad de la cola, alertas) hace visible un fallo silencioso.
El diagrama del camino feliz es fácil: origen, flecha, destino. La arquitectura empieza cuando pregunto qué pasa si se detiene a medias, la respuesta desaparece, fallan tres registros, el mismo mensaje llega dos veces, el suscriptor está desconectado o nadie se dio cuenta de que lleva tres días sin ejecutarse. Quien sabe lo que debería llegar demuestra que llegó. Dale a ese lado claves, un registro, puntos de control, reintentos seguros, acuses, incrementos, fallos capturados y monitorización, y asegúrate de que pueda arrancar, detenerse y reanudarse con elegancia. Mover datos no ha terminado hasta que tienes la prueba de entrega.
Explora
Sección titulada «Explora »- Salesforce Developers, Pub/Sub API, Event Message Durability (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Salesforce Developers, Platform Events Developer Guide, Considerations for Defining and Publishing Platform Events (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Salesforce Architects, Well-Architected, Reliability (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Salesforce Architects, Data Integration with Salesforce (se abre en una pestaña nueva) and Integration Patterns (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Salesforce Developers, Change Data Capture Developer Guide (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Salesforce Help, Spring ‘26 release notes (release 260), Sending Session IDs in Outbound Messages Is Being Removed (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Este curso, capítulo 11: Safe to Retry.
- El curso Integration Architect: Eventos (coming soon), Bulk (coming soon) y Fallos y monitorización (coming soon).