Sei pattern che gli architetti usano per evitare interruzioni nelle integrazioni Salesforce

Abbina il pattern al carico di lavoro, scegli come impostazione predefinita architetture asincrone e orientate agli eventi quando il volume o il rischio di accoppiamento sono elevati, blinda l'identità con Named Credentials e ambiti OAuth 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 mantengono ogni connessione verificabile. Prima del prossimo avvio di un'integrazione, dedica cinque minuti a una verifica dei pattern sul progetto 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 orientati agli eventi come Platform Events o Change Data Capture negli scenari disaccoppiati ad alto volume, per ridurre le chiamate sincrone e migliorare la scalabilità.
• Dedica cinque minuti a una verifica dei pattern prima della realizzazione, per individuare le chiamate sincrone che andrebbero sostituite da integrazioni basate su eventi, soprattutto sotto carico elevato.
• Scegli metodi di integrazione asincroni come impostazione predefinita, a meno che l'utente non stia aspettando attivamente un riscontro immediato: eviti così problemi di limiti di piattaforma ed errori di blocco delle righe.
• Preferisci la virtualizzazione dei dati tramite Salesforce Connect per dati esterni che cambiano spesso e non devono essere archiviati in Salesforce, oppure la replica per i dati che servono di frequente in report e flussi.
• Applica pratiche di sicurezza complete: salva le credenziali in Named Credentials, riduci al minimo gli ambiti OAuth, ruota i token con regolarità e limita le impostazioni dei siti remoti ai domini attendibili.

Indice

• Quali sono i pattern di integrazione Salesforce fondamentali?
• Come si sceglie il pattern di integrazione giusto?
• Meglio un'integrazione sincrona o asincrona?
• Replica o virtualizzazione: quale strategia dei dati vince?
• Quali controlli di sicurezza servono a ogni integrazione?
• Come si costruiscono integrazioni resilienti e osservabili?
• Quando conviene 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 Salesforce fondamentali?

L'architettura di integrazione di Salesforce si divide in tre categorie: processo, 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ì ognuno ha 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 associa ogni categoria a pattern specifici, ed è utile tenerla aperta durante qualsiasi sessione di progettazione.

All'interno di queste tre categorie, sei pattern coprono quasi tutto quello che dovrai 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 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 la registrazione dei log, le notifiche o qualsiasi caso in cui il chiamante non debba conoscere subito l'esito. Modalità di guasto: perdita silenziosa dei messaggi in assenza di conferma o di un livello di ritentativo.
• Sincronizzazione dei dati in blocco: grandi volumi si spostano secondo una pianificazione, di solito notturna, tramite Bulk API. Adatta alle sincronizzazioni con il data warehouse o alle riconciliazioni con sistemi legacy, dove il quasi tempo reale non serve. Modalità di guasto: fallimenti parziali del blocco che lasciano due sistemi disallineati fino all'esecuzione successiva.
• Chiamata dall'esterno: un sistema esterno chiama Salesforce, spesso via API REST o endpoint Apex REST, per leggere o scrivere record. Comune per app mobili o portali per partner. Modalità di guasto: si toccano i limiti di piattaforma quando i sistemi esterni non rispettano i tetti per transazione di Salesforce.
• Virtualizzazione dei dati: Salesforce interroga i dati di un sistema esterno su richiesta invece di archiviarne una copia, tipicamente tramite Salesforce Connect e OData o adattatori personalizzati. Adatta ai casi in cui i dati cambiano troppo spesso per tenerli replicati, oppure in cui il costo di archiviazione e la duplicazione sono un problema. Modalità di guasto: se il tempo di risposta del sistema esterno peggiora, degrada l'intera esperienza.
• Pubblicazione e sottoscrizione: un evento viene diffuso una volta sola e un numero qualsiasi di sottoscrittori lo raccoglie, tramite 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 permanente.

Le Salesforce blog’s own guidance on aligning patterns to use cases fanno un'osservazione che vale la pena ripetere: gli approcci orientati agli eventi evitano di bloccare il chiamante e gestiscono la concorrenza molto meglio delle chiamate sincrone quando il volume cresce. È il pattern a cui gran parte degli architetti ricorre troppo tardi, dopo che un'integrazione sincrona ha già causato un incidente in produzione.

Come si sceglie 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 degli errori 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.

I tempi dicono se il processo aziendale ha bisogno di un risultato subito o può tollerare un ritardo. Un preventivo richiesto al checkout è cosa diversa dal calcolo mensile delle provvigioni. La proprietà dei dati stabilisce quale sistema sia la fonte di verità. Se Salesforce non è l'autorità 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 Bulk API e processi asincroni invece di qualcosa di transazionale.

Le esigenze transazionali riguardano il fatto che un'operazione debba riuscire o fallire come unità. La semantica degli errori chiede cosa succede quando un sistema a valle non è raggiungibile. Il record si accoda 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 costruire.

Alcuni scenari si mappano in modo netto:

• 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, della virtualizzazione dei dati tramite Salesforce Connect.
• Un'opportunità che si chiude e deve attivare una notifica su Slack, un ordine nell'ERP e un contrassegno 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 blocco tramite 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 dall'esterno, protetta con un'app connessa 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 è proprietario del record dopo questa transazione? Qual è il volume giornaliero previsto? Cosa succede in caso di errore: nuovo tentativo, avviso o scarto? Serve una consegna garantita una sola volta, oppure a valle è accettabile gestire i duplicati? Rispondi a queste cinque domande prima di aprire il catalogo dei pattern, e la scelta giusta di solito diventa ovvia.

Meglio un'integrazione sincrona o asincrona?

Scegli l'asincrono come impostazione predefinita, a meno che l'utente non stia aspettando attivamente il risultato davanti a uno schermo. Questa sola regola previene gran parte dei problemi di limiti di piattaforma e di blocco in cui gli architetti incappano dopo il lancio.

Le integrazioni sincrone sembrano più facili da costruire, ed è proprio per questo che i team le adottano di default anche quando il caso d'uso non le richiede. La stessa analisi di Salesforce sugli errori architetturali più comuni indica l'eccessiva dipendenza dalle chiamate sincrone come un difetto 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 un'API esterna lenta rischia di raggiungere il limite di tempo CPU, e se quel sistema esterno scrive anche sugli stessi record, si crea contesa sul blocco delle righe che si manifesta con errori UNABLE_TO_LOCK_ROW casuali sotto carico.

La soluzione di disaccoppiamento è quasi sempre la stessa: togli la scrittura dal percorso critico. Pubblica un Platform Event invece di effettuare una 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 volume nel futuro.

Alcune regole pratiche reggono nella maggior parte dei progetti:

• Se l'utente sta fissando 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ò avere picchi imprevedibili, 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 fermi trascinino giù anche Salesforce.

Consiglio pratico: Tieni d'occhio il budget di chiamate API quando pubblichi eventi tramite l'endpoint REST invece che nativamente da Apex o Flow. Le indicazioni della community segnalano che gli eventi pubblicati via API rientrano nel limite giornaliero di chiamate, 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 all'esterno e interrogali su richiesta quando cambiano troppo spesso per tenerli sincronizzati o quando duplicarli crea grattacapi di conformità.

La replica significa archiviare una copia dei dati esterni come record Salesforce, aggiornata secondo una pianificazione o tramite eventi. È la scelta giusta per tutto ciò su cui gli utenti fanno report dentro Salesforce o a cui fanno riferimento in flussi e regole di convalida, dato che i dati virtualizzati non sempre lo supportano in modo nativo. La virtualizzazione, tramite Salesforce Connect e gli oggetti esterni, salta la copia e interroga il sistema di origine in tempo reale. È adatta a cataloghi molto grandi che cambiano di continuo, come il listino prezzi in tempo reale di un distributore, dove mantenere una copia sincronizzata vorrebbe dire processi di sincronizzazione continui, in bilico tra aggiornamento dei dati e costo di archiviazione.

Gli approcci zero-copy vanno ancora 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 su ogni sistema collegato: aspetto rilevante quando un data warehouse e Salesforce hanno bisogno dello stesso record cliente senza diventare due fonti di verità.

La proprietà dei dati anagrafici va definita prima che venga scritto qualsiasi processo di sincronizzazione, non dopo. Decidi in anticipo quale sistema è autorevole per ciascuna entità, cliente, prodotto, prezzi, e mettilo per iscritto come contratto sullo schema approvato da entrambi i team. La logica di deduplicazione va collocata nel punto di acquisizione, non in un intervento di pulizia sei mesi dopo, quando gli account duplicati hanno già inquinato ogni report a valle.

Alcuni accorgimenti pratici:

• Tratta lo schema come un contratto tra sistemi: il cambio di tipo di un campo, da una parte o dall'altra, deve richiedere un'approvazione, non solo un rilascio.
• Usa Salesforce Connect per i dati esterni a lettura intensa e con tolleranza alla latenza, invece di replicarli.
• Ricorri a Data Cloud quando ti serve un profilo cliente unificato su molti sistemi di origine, non come sostituto generico di un 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 la dimensione dei blocchi della Bulk API partendo da circa 200 record e adattala 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.

Quali controlli di sicurezza servono a ogni integrazione?

Nessuna credenziale 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 scrivere direttamente nel codice Apex l'URL di un endpoint o un token di autenticazione. Centralizzano i dettagli di connessione e lasciano che sia Salesforce a gestire lo scambio OAuth, il che significa anche che ruotare una credenziale non richiede un rilascio di codice. Le External Client Apps sono la sostituzione moderna della configurazione legacy delle app connesse, 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 verifiche di sicurezza delle integrazioni.

Su OAuth nello specifico: riduci gli ambiti a quanto serve esattamente all'integrazione, niente di più ampio. Usa il flusso JWT bearer per le integrazioni da server a 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 custodire in sicurezza un segreto client. Ruota i token secondo una pianificazione definita, invece di lasciare attivi a tempo indeterminato token di lunga durata.

Un pattern ampiamente citato nel settore: le integrazioni che centralizzano l'archiviazione delle credenziali tramite connessioni denominate invece che con 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 rilascio di codice.

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

• Limita le impostazioni dei siti remoti esattamente ai domini che servono all'integrazione, senza caratteri jolly.
• Tieni traccia in modo centralizzato delle date di scadenza dei certificati: un certificato scaduto che spezza in silenzio un'integrazione nella notte è uno dei fermi 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 normative equivalenti, soprattutto quando i dati personali attraversano un confine tra sistemi.

Come si costruiscono integrazioni resilienti e osservabili?

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

La strategia di ritentativo dovrebbe usare un backoff esponenziale con jitter, non tentativi a intervalli fissi che colpiscono tutti insieme il sistema in avaria e peggiorano il fermo. Un pattern tipico: riprova dopo 2 secondi, poi 4, poi 8, con un piccolo scarto casuale aggiunto a ciascun tentativo, fino a un massimo definito oltre il quale si rinuncia. I circuit breaker interrompono del tutto le chiamate a un sistema a valle quando questo mostra una serie di errori, dandogli spazio per riprendersi invece di essere martellato dai tentativi di ogni integrazione che dipende da lui. Le code dead-letter 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 avvengono i ritentativi: 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 gli ID transazione trasmessi con ogni messaggio e verificati contro un vincolo di unicità sul lato ricevente. L'architettura a eventi di Salesforce supporta bene questo approccio: gli eventi rigiocabili con i 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 è sfuggito.

L'osservabilità chiude il cerchio. Registrazione centralizzata dei log 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 progetto fin dal primo giorno, non è qualcosa da aggiungere dopo il primo incidente in produzione.

Un breve elenco operativo da tenere sotto gli occhi:

• Riprova con backoff esponenziale e jitter, con un limite ragionevole al numero di tentativi.
• Indirizza i tentativi esauriti a una coda dead-letter con un avviso, non a uno scarto silenzioso.
• Allega un ID transazione univoco a ogni messaggio e applicalo a valle come vincolo di unicità.
• Monitora tasso di errore, latenza p95 e profondità delle code come metriche fisse, non solo la disponibilità.

Consiglio pratico: Metti alla prova la logica di ritentativo e di coda dead-letter in un ambiente di staging, spegnendo di proposito un mock a valle mentre il processo è in corso. La maggior parte dei team scopre che il backoff non funziona solo durante un fermo reale, cioè nel momento peggiore possibile.

Quando conviene il middleware invece degli strumenti nativi di Salesforce?

Ricorri al middleware, una piattaforma di integrazione (iPaaS), un bus di servizi aziendale o un gateway API, 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 coinvolge cinque sistemi.

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

L'integrazione nativa di Salesforce, tramite Platform Events, Apex REST o un'app connessa diretta, funziona bene per collegamenti 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 comincia a spargersi su più classi Apex solo per rimodellare un payload, è il segnale per spostare la logica nel middleware invece di lasciarla proliferare dentro l'org.

Organizzare le API a livelli per responsabilità ripaga man mano che il numero di integrazioni cresce. Le System API incapsulano un singolo sistema di back-end 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 descrive questa stratificazione come la differenza tra integrazioni riutilizzabili in più progetti e integrazioni da ricostruire da zero ogni volta che compare un nuovo consumatore.

• Usa il middleware quando tre o più sistemi richiedono un'orchestrazione coordinata per un singolo processo aziendale.
• Resta sul nativo quando l'integrazione è un collegamento semplice, a basso volume, tra due sistemi.
• Struttura le API in System, Process ed Experience per massimizzare il riutilizzo nei progetti futuri.

Cosa deve contenere la checklist di integrazione di un architetto?

Una revisione di progetto che il primo giorno tralascia proprietà, rollback e monitoraggio è una revisione che genererà un incidente più avanti. Una checklist accurata prima dell'inizio della realizzazione vale la pena di essere adottata in blocco negli incarichi di integrazione.

Elementi della revisione di progetto: 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 cambio di persone. Assegna una proprietà chiara per ciascun sistema integrato, incluso chi viene chiamato quando si rompe. Definisci un piano di rollback prima del rilascio, non durante un incidente.

Elementi di verifica in CI/CD: automatizza i test sugli URI di reindirizzamento OAuth, così una modifica di configurazione non spezza in silenzio l'autenticazione in produzione. Controlla le date di scadenza dei certificati come parte della pipeline, non come promemoria manuale sul calendario, perché le novità sull'identità di Spring '26 hanno reso la certificate lifecycle management a first-class operational concern invece di un'attività di secondo piano. Verifica 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 vada in produzione, non improvvisati durante il primo fermo.

• Documenta un architecture decision record per ogni scelta di pattern fatta in fase di progettazione.
• 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 risale a decisioni che sul momento sembravano ragionevoli: costruire in modo sincrono per andare più veloci, saltare gli architecture decision record per via delle scadenze strette, o scrivere i token nel codice invece di gestire le credenziali come si deve 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 negli incarichi di integrazione, dalle semplici sincronizzazioni con l'ERP alle architetture a eventi che coinvolgono più sistemi. Coinvolgere presto figure senior nella discussione sull'architettura, e non solo alla consegna, aiuta a intercettare le chiamate sincrone premature prima del rilascio. Un incarico tipico procede per audit, poi piano, poi realizzazione, poi supporto continuativo, e gran parte del valore reale emerge già in quel primo audit, dove diventa visibile lo scarto 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, oppure a un nuovo progetto in cui la scelta del pattern è ancora incerta, è il momento giusto per chiedere una revisione architetturale esterna, prima che venga scritto altro codice su fondamenta poco chiare.

, Davide Morotti

Come Ampersand Labs supporta i progetti di integrazione Salesforce

Costruire l'architettura di integrazione giusta al primo colpo costa meno che districarne una sincrona e con i token nel codice quando è già in produzione e porta carico. Gli incarichi di integrazione Salesforce e sviluppo di API traggono vantaggio dal coinvolgimento di architetti senior già 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 incarico tipico può comprendere un audit dell'attuale panorama delle integrazioni, un proof of concept per le scelte 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 includere integrazioni di sistema, sviluppo di API, supporto come CTO ad interim, audit di CI/CD e sicurezza, e automazione con l'IA per i flussi di lavoro adiacenti ai dati Salesforce.

Se un'integrazione attuale ti sembra fragile, oppure stai per progettarne una e vuoi un secondo parere senior sulla scelta del pattern prima che venga scritto il codice, parti dalla pagina Integrazioni di sistema e sviluppo API per vedere come viene impostato un incarico di audit e 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 orientati agli eventi, mentre Named Credentials e Salesforce Connect si occupano di connessioni sicure e virtualizzazione dei dati. Per orchestrare più di due sistemi, una piattaforma di integrazione (iPaaS) o un gateway API di norma rende meglio dei soli strumenti nativi.

Quali sono alcune buone pratiche di sviluppo Salesforce nei progetti di integrazione?

Progetta seguendo un metodo di selezione dei pattern prima di scrivere codice, scegli metodi asincroni come impostazione predefinita per tutto ciò che va oltre un semplice collegamento tra due sistemi, e proteggi ogni credenziale con le Named Credentials invece di scrivere i token nel codice. Integra idempotenza e logica di ritentativo 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 di solito usa Platform Events o Change Data Capture per una sincronizzazione quasi in tempo reale, oppure la Bulk API per trasferimenti in blocco pianificati di volumi di dati maggiori. Le Named Credentials su entrambe le org, abbinate a un'app connessa o a una External Client App con OAuth, mantengono sicura la connessione 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 invece eventi definiti su misura, che pubblichi esplicitamente 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, oppure quando duplicarli crea problemi di archiviazione o di conformità. Scegli la replica, invece, quando gli utenti devono fare report su quei dati dentro Salesforce o richiamarli in flussi e regole di convalida che gli oggetti virtualizzati non supportano appieno.

Da leggere

• Integrazioni di sistema e sviluppo API a Zurigo
• Automazione con l'IA e agenti per i flussi di lavoro a Zurigo