Sabe qué significa la flecha
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)
Capítulo 9 de Data Architect, Parte 2: Arquitectura a escala. Anterior: Arquitectura de consultas y recuperación.
La mayoría de los problemas de calidad de datos en una org conectada llegan a través de una integración. Duplicados por una clave que falta. Valores obsoletos por un lote que dejó de ejecutarse sin que nadie se diera cuenta. Campos sobrescritos por un sistema que nunca debió escribirlos. El arquitecto de datos no tiene que construir la integración. Pero el arquitecto de datos decide qué puede hacerles a los datos.
Image generated with AI. ⟲
Así que este capítulo es un plato de degustación: una muestra de la integración para el arquitecto de datos, con el menú completo en el curso Integration Architect. Empieza donde lo dejó el capítulo 4: cada flecha del panorama necesita un mecanismo. Ahora cada flecha necesita un significado.
Las ideas de este capítulo
Sección titulada «Las ideas de este capítulo »- Aleja la vista y luego acércala. Empieza por el panorama completo y luego toma una flecha cada vez y pregunta qué significa para los datos.
- Sabe lo que está planeando el arquitecto de integración, aunque lo construya otra persona. La forma del tráfico cambia el diseño de los datos.
- Quién inicia la conversación no es hacia dónde fluyen los datos, y solo el cliente ve el viaje de ida y vuelta completo.
- La frescura es un requisito, no un valor por defecto. Y una base de datos almacena; un proceso llama: el sondeo (polling) necesita un proceso, y sondear para nada es un desperdicio.
- Uno a uno, por conjuntos o masivo: respeta los ceros. El volumen de integración se convierte en volumen de datos.
- Una clave por registro, uno a uno, en un campo External ID marcado como único. Cuando un cliente tiene varios registros externos, añade registros, no campos: una jerarquía, pares o un objeto hijo (capítulo 6), nunca un campo de clave por sistema.
- Una clave no es autoridad. Las integraciones escriben los campos de los que es dueño su sistema, no “la cuenta”. El movimiento en dos sentidos sigue teniendo un dueño por campo.
- Prueba de entrega: el cliente es dueño de la conversación; quien sabe lo que debería llegar demuestra que llegó. Registra cada llamada, reanuda con elegancia, reintenta de forma segura y envía incrementos, no el universo.
- Los eventos de plataforma son la columna vertebral; la mensajería saliente es heredada, se sigue admitiendo pero no es donde empiezan los diseños nuevos.
- Cada flecha importante recibe un contrato, escrito antes de elegir el mecanismo, y sobrevive a la tecnología.
El contrato de datos de la integración
Sección titulada «El contrato de datos de la integración »Cada flecha importante recibe uno, de once líneas:
| Línea | La decisión |
|---|---|
| Iniciador | ¿Quién inicia la conversación? |
| Dirección de los datos | ¿Hacia dónde se mueven los datos de negocio? |
| Frescura | ¿Cuán actuales deben ser los datos, con una cifra? |
| Volumen y forma | ¿Cuánto, y uno a uno, por conjuntos o masivo? |
| Clave | ¿Cómo identificamos el mismo registro en distintos sistemas? |
| Autoridad de escritura | ¿Qué sistema es dueño de qué campos, y puede escribirlos? |
| Patrón | ¿Solicitud y respuesta, disparar y olvidar, lote o eventos? |
| Mecanismo | ¿Qué lo implementa? |
| Prueba de entrega | ¿Quién demuestra que llegó, y es responsable de la recuperación? |
| Sensibilidad y recorrido | ¿Cuán sensibles son los datos, y por dónde pasan? |
| Cambio | ¿Cómo cambia el contrato sin romper el otro lado? |
El recorrido de este capítulo
Sección titulada «El recorrido de este capítulo »Cuatro módulos, cada uno se sostiene por sí solo.
- Antes de la flecha. El panorama de sistemas de Steve Trucking y luego una flecha: quién la inicia y hacia dónde se mueven los datos, con qué frescura, sondear o escuchar, uno a uno, por conjuntos o masivo, y qué pasa cuando falla.
- Claves y propiedad de la escritura. Una clave por registro, upsert y reintentos seguros, añadir registros y no campos, autoridad por campo, y bucles.
- Prueba de entrega. Quién demuestra que llegó, el registro de integración, reanudaciones y reintentos, el acuse de recibo, las cuatro formas y la monitorización.
- El contrato de datos de la integración. Nueve contratos sobre el panorama, uno línea a línea; primero el requisito, luego el patrón, luego el mecanismo; la API estándar o la tuya propia; por dónde viajan los datos; y cuándo el contrato dice que no los muevas.
No mover los datos en absoluto (Salesforce Connect, mashups, zero copy) es el capítulo 14, Virtualization, Federation, and Zero-Copy (coming soon).
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Qué significa cada flecha: iniciador, dirección, frescura, volumen.
- Cómo siguen emparejados los registros entre sistemas, y quién puede cambiar qué campos.
- Quién demuestra la integridad y es responsable de la recuperación en cada movimiento.
- Si los datos deberían moverse en absoluto.
Más allá del examen: cada camino de lectura y escritura de un agente es una flecha de integración. Un agente que “actualiza el cliente” necesita una clave, un contrato de escritura estrecho, reintentos seguros y observabilidad, porque un llamador probabilístico está invocando operaciones empresariales deterministas. Cada módulo termina con lo que cambia la IA.
Explora
Sección titulada «Explora »- Salesforce Architects, Data Integration with Salesforce (se abre en una pestaña nueva) (decision guide), checked 2026-11-01. ⟲
- Salesforce Architects, Integration Patterns (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva), Winter ‘27, checked 2026-11-01. ⟲
Siguiente: Migración y sincronización