Antes de la flecha
También en 19 idiomas
English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 1 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: el capítulo anterior, Arquitectura de consultas y recuperación · Siguiente: Claves y propiedad de la escritura
La pregunta que responde este módulo: ¿qué debe saber un arquitecto de datos sobre una integración antes de que nadie dibuje la flecha?
Empieza por el dibujo
Sección titulada «Empieza por el dibujo »Este es Steve Trucking al final de la Parte 1. En el Checkpoint 1 dibujé lo que yo diseñaría: los manifiestos de los socios que entran, el estado que vuelve a salir, la última posición de cada camión desde FleetLink, los eventos de estado hacia Snowflake, los recuentos de entregas hacia el ERP de finanzas. Y en medio de todas esas flechas, dibujé una caja y escribí en ella: Integración, diseñada en la Parte 2.
Esta es la Parte 2.
El panorama del Checkpoint 1. Cada flecha es una decisión sobre datos; este módulo se acerca a una.
Me encantan los panoramas de sistemas. Incluso dos cajas te protegen: pon una en una primera llamada y te sorprendería cuántos recuerdos se despiertan de repente. “Espera, ¿dónde está mi aplicación móvil? ¿Dónde está el envío de mis pedidos?” Pero un panorama tiene un punto débil, y son las flechas. Mira este. Todas las flechas son la misma línea fina. Una puede llevar un registro cada pocos minutos, otra 500 por minuto, otra un archivo nocturno de 200.000. Una es una solicitud en la que Salesforce espera una respuesta; otra es un evento que Salesforce publica y olvida. No son la misma arquitectura. El dibujo no muestra la diferencia. Así que antes de dibujar una flecha, quiero saber qué significa.
Eso es lo que significa antes de la flecha: las preguntas sobre los datos que respondes antes de que nadie elija REST, eventos, archivos o middleware.
“De eso se encarga el arquitecto de integración”
Sección titulada «“De eso se encarga el arquitecto de integración” »Quizá. En un programa grande, puede que otra persona diseñe las API, los eventos, las transformaciones y el middleware. Está bien. Este capítulo es un plato de degustación; el curso Integration Architect es el menú completo. Pero quiero saber sin falta lo que está planeando el arquitecto de integración, porque la integración está a punto de tocar mis datos. Una API que empuja cientos de registros por minuto es un problema de datos distinto de una carga masiva cada hora. Esas escrituras pueden disparar automatizaciones, recalcular el uso compartido, bloquear registros padre, ejecutar comprobaciones de duplicados y validaciones, actualizar resúmenes acumulados, hacer crecer el almacenamiento y desencadenar otras integraciones. El arquitecto de datos no tiene que construir la integración, pero decide qué se le permite hacer a los datos. Entiende el tráfico que viene.
Acércate a una flecha
Sección titulada «Acércate a una flecha »Así que elijamos una flecha y mirémosla de cerca: los manifiestos de Redrock, que entran por la capa de integración y llegan a Salesforce. En el capítulo 4 también nos acercamos a una flecha y vimos la fontanería: dónde escucha el servidor, cómo se autentica el cliente, el protocolo y la carga útil. Esa es la vista del arquitecto de integración. Esta es la vista del arquitecto de datos sobre el mismo tipo de flecha: siete preguntas, y lo que cada respuesta les hace a los datos.
Una flecha, siete preguntas. Ninguna de las respuestas nombra una tecnología.
Lee de arriba abajo la columna izquierda. Redrock la inicia. Los manifiestos van de Redrock a Salesforce. Se envían con uno o dos días de antelación, pero se revisan el mismo día. Unas 1.100 entregas al día llegan como un conjunto por centro de distribución cada tarde y luego como revisiones sueltas. La referencia de pedido y de entrega de Redrock identifica cada una. Redrock es dueño de lo que se pidió y de adónde va. Y Redrock, como cliente, es quien ve si la llamada funcionó.
Ahora la columna derecha, que es donde vive el arquitecto de datos. Un manifiesto reenviado debe actualizar, no duplicar. Redrock puede cambiar los artículos y la dirección, pero no el equipo. Un coordinador debe ver una revisión antes de que el camión salga del muelle. Unas 350.000 órdenes de trabajo al año bajan por esta única flecha, con un crecimiento del 30 % anual. Fíjate en lo que no está en ninguna de las dos columnas: REST, Bulk API, eventos de plataforma, MuleSoft. Elige el mecanismo antes de entender el movimiento y estarás diseñando al revés.
Las siete preguntas, para cada flecha importante:
- ¿Quién la inicia?
- ¿Hacia dónde se mueven los datos?
- ¿Con qué frescura los necesitan?
- ¿Cuántos datos, y con qué forma?
- ¿Cuál es la clave?
- ¿Quién puede escribir qué campos?
- ¿Quién sabe si funcionó, y quién recupera cuando no?
Este módulo recorre las cuatro primeras, más lo que cuesta una flecha. El módulo 2 trata la clave y la autoridad de escritura; el módulo 3, la última pregunta.
Quién la inicia no es hacia dónde se mueven los datos
Sección titulada «Quién la inicia no es hacia dónde se mueven los datos »¿Qué significa una flecha en un panorama de sistemas? Pregunta en una sala y obtendrás dos respuestas. Una: quién es el cliente y quién el servidor, quién abre la conexión. Dos: hacia dónde fluyen los datos. Las dos son razonables, y pueden apuntar en direcciones completamente opuestas. Un usuario se conecta a Salesforce y un mar de datos fluye de vuelta en la otra dirección. Así que tienes que decidir qué significan tus flechas. Yo dibujo las mías desde el sistema que abre la conexión, y pongo en la etiqueta qué se mueve y hacia dónde. Esa es la regla en todos los panoramas de este curso.
Toma FleetLink. En el Checkpoint 1 decidimos que Salesforce guarda solo la última posición de cada camión. Esos datos se mueven en un solo sentido: de FleetLink a Salesforce. Pero ¿quién lo inicia? Dos diseños:
- Salesforce pregunta. Cada pocos minutos, un trabajo programado en Salesforce llama a FleetLink: “¿Dónde están mis camiones?”. Salesforce es el cliente. Los datos siguen fluyendo FleetLink → Salesforce.
- FleetLink avisa. Cada vez que un camión se mueve lo suficiente, FleetLink llama a Salesforce con la nueva posición. FleetLink es el cliente. Los datos siguen fluyendo FleetLink → Salesforce.
Los mismos datos, la misma dirección, distinto iniciador. Y importa, porque el iniciador lleva la carga y la responsabilidad. En el primer diseño, Salesforce gasta sus propios límites haciendo llamadas, guarda las credenciales de FleetLink y tiene que gestionar que FleetLink esté caído. En el segundo, FleetLink gasta las llamadas a la API de Salesforce, y FleetLink tiene que darse cuenta cuando Salesforce rechaza algo. En clase lo llamo la dirección de la acción: quién inicia la acción, que puede ser distinta del flujo de los datos.
Salesforce pregunta. Salesforce la inicia; las posiciones fluyen FleetLink → Salesforce.
FleetLink avisa. FleetLink la inicia; las posiciones siguen fluyendo FleetLink → Salesforce.
En lo más básico, sigue siendo cliente y servidor. El cliente inicia la conversación y el servidor escucha. El servidor sabe si recibió, rechazó, procesó o falló la solicitud. Lo que no puede ver es si su respuesta llegó de vuelta. El cliente sí. Solo el cliente ve el viaje de ida y vuelta completo. Eso tiene una gran consecuencia para la recuperación, que el módulo 3 concreta.
Conocimiento para el examen. Separa quién inicia una integración de hacia dónde fluyen los datos. “Salesforce llama al ERP para obtener el estado de crédito” la inicia Salesforce, pero los datos fluyen del ERP a Salesforce. Espera escenarios que describen una cosa y preguntan por la otra.
¿Con qué frescura los necesitan?
Sección titulada «¿Con qué frescura los necesitan? »La primera palabra que cuestiono es “tiempo real”. ¿Por qué? ¿Qué pasa si tiene cinco segundos de antigüedad? ¿Treinta segundos, cinco minutos, una hora, mañana por la mañana? Hay requisitos de tiempo real de verdad, y muchos etiquetados como tiempo real porque nadie hizo la siguiente pregunta.
Enseño tres tiempos:
- Tiempo real es síncrono: quien llama espera la respuesta. Un usuario no puede dar el siguiente paso hasta que vuelve. Es el más difícil de construir y el que más gestión de errores tiene.
- Casi tiempo real es cualquier cosa desde menos de un segundo hasta un minuto, dos, quizá cinco. Hay una gran diferencia entre menos de un segundo y de uno a cinco minutos, y el casi tiempo real es mucho más barato y fácil de mantener que el tiempo real.
- Por lotes es cada hora, cada día o cada semana. De la vieja escuela, y a menudo exactamente lo correcto.
Ahora pon las flechas de Steve Trucking en esa escala.
| La flecha | Con qué frescura se necesita | Tiempo |
|---|---|---|
| Estado hacia Redrock, por webhook | Según ocurre: Redrock se lo muestra a sus propios clientes | Casi tiempo real, segundos |
| Última posición del camión, FleetLink → Salesforce | Unos minutos de antigüedad está bien para “tu camión está a unos 20 minutos” | Casi tiempo real, minutos |
| Revisiones del manifiesto de Redrock | Antes de que el camión salga del muelle | Casi tiempo real, minutos |
| Eventos de estado, Salesforce → Snowflake, a través de la capa de integración | Los paneles de hoy; nadie dirige la empresa con el último segundo | Casi tiempo real o lote cada hora |
| Archivo de estado para Keystone | Keystone lo pidió cada noche | Por lotes, diario |
| Recuentos de entregas para el ERP de finanzas | A los socios se les factura mensualmente | Por lotes, diario es más que suficiente |
Mira lo que falta: nada en este panorama necesita que Salesforce espere la respuesta de otro sistema. No es raro. El tiempo real cuesta más llamadas, más eventos, más procesamiento, más contención y más complejidad operativa, así que quiero un motivo para cada uno. Si una actualización nocturna cubre la necesidad, no me avergüenza usarla. La frescura es un requisito, no un valor por defecto.
El marco Well-Architected de Salesforce dice lo mismo desde el otro lado: el mecanismo que eliges fija cuánto puedes perder y cuán desfasada puede quedar una copia. Su guía de Reliability (se abre en una pestaña nueva) enumera las opciones de replicación según esa medida. Change Data Capture ofrece “replicación casi en tiempo real con un esfuerzo de desarrollo mínimo”. Los eventos de plataforma llevan tus propias cargas útiles, pero necesitan una lógica de publicación que construyes tú. Una extracción programada con Bulk API 2.0 es la más sencilla, “con un RPO igual a la frecuencia de extracción”: una extracción nocturna puede tener un día de desfase, por diseño.
Conocimiento para el examen. Empareja el tiempo con el mecanismo. Esperar una respuesta (solicitud y respuesta) necesita una llamada síncrona. Disparar y olvidar desde Salesforce: eventos de plataforma (los mensajes salientes son la opción más antigua). Mantener otro sistema sincronizado con los cambios de Salesforce: Change Data Capture. Grandes cargas programadas: Bulk API. Atento a los escenarios que dicen “inmediatamente” cuando el negocio solo necesita minutos.
Preguntar cada minuto
Sección titulada «Preguntar cada minuto »Hay una manera de conseguir casi tiempo real que parece sencilla: preguntar. Un proceso fuera de Salesforce llama de forma programada. “¿Ha cambiado algo? ¿Ha cambiado algo? ¿Ha cambiado algo?” Eso es el sondeo (polling). Una vez por minuto no suena terrible, hasta que haces la cuenta: 60 por 24 son 1.440 llamadas al día, para una pregunta, desde un sistema. Cada llamada usa una solicitud de API de tu asignación y pone su propia carga sobre Salesforce, haya cambiado algo o no.
Supón que el ERP de finanzas quiere los recuentos de entregas de Steve Trucking, y alguien construye un trabajo que pregunta a Salesforce cada cinco minutos. Son 288 llamadas al día y más de 105.000 al año, para unas cifras que el negocio factura una vez al mes. Casi todas esas llamadas vuelven sin nada que importe. El pilar Resource and Cost Optimization (se abre en una pestaña nueva) de Well-Architected tiene un nombre para eso: una integración que sondea cada cinco minutos y no encuentra nada “es puro desperdicio”. Un lote nocturno sirve mejor a finanzas, con una fracción de las llamadas.
Ahora toma Snowflake, que quiere cada cambio de estado, y pronto. Primera pregunta: ¿quién pregunta? No Snowflake. Una base de datos almacena; un proceso llama. Las tablas no inician conversaciones. Algo tiene que despertarse, hacer la llamada, gestionar el error, reintentar y escribir el resultado. Salesforce puede ser ese proceso para sus propias llamadas salientes, pero Salesforce no se sondea a sí mismo en nombre de otro sistema. Así que cuando ninguno de los dos extremos ejecuta el proceso que necesitas, añades una tercera pieza de software: el middleware, la capa de integración.
Look closely and even the “built-in” options are that third piece. Snowflake’s own Salesforce connector runs on Snowflake Openflow, which Snowflake describes as “an integration service” built on Apache NiFi; it polls Salesforce’s Bulk API 2.0 on a schedule, from every minute to once a day (Openflow (se abre en una pestaña nueva) and its Salesforce Bulk API connector (se abre en una pestaña nueva), checked 2026-10-27). Or you write a stored procedure that calls out through Snowflake’s external network access (se abre en una pestaña nueva) and schedule it as a task. Either way it’s a process, with its own credentials, schedule and failures, and someone has to own it. (When that connector’s page says it “supports Change Data Capture,” it means its own change detection by timestamp, not Salesforce’s change events.) Can it be done? Yes. Would I, and should I? That’s the architecture decision, not a feature of the database. ⟲
Así que la capa de integración puede sondear: cada minuto, “¿ha cambiado algo?”, 1.440 llamadas al día, la mayoría sin encontrar nada. O Salesforce puede avisarla. Podría construir el aviso yo mismo: un flujo desencadenado por registro en la orden de trabajo, consultar los campos, ponerlos en un evento de plataforma, y la capa de integración se suscribe y los escribe en Snowflake. Funciona. Luego alguien añade un campo a la orden de trabajo. Ahora tengo que añadirlo a la consulta del flujo, al evento de plataforma, y cambiar también el suscriptor y la tabla de Snowflake. Es código que mantener, para siempre, siguiendo el ritmo de la definición del objeto.
O activo Change Data Capture para la orden de trabajo. Ni flujo ni evento que mantener: Salesforce publica un evento de cambio por cada creación, actualización, eliminación y recuperación, con los campos modificados, y un campo nuevo se recoge automáticamente. Work Order y Service Appointment lo admiten, comprobado en el Object Reference (se abre en una pestaña nueva), Winter ‘27.
But count the zeros first. About 3,300 deliveries a day, with about 8 status changes each, is roughly 26,400 status changes a day, before any other field on the Work Order changes. CDC sends every change, not just status. And event delivery has a daily allocation: without an add-on, 50,000 delivered events in a rolling 24 hours for Performance and Unlimited Editions and 25,000 for Enterprise Edition, shared with high-volume platform events and counted per subscriber, so two subscribers use it twice (Change Data Capture Allocations (se abre en una pestaña nueva), checked 2026-10-27). When I first taught this, the warning was “you’re going to get a tsunami of data.” Today you can filter the stream (se abre en una pestaña nueva) in a custom channel, so the subscriber receives only the status changes it asked for. And the subscriber is middleware too: receiving change events means holding a subscription open to Salesforce’s Pub/Sub API, a job for an integration layer such as MuleSoft or a Kafka connector, not for the warehouse. Event-driven is better than polling for this arrow, but it still has a number of zeros. ⟲
La capa de integración pregunta con un reloj: 1.440 llamadas al día, la mayoría sin encontrar nada.
La capa de integración escucha en su lugar. Snowflake recibe de cualquier modo: una base de datos almacena; un proceso llama.
Las propias Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva) de Salesforce dan una forma más antigua del mismo consejo para mantener otro sistema sincronizado con Salesforce. Usa las llamadas getUpdated() y getDeleted() de la SOAP API “para sincronizar un sistema externo con Salesforce a intervalos de más de 5 minutos”, y “usa la función de mensajería saliente para una sincronización más frecuente” (Extracting Data from the API (se abre en una pestaña nueva), Winter ‘27, consultado el 2026-10-27). La idea sigue siendo válida. De forma programada, pide solo lo que cambió, y no olvides lo que se eliminó. Cuando tiene que ser antes, deja que Salesforce te avise. El mecanismo ha evolucionado: la mensajería saliente no recibe más inversión (módulo 3), así que hoy el aviso suele ser Change Data Capture o eventos de plataforma.
Conocimiento para el examen. Sacar los cambios de Salesforce de forma programada:
getUpdated()ygetDeleted()devuelven lo que cambió y lo que se eliminó en un intervalo de tiempo, para intervalos de más de 5 minutos. Con más frecuencia, deja que Salesforce envíe el cambio (la guía de Salesforce nombra la mensajería saliente; hoy, Change Data Capture o eventos de plataforma). Espera un escenario en el que una extracción completa cada pocos minutos es la respuesta equivocada.
El Número de Ceros también se aplica a las integraciones
Sección titulada «El Número de Ceros también se aplica a las integraciones »Luego: ¿cuánto? No “¿es mucho?”. Dame los ceros. Y no solo la cifra diaria; dime cómo llega. Un equipo de integración quiere tres cifras: transacciones por segundo, bytes por segundo y la ventana de actividad, las horas en que el tráfico circula de verdad. Puede que tengas 24 horas en un día, pero los datos no llegan a las 2 de la madrugada. Los equipos de Steve Trucking trabajan unas doce horas, así que esa es la ventana.
| El tráfico de Steve Trucking | Al día | Por segundo, en una ventana de 12 horas | Bytes |
|---|---|---|---|
| Posiciones de camiones desde FleetLink | unas 200.000 lecturas | unas 4,6 | minúsculo: una posición y una hora |
| Delivery status changes | about 26,400 | about 0.6 | small |
| Delivery photos | about 13,200 photos | about 0.3 | heavy: at about 4 MB each, 53 GB a day, 1.2 MB every second |
Mira las fotos: menos de una transacción cada tres segundos, y aun así la flecha más pesada del panorama. Las posiciones son lo contrario: el mayor número de transacciones, casi ningún byte. Muchos datos con pocas transacciones por segundo, o muchas transacciones por segundo con pocos datos: tienen perfiles de comportamiento completamente distintos. Cuenta ambos. Y planifica para la temporada de más actividad, no para el día medio.
También pienso en el tráfico de integración con tres formas:
- Uno a uno. Un registro cada vez: un cambio de estado, un pedido. Exactamente lo correcto para la actividad transaccional. Pero envía 100.000 registros uno a uno tan rápido como puedas, y un patrón razonable se convierte en una ametralladora: cada llamada tiene un coste adicional, puede ejecutar automatizaciones y compite por los recursos.
- Por conjuntos. Agrúpalos, decenas o cientos por llamada, y deja que el receptor procese grupos razonables. El manifiesto de la tarde de Redrock es un conjunto. Para muchas integraciones, el término medio es lo que mejor encaja.
- Masivo. Cientos de miles o millones de registros, como una carga histórica. No finjas que dos millones de registros son dos millones de pequeñas transacciones en tiempo real. Salesforce tiene Bulk API para el trabajo masivo: en clase la llamo el camión de dieciocho ruedas al lado del cajero del banco.
Es un modelo para enseñar, no una tabla de límites, pero hace que respetes los ceros.
La guía de Salesforce sí traza una línea con cifras: “Cualquier operación de datos que incluya más de 2.000 registros es una buena candidata para Bulk API 2.0”; por debajo, deberían ser llamadas síncronas “agrupadas” (bulkified), en REST (Composite, por ejemplo) o SOAP. Y cuando actualizas, “envía solo los campos que han cambiado” (Loading Data from the API (se abre en una pestaña nueva), consultado el 2026-10-27). Enviar todos los campos cada vez es la versión de integración de la ametralladora. El capítulo 10 tiene el resto de los consejos de carga de esa guía.
Uno a uno, por conjuntos y masivo. Un modelo para enseñar, no límites de la plataforma.
Conocimiento para el examen. Para cientos de miles o millones de registros, la respuesta es Bulk API, no muchas llamadas REST sueltas. La línea de Salesforce: más de 2.000 registros es un buen candidato para Bulk API 2.0; por debajo, llamadas síncronas agrupadas. Cuando los límites de la API aprietan con un conjunto de registros relacionados de distintos objetos, mira los recursos compuestos (composite), que llevan varias operaciones en una sola llamada. Al actualizar, envía solo los campos que cambiaron.
El volumen de integración se convierte en volumen de datos
Sección titulada «El volumen de integración se convierte en volumen de datos »Supongamos que un sistema externo va a crear 500 registros por minuto. Son 30.000 por hora, 720.000 al día si funciona sin parar: cientos de millones de operaciones al año. Quizá no funcione constantemente; quizá la mayoría sean actualizaciones. Bien, por eso quiero las cifras. Porque entonces empiezan las preguntas de datos. ¿A qué objeto llegan? ¿Cómo se reparte la propiedad? ¿Comparten padres? ¿Qué automatización se dispara, qué uso compartido se recalcula, se crean registros de historial, hay resúmenes acumulativos, cuál es la retención? ¿Podríamos crear un punto caliente? ¿Necesitamos todos y cada uno de estos registros en Salesforce?
Una integración puede crear por sí sola un problema de gran volumen de datos. “Cada vez que FleetLink envíe una posición GPS, crearemos un registro de Salesforce.” Son 200.000 al día: 73 millones de registros al año. Antes de preocuparme de si es REST, eventos o middleware, pregunto: ¿por qué íbamos a meter 73 millones de lecturas de GPS al año en el modelo de datos transaccional? En el Checkpoint 1 decidimos no hacerlo; a la organización solo le importa la última posición. El mecanismo de integración no responde a esa pregunta. Es una decisión de arquitectura de datos. A veces entender la integración rediseña el modelo; a veces rediseña la integración; a veces decide no mover los datos en absoluto.
Mover datos no es gratis
Sección titulada «Mover datos no es gratis »Cada copia tiene consecuencias: almacenamiento, frescura, sincronización, seguridad, privacidad, gestión como maestro, eliminación, conciliación. Copia datos de clientes del ERP a Salesforce y tendrás otra representación que gobernar. ¿Quién es su dueño? ¿Cuánto pueden quedarse obsoletos? ¿Qué pasa si alguien los cambia en Salesforce, o el ERP envía otro valor cinco minutos después, o el cliente pide que lo olviden, o un agente los actualiza? La flecha no solo transporta bytes. Está creando otro lugar donde hay que gobernar los datos de la empresa.
Dos de las siete preguntas son para el próximo módulo. ¿Cuál es la clave? Si Redrock reenvía la entrega 8472914, ¿Salesforce crea, actualiza, rechaza o vincula? Sin una clave estable, los reintentos se convierten en duplicados y la conciliación en conjeturas; por eso el Checkpoint 1 dio a cada orden de trabajo una clave que coincide con el pedido del socio. ¿Quién puede escribir? Si el ERP de finanzas es dueño de las condiciones de facturación y Salesforce es dueño de la cita y el equipo, una integración no significa “el ERP puede actualizar el registro”. Significa “el ERP puede actualizar estos campos”. Es el mapa de autoridad del capítulo 6 hecho ejecutable. Un diagrama de sistemas de registro que no cambia el comportamiento de escritura es decoración.
Y cuando falla
Sección titulada «Y cuando falla »Fallará. Aquí está otra vez nuestro panorama, en los mismos lugares, con la flecha a la que nos acercamos. El manifiesto de Redrock de esta noche, 370 entregas, llega a la capa de integración, y la llamada a Salesforce agota el tiempo de espera.
La flecha falla, en el panorama completo.
Ahora acércate a esa única flecha. Deja todo lo demás atrás: Salesforce a la izquierda, la capa de integración a la derecha y la llamada entre ellas.
Una flecha, un tiempo agotado.
Antes de seguir leyendo, para y respóndelo. ¿Se guardó el manifiesto? Hay tres respuestas honestas. Todo: Salesforce guardó las 370 órdenes de trabajo, y solo se perdió la respuesta de vuelta. Nada: la llamada nunca terminó. Una parte: se guardaron 367 y una regla de validación rechazó 3, y nadie ha leído todavía los errores. Salesforce sabe cuál ocurrió. La capa de integración, el cliente, solo sabe que no recibió respuesta.
Salesforce sabe lo que guardó. La capa de integración solo sabe que no oyó nada de vuelta.
Ahora la capa de integración hace lo que hacen los clientes: vuelve a enviar el manifiesto. Si cada orden de trabajo se empareja por la referencia de pedido y de entrega de Redrock, el reenvío actualiza lo que hay y crea solo lo que falta. Si no, y la primera llamada sí se había guardado, Steve Trucking tiene ahora 740 órdenes de trabajo para 370 entregas, y puede que se envíen dos equipos a la misma puerta. El mismo tiempo agotado, datos muy distintos. Por eso la clave va antes que el mecanismo (módulo 2), y por eso alguien tiene que hacerse cargo de saber si llegó todo (módulo 3).
El reenvío. Seguro con una clave; duplicados sin ella.
Un tiempo agotado es solo uno de los fallos habituales. Una carga útil mal formada, un token caducado, una regla de validación que rechaza un registro, un servidor caído, el registro 7.428 de 20.000 que falla, un evento entregado dos veces. Aquí la integración y la arquitectura de datos se vuelven inseparables. El arquitecto de integración piensa en reintentos, colas, reproducción, gestión de errores y monitorización. El arquitecto de datos piensa en duplicados, registros que faltan, estados parciales, valores desfasados, relaciones rotas y el sistema equivocado escribiendo. Dos vistas del mismo fallo.
Así que para cada flecha pregunto lo mismo. En cada flecha saliente: ¿dónde lo registro, qué le digo al usuario y cómo reintento? En cada flecha entrante: ¿cómo se recuperan ellos? Los errores ocurrirán.
Y “la API devolvió 200” no es calidad de datos. La interfaz funcionó. ¿Llegaron los 10.000 registros previstos, o 9.997? ¿Se rechazaron tres? ¿Duplicó algo un reintento? ¿Cambiaron los registros correctos? ¿Corrompió un valor una transformación? ¿Sobrescribimos campos que no son nuestros? Por eso mi regla recurrente encaja tan bien aquí: confía, pero verifica. El módulo 3 la concreta.
Más allá del examen: lo que cambia la IA. Un agente que consulta una entrega en otro sistema es una integración. Un agente que actualiza Salesforce mediante una API, o que llama a los servidores MCP alojados de Salesforce, es una integración; un agente que reintenta tras un fallo es un reintento de integración. Quien llama es nuevo; las preguntas no. ¿Quién la inicia? El agente, en nombre de un usuario, con los permisos de ese usuario. ¿Cuánto? Un agente puede hacer la misma pregunta muchas veces al día, así que el Número de Ceros crece con cada conversación (el asistente incansable (coming soon) del capítulo 16). Trata cada camino de lectura y escritura de un agente como una flecha, con identidad, autoridad, volumen, gestión de fallos y observabilidad.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Qué significa cada flecha importante: quién la inicia, hacia dónde se mueven los datos, con qué frescura deben llegar, y su volumen y su forma.
- Si “tiempo real” es un requisito o una costumbre, y qué tiempo necesita de verdad cada flecha.
- Qué proceso ejecuta cada flecha (Salesforce, el otro sistema o el middleware), si sondea o escucha los cambios, y lo que cuestan sus eventos en asignaciones.
- Si la integración presiona el modelo de datos mediante la automatización, los bloqueos, el uso compartido, el almacenamiento o el crecimiento del volumen.
- Si los datos deberían entrar en Salesforce en absoluto.
- Qué clave estable y qué autoridad de escritura necesita la integración, antes de elegir un mecanismo.
- Quién ve lo suficiente de la interacción como para verificar el éxito y ser responsable de la recuperación.
Los diagramas hacen que los sistemas parezcan limpios. Las integraciones reales son conversaciones entre sistemas que mueven datos bajo unas reglas y fallan de maneras concretas. No tienes que construir cada una, pero en cuanto la flecha empieza a mover datos, el diseño de la integración pasa a formar parte de tu arquitectura de datos. Así que antes de REST, Bulk API, eventos o middleware, acércate a la flecha y sabe qué significa. Luego diséñala.
Explora
Sección titulada «Explora »- On this site: Steve’s Number of Zeros for Integrations, the method from this module with four worked examples and a calculator to use with the business in the room. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva), Winter ‘27 (last updated September 18, 2026): Loading Data from the API (se abre en una pestaña nueva) and Extracting Data from the API (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Salesforce Architects, Data Integration with Salesforce (se abre en una pestaña nueva) (decision guide), checked 2026-11-01. ⟲
- Salesforce Architects, Well-Architected, Reliability (se abre en una pestaña nueva) and Resource and Cost Optimization (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Snowflake, Openflow (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Salesforce Developers, Change Data Capture Allocations (se abre en una pestaña nueva) (Change Data Capture Developer Guide), checked 2026-11-01. ⟲
- El curso Integration Architect: Cómo funciona una llamada y Tiempos y volumen (coming soon).
- Snowflake, About the Openflow Connector for Salesforce Bulk API (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Snowflake, External network access overview (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Salesforce Developers, Object Reference: StandardObjectNameChangeEvent (se abre en una pestaña nueva), Winter ‘27, checked 2026-11-01. ⟲
- Salesforce Developers, Change Data Capture Developer Guide: Add a Filter with Tooling API (se abre en una pestaña nueva), checked 2026-11-01. ⟲