Sei pattern che gli architetti usano per evitare i blocchi delle integrazioni Salesforce

Abbina il pattern al carico di lavoro, punta su design asincroni e guidati dagli eventi quando il volume o il rischio di accoppiamento sono alti, blinda l'identità con Named Credentials e OAuth con ambiti ristretti, e affida orchestrazione, tentativi ripetuti e trasformazione al middleware invece che a codice Apex di raccordo. Platform Events, Change Data Capture e Data Cloud coprono la maggior parte degli scenari disaccoppiati ad alto volume, mentre Named Credentials e i flussi OAuth moderni rendono ogni connessione verificabile. Prima del prossimo avvio di un'integrazione, dedica cinque minuti a un controllo dei pattern sul design attuale. Di solito emerge almeno un punto in cui una chiamata sincrona sta facendo, in silenzio, il lavoro che spetterebbe a un evento.

---

In breve:

• Usa pattern guidati dagli eventi come Platform Events o Change Data Capture per scenari ad alto volume e disaccoppiati: riduci le chiamate sincrone e migliori la scalabilità.

• Fai un controllo dei pattern di cinque minuti prima dell'implementazione per individuare le chiamate sincrone che andrebbero sostituite da integrazioni basate su eventi, soprattutto sotto carico elevato.

• Scegli per default metodi di integrazione asincroni, a meno che l'utente non stia attivamente aspettando un riscontro immediato: eviti problemi di governor limit ed errori di blocco delle righe.

• Preferisci la virtualizzazione dei dati con Salesforce Connect per dati esterni che cambiano spesso e non devono essere archiviati dentro Salesforce, oppure usa la replica per i dati che servono di frequente in report e flow.

• Applica pratiche di sicurezza complete: conserva le credenziali nelle Named Credentials, riduci al minimo gli ambiti OAuth, ruota regolarmente i token e limita le impostazioni dei siti remoti ai domini attendibili.

Indice

• Quali sono i pattern di integrazione fondamentali di Salesforce?

• Come scegli il pattern di integrazione giusto?

• Meglio un'integrazione sincrona o asincrona?

• Replica o virtualizzazione: quale strategia dei dati vince?

• Di quali controlli di sicurezza ha bisogno ogni integrazione?

• Come costruisci integrazioni resilienti e osservabili?

• Quando conviene usare il middleware invece degli strumenti nativi di Salesforce?

• Cosa deve contenere la checklist di integrazione di un architetto?

• Il nostro punto di vista su dove i progetti di integrazione falliscono davvero

• Come Ampersand Labs supporta i progetti di integrazione Salesforce

• Fonti

• Domande frequenti

Quali sono i pattern di integrazione fondamentali di Salesforce?

L'architettura di integrazione di Salesforce si divide in tre categorie: processi, dati e virtuale. Ognuna risolve un problema diverso, e sceglierne una sbagliata è di gran lunga la causa più frequente di integrazioni fragili che cedono sotto carico.

L'integrazione di processo collega processi aziendali tra sistemi, di solito per far avanzare un flusso di lavoro quasi in tempo reale. L'integrazione dei dati copia o sincronizza i record tra sistemi, così che ognuno abbia la propria copia coerente. L'integrazione virtuale evita del tutto la copia e interroga il sistema di origine su richiesta. La documentazione di architettura di Salesforce descrive questa three-way split and a selection matrix che collega ogni categoria a pattern specifici, e vale la pena tenerla aperta durante ogni sessione di design.

All'interno di queste tre categorie, sei pattern coprono quasi tutto ciò che ti capiterà di costruire:

• Richiesta e risposta: una chiamata sincrona in cui il chiamante resta bloccato finché non riceve una risposta, tipicamente via REST o SOAP. Ideale per le ricerche rivolte all'utente che devono rispondere in meno di un secondo, come una verifica del credito durante il checkout. Modalità di guasto: se il sistema a valle è lento, i timeout si ripercuotono a cascata sull'utente.

• Invia e dimentica: il chiamante spedisce un messaggio e prosegue senza attendere conferma. Utile per log, notifiche o per qualsiasi caso in cui il chiamante non debba conoscere subito l'esito. Modalità di guasto: perdita silenziosa dei messaggi se non c'è un livello di conferma o di tentativi ripetuti.

• Sincronizzazione dati in batch: grandi volumi si spostano secondo una pianificazione, di solito notturna, usando la Bulk API. Adatta alle sincronizzazioni verso un data warehouse o alla riconciliazione di sistemi legacy, dove il quasi tempo reale non serve. Modalità di guasto: guasti parziali del batch che lasciano due sistemi disallineati fino all'esecuzione successiva.

• Chiamata remota in entrata: un sistema esterno chiama Salesforce, spesso via REST API o endpoint Apex REST, per leggere o scrivere record. Comune per app mobile o portali per partner. Modalità di guasto: si raggiungono i governor limit quando i sistemi esterni non rispettano i tetti per transazione di Salesforce.

• Virtualizzazione dei dati: Salesforce interroga su richiesta i dati di un sistema esterno invece di conservarne una copia, tipicamente tramite Salesforce Connect e OData o adattatori personalizzati. Adatta ai casi in cui i dati cambiano troppo spesso per tenerli replicati, o in cui il costo di archiviazione e la duplicazione sono un problema. Modalità di guasto: l'intera esperienza peggiora se i tempi di risposta del sistema esterno si allungano.

• Pubblicazione e sottoscrizione: un evento viene trasmesso una volta e un numero qualsiasi di sottoscrittori lo riceve, usando Platform Events, Change Data Capture o la Pub/Sub API. È il pattern per gli scenari di notifica uno-a-molti, come avvisare cinque sistemi a valle nel momento in cui un'opportunità si chiude. Modalità di guasto: sottoscrittori che restano indietro rispetto alla finestra di conservazione degli eventi e perdono messaggi in modo definitivo.

Le Salesforce blog’s own guidance on aligning patterns to use cases mettono in evidenza un punto che vale la pena ripetere: gli approcci guidati dagli eventi non bloccano il chiamante e gestiscono la concorrenza molto meglio delle chiamate sincrone quando i volumi crescono. È il pattern a cui la maggior parte degli architetti ricorre troppo tardi, dopo che un'integrazione sincrona ha già causato un incidente in produzione.

Come scegli il pattern di integrazione giusto?

Passa ogni decisione di integrazione attraverso sei dimensioni prima di scrivere una riga di codice: requisiti temporali, proprietà dei dati, volume dei dati, esigenze transazionali, semantica dei guasti e SLA di latenza. Saltare questo passaggio è il motivo per cui i team finiscono per innestare un bus di eventi su qualcosa costruito sei mesi prima come chiamata sincrona.

La tempistica chiede se il processo aziendale ha bisogno di un risultato adesso o può tollerare un ritardo. Un preventivo richiesto al checkout è diverso da un calcolo mensile delle provvigioni. La proprietà dei dati chiede quale sistema sia la fonte di verità. Se Salesforce non è il riferimento autorevole per il catalogo prezzi, non replicarlo in Salesforce sperando che resti aggiornato. Il volume dei dati, a volte indicato come LDV (large data volumes), determina se ti servono la Bulk API e job asincroni al posto di qualsiasi cosa transazionale.

Le esigenze transazionali riguardano il fatto che un'operazione debba riuscire o fallire come blocco unico. La semantica dei guasti chiede cosa succede quando un sistema a valle è irraggiungibile. Il record entra in coda per un nuovo tentativo, l'utente vede un errore, oppure il record viene scartato? Lo SLA di latenza è il tetto massimo di tempo di risposta accettabile, e deve arrivare dal business, non da ciò che è comodo da costruire.

Alcuni scenari si mappano in modo chiaro:

• Un tecnico sul campo che verifica le scorte in tempo reale prima dell'intervento ha bisogno di richiesta e risposta oppure, se il volume è alto, di virtualizzazione dei dati tramite Salesforce Connect.

• Un'opportunità che si chiude e deve attivare una notifica Slack, un ordine nell'ERP e un flag nella marketing automation rientra in pubblicazione e sottoscrizione con Platform Events, perché tre sistemi distinti hanno bisogno dello stesso segnale.

• Un aggiornamento notturno del catalogo prodotti da un sistema ERP appartiene alla sincronizzazione in batch con Bulk API, non a una chiamata in tempo reale a ogni salvataggio.

• Un portale per partner che scrive lead in Salesforce durante l'orario di lavoro è un candidato per la chiamata remota in entrata, protetta con una connected app dagli ambiti ristretti.

Per l'uso in workshop, una breve checklist tiene la discussione con i piedi per terra: qual è lo SLA di latenza, in secondi o in ore? Chi possiede il record dopo questa transazione? Qual è il volume giornaliero atteso? Cosa succede in caso di guasto: nuovo tentativo, avviso o scarto? Serve una consegna garantita una sola volta, oppure la gestione dei duplicati a valle è accettabile? Rispondi a queste cinque domande prima di aprire il catalogo dei pattern, e la scelta giusta di solito è evidente.

Meglio un'integrazione sincrona o asincrona?

Scegli l'asincrono per default, a meno che l'utente non stia davvero aspettando il risultato davanti allo schermo. Questa singola regola previene la maggior parte dei problemi di governor limit e di blocco che gli architetti incontrano dopo il go-live.

Le integrazioni sincrone sembrano più facili da costruire, ed è proprio per questo che i team ci ricadono anche quando il caso aziendale non lo richiede. La stessa analisi di Salesforce sugli errori architetturali più comuni indica l'eccessiva dipendenza dalle chiamate sincrone come schema di guasto ricorrente, di solito perché nessuno ha verificato lo SLA reale prima di scrivere l'integrazione. Una chiamata sincrona che blocca una transazione Salesforce in attesa di una API esterna lenta rischia di raggiungere il limite di tempo CPU e, se quel sistema esterno scrive anche sugli stessi record, ottieni contese di blocco delle righe che si manifestano come errori casuali UNABLE_TO_LOCK_ROW sotto carico.

La soluzione di disaccoppiamento è quasi sempre la stessa: togli la scrittura dal percorso critico. Pubblica un Platform Event invece di fare la chiamata diretta, lascia che un sottoscrittore lo elabori in modo asincrono e dai all'utente una conferma immediata invece di una rotellina che gira. Change Data Capture funziona bene quando devi reagire alle modifiche dei record senza scrivere logica di trigger per ogni oggetto, perché pubblica automaticamente gli eventi di modifica in base alla sottoscrizione. La Pub/Sub API è il canale più recente, basato sui protocol buffer, che supporta sia la pubblicazione sia la sottoscrizione su larga scala, ed è la strada consigliata per i flussi di eventi ad alto throughput d'ora in avanti.

Alcune regole pratiche reggono nella maggior parte dei progetti:

• Se l'utente fissa lo schermo in attesa del risultato, il sincrono è probabilmente la scelta giusta.

• Se tre o più sistemi devono conoscere lo stesso evento, pubblicazione e sottoscrizione batte tre chiamate punto a punto separate.

• Se il volume può impennarsi in modo imprevedibile, l'asincrono con una coda assorbe il picco; il sincrono va semplicemente in timeout.

• Se la disponibilità del sistema esterno è peggiore di quella di Salesforce, non lasciare che i suoi tempi di fermo si portino dietro anche Salesforce.

Consiglio pratico: Tieni d'occhio il budget di chiamate API quando pubblichi eventi tramite l'endpoint REST API invece che nativamente da Apex o Flow. Le indicazioni della community segnalano che gli eventi pubblicati via API vengono conteggiati nel limite giornaliero di chiamate API, mentre i metodi di pubblicazione nativi no, e questa differenza pesa parecchio quando pubblichi migliaia di eventi al giorno.

Replica o virtualizzazione: quale strategia dei dati vince?

Copia i dati in Salesforce quando devono essere veloci, interrogabili e utilizzabili nei report all'interno della piattaforma. Lasciali esterni e interrogali su richiesta quando cambiano troppo spesso per restare sincronizzati o quando duplicarli crea grattacapi di conformità.

La replica significa conservare una copia dei dati esterni sotto forma di record Salesforce, aggiornata secondo una pianificazione o tramite eventi. È la scelta giusta per tutto ciò su cui gli utenti creano report dentro Salesforce o a cui fanno riferimento in flow e regole di convalida, dato che i dati virtualizzati non sempre lo supportano nativamente. La virtualizzazione, tramite Salesforce Connect e gli oggetti esterni, salta la copia e interroga il sistema di origine in tempo reale. È adatta a cataloghi ampi che cambiano di continuo, come la tabella prezzi in tempo reale di un distributore, dove mantenere una copia sincronizzata significherebbe job di sincronizzazione continui, in bilico tra aggiornamento dei dati e costo di archiviazione.

Gli approcci zero-copy vanno oltre. Le indicazioni di Salesforce sui pattern di integrazione di Data 360 descrivono modalità di acquisizione che permettono a Data Cloud di fare riferimento ai dati dove si trovano, invece di duplicarli in ogni sistema collegato: un aspetto rilevante quando un data warehouse e Salesforce hanno entrambi bisogno dello stesso record cliente senza diventare due fonti di verità.

La proprietà dei dati anagrafici va definita prima che venga scritto qualsiasi job di sincronizzazione, non dopo. Decidi fin dall'inizio quale sistema è autorevole per ogni entità, cliente, prodotto, prezzi, e mettilo per iscritto come un contratto sullo schema che entrambi i team approvano. La logica di deduplicazione va collocata al momento dell'acquisizione, non in un job di pulizia sei mesi dopo, quando gli account duplicati hanno già inquinato ogni report a valle.

Alcune protezioni pratiche:

• Tratta lo schema come un contratto tra sistemi; una modifica al tipo di un campo, da una parte o dall'altra, deve richiedere un'approvazione, non solo un deploy.

• Usa Salesforce Connect per dati esterni con molte letture e buona tolleranza alla latenza, invece di replicarli.

• Ricorri a Data Cloud quando ti serve un profilo cliente unificato tra molti sistemi di origine, non come sostituto generico dell'ETL.

• Introduci il middleware quando la logica di trasformazione tra sistemi diventa così complessa che Apex si trasformerebbe in un livello di mappatura ingestibile.

Per i caricamenti di grandi volumi di dati, regola le dimensioni dei batch della Bulk API partendo da circa 200 record e adattale ai limiti di concorrenza del sistema a valle, perché pushing too hard against a partner’s ingestion rate sposta soltanto il collo di bottiglia senza risolverlo.

Di quali controlli di sicurezza ha bisogno ogni integrazione?

Zero credenziali nel codice, ambiti OAuth ridotti al minimo e rotazione dei token secondo una pianificazione, non solo quando qualcosa si rompe. Questa è la base, e le integrazioni che la saltano sono quelle che finiscono nei rapporti sugli incidenti.

Le Named Credentials esistono proprio perché tu non debba mai inserire a mano l'URL di un endpoint o un token di autenticazione in Apex. Centralizzano i dettagli della connessione e lasciano a Salesforce la gestione dell'handshake OAuth, il che significa anche che ruotare una credenziale non richiede un deploy di codice. Le External Client Apps sono la sostituzione moderna della configurazione delle connected app tradizionali, e la release Spring '26 di Salesforce ha spinto con decisione sulla migrazione delle configurazioni più vecchie. I security best-practice references mantenuti dalla community sono espliciti: i segreti scritti nel codice e gli ambiti OAuth troppo ampi sono i due rilievi più frequenti nelle revisioni di sicurezza delle integrazioni.

Su OAuth nello specifico: riduci gli ambiti esattamente a ciò che serve all'integrazione, niente di più ampio. Usa il flusso JWT bearer per le integrazioni server-to-server, dove non c'è un utente che possa autenticarsi in modo interattivo. Usa PKCE per qualsiasi client pubblico, come un'app mobile, dove non è possibile conservare in sicurezza un client secret. Ruota i token secondo una pianificazione definita, invece di lasciare token a lunga durata attivi all'infinito.

Uno schema molto citato nel settore: le integrazioni che centralizzano la conservazione delle credenziali tramite connessioni denominate, invece di segreti inseriti nel codice, registrano molti meno incidenti legati a token trapelati o scaduti, perché la rotazione diventa una modifica di configurazione invece di un deploy di codice.

Oltre all'identità, alcuni controlli di rete e di conformità completano la checklist:

• Limita le impostazioni dei siti remoti esattamente ai domini che servono a un'integrazione, senza caratteri jolly.

• Tieni traccia centralmente delle date di scadenza dei certificati; un certificato scaduto che rompe in silenzio un'integrazione durante la notte è uno dei blocchi autoinflitti più comuni.

• Cifra i dati personali identificabili sia in transito sia a riposo, ovunque l'integrazione li tocchi.

• Documenta i flussi di dati per il GDPR o regimi equivalenti, soprattutto quando i dati personali attraversano un confine tra sistemi.

Come costruisci integrazioni resilienti e osservabili?

Parti dal presupposto che ogni chiamata a valle prima o poi fallirà, e progetta la logica di nuovo tentativo, avvisi e idempotenza prima del percorso ideale, non dopo il primo blocco.

La strategia di nuovo tentativo dovrebbe usare un backoff esponenziale con jitter, non tentativi a intervalli fissi che colpiscono tutti insieme il sistema in avaria e peggiorano il disservizio. Uno schema tipico: riprova dopo 2 secondi, poi 4, poi 8, con un piccolo scarto casuale aggiunto a ciascuno e un tetto massimo definito prima di arrendersi. I circuit breaker smettono del tutto di chiamare un sistema a valle quando questo ha mostrato una serie di guasti, dandogli spazio per riprendersi invece di essere martellato dai tentativi di ogni integrazione che dipende da lui. Le dead-letter queue raccolgono tutto ciò che esaurisce i tentativi, così i messaggi falliti vengono esaminati e rielaborati manualmente invece di sparire.

L'idempotenza conta soprattutto proprio negli scenari in cui si verificano i nuovi tentativi: se un messaggio viene elaborato due volte perché una conferma è andata persa, la seconda elaborazione non deve creare un record duplicato. La soluzione standard sono ID di transazione trasmessi con ogni messaggio e verificati contro un vincolo di unicità dal lato ricevente. L'architettura a eventi di Salesforce lo supporta bene: gli eventi riproducibili con replay ID permettono a un sottoscrittore che ha perso dei messaggi di recuperare da un punto noto, invece di tirare a indovinare su cosa gli sia sfuggito.

L'osservabilità chiude il cerchio. Log centralizzati su ogni sistema della catena di integrazione, tracciamento distribuito per seguire una singola transazione dall'inizio alla fine e dashboard che monitorano tasso di errore, percentili di latenza e profondità delle code: tutto questo fa parte del design dal primo giorno, non è qualcosa da attaccare dopo il primo incidente in produzione.

Un breve elenco operativo da tenere sott'occhio:

• Riprova con backoff esponenziale e jitter, con un tetto ragionevole al numero di tentativi.

• Indirizza i tentativi esauriti a una dead-letter queue con un avviso, non a uno scarto silenzioso.

• Allega un ID di transazione univoco a ogni messaggio e imponilo come vincolo di unicità a valle.

• Monitora tasso di errore, latenza p95 e profondità delle code come metriche fisse, non solo la disponibilità.

Consiglio pratico: Testa la logica di nuovo tentativo e di dead-letter in un ambiente di staging mettendo deliberatamente offline un mock a valle mentre l'elaborazione è in corso. Molti team scoprono che la loro logica di backoff è difettosa solo durante un vero blocco, cioè nel momento peggiore possibile per accorgersene.

Quando conviene usare il middleware invece degli strumenti nativi di Salesforce?

Ricorri al middleware, una piattaforma di integrazione (iPaaS), un enterprise service bus o un API gateway, nel momento in cui entrano in gioco l'orchestrazione tra più di due sistemi, la traduzione di protocollo o l'applicazione centralizzata delle policy. Gli strumenti nativi di Salesforce coprono parecchio da soli, ma non sono mai stati pensati come livello di orchestrazione per un flusso di lavoro che tocca cinque sistemi.

Il middleware si guadagna il suo posto con una serie precisa di responsabilità: orchestrazione di più chiamate a valle in una sequenza definita, mediazione di protocollo quando un sistema parla SOAP e un altro REST o il protocollo di una coda di messaggi, limitazione del traffico per proteggere sistemi con capacità inferiore a Salesforce, trasformazione dei payload tra modelli di dati incompatibili e applicazione delle policy, come limiti di frequenza o controlli di autenticazione, applicati in modo coerente a ogni integrazione invece di essere reimplementati in ciascuna.

L'integrazione nativa di Salesforce, tramite Platform Events, Apex REST o una connected app diretta, funziona bene per connessioni punto a punto semplici tra due sistemi, dove quella complessità di orchestrazione non esiste. Nel momento in cui entra in scena un terzo sistema, o la logica di trasformazione inizia a distribuirsi su più classi Apex solo per rimodellare un payload, quello è il segnale per spostare la logica nel middleware invece di lasciarla dilagare dentro l'org.

Organizzare le API a livelli in base alla responsabilità ripaga man mano che il numero di integrazioni cresce. Le System API incapsulano un singolo sistema di backend dietro un'interfaccia stabile. Le Process API compongono più System API in un'operazione a livello di business. Le Experience API modellano i dati per un canale specifico: mobile, web, portale partner. La documentazione sull'architettura di integrazione API-first presenta questa stratificazione come la differenza tra integrazioni riutilizzabili tra progetti e integrazioni da rifare da zero ogni volta che si presenta un nuovo consumatore.

• Usa il middleware quando tre o più sistemi hanno bisogno di un'orchestrazione coordinata per un singolo processo aziendale.

• Resta sul nativo quando l'integrazione è una connessione semplice, a basso volume, tra due sistemi.

• Struttura le API su livelli System, Process ed Experience per massimizzare il riutilizzo nei progetti futuri.

Cosa deve contenere la checklist di integrazione di un architetto?

Una revisione del design che al primo giorno tralascia proprietà, rollback e monitoraggio è una revisione che genererà un incidente più avanti. Una checklist accurata prima dell'inizio dell'implementazione vale la pena di essere adottata in blocco per i progetti di integrazione.

Elementi della revisione del design: documenta i requisiti di alto livello e lo SLA aziendale prima di scegliere un pattern. Scrivi un architecture decision record per ogni scelta non banale, sincrono o asincrono, replica o virtualizzazione, così il ragionamento sopravvive al ricambio del personale. Assegna una proprietà chiara per ogni sistema integrato, incluso chi viene chiamato quando si rompe. Definisci un piano di rollback prima del rilascio, non durante un incidente.

Elementi di validazione CI/CD: automatizza i test sugli URI di reindirizzamento OAuth, così una modifica di configurazione non rompe in silenzio l'autenticazione in produzione. Verifica le date di scadenza dei certificati all'interno della pipeline, non come promemoria manuale sul calendario, dato che le modifiche all'identità della Spring '26 hanno reso certificate lifecycle management a first-class operational concern invece di un'attività di secondo piano. Controlla che ogni endpoint esterno risponda correttamente come condizione di rilascio, intercettando una Named Credential mal configurata prima che arrivi agli utenti.

Runbook di monitoraggio: definisci cosa fa scattare un avviso, chi lo riceve e quali sono i primi tre passi di diagnosi, messi per iscritto prima che l'integrazione entri in produzione, non improvvisati durante il primo blocco.

• Documenta un architecture decision record per ogni scelta di pattern fatta durante il design.

• Esegui controlli automatici su OAuth e certificati come condizione di rilascio, non come passaggio manuale.

• Assegna una proprietà con nome e cognome e un percorso di escalation per ogni sistema integrato.

• Scrivi il piano di rollback prima del primo rilascio, non dopo il primo guasto.

Il nostro punto di vista su dove i progetti di integrazione falliscono davvero

La maggior parte dei guasti di integrazione riscontrati durante gli audit riporta a decisioni che al momento sembravano ragionevoli: costruire in modo sincrono per andare più veloci, saltare gli architecture decision record per via delle scadenze strette, o inserire i token nel codice invece di gestire correttamente le credenziali per integrazioni rapide. Nessuna di queste è ignoranza. Sono scorciatoie piccole, singolarmente difendibili, che però si sommano.

Il catalogo dei pattern e la checklist di sicurezza di questa guida sono controlli pratici usati nei progetti di integrazione, dalle semplici sincronizzazioni con l'ERP alle architetture a eventi tra più sistemi. Coinvolgere presto figure senior nella discussione sull'architettura, e non solo alla consegna, aiuta a individuare le chiamate sincrone premature prima del rilascio. Un progetto tipico prevede audit, poi piano, poi realizzazione, poi supporto continuativo, e gran parte del valore reale emerge proprio in quel primo audit, dove diventa visibile la distanza tra ciò che un sistema doveva fare e ciò che fa davvero.

Se ti trovi davanti a un'integrazione legacy di cui nessuno si fida più del tutto, o a un nuovo progetto in cui la scelta del pattern è ancora incerta, quello è il momento giusto per chiedere una revisione dell'architettura dall'esterno, prima che venga scritto altro codice sopra fondamenta poco chiare.

Come Ampersand Labs supporta i progetti di integrazione Salesforce

Costruire subito l'architettura di integrazione giusta costa meno che districarne una sincrona e piena di credenziali nel codice quando è già in produzione e porta il peso del business. I progetti di integrazione Salesforce e sviluppo API traggono vantaggio dal coinvolgimento di architetti senior fin dal primo workshop, e non solo dopo la firma del contratto: così gli errori nella scelta del pattern si intercettano presto, invece che in produzione.

Un progetto tipico può includere un audit dell'attuale panorama di integrazione, una prova di concetto per le decisioni di pattern più rischiose, la realizzazione e il supporto continuativo per mantenere l'architettura gestibile man mano che si aggiungono nuovi sistemi. I servizi possono comprendere integrazioni di sistemi, sviluppo di API, supporto come CTO ad interim, audit su CI/CD e sicurezza, e automazione con AI per i flussi di lavoro collegati ai dati di Salesforce.

Se un'integrazione attuale ti sembra fragile, o stai per progettarne una e vuoi un secondo parere senior sulla scelta del pattern prima che venga scritto il codice, parti dalla pagina Integrazione di sistemi e sviluppo API per vedere come vengono impostati un audit e un progetto di realizzazione.

Fonti

• three-way split and a selection matrix

• Salesforce blog’s own guidance on aligning patterns to use cases

• security best-practice references

• certificate lifecycle management a first-class operational concern

Domande frequenti

Quali sono i migliori strumenti di integrazione per Salesforce?

Platform Events, Change Data Capture e la Pub/Sub API coprono la maggior parte degli scenari guidati dagli eventi, mentre Named Credentials e Salesforce Connect gestiscono connessioni sicure e virtualizzazione dei dati. Per l'orchestrazione tra più di due sistemi, una piattaforma di integrazione (iPaaS) o un API gateway rendono in genere meglio dei soli strumenti nativi.

Quali sono le buone pratiche per lo sviluppo su Salesforce nei progetti di integrazione?

Progetta seguendo un metodo di selezione dei pattern prima di scrivere codice, scegli per default metodi asincroni per tutto ciò che va oltre semplici connessioni tra due sistemi, e proteggi ogni credenziale con le Named Credentials invece di inserire i token nel codice. Costruisci idempotenza e logica di nuovo tentativo fin dall'inizio, invece di aggiungerle dopo il primo guasto in produzione.

Come si integra Salesforce con un'altra org Salesforce?

L'integrazione tra org usa in genere Platform Events o Change Data Capture per una sincronizzazione quasi in tempo reale, oppure la Bulk API per trasferimenti in batch pianificati di volumi di dati più grandi. Le Named Credentials su entrambe le org, abbinate a una connected app o a una External Client App con OAuth, mantengono la connessione sicura senza segreti scritti nel codice.

Qual è la differenza tra Change Data Capture e Platform Events?

Change Data Capture pubblica automaticamente eventi di modifica ogni volta che i record di un oggetto sottoscritto vengono creati, aggiornati, eliminati o ripristinati, senza bisogno di logica di trigger personalizzata. I Platform Events sono eventi definiti su misura che pubblichi in modo esplicito da Apex, Flow o un sistema esterno per qualsiasi evento aziendale, non solo per le modifiche ai record.

Quando usare Salesforce Connect invece della replica dei dati?

Usa Salesforce Connect quando i dati esterni cambiano troppo spesso per mantenere aggiornata una copia sincronizzata, o quando duplicarli crea problemi di archiviazione o di conformità. Scegli invece la replica quando gli utenti devono creare report su quei dati dentro Salesforce o farvi riferimento in flow e regole di convalida che gli oggetti virtualizzati non riescono a supportare fino in fondo.

Consigliati

• Integrazione di sistemi e sviluppo API a Zurigo

• Automazione AI e agenti per i flussi di lavoro a Zurigo