Integración y movimiento de datos

🌐 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)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés Esta sección cambió en inglés y aún no se ha vuelto a traducir. (2)

Guía de estudio del capítulo 9 del curso Data Architect. Lee primero los cuatro módulos; esta página te ayuda a comprobar qué se te ha quedado.

Sobre esta guía de estudio. Está construida solo con el contenido de este curso y con la lista de objetivos publicada en la guía del examen de Salesforce. Nunca se basa en preguntas reales del examen, y no pretende saber qué hay en el examen. Si ya hiciste el examen, por favor no me envíes preguntas: el acuerdo de certificación prohíbe compartirlas, y memorizar respuestas es, de todos modos, la forma equivocada de convertirse en arquitecto.

La guía del examen dice que no evalúa la configuración de herramientas de integración, y este capítulo es una muestra para el arquitecto de datos, no el curso Integration Architect. Lo que sí le importa al examen es lo que las integraciones hacen con tus datos: claves, autoridad de escritura, volumen e integridad, y datos que se mueven entre orgs. Las cifras de la plataforma cambian, así que comprueba las actuales antes de confiar en ellas.

Para el examen

Márcalos a medida que avanzas. Cada uno enlaza con el lugar donde se enseña.

Antes de la flecha (apoya LDV-1 y SDM-2)

• Alejo la vista hasta el panorama de sistemas, luego me acerco a una flecha y le hago sus preguntas de datos: iniciador, dirección, frescura, volumen y forma, clave, autoridad de escritura y quién demuestra que llegó. (Acércate a una flecha)
• Separo quién inicia de hacia dónde fluyen los datos, y sé que solo el cliente ve el viaje de ida y vuelta completo. (Quién la inicia no es hacia dónde se mueven los datos)
• Trato la frescura como un requisito, no como un valor por defecto, y emparejo el tiempo con el mecanismo: una llamada síncrona cuando quien llama espera, eventos de plataforma para disparar y olvidar, Change Data Capture para mantener otro sistema sincronizado, Bulk API para las grandes cargas programadas. (¿Con qué frescura los necesitan?)
• Sé que una base de datos almacena; un proceso llama: el sondeo necesita un proceso, a menudo un middleware, y sondear para nada es un desperdicio. Change Data Capture tiene una asignación diaria de entrega, contada por suscriptor. (Preguntar cada minuto)
• Conozco la orientación de Salesforce para extraer cambios de forma programada: getUpdated() y getDeleted() para intervalos de más de 5 minutos; con más frecuencia, deja que Salesforce envíe el cambio. (Preguntar cada minuto)
• Conozco las tres formas del tráfico, uno a uno, por conjuntos y masivo; que más de 2.000 registros es un buen candidato para Bulk API 2.0, y menos para llamadas síncronas agrupadas como Composite; y que hay que enviar solo los campos que cambiaron. (El Número de Ceros también se aplica a las integraciones)
• Sé que el volumen de integración se convierte en volumen de datos: propiedad, automatización, uso compartido y almacenamiento. (El volumen de integración se convierte en volumen de datos)

Claves y autoridad de escritura (apoya SDM-2, SDM-4 y MDM-2)

• Guardo la clave de un sistema externo en un campo External ID marcado como Único, uno a uno, y hago upsert con él: sin coincidencia crea, con una coincidencia actualiza, con más de una falla. (Un registro, una clave)
• Cuando un cliente tiene varios registros externos, añado registros, no campos (una jerarquía, pares o un objeto hijo), nunca un campo de clave por ERP. (Cuando el cliente está en dos ERP, capítulo 6: Un cliente, dos ERP)
• Sé que un solo campo de clave con el origen en el valor sigue siendo una clave por registro, y que un socio nuevo es un valor nuevo, no un campo nuevo. (Steve Trucking: un campo, el origen en el valor)
• Sé que las claves estables hacen seguros los reintentos (el principio de la idempotencia). (Las claves hacen seguros los reintentos)
• Sé que una clave no es autoridad, y hago cumplir la autoridad de escritura en la organización: tipos de registro, campos de solo lectura para los usuarios y un usuario de integración con solo el acceso que necesita su contrato. (Una clave no es autoridad)
• Sé que el movimiento en dos sentidos sigue teniendo un dueño por campo, y cómo una autoridad poco clara provoca bucles. (Movimiento en dos sentidos, un dueño por campo)
• Sé que un ID de registro de una org de Salesforce no es una clave de la empresa en otra: dos orgs son dos sistemas. (Las claves también tienen ciclo de vida)

Prueba de entrega (apoya MIG-1 y MIG-2)

• Sé que el cliente es dueño de la conversación, y quien sabe lo que debería llegar demuestra que llegó; el servidor cumple sus propias promesas e informa de lo que recibió. (¿Quién demuestra que llegó?)
• Sé que “sin errores” no es integridad: concilia los recuentos y, donde importe, los totales de control. (“Sin errores” no es integridad)
• Diseño para la reanudación y los reintentos seguros, y registro cada llamada: ID de solicitud, endpoint, código de respuesta y duración. (Sabe dónde estás, y reanuda con elegancia, Registra cada llamada, Los reintentos son normales; hazlos seguros)
• Sé que los eventos de plataforma y los eventos de Change Data Capture permanecen en el bus 72 horas, que los suscriptores reanudan por Replay ID, que puede haber duplicados y que la prueba necesita mi propio acuse de recibo. (El acuse de recibo)
• Conozco el aterrizaje suave ante el fallo parcial, y envío el incremento, no el universo. (El fallo parcial, y el aterrizaje suave, Envía el incremento, no el universo)
• Conozco las cuatro formas: solicitud y respuesta, disparar y olvidar, lotes y eventos, y dónde se recupera cada una. (Cuatro formas de integración)
• Sé que la mensajería saliente tiene soporte pero no recibe más inversión, y que desde Spring ‘26 no envía ID de sesión. (Mensajería saliente: conócela, no empieces por ahí)

El contrato de datos de la integración (apoya SDM-4)

• Sé escribir un contrato de datos de la integración para una flecha, de once líneas: iniciador, dirección, frescura, volumen y forma, clave, autoridad de escritura, patrón, mecanismo, prueba de entrega, sensibilidad y recorrido, y cambio. (Una flecha necesita más que una etiqueta)
• Sigo el orden requisito, luego patrón, luego mecanismo. (Primero los requisitos, luego el patrón, luego el mecanismo)
• Sé cuándo dar a otro equipo un endpoint Apex REST personalizado en lugar de las API estándar (una interfaz estable, mi propio registro y orquestación) y lo que cuesta (código que mantener; los límites de API y de Apex se siguen aplicando). (Un contrato entre equipos)
• Cuento cada lugar donde reposan los datos en su camino, registros y colas de reintentos incluidos, cuando tienen que quedarse en un país. (Haz concreta cada línea)
• Para varias organizaciones, empiezo por un contrato por movimiento, y a veces el contrato dice no lo muevas (capítulo 14). (Varias orgs, y “no lo muevas”)

Dónde está el resto. Este capítulo trata de mover datos. No moverlos (Salesforce Connect, mashups, datos traídos bajo demanda, zero copy: el objetivo de examen LDV-3) es el capítulo 14, Virtualization, Federation, and Zero-Copy (coming soon). Cargar y extraer con volumen es el capítulo 10, Migración y sincronización.

Más allá del examen

El examen es el piso, no el techo. Estos son los hábitos de este capítulo que necesita un arquitecto, los pregunte o no el examen.

• Aleja la vista y luego acércala. Empieza por el panorama; luego toma una flecha cada vez.
• Entiende el tráfico que se avecina, aunque otra persona diseñe la integración.
• Elige el mecanismo después de entender el movimiento.
• Una base de datos almacena; un proceso llama. Alguien tiene que hacerse cargo del proceso.
• Mover datos no es gratis. Cada copia es otro lugar que gobernar.
• Añade registros, no campos.
• Conoce el registro. Conoce al dueño. Luego deja que la integración escriba.
• Quien sabe lo que debería llegar demuestra que llegó.
• Si puede fallar en silencio, no está terminada. Una integración detenida es un problema de calidad de datos.
• El permiso dice qué se puede; la arquitectura dice qué se debe.
• Decide la interfaz entre equipos en las primeras semanas: la API estándar o un envoltorio del que eres dueño.
• El contrato sobrevive a la tecnología.
• Trata cada acción de un agente como una integración, con claves, autoridad, idempotencia y observabilidad.

Palabras que conviene conocer

Término	En una línea
Iniciador	El sistema que inicia la conversación (el cliente)
Dirección de los datos	Hacia dónde se mueven los datos de negocio, la inicie quien la inicie
Frescura	Cuán actuales deben ser los datos
Sondeo (polling)	Preguntar de forma programada si ha cambiado algo
Uno a uno, por conjuntos, masivo	Un registro cada vez, grupos pequeños o grandes volúmenes en un solo trabajo
External ID	La clave de otro sistema guardada en el registro de Salesforce, que se usa para emparejar
Upsert	Actualizar el registro que coincide si existe, crearlo si no
Idempotencia	Repetir una operación sin efectos adicionales no deseados
Marca de agua / punto de control	El registro de hasta dónde ha llegado de forma segura una integración
Conciliación	Comparar lo que se pretendía con lo que llegó
Prueba de entrega	La evidencia, en manos del lado que sabe lo que debería llegar, de que llegó
Acuse de recibo	Una confirmación enviada de vuelta para decir que un mensaje se recibió y se procesó
Solicitud y respuesta	El cliente envía y espera la respuesta
Disparar y olvidar	El cliente envía sin esperar el resultado
Evento de plataforma	Un mensaje publicado en el bus de eventos de Salesforce para los suscriptores
Change Data Capture	Eventos que publica Salesforce cuando cambian los registros
Replay ID	La posición que usa un suscriptor para reanudar la lectura de eventos
Apex REST personalizado	Tu propio endpoint REST en Salesforce, escrito en Apex, delante de tus objetos
Contrato de datos de la integración	Un registro breve de lo que una integración puede hacerles a los datos

Ponte a prueba

Escenarios cortos al estilo del curso. Decide tu respuesta antes de abrirla.

1. Salesforce llama al ERP para obtener el estado de crédito de un cliente. ¿Hacia dónde fluyen los datos, y quién inicia?

Inicia Salesforce; los datos fluyen ERP → Salesforce. El iniciador y la dirección son preguntas separadas, y el iniciador (el cliente) es quien ve el viaje de ida y vuelta completo. Vuelve a leer Quién la inicia no es hacia dónde se mueven los datos.

2. El equipo propone crear un registro en Salesforce por cada lectura de GPS: 200.000 al día. ¿Qué preguntas primero?

¿Por qué meter 73 millones de lecturas al año en el modelo transaccional? Es una decisión de arquitectura de datos antes que de integración; puede que la org solo necesite la última posición. Vuelve a leer El volumen de integración se convierte en volumen de datos.

3. Un equipo de almacén de datos dice: "Snowflake sondeará Salesforce cada minuto y ya está". ¿Qué falta?

Una base de datos almacena; un proceso llama. Algo tiene que ejecutar el sondeo (normalmente una capa de integración), con sus propias credenciales, su programación y sus fallos, y 1.440 llamadas al día casi nunca encuentran nada. Pregunta con qué frescura se necesitan los datos y luego plantéate dejar que Salesforce envíe los cambios (Change Data Capture), y cuenta los eventos. Vuelve a leer Preguntar cada minuto.

4. Un sistema externo necesita los cambios de Salesforce más o menos cada hora, incluidas las eliminaciones. ¿Qué sugiere la propia orientación de Salesforce?

Para intervalos de más de 5 minutos, getUpdated() y getDeleted() de la SOAP API devuelven lo que cambió y lo que se eliminó en una ventana, en lugar de una extracción completa. Con más frecuencia, deja que Salesforce envíe el cambio. Vuelve a leer Preguntar cada minuto.

5. El ERP reintenta una llamada de "crear cliente" tras un tiempo agotado y Salesforce acaba con dos cuentas. ¿Cómo debería haberse diseñado?

Upsert por el número de cliente del ERP en un campo External ID marcado como único, para que un reintento empareje el registro existente en lugar de insertar un duplicado. Vuelve a leer Las claves hacen seguros los reintentos.

6. El cliente existe en dos ERP, y alguien propone `NA_ERP_ID__c` y `EMEA_ERP_ID__c` en Account. ¿Qué opinas?

Es un campo de clave por ERP: un antipatrón. Esconde una estructura repetida en campos y convierte cada ERP nuevo en un cambio de esquema. Añade registros, no campos: cuentas hijas, cuentas pares o un objeto hijo por cada registro del ERP, cada uno con una clave. Vuelve a leer Cuando el cliente está en dos ERP.

7. El registro de integración muestra cero errores, pero los totales de finanzas no cuadran. ¿Qué pasó, y quién debería haberlo detectado?

Cero errores no es integridad: quizá se enviaron menos registros de los previstos, o los valores cambiaron por el camino. El lado que sabe lo que debería haber llegado demuestra que llegó: concilia los recuentos y los totales de control con lo que pretendía enviar. Vuelve a leer ¿Quién demuestra que llegó?.

8. Un suscriptor de eventos de plataforma estuvo caído un día. ¿Puede ponerse al día?

Sí, dentro de la conservación de 72 horas: reanuda desde su último Replay ID. También debe gestionar los duplicados, porque el mismo evento puede llegar dos veces. Vuelve a leer El acuse de recibo.

9. El requisito dice "necesitamos una integración REST para los bloqueos de crédito". ¿Qué falla?

REST es un mecanismo, no un requisito. El requisito es algo como “los agentes ven un bloqueo de crédito en los cinco minutos siguientes al cambio en el ERP”. Empieza por ahí, elige el patrón, luego el mecanismo, y escribe el contrato. Vuelve a leer Primero los requisitos, luego el patrón, luego el mecanismo.

10. El equipo de middleware de un socio enviará pedidos que tocan cuatro objetos, y tu modelo de datos cambia en cada versión. ¿API estándar o Apex REST personalizado?

Depende del equipo. Si conocen Salesforce a fondo y pueden cambiar rápido, las API estándar funcionan. Si no, un endpoint Apex REST personalizado les da una interfaz estable, permite a Salesforce orquestar las cuatro escrituras y registrar cada llamada, y absorbe tus cambios dentro. El coste es código que mantienes, dentro de los límites de API y de Apex de Salesforce. Decide en las primeras semanas. Vuelve a leer Un contrato entre equipos.

Explora

• Salesforce Certified Platform Data Architect Exam Guide (se abre en una pestaña nueva), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
• Salesforce, Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva), Winter ‘27 (last updated September 18, 2026), checked 2026-11-01: the guide behind the exam’s Large Data Volumes section. Its integration rules are in module 1; its mashups are in chapter 14. ⟲
• La sección Explora de cada módulo enumera la documentación de Salesforce detrás de sus datos, con la fecha en que se comprobaron.