Sappi cosa significa la freccia
Disponibile anche in 19 lingue
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Capitolo 9 di Data Architect, Parte 2: Architettare su larga scala. Precedente: Architettura delle query e del recupero dei dati.
In una org connessa, la maggior parte dei problemi di qualità dei dati arriva da un’integrazione. Duplicati per una chiave mancante. Valori vecchi per un batch che ha smesso di girare senza dirlo. Campi sovrascritti da un sistema che non avrebbe mai dovuto scriverli. L’architetto dei dati non deve costruire l’integrazione. Ma è l’architetto dei dati a decidere cosa le è permesso fare ai dati.
Image generated with AI. ⟲
Quindi questo capitolo è un piatto di assaggio: un assaggio di integrazione per l’architetto dei dati, con il pasto completo nel corso Integration Architect. Riparte da dove si era fermato il capitolo 4: ogni freccia del panorama ha bisogno di un meccanismo. Ora ogni freccia ha bisogno di un significato.
Le idee di questo capitolo
Sezione intitolata “Le idee di questo capitolo ”- Zoom out, then zoom in. Start with the whole landscape, then take one arrow at a time and ask what it means to the data. ⟲
- Sappi cosa sta pianificando l’architetto di integrazione, anche quando a costruirlo è qualcun altro. La forma del traffico cambia il progetto dei dati.
- Chi avvia la conversazione non è la direzione in cui viaggiano i dati, e solo il client vede l’intero andata e ritorno.
- Freshness is a requirement, not a default. And a database stores; a process calls: polling needs a process, and polling for nothing is waste. ⟲
- Singles, sets or bulk: respect the zeros. Integration volume becomes data volume. ⟲
- One key per record, one-to-one, in an External ID field marked unique. When one customer has several external records, add records, not fields: a hierarchy, peers or a child object (chapter 6), never a key field per system. ⟲
- A key isn’t authority. Integrations write the fields their system owns, not “the Account.” Two-way movement still has one owner per field. ⟲
- Proof of delivery: the client owns the conversation; whoever knows what should arrive proves that it did. Log every call, restart gracefully, retry safely, and send increments, not the universe. ⟲
- I platform event sono la spina dorsale; l’outbound messaging è un’eredità, supportato ma non il punto da cui partono i nuovi progetti.
- Every important arrow gets a contract, written before the mechanism is chosen, and it outlives the technology. ⟲
Il contratto dati dell’integrazione
Sezione intitolata “Il contratto dati dell’integrazione ”Every important arrow gets one, eleven lines: ⟲
| Line | The decision |
|---|---|
| Iniziatore | Chi avvia la conversazione? |
| Direzione dei dati | In che direzione si muovono i dati di business? |
| Freshness | How current must the data be, in a number? |
| Volume and shape | How much, and as singles, sets or bulk? |
| Key | How do we identify the same record across systems? |
| Write authority | Which system owns, and may write, which fields? |
| Pattern | Request and reply, fire and forget, batch, or events? |
| Meccanismo | Cosa lo implementa? |
| Proof of delivery | Who proves it arrived, and owns recovery? |
| Sensitivity and travel | How sensitive is the data, and where does it pass through? |
| Change | How does the contract change without breaking the other side? |
Il percorso di questo capitolo
Sezione intitolata “Il percorso di questo capitolo ”Quattro moduli, ognuno si regge da solo.
- Before the Arrow. Steve Trucking’s landscape, then one arrow: who starts it and which way the data moves, how current, polling or listening, singles, sets and bulk, and what happens when it fails. ⟲
- Keys and Write Ownership. One key per record, upsert and safe retries, add records not fields, field-level authority, and loops. ⟲
- Proof of Delivery. Who proves it arrived, the integration log, restarts and retries, the return receipt, the four shapes and monitoring. ⟲
- The Integration Data Contract. Nine contracts on the landscape, one line by line; requirement, then pattern, then mechanism; the standard API or your own; where the data travels; and when the contract says don’t move it. ⟲
Not moving data at all (Salesforce Connect, mashups, zero copy) is chapter 14, Virtualization, Federation, and Zero-Copy (coming soon). ⟲
Cosa decide qui un architetto
Sezione intitolata “Cosa decide qui un architetto ”- What each arrow means: initiator, direction, freshness, volume. ⟲
- Come i record restano abbinati tra sistemi diversi, e chi può cambiare quali campi.
- Chi dimostra la completezza e risponde del ripristino per ogni movimento.
- Se i dati debbano muoversi del tutto.
Oltre l’esame: ogni percorso di lettura e scrittura di un agente è una freccia di integrazione. Un agente che “aggiorna il cliente” ha bisogno di una chiave, di un contratto di scrittura stretto, di ritentativi sicuri e di osservabilità, perché un chiamante probabilistico sta invocando operazioni aziendali deterministiche. Ogni modulo si chiude con cosa cambia l’IA.
Per approfondire
Sezione intitolata “Per approfondire ”- Salesforce Architects, Data Integration with Salesforce (si apre in una nuova scheda) (decision guide), checked 2026-11-01. ⟲
- Salesforce Architects, Integration Patterns (si apre in una nuova scheda), checked 2026-11-01. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes (si apre in una nuova scheda), Winter ‘27, checked 2026-11-01. ⟲
Successivo: Migrazione e sincronizzazione