Mantener otro sistema sincronizado

🌐 También en 19 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · 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. (4)

Módulo 5 de 5 del capítulo Migración y sincronización, capítulo 10 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: El fin de semana de corte · Siguiente: el próximo capítulo, Transacciones, concurrencia y confiabilidad

La pregunta que responde este módulo: ¿cómo llevas una copia de los datos de Salesforce a otro sistema, con volumen, y la mantienes al día?

Hasta ahora hemos hablado de meter datos en Salesforce. Los arquitectos de datos también tienen que sacarlos. No para salir de Salesforce: porque los datos viven en Salesforce, y otro sistema necesita una copia. Un almacén de datos como Snowflake para informes y análisis, un archivo o una copia de seguridad, otra organización de Salesforce, o un sandbox con datos realistas para un ensayo. El Número de Ceros también funciona al revés: sacar 500 registros es fácil; sacar 50 millones es arquitectura. Y la copia rara vez es algo de una sola vez. Normalmente el otro sistema la quiere hoy, y otra vez mañana, y cada día a partir de entonces.

Empieza por el dibujo

Este es el panorama de Steve Trucking después del corte. RouteDesk está retirado. Salesforce es el sistema de registro de cada entrega. Y una flecha lleva el historial de estados fuera de Salesforce, a través de la capa de integración, hasta Snowflake, donde viven los informes a cinco años de la dirección y los analistas.

Clic para ampliar

Salesforce guarda los datos. Snowflake guarda un espejo de ellos, cada día.

Salesforce no se va a ninguna parte. Snowflake no lo sustituye; Snowflake necesita una copia de una parte, mantenida sincronizada. Para eso sirve sacar los datos, y son dos problemas seguidos: la primera copia, que puede ser grande, y cada copia después, que tiene que estar al día.

Por qué sacarías muchos datos

La primera copia es la grande. Cuando Snowflake empieza a reflejar el historial de estados, necesita todo lo que hay hasta ahora, no solo los cambios de hoy. En Steve Trucking eso empieza justo después del corte: el módulo 3 aplazó el historial de estados de las 196.400 órdenes de trabajo migradas de RouteDesk a “una carga de recuperación después de la carga”. Esa carga de recuperación es la primera gran extracción de Salesforce. Y a medida que crece el negocio, cada espejo nuevo, cada almacén de informes nuevo, cada reconstrucción tras un problema empieza con una copia de todo.

Otras razones también te traen aquí: un archivo para los registros que salen del núcleo (capítulo 7), una copia de seguridad desde la que poder restaurar, otra organización de Salesforce que necesita una parte de los datos, un sandbox con datos realistas para un ensayo.

Y no lo exportes todo porque puedas. Ocho años de historial, archivos grandes, registros obsoletos, datos temporales, valores derivados, transacciones archivadas: entiende por qué se extrae cada clase. Cada registro tiene un coste en tiempo, almacenamiento, transformación, traslado, validación, conciliación, seguridad y obligaciones de retención posteriores. “Exporta toda la org” no es automáticamente una arquitectura.

Las formas de salir

Salesforce te da varias salidas, y encajan con trabajos distintos.

• Data Export Service. La exportación de datos de Configuración produce un zip de archivos CSV de toda la organización, semanal (ediciones Enterprise, Performance y Unlimited) o mensual (todas las ediciones salvo Database.com), bajo demanda o programado. Puedes ejecutarla manualmente una vez cada 7 días (semanal) o cada 29 días (mensual). Las ediciones Professional y Developer solo tienen la exportación mensual. Los archivos se eliminan 48 horas después de enviarse el correo, sin contar los fines de semana; los campos de fórmula y de resumen acumulado siempre se excluyen; y quien tenga el permiso Weekly Data Export puede ver todos los datos exportados (Export Backup Data from Salesforce (se abre en una pestaña nueva), Salesforce Help, consultado el 2026-10-27). Es una instantánea con forma de copia de seguridad, no una canalización de migración.
• Data Loader e informes. Data Loader exporta un objeto cada vez a CSV, con Export All para incluir los registros borrados y archivados; la exportación de un informe sirve para una extracción pequeña y con forma. Los dos están bien para miles de filas, no para decenas de millones.
• Consulta masiva. Para el volumen, el muelle de carga funciona en los dos sentidos: a veces el camión descarga, a veces lo están cargando. Una consulta masiva se ejecuta de forma asíncrona y devuelve sus resultados en archivos. Bulk API 2.0 gestiona los lotes por ti, y en las tablas grandes divide la propia consulta: sus trabajos de consulta “determinan automáticamente la mejor forma de dividir tu trabajo de consulta en bloques más pequeños, lo que ayuda a evitar fallos o tiempos agotados” (Understanding Bulk API 2.0 Query (se abre en una pestaña nueva), consultado el 2026-10-27). En Bulk API (1.0) lo activas tú, con PK chunking. La guía de grandes volúmenes de datos de Salesforce traza la línea: “Cuando uses una consulta que pueda devolver más de un millón de resultados, plantéate usar la capacidad de consulta de Bulk API 2.0” (Extracting Data from the API (se abre en una pestaña nueva), Winter ‘27, consultado el 2026-10-27).
• Un producto de copia de seguridad para la recuperación, como el propio Backup & Recover de Salesforce, que es un trabajo distinto de la migración: restaurar un momento dado, no mover los datos a un nuevo hogar.

Para un espejo, quiero que la extracción sea repetible, registrada y conciliable, así que normalmente significa una consulta masiva dirigida por un script, no por clics. La carga de recuperación de Steve Trucking es exactamente eso: una consulta masiva de las órdenes de trabajo migradas y su historial de estados, escrita en Snowflake una vez, y conciliada.

Conocimiento para el examen. Conoce las formas en que los datos salen de Salesforce y para qué sirve cada una. Data Export Service es una copia de seguridad programada de toda la organización en CSV (semanal o mensual según la edición; archivos conservados 48 horas; sin campos de fórmula ni de resumen acumulado). Data Loader y los informes sirven para extracciones pequeñas, objeto a objeto o con forma. La consulta de Bulk API gestiona el volumen de forma asíncrona. Un producto de copias de seguridad restaura un momento en el tiempo; no es una herramienta de migración.

Copias muy grandes: PK chunking

Cincuenta millones de registros como una sola consulta gigante puede que nunca terminen. El PK chunking divide la tabla por su clave primaria, el ID de registro: Salesforce añade límites de ID a tu consulta y la ejecuta como una serie de consultas más pequeñas, cada una un lote separado con sus propios resultados. El bloque predeterminado es de 100.000 registros y el máximo de 250.000. Salesforce lo recomienda para tablas de más de unos 10 millones de registros, o cuando una consulta masiva no deja de agotar el tiempo de espera. Ahí es donde yo también lo uso: es especializado, para exportaciones muy grandes. Es un encabezado de Bulk API 1.0, funciona en una lista definida de objetos, y cada bloque cuenta para la asignación diaria de lotes (PK Chunking (se abre en una pestaña nueva), consultado el 2026-10-27). Bulk API 2.0 hace la misma división por ti, pero un ORDER BY o un LIMIT la desactiva en cualquiera de las dos API, y entonces puede que la consulta agote el tiempo de espera.

Steve Trucking llegará ahí. Alrededor de un millón de órdenes de trabajo al año, con un crecimiento del 30 por ciento anual, suman unos 12,8 millones al final del año 6, salvo que el archivado del capítulo 7 mantenga la tabla más pequeña. Work Order está en la lista de objetos admitidos de Salesforce.

Clic para ampliar

Doce millones de filas se convierten en unas 52 consultas de 250.000.

La sintaxis está en la documentación. Lo que el arquitecto debería reconocer es el patrón: cuando cambia el Número de Ceros, puede que también tenga que cambiar la estrategia de extracción.

Conocimiento para el examen. Para extracciones muy grandes (la línea de Salesforce es de más de 10 millones de registros), el PK chunking divide una consulta masiva en intervalos de ID de registro, cada uno ejecutado y descargado por separado. Es un encabezado que se fija en Bulk API 1.0; los trabajos de consulta de Bulk API 2.0 dividen automáticamente. ORDER BY y LIMIT lo desactivan.

Luego, mantenlo al día

La primera copia es una instantánea. Cuando termina, el origen ya ha cambiado: los equipos cerraron entregas, los coordinadores cambiaron franjas, los socios revisaron manifiestos. Es normal. La arquitectura tiene que responder: ¿qué cambió después de nuestra base? Ese es el trabajo de una marca de agua: una marca de tiempo, una secuencia, un mecanismo de seguimiento de cambios, un identificador de origen. Conceptualmente dice: esto es lo que copiamos, este es el punto hasta el que estaba al día, estos son los cambios desde entonces. Sin esa frontera, procesar las diferencias es una conjetura. En el lado de Salesforce, la marca de agua suele ser SystemModstamp, que está indexado (capítulo 8): cada ejecución pide lo que cambió desde la marca de agua de la ejecución anterior, y solo avanza la marca de agua cuando la ejecución sale bien.

No olvides las eliminaciones. Un registro eliminado en Salesforce tiene que desaparecer también del espejo, o los informes lo seguirán contando. Una consulta normal no devuelve los registros eliminados; una consulta masiva con la operación queryAll “devuelve los registros que se han eliminado por una fusión o un borrado” (Create a Query Job (se abre en una pestaña nueva), Bulk API 2.0, consultado el 2026-10-27). Pero los registros eliminados permanecen en la Papelera de reciclaje 15 días como máximo, menos si alguien la vacía (Deleting Data (se abre en una pestaña nueva), Best Practices for Deployments with Large Data Volumes, consultado el 2026-10-27), así que un espejo que busca las eliminaciones con menos frecuencia se perderá algunas. Y un borrado definitivo se salta por completo la Papelera de reciclaje, así que planifica también cómo se entera el espejo de esos.

¿Con qué frecuencia? Esa es la pregunta del capítulo 9, y la propia orientación de Salesforce da la línea: las llamadas getUpdated() y getDeleted() de la SOAP API para intervalos de más de 5 minutos, y para cualquier cosa antes, deja que Salesforce envíe el cambio (Preguntar cada minuto). Steve Trucking hace las dos cosas: la carga de recuperación es una consulta masiva, y desde la marca de agua del corte en adelante, Change Data Capture envía cada cambio de estado a través de la capa de integración según ocurre.

Clic para ampliar

Una vez: la primera copia, todo lo que hay hasta ahora. Fija la marca de agua.

Clic para ampliar

Luego, cada cambio posterior a la marca de agua, según ocurre.

Clic para ampliar

Y cada pocos días, las eliminaciones. Una copia grande y luego un flujo de copias pequeñas.

Conocimiento para el examen. Para mantener otro sistema al día, extrae solo lo que cambió desde una marca de agua (SystemModstamp está indexado), y usa queryAll para detectar los registros eliminados o fusionados. Los registros eliminados permanecen 15 días en la Papelera de reciclaje, así que ejecuta la comprobación de eliminaciones con más frecuencia. Para los cambios que se necesitan en minutos, usa eventos (Change Data Capture) en lugar del sondeo.

Una copia una vez, o una copia para siempre

Esta es la distinción que uso: la migración tiene un principio y un final definidos. Pasamos de un estado a otro. Puede empezar con la primera extracción de producción, incluir varias cargas previas, durar una semana, incluir varias cargas delta. Sigue siendo una migración, porque tiene un destino: un punto en el que la migración está completa.

La sincronización es un proceso continuo para mantener coherentes dos sistemas. No hay un “migración completa, apágalo”. Los dos sistemas siguen siendo relevantes, los cambios siguen ocurriendo y tienen que moverse. Ahora volvemos al capítulo 9: ¿qué sistema es dueño del valor, en qué dirección se mueve, qué clave lo identifica, quién empuja y quién garantiza la integridad, cómo se reintentan y se monitorizan los fallos, qué pasa cuando los dos sistemas cambian lo mismo? En cuanto el requisito es “mantener coherentes estos sistemas”, ya no estamos diseñando una migración. Estamos diseñando una integración.

Steve Trucking tuvo una de cada, el mismo fin de semana. RouteDesk hacia Salesforce fue una migración: sus cargas de diferencias cerraron la distancia y luego terminó. Salesforce hacia Snowflake es sincronización: empezó ese fin de semana y nunca termina.

Clic para ampliar

El mismo fin de semana, dos flechas. Una tiene final, así que todo en ella es distinto.

Pero un delta no significa automáticamente sincronización. “Tenemos cargas delta, así que estamos sincronizando”. No necesariamente. Pregunta: ¿tiene el proceso un final definido? “Sí, ejecutamos estos deltas hasta el corte y luego se detiene el proceso heredado” sigue siendo una migración; los deltas nos ayudan a llegar a su estado final. “No, los dos sistemas siguen activos y esto los mantiene coherentes indefinidamente” es una sincronización. La operación puede parecer la misma. La obligación de arquitectura es distinta.

Conocimiento para el examen. Una migración tiene un final definido; la sincronización es continua. Las cargas de diferencias antes de un corte pertenecen a la migración. Mantener después otro sistema sincronizado con Salesforce es sincronización, y necesita un diseño de integración con un dueño claro para cada valor.

El espejo no es el maestro

Salesforce es dueño del estado de la entrega. Snowflake guarda una copia. Eso tiene que seguir siendo así. Supón que un analista ve un estado erróneo en Snowflake y lo corrige allí. Ahora los dos sistemas no coinciden, y la siguiente sincronización o bien sobrescribe la corrección o, peor, alguien construye un envío para devolverla. Entonces los dos sistemas creen que son dueños de Delivery Status. ¿Gana la última escritura? ¿Gana Salesforce? ¿Revisión humana? Si eso queda sin respuesta, no hemos construido un espejo; hemos creado dos copias editables. La regla del capítulo 9: el permiso técnico no es autoridad de arquitectura. Corrígelo en el origen, y deja que la sincronización lleve la corrección.

Así que escribe el contrato de la flecha, como hace el capítulo 9: quién es dueño de cada valor, hacia dónde se mueve, qué clave lo identifica, con qué frescura debe llegar, qué cuenta como entregado, cómo se reintentan los fallos, cómo se monitoriza, cuál es la marca de agua. No son preguntas del script de extracción; son preguntas del modelo operativo. La primera copia construye el estado inicial. La sincronización lo mantiene coherente.

Demuestra la primera copia, y sigue demostrándolo

Usa las cuatro pruebas del módulo 4 (recuentos, totales, comprobaciones puntuales, informes agregados) en la primera copia. Demuestra la base antes de que la sincronización se convierta en el modelo operativo normal, o la sincronización mantendrá fielmente un mal punto de partida. La integración no repara una mala copia solo porque se ejecute continuamente; puede mantener dos sistemas perfectamente sincronizados en torno a los datos equivocados.

Luego sigue demostrándolo. Un espejo que se detiene en silencio es un problema de calidad de datos con retraso: los informes parecen correctos y poco a poco se quedan desfasados. La prueba de entrega del capítulo 9 se aplica a cada ejecución: el lado que sabe lo que debería llegar comprueba que llegó, con recuentos frente a la ventana de la marca de agua, y se avisa a alguien cuando no es así.

La IA puede ayudar a detectar las desviaciones. Mantén determinista la frontera.

La IA puede ayudar a encontrar registros cambiados, diferencias inesperadas entre Salesforce y el espejo, anomalías, conflictos probables y registros que parecen haberse perdido. Útil. Pero “¿está ya este cambio en el espejo?” no debería depender de una suposición de una IA a partir del contexto. Lo deciden las marcas de agua, las claves, las reglas de propiedad y el estado.

Más allá del examen: lo que cambia la IA. La IA puede hacer mucho más rápidas la comparación y la detección de anomalías entre un sistema y su espejo. Mantén determinista la sincronización: las claves, la autoridad y las marcas de agua explícitas deciden qué se mueve y cuándo.

Lo que decide aquí un arquitecto

• Por qué existe cada copia de los datos de Salesforce, qué clases de datos necesita de verdad y qué sistema es dueño de cada valor.
• Qué mecanismo de exportación encaja con el trabajo y con el Número de Ceros: el Data Export Service, Data Loader o los informes, la consulta masiva o el PK chunking para tablas muy grandes.
• Qué marca de agua establece la base, cómo se capturan los cambios y las eliminaciones posteriores, y con qué frecuencia (sondeo o eventos).
• Si un movimiento de datos es una migración con final o una sincronización sin él, y qué contrato de integración mantiene coherente el espejo.
• Cómo se demuestra la primera copia, y cómo se comprueba cada ejecución posterior.

La sincronización te mantiene ahí

Sacar los datos no es salir de Salesforce. Es dar a otro sistema lo que necesita: una vez, con volumen, y luego cada día a partir de entonces, al día, completo y nunca como maestro. La primera copia es el gran trabajo; mantenerla al día es el largo. Recuerda la frase de este capítulo: una migración tiene un principio y un final definidos; la sincronización es un proceso continuo para mantener coherentes dos sistemas. La primera copia lleva el espejo hasta ahí. La sincronización lo mantiene ahí.

Explora

• Salesforce Help, Export Backup Data from Salesforce (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce, PK Chunking (se abre en una pestaña nueva), Understanding Bulk API 2.0 Query (se abre en una pestaña nueva), Create a Query Job (se abre en una pestaña nueva) and Bulk API and Bulk API 2.0 Limits and Allocations (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce, Best Practices for Deployments with Large Data Volumes, Deleting Data (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• En este curso: Integración y movimiento de datos (el contrato, sondeo o eventos, la prueba de entrega) y, para el historial fuera del núcleo, Diseñar para la escala.
• Salesforce Developers, Extracting Data from the API (se abre en una pestaña nueva), Best Practices for Deployments with Large Data Volumes, Winter ‘27, checked 2026-11-01. ⟲