Aller au contenu

Intégration et mouvement des données

Aussi en 19 langues

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Deutsch (Schweiz)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp.
Image générée par IA

Guide d’étude du chapitre 9 du cours Data Architect. Lisez d’abord les quatre modules ; cette page vous aide à vérifier ce que vous en avez retenu.

À propos de ce guide d’étude. Il est construit uniquement à partir du contenu de ce cours et de la liste des objectifs publiée dans le guide d’examen de Salesforce. Il ne s’appuie jamais sur de vraies questions d’examen et ne prétend pas savoir ce que contient l’examen. Si vous avez passé l’examen, merci de ne pas m’en envoyer les questions : l’accord de certification interdit de les partager, et apprendre des réponses par cœur n’est de toute façon pas la bonne manière de devenir architecte.

Le guide d’examen indique qu’il ne teste pas la configuration des outils d’intégration, et ce chapitre est une dégustation pour l’architecte de données, pas le cours Integration Architect. Ce qui compte pour l’examen, c’est ce que les intégrations font à vos données : les clés, l’autorité d’écriture, le volume et l’exhaustivité, et les données qui circulent entre organisations. Les chiffres de la plateforme changent, alors vérifiez les valeurs actuelles avant de vous y fier.

Cochez-les au fur et à mesure. Chacun renvoie à l’endroit où il est enseigné.

Avant la flèche (soutient LDV-1 et SDM-2)

  • I zoom out to the landscape, then zoom in on one arrow and ask its data questions: initiator, direction, freshness, volume and shape, key, write authority, and who proves it arrived. (Zoom In on One Arrow) ⟲
  • Je sépare qui initie de dans quel sens circulent les données, et je sais que seul le client voit l’aller-retour complet. (Qui lance l’échange, ce n’est pas le sens des données)
  • I treat freshness as a requirement, not a default, and match the timing to the mechanism: a synchronous call when the caller waits, platform events for fire and forget, Change Data Capture to keep another system in step, the Bulk API for large scheduled loads. (How Current Does It Need to Be?) ⟲
  • I know a database stores; a process calls: polling needs a process, often middleware, and polling for nothing is waste. Change Data Capture has a daily delivery allocation, counted per subscriber. (Asking Every Minute) ⟲
  • I know Salesforce’s guidance for pulling changes on a schedule: getUpdated() and getDeleted() for intervals over 5 minutes; more often than that, let Salesforce send the change. (Asking Every Minute) ⟲
  • I know the three traffic shapes, singles, sets and bulk; that more than 2,000 records is a good candidate for Bulk API 2.0, fewer for bulkified synchronous calls such as Composite; and to send only the fields that changed. (The Number of Zeros Applies to Integrations Too) ⟲
  • I know integration volume becomes data volume: ownership, automation, sharing and storage. (Integration Volume Becomes Data Volume) ⟲

Les clés et l’autorité d’écriture (soutient SDM-2, SDM-4 et MDM-2)

  • I carry an external system’s key in an External ID field marked Unique, one-to-one, and upsert on it: no match creates, one match updates, more than one fails. (One Record, One Key) ⟲
  • When one customer has several external records, I add records, not fields (a hierarchy, peers or a child object), never a key field per ERP. (When the Customer Is in Two ERPs, chapter 6: One Customer, Two ERPs) ⟲
  • I know one key field with the source in the value is still one key per record, and a new partner is a new value, not a new field. (Steve Trucking: One Field, the Source in the Value) ⟲
  • Je sais que des clés stables rendent les nouvelles tentatives sûres (le début de l’idempotence). (Les clés rendent les nouvelles tentatives sûres)
  • I know a key isn’t authority, and enforce write authority in the org: record types, read-only fields for users, and an integration user with only the access its contract needs. (A Key Isn’t Authority) ⟲
  • I know two-way movement still has one owner per field, and how unclear authority causes loops. (Two-Way Movement, One Owner per Field) ⟲
  • Je sais qu’un ID d’enregistrement d’une organisation Salesforce n’est pas une clé d’entreprise dans une autre : deux organisations sont deux systèmes. (Les clés ont aussi un cycle de vie)

Proof of delivery (supports MIG-1 and MIG-2) ⟲

Le contrat de données d’intégration (soutient SDM-4)

  • I can write an integration data contract for an arrow, eleven lines: initiator, direction, freshness, volume and shape, key, write authority, pattern, mechanism, proof of delivery, sensitivity and travel, and change. (An Arrow Needs More Than a Label) ⟲
  • I go requirement, then pattern, then mechanism. (Requirements, Then Pattern, Then Mechanism) ⟲
  • I know when to give another team a custom Apex REST endpoint instead of the standard APIs (one stable interface, my own logging and orchestration) and what it costs (code to maintain; API and Apex limits still apply). (A Contract Between Teams) ⟲
  • I count every place the data rests on its way, logs and retry queues included, when it has to stay in a country. (Make Each Line Specific) ⟲
  • For multiple orgs, I start with a contract per movement, and sometimes the contract says don’t move it (chapter 14). (Multiple Orgs, and “Don’t Move It”) ⟲

Where the rest lives. This chapter is about moving data. Not moving it (Salesforce Connect, mashups, data brought in on demand, zero copy: exam objective LDV-3) is chapter 14, Virtualization, Federation, and Zero-Copy (coming soon). Loading and extracting at volume is chapter 10, Migration and Synchronization. ⟲

L’examen est le plancher, pas le plafond. Voici les habitudes de ce chapitre dont un architecte a besoin, qu’une question les aborde ou non.

  • Zoom out, then zoom in. Start with the landscape; then take one arrow at a time. ⟲
  • Comprenez le trafic qui arrive, même quand quelqu’un d’autre conçoit l’intégration.
  • Choisissez le mécanisme après avoir compris le mouvement.
  • A database stores; a process calls. Someone has to own the process. ⟲
  • Le mouvement des données n’est pas gratuit. Chaque copie est un endroit de plus à gouverner.
  • Add records, not fields. ⟲
  • Connaissez l’enregistrement. Connaissez le propriétaire. Ensuite, laissez l’intégration écrire.
  • Whoever knows what should arrive proves that it did. ⟲
  • Si cela peut échouer sans bruit, ce n’est pas terminé. Une intégration arrêtée est un problème de qualité des données.
  • L’autorisation dit « peut » ; l’architecture dit « doit ».
  • Decide the interface between teams in the first weeks: the standard API or a wrapper you own. ⟲
  • Le contrat survit à la technologie.
  • Traitez chaque action d’agent comme une intégration, avec des clés, une autorité, de l’idempotence et de l’observabilité.
TermeEn une ligne
InitiateurLe système qui lance la conversation (le client)
Sens des donnéesLe sens dans lequel circulent les données métier, quel que soit celui qui lance l’échange
FreshnessHow current the data must be
PollingAsking on a schedule whether anything changed
À l’unité, par lots, en masseUn enregistrement à la fois, de petits groupes, ou de gros volumes en un seul traitement
External IDLa clé d’un autre système stockée sur l’enregistrement Salesforce, utilisée pour le rapprochement
UpsertMettre à jour l’enregistrement correspondant s’il existe, le créer sinon
IdempotenceRépéter une opération sans effets supplémentaires non voulus
Filigrane / point de repriseLa trace de jusqu’où une intégration est allée en sécurité
RapprochementComparer ce qui était prévu avec ce qui est arrivé
Proof of deliveryEvidence, held by the side that knows what should arrive, that it did
Return receiptAn acknowledgment sent back to say a message was received and processed
Request and replyThe client sends and waits for the answer
Fire and forgetThe client sends without waiting for the outcome
Platform eventUn message publié sur le bus d’événements de Salesforce pour des abonnés
Change Data CaptureLes événements que Salesforce publie quand des enregistrements changent
Replay IDLa position qu’un abonné utilise pour reprendre la lecture des événements
Custom Apex RESTYour own REST endpoint in Salesforce, written in Apex, in front of your objects
Contrat de données d’intégrationUne courte fiche de ce qu’une intégration peut faire aux données

De courts scénarios dans le style du cours. Décidez de votre réponse avant de l’ouvrir.

1. Salesforce appelle l'ERP pour obtenir la situation de crédit d'un client. Dans quel sens circulent les données, et qui initie ?

Salesforce initie ; les données circulent ERP → Salesforce. L’initiateur et le sens sont deux questions séparées, et l’initiateur (le client) est celui qui voit l’aller-retour complet. Relisez Qui lance l’échange, ce n’est pas le sens des données.

2. L'équipe propose de créer un enregistrement Salesforce pour chaque relevé GPS : 200 000 par jour. Que demandez-vous d'abord ?

Pourquoi mettre 73 millions de relevés par an dans le modèle transactionnel ? C’est une décision d’architecture de données avant d’être une décision d’intégration ; l’organisation n’a peut-être besoin que de la dernière position. Relisez Le volume d’intégration devient du volume de données.

3. A warehouse team says, "Snowflake will just poll Salesforce every minute." What's missing? ⟲

A database stores; a process calls. Something has to run the polling (usually an integration layer), with its own credentials, schedule and failures, and 1,440 calls a day mostly find nothing. Ask how current the data must be, then consider letting Salesforce send the changes (Change Data Capture), and count the events. Reread Asking Every Minute.

⟲
4. An external system needs Salesforce's changes about every hour, including deletions. What does Salesforce's own guidance suggest? ⟲

For intervals over 5 minutes, the SOAP API’s getUpdated() and getDeleted() return what changed and what was deleted in a window, instead of a full extract. More often than that, let Salesforce send the change. Reread Asking Every Minute.

⟲
5. The ERP retries a "create customer" call after a timeout and Salesforce ends up with two accounts. How should it have been designed? ⟲

Upsert on the ERP’s customer number in an External ID field marked unique, so a retry matches the existing record instead of inserting a duplicate. Reread Keys Make Retries Safe.

⟲
6. The customer exists in two ERPs, and someone proposes `NA_ERP_ID__c` and `EMEA_ERP_ID__c` on the Account. Your view? ⟲

That’s a key field per ERP: an anti-pattern. It hides repeating structure in fields and turns every new ERP into a schema change. Add records, not fields: child accounts, peer accounts, or a child object per ERP record, each with one key. Reread When the Customer Is in Two ERPs.

⟲
7. The integration log shows zero errors, but finance totals don't match. What happened, and who should have caught it? ⟲

Zero errors isn’t completeness: maybe fewer records were sent than intended, or values changed in transit. The side that knows what should have arrived proves it did: it reconciles counts and control totals against what it meant to send. Reread Who Proves It Arrived?.

⟲
8. A subscriber to platform events was down for a day. Can it catch up? ⟲

Yes, within the 72-hour retention: it resumes from its last Replay ID. It must also handle duplicates, because the same event can arrive twice. Reread The Return Receipt.

⟲
9. The requirement says "we need a REST integration for credit holds." What's wrong with that? ⟲

REST is a mechanism, not a requirement. The requirement is something like “agents see a credit hold within five minutes of the ERP change.” Start there, choose the pattern, then the mechanism, and write the contract. Reread Requirements, Then Pattern, Then Mechanism.

⟲
10. A partner's middleware team will send orders that touch four objects, and your data model changes every release. Standard API or custom Apex REST? ⟲

It depends on the team. If they know Salesforce deeply and can change quickly, the standard APIs work. If not, a custom Apex REST endpoint gives them one stable interface, lets Salesforce orchestrate the four writes and log every call, and absorbs your changes inside. The cost is code you maintain, inside Salesforce’s API and Apex limits. Decide in the first weeks. Reread A Contract Between Teams.

⟲