In genere, quando si implementa Salesforce è necessario integrarlo con altre applicazioni. Sebbene ogni scenario di integrazione sia univoco, esistono requisiti e problemi comuni che sviluppatori e architetti devono risolvere.

Questo documento descrive le strategie (sotto forma di schemi) per questi scenari di integrazione comuni. Ogni schema descrive la progettazione e l'approccio per uno scenario particolare anziché descrivere in dettaglio un'implementazione specifica. In questo documento troverai:

• Una serie di schemi che affrontano scenari chiave di integrazione "archetipo"
• Una matrice di selezione per determinare quale schema si adatta meglio al proprio scenario
• Suggerimenti e procedure consigliate per l'integrazione

Scopo e ambito

Questo documento è destinato ai progettisti e agli architetti che necessitano di integrare Salesforce Platform con altre applicazioni aziendali. Questo contenuto è un distillato di molte implementazioni di successo degli architetti e dei partner Salesforce.

Per acquisire familiarità con le funzionalità e le opzioni di integrazione disponibili per l'adozione su larga scala di applicazioni basate su Salesforce, vedere Riepilogo degli schemi e Guida alla selezione degli schemi. Gli architetti e gli sviluppatori devono tenere presenti i dettagli dello schema e le procedure consigliate durante la fase di progettazione e implementazione di un progetto di integrazione Salesforce.

Se implementati correttamente, questi schemi consentono di arrivare in produzione il più velocemente possibile e di avere la serie di applicazioni più stabile, scalabile ed esente da manutenzione possibile. Gli architetti consulenti Salesforce utilizzano questi schemi come punti di riferimento durante le revisioni architettoniche e li gestiscono e migliorano attivamente.

Come per tutti gli schemi, questo contenuto copre la maggior parte degli scenari di integrazione, ma non tutti. Benché Salesforce consenta l'integrazione dell'interfaccia utente, i mashup, ad esempio, esulano dall'ambito di questo documento.

Modello schema

Ogni schema di integrazione segue una struttura coerente. Ciò offre coerenza nelle informazioni fornite in ogni schema e semplifica anche il confronto degli schemi.

Nome

Identificatore dello schema che indica anche il tipo di integrazione contenuto nello schema.

Context

Scenario di integrazione generale affrontato dallo schema. Il contesto fornisce informazioni su ciò che gli utenti stanno cercando di ottenere e su come si comporterà l'applicazione per supportare i requisiti.

Problema

Lo scenario o il problema (espresso come domanda) che lo schema è progettato per risolvere. Quando si rivedono gli schemi, leggere questa sezione per capire rapidamente se lo schema è appropriato per il proprio scenario di integrazione.

Forze

I vincoli e le circostanze che rendono lo scenario dichiarato difficile da risolvere.

Soluzione

Il modo consigliato per risolvere lo scenario di integrazione.

Sketch

Diagramma di sequenza UML che mostra come la soluzione affronta lo scenario.

Risultati

Spiega i dettagli di come applicare la soluzione allo scenario di integrazione e come risolvere le forze associate a quello scenario. Questa sezione contiene anche nuove sfide che possono sorgere in seguito all'applicazione dello schema.

Intestazioni laterali

Sezioni aggiuntive correlate allo schema che contengono problemi tecnici chiave, variazioni dello schema, problemi specifici dello schema e così via.

Esempio

Uno scenario completo che descrive come viene utilizzato lo schema di progettazione in uno scenario Salesforce reale. L'esempio spiega gli obiettivi di integrazione e come implementare lo schema per raggiungere tali obiettivi.

Riepilogo schema

La tabella seguente elenca gli schemi di integrazione contenuti in questo documento.

Elenco degli schemi remote-process-invocation--request-and-reply

Approccio schematico

Gli schemi di integrazione di questo documento sono classificati in tre categorie:

• Integrazione dei dati: questi schemi soddisfano l'esigenza di sincronizzare i dati che risiedono in due o più sistemi in modo che entrambi i sistemi contengano sempre dati puntuali e significativi. L'integrazione dei dati è spesso il tipo di integrazione più semplice da implementare, ma richiede tecniche di gestione delle informazioni adeguate per rendere la soluzione sostenibile e conveniente. Tali tecniche spesso includono aspetti di gestione dei dati master (MDM), governance dei dati, mastering, deduplicazione, progettazione del flusso di dati e altri.

• Integrazione dei processi: gli schemi di questa categoria rispondono alla necessità che un processo aziendale utilizzi due o più applicazioni per completare la propria operazione. Quando si implementa una soluzione per questo tipo di integrazione, l'applicazione di attivazione deve effettuare chiamate oltre i confini del processo ad altre applicazioni. Di solito, questi schemi includono anche sia l'orchestrazione (dove un'applicazione è il "controller" centrale) che la coreografia (dove le applicazioni sono multi-partecipanti e non esiste un "controller" centrale). Queste integrazioni spesso richiedono requisiti complessi di progettazione, test e gestione delle eccezioni. Inoltre, tali applicazioni composite sono in genere più impegnative per i sistemi sottostanti perché spesso supportano transazioni di lunga durata e la possibilità di generare rapporti o gestire lo stato dei processi.

• Integrazione virtuale: gli schemi di questa categoria rispondono alla necessità per un utente di visualizzare, cercare e modificare i dati memorizzati in un sistema esterno. Quando si implementa una soluzione per questo tipo di integrazione, l'applicazione di attivazione deve effettuare una chiamata ad altre applicazioni e interagire con i loro dati in tempo reale. Questo tipo di integrazione elimina la necessità di replicare i dati tra i sistemi e consente agli utenti di interagire sempre con i dati più aggiornati.

Scegliere la strategia di integrazione migliore per il proprio sistema non è banale. Ci sono molti aspetti da considerare e molti strumenti che possono essere utilizzati, con alcuni strumenti più appropriati di altri per determinate operazioni. Ogni schema affronta specifiche aree critiche, tra cui le funzionalità di ogni sistema, il volume dei dati, la gestione dei guasti e la transazionalità.

Guida alla selezione degli schemi

Le tabelle a matrice di selezione elencano gli schemi e i relativi aspetti chiave per consentire di determinare quale schema si adatta meglio alle proprie esigenze di integrazione. Gli schemi vengono classificati utilizzando le seguenti dimensioni.

Integrazione di Salesforce con un altro sistema

In questa tabella sono elencati gli schemi e i relativi aspetti chiave per consentire di determinare quale schema si adatta meglio alle proprie esigenze quando l'integrazione passa da Salesforce a un altro sistema.

Integrazione di un altro sistema con Salesforce

In questa tabella sono elencati gli schemi e i relativi aspetti chiave per consentire di determinare lo schema più adatto alle proprie esigenze quando l'integrazione avviene da un altro sistema a Salesforce.

Termini e definizioni middleware

In questa tabella sono elencati alcuni termini chiave relativi al middleware e le relative definizioni in relazione a questi schemi.

Context

Salesforce si utilizza per tenere traccia dei lead, gestire le opportunità in corso di realizzazione, creare opportunità e acquisire i dettagli degli ordini che convertono i lead in clienti. Tuttavia, il sistema Salesforce non contiene né elabora gli ordini. Dopo aver acquisito i dettagli dell'ordine in Salesforce, l'ordine viene creato nel sistema remoto, che gestisce l'ordine fino alla conclusione.

Quando si implementa questo schema, Salesforce chiama il sistema remoto per creare l'ordine e quindi attende il completamento corretto. In caso di esito positivo, il sistema remoto risponde in modo sincronizzato con lo stato e il numero dell'ordine. Nell'ambito della stessa transazione, Salesforce aggiorna internamente il numero e lo stato dell'ordine. Il numero d'ordine viene utilizzato come chiave esterna per gli aggiornamenti successivi del sistema remoto.

Problema

Quando si verifica un evento in Salesforce, come si avvia un processo in un sistema remoto, si passano le informazioni richieste a quel processo, si riceve una risposta dal sistema remoto e quindi si utilizzano i dati della risposta per eseguire aggiornamenti in Salesforce?

Forze

Considerare le forze seguenti quando si applicano soluzioni basate su questo schema.

• La chiamata al sistema remoto richiede che Salesforce attenda una risposta prima di continuare l'elaborazione? La chiamata al sistema remoto è una richiesta-risposta sincrona o una richiesta asincrona?
• Se la chiamata al sistema remoto è sincrona, Salesforce deve elaborare la risposta nell'ambito della stessa transazione della chiamata iniziale?
• Le dimensioni del messaggio sono piccole o grandi?
• L'integrazione si basa sul verificarsi di un evento specifico, ad esempio un clic su un pulsante nell'interfaccia utente di Salesforce, o di eventi basati su DML?
• L'endpoint remoto è in grado di rispondere alla richiesta con bassa latenza? Quanti utenti probabilmente eseguiranno questa transazione in un periodo di picco?

Soluzione

Questa tabella contiene le soluzioni a questo problema di integrazione.

Sketch

Questo diagramma illustra una chiamata di processo remoto sincrono che utilizza chiamate Apex.

Chiamata Salesforce a un sistema remoto

Scarica diagramma

In questo scenario:

• Viene avviata un'azione nella pagina Lightning (ad esempio, un clic su un pulsante).
• Il browser (tramite un controller lato client nel caso di un componente Lightning) esegue un POST HTTP che a sua volta esegue un'azione sul controller Apex corrispondente.
• Il controller richiama la chiamata effettiva al servizio Web remoto.
• La risposta dal sistema remoto viene restituita al controller Apex. Il controller elabora la risposta, aggiorna i dati in Salesforce in base alle esigenze e visualizza nuovamente la pagina.

Nei casi in cui è necessario tenere traccia dello stato successivo, il sistema remoto restituisce un identificatore univoco memorizzato nel record Salesforce.

Risultati

L'applicazione delle soluzioni correlate a questo schema consente le invocazioni di processi remoti avviate da eventi in cui Salesforce gestisce l'elaborazione.

Meccanismi di chiamata

Il meccanismo di chiamata dipende dalla soluzione scelta per implementare questo schema.

Gestione e ripristino degli errori

È importante includere una strategia di gestione e ripristino degli errori come parte della soluzione complessiva.

• Gestione degli errori: quando si verifica un errore (vengono restituiti al chiamante codici di eccezioni o di errore), il chiamante gestisce la gestione degli errori. Ad esempio, un messaggio di errore visualizzato nella pagina dell'utente finale o registrato in una tabella che richiede ulteriori azioni.

• Ripristino: le modifiche non vengono confermate in Salesforce finché il chiamante non riceve una risposta corretta. Ad esempio, lo stato dell'ordine non viene aggiornato nel database finché non viene ricevuta una risposta che indica che è stato completato correttamente. Se necessario, il chiamante può riprovare l'operazione.

Considerazioni sulla progettazione idempotente

Le funzionalità idempotenti garantiscono che le chiamate ripetute siano sicure. Se non viene implementata l'impotenza, le chiamate ripetute dello stesso messaggio possono avere risultati diversi, potenzialmente causando problemi di integrità dei dati. I problemi potenziali includono la creazione di record duplicati o l'elaborazione di transazioni duplicate.

È importante assicurarsi che la procedura remota chiamata sia idempotente. Se la chiamata viene effettuata dall'interfaccia utente, è necessario prestare attenzione all'impotenza a livello di integrazione, soprattutto se non è garantito che Salesforce chiami una sola volta.

Il metodo più tipico per creare un ricevitore idempotente consiste nel tenere traccia dei duplicati in base a identificatori univoci dei messaggi inviati dal consumatore. Il servizio Web Apex o le chiamate REST devono essere personalizzati per inviare un ID messaggio univoco.

Inoltre, le operazioni che creano record nel sistema remoto devono verificare la presenza di duplicati prima dell'inserimento. Controllare passando un ID record univoco da Salesforce. Se il record esiste nel sistema remoto, aggiornare il record. Nella maggior parte dei sistemi, questa operazione viene definita operazione di inserimento con aggiornamento.

Considerazioni sulla sicurezza

Qualsiasi chiamata a un sistema remoto deve mantenere la riservatezza, l'integrità e la disponibilità della richiesta. Le seguenti considerazioni sulla sicurezza riguardano specificamente l'utilizzo di chiamate Apex SOAP e HTTP in questo schema.

• SSL unidirezionale è abilitato per impostazione predefinita, ma SSL bidirezionale è supportato con certificati autofirmati e firmati da CA per mantenere l'autenticità sia del client che del server.

• Per semplificare l'Apex Code e l'impostazione delle chiamate autenticate, specificare una credenziale denominata nell'endpoint di chiamata.

• Considerare l'uso di OAUTH 2.0 come meccanismo di autenticazione per l'integrazione con sistemi esterni.

• Se necessario, valutare la possibilità di utilizzare hash unidirezionali o firme digitali utilizzando i metodi della classe Apex Crypto per garantire l'integrità della richiesta.

• Il sistema remoto deve essere protetto implementando gli opportuni meccanismi di firewall. Vedere Considerazioni sulla sicurezza.

• Attualmente Salesforce non supporta WS-Security. Benché non generi in modo nativo queste intestazioni WS-Security complesse o le applichi automaticamente da un WSDL in entrata, è possibile crearle e implementarle manualmente creando classi Apex personalizzate per gestire le intestazioni SOAP e i token di protezione per le richieste in entrata.

Intestazioni laterali

Nessuno.

Tempestività

La tempestività è di importanza significativa in questo schema. Di solito:

• La richiesta viene in genere richiamata dall'interfaccia utente, quindi il processo non deve far attendere l'utente.
• Salesforce ha un timeout configurabile fino a 120 secondi per le chiamate da Apex.
• Il completamento del processo remoto viene eseguito in modo tempestivo per concludersi entro il limite di timeout di Salesforce e nel rispetto delle aspettative degli utenti.
• Poiché le chiamate esterne sono soggette ai limiti del governor di transazioni sincrono Apex, assicurarsi di ridurre il rischio di istanziare più di 50 transazioni che durano più di cinque secondi ciascuna. Oltre a garantire che l'endpoint esterno sia performante, le opzioni per ridurre il rischio di timeout includono:
  • Impostazione del timeout della chiamata esterna su cinque secondi.
  • Utilizzo di una continuazione nei componenti Lightning per gestire transazioni di lunga durata

Volumi di dati

Questo schema viene utilizzato principalmente per le attività in tempo reale a volume ridotto, a causa dei piccoli valori di timeout e della dimensione massima della richiesta o della risposta per la soluzione di chiamata Apex. Non utilizzare questo schema nelle attività di elaborazione batch in cui il payload di dati è contenuto nel messaggio.

Supporto della capacità endpoint e degli standard

La funzionalità e il supporto standard per l'endpoint dipendono dalla soluzione scelta.

Gestione statale

Quando si integrano i sistemi, le chiavi sono importanti per il tracciamento continuo dello stato. Esistono due opzioni.

• Salesforce memorizza la chiave surrogata principale o univoca del sistema remoto per il record remoto.
• Il sistema remoto memorizza l'ID record univoco Salesforce o un'altra chiave surrogata univoca.

Esistono considerazioni specifiche per la gestione delle chiavi di integrazione, a seconda del sistema che contiene il record principale, come indicato nella tabella seguente.

Scenari di integrazione complessi

In alcuni casi, la soluzione prescritta da questo schema può richiedere l'implementazione di diversi scenari di integrazione complessi. Questo è il modo migliore per utilizzare middleware o fare in modo che Salesforce chiami un servizio composito. Questi scenari includono:

• Orchestrazione di processi aziendali e regole che comportano una logica di flusso complessa
• Aggregazione delle chiamate e dei relativi risultati nelle chiamate a più sistemi
• Trasformazione dei messaggi in entrata e in uscita
• Mantenere l'integrità delle transazioni tra le chiamate a più sistemi

Limitazioni del governatore

Per informazioni sui limiti Apex, vedere Execution Governors and Limits nella Apex Developer Guide.

Funzioni middleware

La tabella seguente evidenzia le proprietà desiderate di un sistema middleware che partecipa a questo schema.

Esempio

Una società di servizi utilizza Salesforce e dispone di un sistema separato che contiene le informazioni di fatturazione dei clienti. Come parte del processo di ordinazione è necessario creare nuovi account di fatturazione nel sistema di fatturazione e Salesforce deve riflettere il numero di account di fatturazione all'interno del processo di attivazione dell'ordine. Hanno un servizio Web esistente che consente la creazione di un account di fatturazione e restituisce il numero dell'account di fatturazione come risposta.

Questo requisito può essere soddisfatto con il seguente approccio.

1. Salesforce utilizza il servizio account di fatturazione WSDL da una classe proxy Apex.
2. Eseguire la classe proxy Apex con le informazioni sul cliente passate al servizio Web esterno da un controller Apex personalizzato o da un servizio esterno.
3. Il controller personalizzato analizza quindi i valori restituiti dalla chiamata Apex e memorizza tali informazioni nell'oggetto Salesforce.

Questo esempio dimostra che:

• Lo stato del cliente viene tracciato con un numero di account memorizzato nell'oggetto account Salesforce.
• Elaborazione successiva del messaggio di risposta da parte del chiamante

Context

Salesforce si utilizza per tenere traccia dei lead, gestire le opportunità in corso di realizzazione, creare opportunità e acquisire i dettagli degli ordini che convertono i lead in clienti. Tuttavia, nell'ambito dei processi di gestione degli ordini, è necessario creare un account di fatturazione nel sistema di fatturazione per l'ordine.

Quando si implementa questo schema, Salesforce chiama il sistema remoto per creare l'account di fatturazione, ma non attende il completamento della chiamata. Se si desidera, il sistema remoto può aggiornare Salesforce con il nuovo account di fatturazione creato in una transazione separata.

Problema

Quando si verifica un evento in Salesforce, come si avvia un processo in un sistema remoto e si trasmettono le informazioni richieste a quel processo senza attendere una risposta dal sistema remoto?

Forze

Considerare le forze seguenti quando si applicano soluzioni basate su questo schema.

• La chiamata al sistema remoto richiede che Salesforce attenda una risposta prima di continuare l'elaborazione? La chiamata al sistema remoto è sincrona o asincrona?
• Se la chiamata al sistema remoto è sincrona, la risposta deve essere elaborata da Salesforce nell'ambito della stessa transazione della chiamata?
• Le dimensioni del messaggio sono piccole?
• L'integrazione si basa sul verificarsi di un evento specifico, ad esempio un clic su un pulsante nell'interfaccia utente di Salesforce, o di eventi basati su DML?
• La consegna garantita dei messaggi da Salesforce al sistema remoto è un requisito?
• Il sistema remoto è in grado di partecipare a un'integrazione contract-first in cui Salesforce specifica il contratto? In alcune varianti di soluzione (ad esempio, messaggistica in uscita), Salesforce specifica un contratto implementato dall'endpoint di sistema remoto.
• L'endpoint o l'Enterprise Service Bus (ESB) supporta il polling lungo?
• I metodi di configurazione dichiarativi sono preferiti allo sviluppo Apex personalizzato? In questo caso, soluzioni come gli eventi piattaforma sono preferite alle chiamate Apex.

Soluzione

La tabella seguente contiene le soluzioni a questo problema di integrazione.

Sketch

Lo schema riportato sotto illustra una chiamata da Salesforce a un sistema remoto in cui la creazione o l'aggiornamento di operazioni su un record attiva la chiamata.

Scarica diagramma

In questo scenario:

1. Un sistema remoto si abbona all'evento piattaforma.
2. Viene eseguito un aggiornamento o un inserimento in un determinato insieme di record in Salesforce.
3. Un flusso Salesforce viene attivato quando viene soddisfatta una serie di condizioni.
4. Questo flusso crea un evento piattaforma.
5. L'ascoltatore remoto riceve il messaggio di evento e lo inserisce in un'area di attesa locale.
6. L'applicazione di area di attesa inoltra il messaggio all'applicazione remota per l'elaborazione.

Nel caso in cui il sistema remoto debba eseguire operazioni contro Salesforce, è possibile implementare un'operazione di richiamata facoltativa.

Risultati

L'applicazione delle soluzioni correlate a questo schema consente di:

• Interfaccia utente: chiamate a processi remoti avviate dall'interfaccia utente in cui il risultato della transazione può essere visualizzato all'utente finale
• Chiamate a processi remoti avviate da eventi DML in cui il risultato della transazione può essere elaborato dal processo chiamante

Meccanismi di chiamata

Il meccanismo di chiamata dipende dalla soluzione scelta per implementare questo schema.

Gestione e ripristino degli errori

Una strategia di gestione e ripristino degli errori deve essere considerata parte della soluzione complessiva. Il metodo migliore dipende dalla soluzione scelta.

Considerazioni sulla progettazione idempotente

Gli eventi piattaforma vengono pubblicati sul bus una sola volta. Non sono previsti nuovi tentativi sul lato Salesforce. Spetta all'ESB richiedere che gli eventi vengano riprodotti. In un replay, l'ID replay dell'evento piattaforma rimane lo stesso e l'ESB può provare a duplicare i messaggi in base all'ID replay.

L'impotenza è importante per la messaggistica in uscita perché è asincrona e i nuovi tentativi vengono avviati quando non viene ricevuta alcuna conferma positiva. Pertanto, il servizio remoto deve essere in grado di gestire i messaggi di Salesforce in modo idempotente.

La messaggistica in uscita invia un ID univoco per messaggio e questo ID rimane lo stesso per tutti i tentativi. Il sistema remoto può tenere traccia dei messaggi duplicati in base a questo ID univoco. Viene inviato anche l'ID record univoco di ogni record in aggiornamento, che può essere utilizzato per evitare la creazione di record duplicati.

Le considerazioni sulla progettazione dello schema Remote Process Invocation — Request and Reply si applicano anche a questo schema.

Considerazioni sulla sicurezza

Qualsiasi chiamata a un sistema remoto deve mantenere la riservatezza, l'integrità e la disponibilità della richiesta. Vengono applicate diverse considerazioni sulla sicurezza, a seconda della soluzione scelta.

Vedere Considerazioni sulla sicurezza.

Intestazioni laterali

Nessuno.

Tempestività

La tempestività è meno un fattore con lo schema fuoco-e-dimentica. Il controllo viene restituito al cliente immediatamente o dopo la conferma positiva di una consegna riuscita al sistema remoto. Con la messaggistica in uscita di Salesforce, la conferma deve avvenire entro 24 ore (prolungabile fino a sette giorni), altrimenti il messaggio scade. Per gli eventi piattaforma, Salesforce invia gli eventi al bus degli eventi e non attende una conferma o una conferma da parte dell'abbonato. Se l'abbonato non risponde al messaggio, può richiedere di riprodurre l'evento utilizzando l'ID risposta dell'evento. I messaggi degli eventi a volume elevato vengono memorizzati per 72 ore (tre giorni). Per recuperare i messaggi degli eventi passati, utilizzare i client CometD per abbonarsi a un canale.

Volumi di dati

Le considerazioni sul volume dei dati dipendono dalla soluzione scelta. Per i limiti di ogni soluzione, vedere il Riferimento rapido Limiti Salesforce.

Supporto della capacità endpoint e degli standard

La funzionalità e il supporto standard per l'endpoint dipendono dalla soluzione scelta.

Gestione statale

Quando si integrano i sistemi, gli identificatori univoci dei record sono importanti per il tracciamento dello stato in corso. Ad esempio, se viene creato un record nel sistema remoto, sono disponibili due opzioni.

• Salesforce memorizza la chiave surrogata principale o univoca del sistema remoto per il record remoto.
• Il sistema remoto memorizza l'ID record univoco Salesforce o un'altra chiave surrogata univoca.

La tabella seguente elenca le considerazioni relative alla gestione dello stato in questo schema.

Scenari di integrazione complessi

Ogni soluzione in questo schema ha considerazioni diverse per scenari di integrazione complessi come la trasformazione e l'orchestrazione dei processi.

Limitazioni del governatore

A causa della natura multi-tenant della piattaforma Salesforce, esistono limiti per le chiamate in uscita. I limiti dipendono dal tipo di chiamata in uscita e dall'orario della chiamata.

Per i limiti e le allocazioni che si applicano agli eventi piattaforma, vedere il documento Platforms Events Developer Guide.

Messaggistica affidabile

Messaggistica affidabile tenta di risolvere il problema di garantire la consegna di un messaggio a un sistema remoto in cui i singoli componenti non sono affidabili. Il metodo per garantire la ricezione di un messaggio dal sistema remoto dipende dalla soluzione scelta.

In caso di Acquisizione dati di modifica Salesforce vengono forniti tipi di eventi di modifica per gestire situazioni speciali, ad esempio l'acquisizione di modifiche non rilevate nei server delle applicazioni Salesforce o la gestione di carichi elevati di modifiche.

In alcuni casi, Salesforce invia eventi gap anziché eventi di modifica per informare gli abbonati in caso di errori o se non è possibile generare eventi di modifica. Un evento gap contiene informazioni sulla modifica nell'intestazione, ad esempio il tipo di modifica e l'ID record. Non include dettagli sulla modifica, ad esempio i campi dei record. Per acquisire le modifiche in modo più efficiente, vengono generati eventi Overflow per le transazioni singole che superano una soglia. Per ulteriori informazioni vedere qui.

Funzioni middleware

La tabella seguente evidenzia le proprietà desiderate di un sistema middleware che partecipa a questo schema.

Variante della soluzione - Eventi piattaforma: Comportamento di pubblicazione e transazioni

Quando i messaggi degli eventi piattaforma vengono pubblicati immediatamente, la pubblicazione degli eventi non rispetta i confini delle transazioni del processo di pubblicazione. I messaggi degli eventi possono essere pubblicati prima del completamento della transazione o anche se la transazione non riesce. Questo comportamento può causare problemi quando un abbonato prevede di trovare i dati che la transazione di pubblicazione conferma. I dati potrebbero non essere presenti quando l'abbonato riceve il messaggio di evento. Per risolvere questo problema, impostare il comportamento di pubblicazione dell'evento piattaforma su Pubblica dopo l'impegno nella definizione dell'evento. I comportamenti di pubblicazione che è possibile impostare in una definizione evento piattaforma sono:

• Pubblica dopo l'impegno per fare in modo che il messaggio dell'evento venga pubblicato solo dopo che una transazione è stata confermata correttamente. Selezionare questa opzione se gli abbonati si basano sui dati confermati dalla transazione di pubblicazione. Ad esempio, un processo pubblica un messaggio di evento e crea un record operazione. Viene attivato un secondo processo abbonato all'evento che prevede di trovare il record operazione. Un altro motivo per scegliere questo comportamento è quando non si desidera che il messaggio di evento venga pubblicato se la transazione non riesce.
• Pubblica immediatamente per fare in modo che il messaggio di evento venga pubblicato quando viene eseguita la chiamata di pubblicazione. Selezionare questa opzione se si desidera che il messaggio dell'evento venga pubblicato indipendentemente dal fatto che la transazione abbia esito positivo. Scegliere anche questa opzione se il publisher e gli abbonati sono indipendenti e gli abbonati non si basano sui dati confermati dal publisher. Ad esempio, il comportamento di pubblicazione immediata è adatto a un evento utilizzato per la registrazione. Con questa opzione, un abbonato potrebbe ricevere il messaggio di evento prima che i dati vengano confermati dalla transazione publisher.

Esempio

Una società di telecomunicazioni desidera utilizzare Salesforce come front-end per la creazione di account utilizzando il processo lead-to-opportunity. Un ordine viene creato in Salesforce quando l'opportunità viene chiusa e conseguita, ma il sistema ERP di back-end è il master dei dati. L'ordine deve essere salvato nel record opportunità Salesforce e lo stato dell'opportunità modificato per indicare che l'ordine è stato creato.

Si applicano i seguenti vincoli.

• Solo lo sviluppo dichiarativo può essere implementato.
• Non è necessaria una notifica immediata del numero d'ordine dopo che l'opportunità è stata convertita in ordine.
• L'organizzazione dispone di un ESB che supporta il protocollo CometD ed è in grado di abbonarsi agli eventi piattaforma.

Questo esempio è implementato al meglio utilizzando gli eventi piattaforma Salesforce, ma richiede che l'ESB si abboni all'evento piattaforma.

Sul lato Salesforce:

• Creare un flusso per avviare l'evento piattaforma (ad esempio, quando lo stato dell'opportunità diventa Chiusa-conseguita).
• Creare un nuovo evento piattaforma che pubblica i dettagli dell'opportunità.

Sul lato del sistema remoto:

• L'ESB si abbona all'evento piattaforma Salesforce utilizzando il protocollo CometD.
• L'ESB riceve una o più notifiche che indicano che l'opportunità deve essere convertita in ordine.
• L'ESB inoltra il messaggio al sistema ERP di back-end in modo che l'ordine possa essere creato.
• Dopo che l'ordine è stato creato nel sistema ERP, un thread separato richiama Salesforce utilizzando SessionId come token di autenticazione. La richiamata aggiorna l'opportunità con il numero d'ordine e lo stato. È possibile eseguire questa richiamata utilizzando soluzioni basate su schemi documentati, ad esempio eventi piattaforma Salesforce, API SOAP Salesforce, API REST o un servizio Web Apex.

Questo esempio dimostra quanto segue.

• Implementazione di un processo remoto invocato in modo asincrono
• Consegna garantita end-to-end
• Richiamata successiva a Salesforce per aggiornare lo stato del record

Context

Si sta spostando l'implementazione CRM in Salesforce e si desidera:

• Estrarre e trasformare account, referenti e opportunità dal sistema CRM corrente e caricare i dati in Salesforce (importazione dati iniziale).
• Estrarre, trasformare e caricare i dati di fatturazione dei clienti in Salesforce da un sistema remoto su base settimanale (in corso).
• Estrarre le informazioni sulle attività dei clienti da Salesforce e importarle in un data warehouse locale su base settimanale (in corso).

Problema

Come si importano i dati in Salesforce ed esportano i dati da Salesforce, tenendo presente che queste importazioni ed esportazioni possono interferire con le operazioni degli utenti finali durante l'orario di ufficio e coinvolgere grandi quantità di dati?

Forze

Quando si applicano soluzioni basate su questo schema, è necessario considerare diversi fattori:

• I dati devono essere memorizzati in Salesforce? In caso contrario, esistono altre opzioni di integrazione che un architetto può e deve considerare (ad esempio, i mashup).
• Se i dati devono essere archiviati in Salesforce, è necessario aggiornarli in risposta a un evento nel sistema remoto?
• I dati devono essere aggiornati su base pianificata?
• I dati supportano i processi aziendali principali?
• Esistono requisiti di analisi (reportistica) che risentono della disponibilità di questi dati in Salesforce?

Soluzione

La tabella seguente contiene varie soluzioni a questo problema di integrazione.

Sketch

Il diagramma seguente illustra la sequenza degli eventi in questo schema, in cui Salesforce è il master dei dati.

Scarica diagramma

Il diagramma seguente illustra la successiva sincronizzazione degli eventi quasi in tempo reale, in cui Salesforce è il master dei dati.

Risultati

È possibile integrare i dati provenienti dall'esterno con Salesforce nei seguenti scenari:

• Il sistema esterno è il master dei dati: Salesforce è un consumatore di dati forniti da un singolo sistema di origine o da più sistemi. In questo scenario, è comune avere un data warehouse o un data mart che aggrega i dati prima che i dati vengano importati in Salesforce.
• Salesforce è il master dei dati: Salesforce è il sistema di registrazione di determinate entità e le applicazioni client Acquisizione dati di modifica Salesforce possono essere informate delle modifiche ai dati Salesforce.

In un tipico scenario di integrazione Salesforce, il team di implementazione esegue una delle seguenti operazioni:

• Implementare l'acquisizione dati di modifica nella serie di dati di origine.
• Implementare una serie di strutture di database di supporto, dette tabelle di controllo, in un database locale intermedio.

Lo strumento ETL viene quindi utilizzato per creare programmi che:

1. Leggere una tabella di controllo per determinare l'ultimo tempo di esecuzione del processo ed estrarre eventuali altri valori di controllo necessari.
2. Utilizzare i valori di controllo indicati sopra come filtri ed eseguire query sulla serie di dati di origine.
3. Applicare regole di elaborazione predefinite, tra cui convalida, arricchimento e così via.
4. Utilizzare i connettori/le funzionalità di trasformazione disponibili dello strumento ETL per creare la serie di dati di destinazione.
5. Scrivere la serie di dati negli oggetti Salesforce.
6. Se l'elaborazione ha esito positivo, aggiornare i valori di controllo nella tabella di controllo.
7. Se l'elaborazione non riesce, aggiornare le tabelle di controllo con valori che consentono il riavvio e l'uscita.

Nota: Si consiglia di creare le tabelle di controllo e le strutture di dati associate in un ambiente a cui lo strumento ETL ha accesso anche se l'accesso a Salesforce non è disponibile. Ciò fornisce livelli adeguati di resilienza. Salesforce deve essere considerato un punto saliente in questo processo e l'infrastruttura ETL è l'hub.

Per uno strumento ETL per sfruttare al massimo le funzionalità di sincronizzazione dei dati, tenere presente quanto segue:

• Concatenare e mettere in sequenza i processi ETL per offrire un processo coerente.
• Utilizzare le chiavi principali di entrambi i sistemi per abbinare i dati in entrata.
• Utilizzare metodi API specifici per estrarre solo i dati aggiornati.
• Se si importano record controllati in una relazione record principale-record dettaglio o di ricerca, raggruppare i dati importati utilizzando la chiave controllante all'origine per evitare il blocco. Ad esempio, se si importano i dati dei referenti, assicurarsi di raggruppare i dati dei referenti in base alla chiave account controllante in modo che sia possibile caricare il numero massimo di referenti per un singolo account in una sola chiamata API. Se non si raggruppano i dati importati, in genere il primo record referente viene caricato e i successivi record referente di quell'account non vengono visualizzati nel contesto della chiamata API.
• Qualsiasi elaborazione post-importazione, ad esempio i trigger, deve elaborare i dati solo in modo selettivo.
• Se lo scenario prevede grandi volumi di dati, seguire le procedure consigliate di questo modulo Trailhead Best Practices for Deployments with Large Data Volumes (Migliori pratiche per le distribuzioni con grandi volumi di dati)
.

Gestione e ripristino degli errori

Una strategia di gestione e ripristino degli errori deve essere considerata parte della soluzione complessiva. Il metodo migliore dipende dalla soluzione scelta.

Considerazioni sulla sicurezza

Qualsiasi chiamata a un sistema remoto deve mantenere la riservatezza, l'integrità e la disponibilità della richiesta. Vengono applicate diverse considerazioni sulla sicurezza, a seconda della soluzione scelta.

• Per consentire l'accesso API autenticato all'API Salesforce è necessaria una licenza Lightning Platform con almeno le autorizzazioni utente "Solo API".
• Si consiglia di utilizzare la crittografia standard per garantire la sicurezza dell'accesso con password.
• Utilizzare il protocollo HTTPS quando si effettuano chiamate alle API Salesforce. Se necessario, è anche possibile delegare il traffico alle API Salesforce tramite una soluzione di sicurezza locale.

Vedere Considerazioni sulla sicurezza.

Intestazioni laterali

Nessuno.

Tempestività

La tempestività non è importante in questo schema. Tuttavia, è necessario fare attenzione a progettare le interfacce in modo che tutti i processi batch vengano completati in una finestra batch designata.

Come per tutte le operazioni orientate ai batch, si consiglia vivamente di prestare attenzione a isolare i sistemi di origine e di destinazione durante le finestre di elaborazione batch. Il caricamento dei batch durante l'orario di ufficio può causare controversie, con il risultato che l'aggiornamento di un utente non riesce o, più significativamente, un caricamento batch (o caricamento batch parziale) non riesce.

Per le organizzazioni con operazioni globali, potrebbe non essere possibile eseguire tutti i processi batch contemporaneamente poiché il sistema potrebbe essere continuamente in uso. È possibile utilizzare tecniche di segmentazione dei dati che utilizzano tipi di record e altri criteri di filtro per evitare contenziosi sui dati in questi casi.

Gestione statale

È possibile implementare la gestione dello stato utilizzando chiavi surrogate tra i due sistemi. Se è necessario gestire qualsiasi tipo di transazione tra entità Salesforce, si consiglia di utilizzare lo schema di chiamata remota utilizzando Apex.

Il blocco dei record ottimistico standard si verifica nella piattaforma e tutti gli aggiornamenti effettuati utilizzando l'API richiedono all'utente che sta modificando il record di aggiornare il record e avviare la transazione. Nel contesto dell'API Salesforce, il blocco ottimistico si riferisce a un processo in cui:

• Salesforce non mantiene lo stato di un record modificato da un utente specifico.
• Durante la lettura, registra l'ora in cui i dati sono stati estratti.
• Se l'utente aggiorna il record e lo salva, Salesforce verifica se un altro utente ha aggiornato il record nel frattempo.
• Se il record è stato aggiornato, il sistema notifica all'utente che è stato eseguito un aggiornamento e l'utente deve recuperare la versione più recente del record prima di procedere con gli aggiornamenti.

Funzioni middleware

Le tecnologie esterne più efficaci utilizzate per implementare questo schema sono gli strumenti ETL tradizionali. È importante che gli strumenti middleware scelti supportino l'API in blocco Salesforce.

È utile, ma non fondamentale, che gli strumenti middleware supportino la funzione getUpdated(). Questa funzione offre l'implementazione più vicina alla funzionalità di acquisizione dati di modifica standard nella piattaforma Salesforce.

La tabella seguente evidenzia le proprietà desiderate di un sistema middleware che partecipa a questo schema.

Esempio

Una società di servizi utilizza un processo batch basato su mainframe che assegna i clienti potenziali a singoli agenti di vendita e team. Queste informazioni devono essere importate in Salesforce ogni notte.

Il cliente ha deciso di implementare l'acquisizione dati di modifica nelle tabelle di origine utilizzando uno strumento ETL disponibile in commercio. La soluzione funziona come segue:

• Uno strumento di pianificazione simile a una cronologia esegue un processo batch che assegna clienti potenziali a utenti e team.
• Dopo l'esecuzione del processo batch e l'aggiornamento dei dati, lo strumento ETL riconosce queste modifiche utilizzando l'acquisizione dati di modifica. Lo strumento ETL confronta le modifiche dall'archivio dati.
• Il connettore ETL utilizza l'API REST Salesforce per caricare le modifiche in Salesforce.

Context

Salesforce si utilizza per tenere traccia dei lead, gestire le opportunità in corso di realizzazione, creare opportunità e acquisire i dettagli degli ordini che convertono i lead in clienti. Il sistema Salesforce crea gli ordini internamente e quindi invia i dati al sistema di fatturazione esterno per il provisioning e l'attivazione. Gli ordini di fatturazione sono gestiti da un sistema esterno (remoto). Il sistema remoto deve aggiornare lo stato dell'ordine in Salesforce quando l'ordine o l'entità di fatturazione sullo stato del sistema di fatturazione cambia.

Problema

In che modo un sistema remoto si connette e si autentica con Salesforce per informare Salesforce di eventi esterni, creare record e aggiornare record esistenti?

Forze

Quando si applicano soluzioni basate su questo schema, è necessario considerare diversi fattori:

• Lo scopo della chiamata remota a Salesforce è informare Salesforce di un evento che si è verificato esternamente utilizzando un'architettura basata sugli eventi? Oppure lo scopo è eseguire operazioni CRUD su record specifici? Se si utilizza un'architettura basata sugli eventi, il produttore dell'evento (il processo remoto) viene disaccoppiato dal consumatore dell'evento Salesforce.
• La chiamata a Salesforce richiede che il processo remoto attenda una risposta prima di continuare l'elaborazione? Le chiamate remote a Salesforce sono sempre richieste-risposte sincrone, anche se il processo remoto può scartare la risposta se non è necessario simulare una chiamata asincrona.
• Ogni transazione funziona per un singolo oggetto Salesforce o per più oggetti correlati?
• Qual è il formato del messaggio (ad esempio, SOAP o REST o entrambi su HTTP)?
• Le dimensioni del messaggio sono relativamente piccole o grandi?
• Se il sistema remoto è compatibile con SOAP, è in grado di partecipare a un approccio basato sul contratto, in cui Salesforce detta il contratto? Questo è necessario dove viene utilizzata la nostra API SOAP, per la quale viene fornito un WSDL predefinito.
• È necessaria l'elaborazione delle transazioni?
• Qual è la misura in cui si tollera la personalizzazione in Salesforce?

Soluzione

Questa tabella contiene varie soluzioni a questo problema di integrazione.

Sketch

I diagrammi seguenti illustrano la sequenza degli eventi quando si implementa questo schema utilizzando l'API REST per le notifiche da eventi esterni o l'API SOAP per eseguire query su un oggetto Salesforce. La sequenza degli eventi è la stessa quando si utilizza l'API REST.

Esecuzione remota di query di sistema in Salesforce tramite API SOAP

Notifica del sistema remoto a Salesforce con gli eventi tramite l'API REST

Risultati

In un'architettura basata sugli eventi, il sistema remoto chiama Salesforce utilizzando l'API SOAP, l'API REST o l'API in blocco 2.0 per pubblicare un evento nel bus degli eventi Salesforce. La pubblicazione di un evento invia una notifica a tutti gli abbonati. Gli abbonati agli eventi possono trovarsi in Salesforce Platform, ad esempio Flussi o Componenti Lightning, trigger Apex. Gli abbonati agli eventi possono anche essere esterni a Salesforce Platform, ad esempio gli abbonati CometD.

Quando si lavora direttamente con gli oggetti Salesforce, le soluzioni correlate a questo schema consentono di:

• Il sistema remoto chiama le API Salesforce per eseguire query sul database ed eseguire operazioni su singoli oggetti (creazione, aggiornamento, eliminazione e così via).
• Sistema remoto per chiamare le risorse composite dell'API REST Salesforce per eseguire una serie di operazioni sugli oggetti.
• Sistema remoto per chiamare API Salesforce personalizzate (servizi) che possono supportare operazioni transazionali multi-oggetto e logica di pre/post-elaborazione personalizzata.

Meccanismi di chiamata

Il meccanismo di chiamata dipende dalla soluzione scelta per implementare questo schema.

Gestione e ripristino degli errori

Una strategia di gestione e ripristino degli errori deve essere considerata parte della soluzione complessiva.

• Gestione degli errori: tutti i metodi di chiamata remota, API standard o personalizzate, richiedono che il sistema remoto gestisca eventuali errori successivi, ad esempio i timeout e la gestione dei tentativi. Middleware può essere utilizzato per fornire la logica per la gestione e il ripristino degli errori.
• Ripristino: è necessario creare un meccanismo di tentativo personalizzato se richiesto dai requisiti di qualità del servizio. In questo caso, è importante garantire caratteristiche di progettazione idempotenti. L'evento piattaforma consente agli abbonati di utilizzare il replay ID per recuperare i messaggi entro un determinato periodo di tempo dopo la pubblicazione di tali messaggi.

Considerazioni sulla progettazione idempotente

Le funzionalità idempotenti garantiscono che le chiamate ripetute siano sicure e non abbiano un effetto negativo. Se non viene implementata l'impotenza, le invocazioni ripetute dello stesso messaggio possono avere risultati diversi, causando potenzialmente problemi di integrità dei dati, ad esempio la creazione di record duplicati, l'elaborazione di transazioni duplicate e così via.

Il sistema remoto deve gestire più chiamate (duplicate), in caso di errori o timeout, per evitare inserimenti duplicati e aggiornamenti ridondanti (soprattutto se vengono attivati trigger a valle e regole di flusso di lavoro). Benché sia possibile gestire alcune di queste situazioni all'interno di Salesforce (in particolare nel caso di servizi SOAP e REST personalizzati), si consiglia al sistema remoto (o middleware) di gestire la gestione degli errori e la progettazione idempotente.

Considerazioni sulla sicurezza

Vengono applicate diverse considerazioni sulla sicurezza, a seconda della soluzione di schema scelta. In tutti i casi, la piattaforma utilizza i diritti di accesso dell'utente connesso (ad esempio, impostazioni del profilo, regole di condivisione, insiemi di autorizzazioni e così via). Inoltre, le restrizioni IP del profilo possono essere utilizzate per limitare l'accesso all'API per un intervallo di indirizzi IP specifico.

Vedere Considerazioni sulla sicurezza.

Intestazioni laterali

Nessuno.

Tempestività

L'API SOAP e l'API servizio Web Apex sono sincrone. Si applicano i seguenti timeout:

• Timeout sessione: la sessione scade se non è presente alcuna attività in base all'impostazione di timeout sessione dell'organizzazione Salesforce.
• Timeout della query: ogni query SOQL ha un limite di timeout individuale di 120 secondi.

Volumi di dati

Le considerazioni sul volume di dati dipendono dalla soluzione e dal tipo di comunicazione scelti.

Supporto della capacità endpoint e degli standard

La funzionalità e il supporto standard per l'endpoint dipendono dalla soluzione scelta.

Gestione statale

Quando si integrano i sistemi, le chiavi sono importanti per il tracciamento continuo dello stato, ad esempio se viene creato un record nel sistema remoto, per supportare gli aggiornamenti continui di quel record. Sono disponibili due opzioni:

• Salesforce memorizza la chiave surrogata principale o univoca del sistema remoto per il record remoto.
• Il sistema remoto memorizza l'ID record univoco Salesforce o un'altra chiave surrogata univoca. Esistono considerazioni specifiche sulla gestione delle chiavi di integrazione in questo schema sincrono.

Scenari di integrazione complessi

Ogni soluzione in questo schema ha considerazioni diverse quando si gestiscono scenari di integrazione complessi come la trasformazione e l'orchestrazione dei processi.

Limitazioni del governatore

A causa della natura multi-tenant della piattaforma Salesforce, esistono dei limiti quando si utilizzano le API.

Messaggistica affidabile

Messaggistica affidabile tenta di risolvere il problema di garantire la consegna di un messaggio a un sistema remoto in cui i singoli componenti potrebbero non essere affidabili. L'API SOAP Salesforce e l'API REST sono sincrone e non forniscono supporto esplicito per protocolli di messaggistica affidabili, di per sé (ad esempio, WS-ReliableMessaging).

Si consiglia al sistema remoto di implementare un sistema di messaggistica affidabile per garantire che gli scenari di errore e timeout vengano gestiti correttamente. La pubblicazione di eventi piattaforma da sistemi esterni si basa sulle API Salesforce, pertanto valgono le stesse considerazioni per l'API SOAP e l'API REST.

Funzioni middleware

Questa tabella evidenzia le proprietà desiderate di un sistema middleware che partecipa a questo schema:

Esempio

Una società di forniture e servizi di stampa utilizza Salesforce come front-end per creare e gestire le forniture e gli ordini di stampanti. I record asset Salesforce che rappresentano le stampanti vengono periodicamente aggiornati con le statistiche di utilizzo della stampa (stato dell'inchiostro, livello della carta) dal sistema di gestione stampanti (PMS) locale, che monitora regolarmente le stampanti nelle sedi dei clienti. Quando si raggiunge un valore di soglia impostato (ad esempio, un livello di inchiostro basso o un livello di carta basso/vuoto inferiore al 30%), vengono inviate notifiche a più app/processi (variabili) interessati all'evento, email o Chatter e viene creato un record Ordine. Il PMS memorizza l'ID Salesforce (Salesforce è il record principale asset).

Si applicano i seguenti vincoli:

• Il PMS può partecipare a un'integrazione contract-first, in cui Salesforce fornisce il contratto e il PMS agisce come cliente (consumatore) del servizio Salesforce (definito tramite il WSDL Enterprise o Partner).
• Non dovrebbe esserci sviluppo personalizzato in Salesforce.

Questo esempio è implementato al meglio utilizzando l'API SOAP Salesforce o l'API REST per pubblicare gli eventi e l'automazione dichiarativa (Flusso) in Salesforce. Il motivo principale per utilizzare gli eventi piattaforma è la variabile e il numero non finito di abbonati; tuttavia, per i semplici aggiornamenti a un elenco finito di record, ad esempio gli ordini, utilizzare SOAP o l'API REST per aggiornare i record.

In Salesforce:

• Definire un evento piattaforma in Salesforce per contenere i dati di notifica provenienti dal PMS.
• Creare un flusso attivato dalla notifica dell'evento stampante. Il processo aggiorna l'asset stampante e crea un ordine (utilizzando un flusso AutoLaunched).
• Scaricare il WSDL Enterprise o Partner e fornirlo al sistema remoto.

Nel sistema remoto:

• Creare uno stub client dal WSDL Enterprise o Partner.
• Eseguire l'autenticazione in Salesforce (tramite server Web OAuth o flusso token bearer) utilizzando le credenziali dell'utente integrazione.
• All'evento stato stampante, il PMS chiama l'API per creare l'evento piattaforma stato stampante (con statistiche di utilizzo della stampante). Il bus degli eventi Salesforce invia una notifica all'abbonato Flusso e a tutti gli altri abbonati.

Quando si utilizzano gli eventi piattaforma, il bus degli eventi consente di riprodurre gli eventi per 72 ore per gli eventi piattaforma a volume elevato. La pubblicazione di tali eventi utilizzando una soluzione middleware può aiutare a incorporare la gestione degli errori sul lato pubblicazione. Tuttavia, è possibile implementare la gestione degli errori sul lato abbonamento se si necessita di una maggiore affidabilità.

Questo esempio dimostra quanto segue:

• Implementazione di un client API sincrono Salesforce (consumer).
• Una richiamata a Salesforce per pubblicare un evento piattaforma (in linea con gli schemi di evento piattaforma richiesta/risposta descritti in precedenza).

Context

Salesforce viene utilizzato per gestire i casi dei clienti. Un agente dell'assistenza clienti è al telefono con un cliente che sta lavorando su un caso. Il cliente effettua un pagamento e l'agente dell'assistenza clienti deve visualizzare un aggiornamento in tempo reale nell'applicazione Salesforce dall'applicazione di elaborazione del pagamento, che indica che il cliente ha pagato correttamente l'importo in sospeso dell'ordine.

Problema

Quando si verifica un evento in Salesforce, come si può ricevere una notifica nell'interfaccia utente di Salesforce senza dover aggiornare la schermata e potenzialmente perdere lavoro?

Forze

Quando si applicano soluzioni basate su questo schema, è necessario considerare diversi fattori:

• I dati su cui si agisce devono essere archiviati in Salesforce?
• È possibile creare un livello di interfaccia utente personalizzato per visualizzare questi dati?
• L'utente avrà accesso per invocare l'interfaccia utente personalizzata?

Soluzione

La soluzione consigliata a questo problema di integrazione è utilizzare gli eventi piattaforma che garantiscono eventi quasi in tempo reale in Salesforce. Gli eventi piattaforma offrono un payload strutturato e flessibile indipendentemente da qualsiasi oggetto Salesforce. Garantisce inoltre argomenti durevoli con una finestra di replay di 72 ore. Ciò garantisce che gli eventi siano disponibili anche se un consumatore offline diventa disponibile in un secondo momento. Questa soluzione è costituita dai seguenti elementi:

• Trigger Apex o flussi con una logica per pubblicare un evento piattaforma su un argomento
• Argomento che consente di pubblicare un evento da trigger Apex o flusso
• Un'implementazione basata su JavaScript del protocollo Bayeux (attualmente CometD) che può essere utilizzata dall'interfaccia utente
• Un componente Lightning
• Libreria JavaScript inclusa come risorsa statica

Sketch

Lo schema riportato di seguito illustra come implementare Streaming API per inviare notifiche in streaming all'interfaccia utente di Salesforce. Queste notifiche vengono attivate dalle modifiche dei record in Salesforce.

Aggiornamento dell'interfaccia utente in Salesforce attivato da una modifica dei dati

Risultati

Vantaggi

L'applicazione della soluzione correlata a questo schema presenta i seguenti vantaggi:

• Elimina la necessità di scrivere meccanismi di polling personalizzati
• Elimina la necessità di un loop di feedback avviato dall'utente

Requisiti non supportati

La soluzione presenta le seguenti limitazioni:

• La consegna delle notifiche non è garantita.
• L'ordine delle notifiche non è garantito.
• Le notifiche non vengono generate dalle modifiche ai record apportate dall'API in blocco.

Considerazioni sulla sicurezza

Viene rispettata la protezione standard a livello di organizzazione Salesforce. Si consiglia di utilizzare il protocollo HTTPS per connettersi alla Streaming API. Vedere Considerazioni sulla sicurezza

Intestazioni laterali

La soluzione ottimale prevede la creazione di un'interfaccia utente personalizzata in Salesforce. È imperativo tenere presente un contenitore dell'interfaccia utente appropriato che può essere utilizzato per visualizzare l'interfaccia utente personalizzata. I browser supportati sono elencati nella Streaming API Developer Guide

Esempio

Una società di telecomunicazioni utilizza Salesforce per gestire i casi dei clienti. I responsabili dell'assistenza clienti desiderano ricevere una notifica quando un caso viene chiuso correttamente da uno degli agenti dell'assistenza clienti.

Implementando la soluzione prescritta da questo schema, il cliente deve:

• Creare un PushTopic Trigger Apex che invia un evento piattaforma quando un caso viene salvato con stato "Chiuso" e risoluzione "Riuscito".
• Creare un'interfaccia utente personalizzata disponibile per i responsabili dell'assistenza clienti. Questa interfaccia utente si abbona al bus degli eventi per utilizzare gli eventi piattaforma.
• Implementare la logica nell'interfaccia utente personalizzata che mostra gli avvisi generati dagli agenti dell'assistenza clienti del responsabile.

Context

Salesforce si utilizza per tenere traccia dei lead, gestire le opportunità in corso di realizzazione, creare opportunità e acquisire i dettagli degli ordini che convertono i lead in clienti. Tuttavia, Salesforce non è il sistema che contiene o elabora gli ordini. Gli ordini sono gestiti da un sistema esterno (remoto). Tuttavia, gli agenti di vendita desiderano visualizzare e aggiornare le informazioni sugli ordini in tempo reale in Salesforce senza dover imparare o utilizzare il sistema esterno.

Problema

In Salesforce, come visualizzare, cercare e modificare i dati archiviati all'esterno di Salesforce, senza spostare i dati dal sistema esterno in Salesforce?

Forze

Quando si applicano soluzioni basate su questo schema, è necessario considerare diversi fattori:

• Si desidera creare un'integrazione dichiarativa/point-and-click in uscita o un mashup dell'interfaccia utente in Salesforce?
• Si dispone di una grande quantità di dati che non si desidera copiare nell'organizzazione Salesforce?
• È necessario accedere contemporaneamente a piccole quantità di dati di sistema remoti?
• È necessario accedere in tempo reale ai dati più recenti?
• I dati vengono archiviati nel cloud o in un sistema di back-office ma si desidera visualizzare o elaborare i dati nell'organizzazione Salesforce?
• Si hanno problemi di residenza dei dati per l'archiviazione di alcuni tipi di dati in Salesforce?

Soluzione

La tabella seguente contiene varie soluzioni a questo problema di integrazione.

Sketch

Lo schema seguente illustra come utilizzare Salesforce Connect per estrarre i dati da un sistema esterno utilizzando un adattatore OData.

In questo scenario:

1. Il browser esegue una chiamata AJAX che a sua volta esegue un'azione sull'adattatore oggetto esterno corrispondente.
2. L'adattatore traduce l'azione in una richiesta OData ed effettua una richiesta GET HTTP al sistema remoto tramite i livelli Integrazione e Servizi.
3. Il sistema remoto restituisce una risposta JSON a Salesforce tramite i livelli Integrazione e Servizi.
4. La risposta viene tradotta da OData in un oggetto esterno e ripresentata al browser.

Risultati

L'applicazione delle soluzioni correlate a questo schema consente le chiamate avviate dall'interfaccia utente in cui il risultato della transazione può essere visualizzato all'utente finale.

Meccanismi di chiamata

Il meccanismo di chiamata dipende dalla soluzione scelta per implementare questo schema.

Gestione errori

È importante includere la gestione degli errori nella soluzione generale. Quando si verifica un errore (vengono restituiti al chiamante codici di eccezioni o di errore), il chiamante gestisce la gestione degli errori. Salesforce Connect Validator è uno strumento gratuito per eseguire alcune query comuni e rilevare tipi di errore e cause di errore.

Vantaggi

Alcuni dei vantaggi offerti dall'utilizzo di una soluzione Salesforce Connect sono:

• Questa soluzione non consuma memoria dati in Salesforce.
• Gli utenti non devono preoccuparsi di sincronizzare regolarmente i dati tra il sistema esterno e Salesforce.
• Un'impostazione dichiarativa che può essere eseguita rapidamente con OData o un adattatore tra organizzazioni o utilizzando codice minimo con un adattatore Apex personalizzato.
• Gli utenti possono accedere ai dati esterni con molte delle stesse funzionalità degli oggetti personalizzati sotto forma di oggetti esterni.
• Possibilità di effettuare una ricerca federata nel sistema esterno connesso utilizzando la ricerca globale.
• Possibilità di eseguire rapporti che accedono a dati esterni da fonti cloud e locali. Fare riferimento alle considerazioni sui rapporti riportate di seguito.

Considerazioni su Salesforce Connect

La soluzione Salesforce Connect ha le seguenti considerazioni:

• Gli oggetti esterni si comportano come oggetti personalizzati, ma alcune funzioni non sono disponibili per gli oggetti esterni. Per ulteriori informazioni, vedere Considerazioni sulla compatibilità.
• Gli oggetti esterni possono influire sulle prestazioni dei rapporti. Per ulteriori informazioni, vedere Considerazioni sui rapporti per Salesforce Connect.
• Per ulteriori considerazioni sull'utilizzo degli adattatori Salesforce Connect, vedere Considerazioni per Salesforce Connect — Tutti gli adattatori.
• Se si sta pensando di utilizzare un adattatore tra organizzazioni, vedere Considerazioni per Salesforce Connect — Adattatore tra organizzazioni.
• Se si sta pensando di utilizzare un adattatore OData, vedere Considerazioni per Salesforce Connect — Adattatori OData 2.0 e 4.0.
• Se si sta pensando di utilizzare un adattatore Apex personalizzato, vedere Considerazioni per Salesforce Connect — Adattatore personalizzato.

Considerazioni sulla sicurezza

Le soluzioni per questo schema devono rispettare la protezione standard a livello di organizzazione Salesforce. Si consiglia di utilizzare il protocollo HTTPS per connettersi a qualsiasi sistema remoto. Per ulteriori dettagli, vedere Considerazioni sulla sicurezza

Se si utilizza un connettore OData, assicurarsi di aver compreso i comportamenti speciali, le limitazioni e i consigli per Cross-Site Request Forgery (CSRF) sulle fonti di dati esterne OData. Per ulteriori informazioni, vedere Considerazioni CSRF per Salesforce Connect — Adattatori OData 2.0 e 4.0.

Intestazioni laterali

Nessuno.

Tempestività

La tempestività è di importanza significativa in questo schema. Tenere presenti i seguenti punti:

• La richiesta viene in genere richiamata dall'interfaccia utente, quindi il processo non deve far attendere l'utente.
• A seconda della disponibilità e della connessione al sistema esterno, il recupero dei dati esterni può richiedere molto tempo. Salesforce ha un valore di timeout massimo configurabile di 120 secondi per attendere una risposta dal sistema esterno.
• Il completamento del processo remoto deve essere eseguito in modo tempestivo ed entro il limite di timeout di Salesforce e nel rispetto delle aspettative degli utenti.

Volumi di dati

Questo schema viene utilizzato principalmente per le attività in tempo reale a volume ridotto, a causa dei piccoli valori di timeout e della dimensione massima della richiesta o della risposta per la soluzione di chiamata Apex. Non utilizzare questo schema nelle attività di elaborazione batch in cui il payload di dati è contenuto nel messaggio.

Supporto della capacità endpoint e degli standard

La funzionalità e il supporto degli standard per l'endpoint dipendono dalla soluzione scelta.

Gestione statale

Quando si integrano i sistemi, le chiavi sono importanti per il tracciamento continuo dello stato. Ad esempio, se un record viene creato nel sistema remoto, in genere il record necessita di una sorta di chiave identificativa per supportare gli aggiornamenti in corso. Per memorizzare le chiavi sono disponibili due opzioni.

• Salesforce memorizza la chiave surrogata principale o univoca per il record remoto.
• Il sistema remoto memorizza l'ID record univoco Salesforce o un'altra chiave surrogata univoca. Esistono considerazioni specifiche sulla gestione delle chiavi di integrazione in questo schema sincrono.

Integrazioni complesse

In alcuni casi, la soluzione prescritta da questo schema può richiedere l'implementazione di uno scenario di integrazione complesso. Questi scenari vengono spesso risolti utilizzando middleware.

• Aggregazione delle chiamate e dei relativi risultati nelle chiamate a più sistemi
• Trasformazione dei messaggi in entrata e in uscita
• Mantenere l'integrità delle transazioni tra le chiamate a più sistemi
• Altre attività di orchestrazione dei processi tra Salesforce e il sistema esterno

Limite governativo

Si applicano limiti diversi per adattatori diversi. Per ulteriori dettagli, vedere Limiti generali per Salesforce Connect.

Funzioni middleware

La tabella seguente evidenzia le proprietà desiderate di un sistema middleware che partecipa a questo schema.

Relazioni tra oggetti esterni

Gli oggetti esterni supportano le relazioni di ricerca standard, che utilizzano l'ID record Salesforce di 18 caratteri per associare i record correlati. Tuttavia, i dati archiviati all'esterno dell'organizzazione Salesforce spesso non contengono tali ID record. Pertanto, per gli oggetti esterni sono disponibili due tipi speciali di relazioni di ricerca: ricerche esterne e ricerche indirette.

Questa tabella riepiloga i tipi di relazioni disponibili per gli oggetti esterni.

Considerazioni sui volumi di dati elevati per Salesforce Connect — Adattatori OData 2.0 e 4.0

Se l'organizzazione supera i limiti di traffico quando accede agli oggetti esterni, valutare la possibilità di selezionare l'opzione Volume di dati elevato sulle fonti di dati esterne associate. In questo modo si ignorano la maggior parte dei limiti di traffico, ma si applicano alcuni comportamenti e limitazioni speciali. Per ulteriori informazioni, vedere Considerazioni sui volumi elevati

Paging gestito dal client e dal server per Salesforce Connect — Adattatori OData 2.0 e 4.0

È comune che le query Salesforce Connect di dati esterni abbiano un insieme di risultati di grandi dimensioni suddiviso in batch o pagine più piccoli. È possibile decidere se il comportamento del paging deve essere controllato dal sistema esterno (gestito dal server) o dall'adattatore OData 2.0 o 4.0 per Salesforce Connect (gestito dal client). Il campo Paginazione guidata dal server nella fonte di dati esterna specifica se utilizzare il paging gestito dal client o dal server. Se si abilita il paging gestito dal server su una fonte di dati esterna, Salesforce ignora le dimensioni della pagina richieste, inclusa la dimensione batch predefinita queryMore() di 500 righe. Le pagine restituite dal sistema esterno determinano i batch, ma ogni pagina non può superare le 2.000 righe. Tuttavia, i limiti per gli adattatori OData per Salesforce Connect rimangono validi.

Esempio

Una società di produzione utilizza Salesforce per gestire i casi dei clienti. Gli agenti dell'assistenza clienti desiderano accedere alle informazioni sugli ordini in tempo reale dal sistema ERP di back-office per avere una visione a 360 gradi del cliente senza dover apprendere ed eseguire manualmente i rapporti in ERP.

Implementando la soluzione prescritta da questo schema, è necessario:

• Configurare la fonte di dati esterna con un endpoint OData. L'applicazione remota può includere il supporto nativo per OData. Per altre applicazioni, i principali fornitori di integrazione come Dell Boomi, Informatica, Jitterbit, MuleSoft e Progress Software hanno collaborato con Salesforce su Salesforce Connect per creare adattatori.
• Puntare Salesforce Connect all'endpoint OData, direttamente o tramite una soluzione middleware.
• Sincronizzare le tabelle del database esterno con gli oggetti esterni in Salesforce. Quando un utente accede a una pagina con i dati di questi oggetti esterni, Salesforce Connect effettua chiamate in tempo reale alle applicazioni di back-end.

Documentazione per sviluppatori

• Guida di Salesforce: Assegnazione dell'accesso solo API agli utenti integrazione

• Guida per lo sviluppatore API SOAP

• Guida per lo sviluppatore dell'API REST

• Guida per lo sviluppatore Streaming API

• Guida per lo sviluppatore di API in blocco 2.0 e API in blocco

• Guida Apex Developer

• Riferimento SOQL e SOSL

• Limite e allocazioni di Salesforce Developer

• Guida per lo sviluppatore di eventi piattaforma

• Apex Developer Guide (Guida per lo sviluppatore Apex): Salesforce Connect

Trailhead

• Grandi volumi di dati

• Nozioni di base sugli eventi piattaforma

• Nozioni di base sull'acquisizione dati di modifica

• Avvio rapido: Salesforce Connect

Per essere membri efficaci del portafoglio aziendale, tutte le applicazioni devono essere create e integrate con i meccanismi di sicurezza pertinenti. Le moderne strategie IT utilizzano una combinazione di servizi locali e basati su cloud.

Mentre l'integrazione dei servizi cloud a cloud in genere si concentra sui servizi Web e sulle autorizzazioni associate, la connessione di servizi locali e cloud spesso introduce una maggiore complessità. Questa sezione descrive gli strumenti di sicurezza, le tecniche e le considerazioni specifiche di Salesforce.

Server proxy inverso

Un proxy inverso è un server che si trova di fronte ai server Web e inoltra le richieste client (ad esempio browser Web) a tali server Web. I proxy inversi vengono in genere implementati per migliorare la sicurezza, le prestazioni e l'affidabilità.

È un tipo di server proxy che recupera risorse per conto di un client da uno o più server. Queste risorse vengono quindi restituite al client come se provenissero dal server proxy stesso. A differenza di un proxy forward, che è un intermediario per i client associati per contattare qualsiasi server, un proxy reverse è un intermediario per i server associati per essere contattati da qualsiasi client.

Nelle implementazioni Salesforce, tale servizio viene in genere fornito tramite un prodotto gateway esterno. Ad esempio, è possibile utilizzare opzioni open source come HTTP Apache, lighttpd e nginix. I prodotti commerciali includono IBM WebSeal e Computer Associates SiteMinder. Questi prodotti possono essere facilmente configurati per la delega e la gestione di tutte le richieste Salesforce in uscita per conto del richiedente interno.

Crittografia

Alcune aziende richiedono la crittografia di transazioni o campi di dati selezionati tra una combinazione di applicazioni locali e basate su cloud. Se l'organizzazione deve rispettare ulteriori requisiti di conformità, è possibile implementare alternative, tra cui:

• Servizi gateway di crittografia commerciale locali, inclusi Salesforce, CipherCloud, IBM DataPower, Computer Associates. Per ogni soluzione, il motore di crittografia o il gateway viene richiamato al confine della transazione inviando e ricevendo un payload crittografato o durante la crittografia o la decrittografia di campi di dati specifici prima dell'esecuzione della richiesta HTTP(S).

• Opzioni basate su cloud, ad esempio Salesforce Shield Platform Encryption. Shield Platform Encryption offre ai dati un nuovo livello di sicurezza, preservando le funzionalità essenziali della piattaforma. I dati selezionati vengono crittografati a riposo utilizzando un sistema avanzato di derivazione delle chiavi. È possibile proteggere i dati in modo più sicuro che mai. Per ulteriori informazioni, vedere la guida in linea di Salesforce.

Supporto del protocollo WS-* specializzato

Per soddisfare i requisiti dei protocolli di sicurezza (ad esempio WS-*), si consiglia di utilizzare le seguenti alternative.

• Gateway Security/XML: inserire le credenziali WS-Security (IBM WebSeal o Datapower, Layer7, TIBCO e così via) nello stream della transazione stessa. Questo approccio non richiede modifiche ai servizi Web a livello di applicazione o alle chiamate ai servizi Web da Salesforce. È anche possibile riutilizzare questo approccio nell'installazione di Salesforce. Tuttavia, richiede ulteriore progettazione, configurazione, test e manutenzione per gestire l'iniezione WS-Security appropriata nell'approccio gateway di protezione esistente.

• Crittografia a livello di trasporto: crittografare il canale di comunicazione utilizzando restrizioni SSL e IP bidirezionali. Sebbene questo approccio non implementi direttamente il protocollo WS-* da solo, protegge il canale di comunicazione tra le applicazioni locali e Salesforce senza passare un nome utente e una password. Inoltre, non richiede modifiche alle classi generate da Salesforce. Tuttavia, potrebbero essere necessarie alcune modifiche ai servizi Web locali (a livello dell'applicazione stessa o a livello middleware/ESB).

• Sviluppo personalizzato Salesforce: aggiungere intestazioni WS-Security alla richiesta SOAP in uscita tramite l'utilità WSDL2Apex. Questo genera una classe Apex simile a Java dal file WSDL utilizzato per invocare il servizio interno. Sebbene questo approccio non richieda modifiche ai servizi Web di back-end o ai componenti aggiuntivi nella DMZ, richiede:

  • un maggiore sforzo di creazione e test
  • un processo relativamente complesso e manuale per codificare manualmente gli attributi di WS-Security (inclusa la serializzazione XML all'interno di Apex Code)
  • maggiore impegno di manutenzione a lungo termine

Nota: L'ultima opzione non è consigliata a causa della sua complessità e del rischio che tali integrazioni richiedano revisioni periodiche basate su aggiornamenti regolari di Salesforce.

Altre considerazioni sulla sicurezza

• Credenziali denominate: Con lo scopo di proteggere e semplificare le chiamate API autenticate ai sistemi esterni, una credenziale denominata specifica l'URL di un endpoint di chiamata e i relativi parametri di autenticazione richiesti in un'unica definizione. Per semplificare l'Apex Code e l'impostazione delle chiamate autenticate, specificare una credenziale denominata come endpoint di chiamata. Per ulteriori dettagli vedere qui.

• OAUTH 2.0: OAuth 2.0 è un framework di autorizzazione standard del settore che consente a un utente di concedere un accesso limitato alle proprie risorse protette a un'applicazione di terze parti senza condividere le proprie credenziali (ad esempio le password). Anziché uno scambio diretto di password, l'utente approva una richiesta di token di accesso, che l'applicazione utilizza quindi per accedere ai dati dell'utente da un server di risorse. Questo processo separa l'applicazione client dall'identità e dalla password dell'utente, migliorando la sicurezza fornendo una "chiave" temporanea specifica dell'ambito per l'accesso alle risorse. Per ulteriori informazioni vedere qui.

• Private Connect: Quando si integra l'organizzazione Salesforce con applicazioni ospitate su servizi cloud di terze parti, è essenziale poter inviare e ricevere traffico HTTP/s in modo sicuro. Con Private Connect, aumentare la sicurezza delle integrazioni di Amazon Web Services (AWS) impostando una connessione di rete completamente gestita tra l'organizzazione Salesforce e AWS Virtual Private Cloud (VPC). Quindi, instradare il traffico cross-cloud attraverso la connessione anziché su Internet pubblico per ridurre l'esposizione a minacce alla sicurezza esterne. Private Connect è disponibile in collaborazione con AWS tramite una funzione denominata AWS PrivateLink. Private Connect è bidirezionale: è possibile avviare sia il traffico in entrata che quello in uscita. Con le connessioni in entrata, è possibile inviare traffico a Salesforce utilizzando le API standard. Inoltre, con le connessioni in uscita, è possibile inviare traffico da Salesforce tramite funzioni come chiamate Apex, Servizi esterni e Oggetti esterni. Per ulteriori informazioni su VPC qui.

Bus eventi Salesforce con eventi piattaforma, acquisizione dati di modifica (CDC) e API Pub/Sub consente alle aziende di creare architetture di stile basate sugli eventi (EDA).

Un'AED separa i consumatori di messaggi evento (abbonati) dai produttori di messaggi evento (editori), consentendo una maggiore scalabilità e flessibilità. Schemi specifici sono descritti in questo documento come parte della struttura di schemi esistente che confronta e contrasta le alternative o le opzioni correlate. Tuttavia, ottenere una comprensione olistica dell'architettura basata sugli eventi e di come interagiscono gli schemi può aiutare a selezionare lo schema giusto per le proprie esigenze.

Khalid Mohammed è un illustre architetto leader nei servizi professionali di Salesforce. Da quando è entrato in Salesforce nel 2015, ha sfruttato la sua vasta esperienza in applicazioni e architettura Enterprise, affinata attraverso numerose trasformazioni dei clienti prima del suo mandato in Salesforce. Khalid è a capo del Delivery Architecture Board ed è anche riconosciuto come leader Certified Technical Architect.

Gulal Kumar è un architetto di ingegneria del software presso Salesforce, con particolare attenzione all'architettura dei dati e dell'integrazione. Con oltre 20 anni di esperienza in integrazione e API, programmi di modernizzazione, sicurezza e iniziative AIML, offre una vasta gamma di competenze. Gulal si è impegnata a promuovere iniziative di trasformazione aziendale, migliorare la sicurezza e la resilienza, promuovere l'eccellenza dell'architettura e guidare iniziative AIML in vari domini.

Sushant è un architetto tecnico di Salesforce, specializzato nell'architettura delle soluzioni e nella fornitura end-to-end delle piattaforme Salesforce. Con una profonda esperienza nella governance della piattaforma, nello sviluppo di applicazioni, nell'integrazione e in DevOps, ha guidato numerosi programmi di trasformazione dei clienti in tutti i settori. Sushant si impegna a promuovere l'eccellenza delle consegne e risultati architetturali scalabili.