Utilizzo degli strumenti e degli schemi giusti per le architetture basate sugli eventi

Le architetture basate sugli eventi supportano la produzione e il consumo efficienti degli eventi, che comunicano le modifiche dello stato del sistema o dell'applicazione. Queste architetture consentono connessioni flessibili tra i sistemi e supportano processi e aggiornamenti quasi in tempo reale che funzionano tra i sistemi. Benché i vantaggi delle architetture basate sugli eventi siano facili da vedere, i dettagli dell'implementazione non sono sempre altrettanto chiari. Quali funzionalità è necessario considerare negli schemi architettonici basati sugli eventi? Quali problemi specifici risolvono questi schemi? Quali considerazioni speciali valgono per le soluzioni e quali sono gli schemi ottimali per affrontarle?

Questa guida presenta gli schemi utilizzati per creare architetture basate sugli eventi ottimali quando si utilizzano le tecnologie Salesforce. Vengono inoltre discussi gli strumenti per gli eventi disponibili in Salesforce e vengono forniti consigli sugli strumenti per una selezione di casi d'uso. Per informazioni sulle integrazioni a livello di dati che coinvolgono Salesforce, vedere la nostra Guida alle decisioni.

• Utilizzare architetture basate sugli eventi per i processi che non richiedono risposte sincrone alle richieste. Gli schemi descritti in questa guida sono progettati per la coerenza, la scalabilità e il riutilizzo dei dati, che consentono di ridurre al minimo l'indebitamento tecnico man mano che il panorama applicativo dell'organizzazione si evolve. (Per ulteriori informazioni, vedere Well-Architected - Throughput).

• Se MuleSoft o un'altra soluzione Enterprise Service Bus (ESB) fa parte del panorama esistente, utilizzarla dove possibile. Queste soluzioni sono progettate appositamente per supportare schemi di architettura basati sugli eventi e dispongono di potenti funzionalità che consentono di riutilizzare le integrazioni in tutta l'azienda.

• Utilizzare l'API Pub/Sub per qualsiasi schema di pubblicazione/abbonamento futuro anziché creare i propri handler eventi utilizzando altre API, inclusa Streaming API. Ora che l'API Pub/Sub è disponibile in generale, utilizzarla per eventuali nuovi schemi di pubblicazione/abbonamento. Pianificare la migrazione delle comunicazioni degli eventi esistenti utilizzando altre API piattaforma, ad esempio Streaming API o servizi Apex personalizzati, all'API Pub/Sub quando possibile.

• Eventi piattaforma e Acquisizione dati di modifica (CDC) sono i meccanismi preferiti per pubblicare le modifiche di record e campi che devono essere consumate da altri sistemi. Non è consigliabile utilizzare PushTopic ed eventi generici per le nuove implementazioni. Salesforce continuerà a supportare PushTopic ed eventi generici nell'ambito delle funzionalità correnti, ma non prevede di effettuare ulteriori investimenti in questa tecnologia.

Salesforce Platform è una piattaforma completa basata sull'intelligenza artificiale che unifica dipendenti, agenti autonomi dell'intelligenza artificiale, dati aziendali e applicazioni in un unico sistema affidabile per migliorare la produttività e l'esperienza dei clienti. Consente la creazione di un'"azienda autentica" collegando le app Customer 360, Data Cloud e Slack per l'automazione end-to-end.

MuleSoft è la piattaforma di integrazione leader di Salesforce che consente alle organizzazioni di connettere applicazioni, dati e dispositivi in ambienti locali e cloud. MuleSoft è una piattaforma che offre all'IT le piattaforme per sbloccare i dati tra i sistemi, sviluppare framework di integrazione e automazione scalabili e creare esperienze connesse e differenziate in modo rapido.

Le architetture basate sugli eventi (EDA) sono consigliate per gli scenari che richiedono notifiche quasi in tempo reale, la distribuzione del carico di elaborazione per messaggi a volume elevato o complessi e l'integrazione di sistemi come IoT e dispositivi mobili che richiedono la resilienza della connettività tramite l'area di attesa. Tuttavia, le AED non dovrebbero essere implementate per i processi che richiedono risposte umane immediate e sincrone, poiché sono progettate per l'esecuzione asincrona. Né sono adatti se i dati di origine cambiano così raramente che uno schema più semplice come l'elaborazione batch sarebbe sufficiente.

Di seguito sono riportati alcuni scenari comuni che spesso sono adatti a un'architettura basata sugli eventi:

La maggior parte delle organizzazioni di grandi dimensioni dispone di ambienti IT complessi con una combinazione di sistemi con funzionalità diverse. È possibile, o forse probabile, che l'organizzazione disponga di sistemi legacy che non supportano le integrazioni basate sugli eventi. Si potrebbero anche avere casi d'uso in cui le integrazioni basate sugli eventi non hanno senso, anche se i sistemi le supporteranno (ad esempio, i trasferimenti di file SFTP da terze parti). Se si fa un passo indietro e si esamina il panorama IT dell'organizzazione nel suo complesso, è probabile che, proprio come con altre soluzioni architettoniche, si utilizzi una combinazione di schemi per supportare scenari diversi. Quando si decide di utilizzare l'approccio alle integrazioni basato sugli eventi come approccio preferito, considerarlo come un altro strumento nella propria casella degli strumenti. Può e deve essere utilizzato negli scenari giusti, ma non è un approccio da imporre a tutti i sistemi. Sviluppare una strategia di integrazione completa aiuterà a determinare quando gli schemi descritti in questa guida possono essere appropriati o meno.

Molti scenari richiedono architetture basate sugli eventi e, in alcuni scenari, le architetture basate sugli eventi funzionano anche se non sono particolarmente adatte. Tuttavia, in alcuni scenari, le architetture basate sugli eventi semplicemente non dovrebbero essere utilizzate. Di seguito sono riportate alcune domande sui punti decisionali che consentono di identificare questi scenari:

Esistono diversi schemi di architettura basati sugli eventi. Alcuni sono schemi di uso generale che possono essere applicati in casi d'uso che non hanno requisiti speciali oltre a essere basati sugli eventi; ad esempio, vedere Ben progettato - Interoperabilità. Altri schemi sono applicabili ai casi d'uso specifici descritti qui, ad esempio integrazioni che comportano volumi elevati di dati o scenari che richiedono una conservazione dei messaggi più lunga.

La tabella seguente confronta gli attributi degli schemi descritti in questo documento. Utilizzarlo come riferimento rapido quando è necessario identificare potenziali schemi per un determinato caso d'uso.

Salesforce offre diversi strumenti per gestire i casi d'uso basati sugli eventi. Questa tabella contiene una panoramica generale degli strumenti disponibili.

Quando un record critico cambia stato all'interno di un'applicazione centrale, ad esempio lo stato di un ordine passa da "Elaborazione" a "Spedito", è probabile che più altri sistemi richiedano una notifica quasi in tempo reale per eseguire le rispettive operazioni. Quando il volume di questi cambiamenti è elevato e i messaggi sono complessi, si pone una specifica esigenza aziendale, rendendo le integrazioni tradizionali da punto a punto onerose e difficili da gestire. La creazione di connessioni fragili e personalizzate per ogni singola applicazione dipendente comporta un indebitamento tecnico e impedisce all'organizzazione di scalare rapidamente. È necessario un approccio di integrazione efficace per gestire queste frequenti sincronizzazioni dei dati senza associare il sistema di origine direttamente a ogni sistema che utilizza.

Lo schema riportato sotto rappresenta un tipico schema di pubblicazione/abbonamento in cui più publisher e abbonati condividono i dati tramite un bus degli eventi. Questo schema di base costituisce la base per gli schemi più specifici che si possono trovare nel resto di questa guida. Alcune caratteristiche chiave di questo schema sono:

• Non esiste una connessione diretta tra publisher e abbonati. I publisher inviano semplicemente messaggi a un bus degli eventi, che li trasmette a qualsiasi altro sistema che desideri ascoltarli.

• Lo stesso sistema può essere sia un publisher che un abbonato.

• I sistemi possono pubblicare o abbonarsi a più tipi di eventi.

• Come per tutti gli schemi di questa guida, lo schema di pubblicazione/abbonamento rientra in una categoria di schema di integrazione generale nota come invocazione di procedure remote (RPI) o semplicemente "fire and forget".

Quando un'organizzazione deve inviare aggiornamenti istantanei a un numero elevato di applicazioni client, ad esempio notifiche push o messaggi SMS ai dispositivi mobili, il processo tradizionale di creazione di trasmissioni univoche per ogni singolo destinatario diventa rapidamente un collo di bottiglia nella scalabilità. In questo caso, l'esigenza principale del business è la distribuzione rapida e ad alte prestazioni di una singola informazione, ad esempio un avviso account o un avviso di modifica critica del servizio, a numerose applicazioni endpoint contemporaneamente. Un approccio semplificato per soddisfare questo requisito prevede l'instradamento di tutti i messaggi attraverso un'unica area di attesa, che funge da punto centrale delle informazioni sull'evento per tutti i sistemi che consumano. Questo approccio migliora le prestazioni eliminando la necessità di gestire molte copie separate dei messaggi.

Con lo schema di fanout, i messaggi vengono consegnati a una o più destinazioni (ovvero client o abbonati in ascolto) tramite un'unica area di attesa messaggi. Gli abbonati recuperano lo stesso messaggio dall'area di attesa anziché la propria copia univoca. Tenere presente che, sebbene ciò migliori le prestazioni, può anche rendere più difficile verificare se un determinato abbonato ha ricevuto o meno il messaggio.

Alcuni scenari di eventi sono caratterizzati da un notevole afflusso di volume di messaggi che minaccia di sovraccaricare la capacità dei processi di sincronizzazione e trasformazione o da una logica complessa a più fasi necessaria per elaborare e trasformare i dati degli eventi.

Alcuni esempi sono:

• Picchi di volume stagionali: Ci possono essere picchi di volume che i rivenditori online sperimentano quando una selezione dei loro prodotti è "di stagione". Quando un numero elevato di clienti effettua acquisti contemporaneamente, il numero di eventi generati può superare temporaneamente la capacità dei processi di sincronizzazione e trasformazione. Per ulteriori informazioni, vedere Ben progettato - Gestione dati.

• Gestione di casi o richieste: Le aziende di servizi possono riscontrare un aumento del numero di casi o richieste durante le interruzioni.

• Trasformazioni dati complesse: Le organizzazioni che richiedono una logica complessa per trasformare i messaggi spesso temono che gli eventi vengano generati più velocemente di quanto possano essere trasformati.

Questo schema affronta la sfida di generare i messaggi più velocemente di quanto possano essere trasformati. Garantisce che volumi elevati di messaggi e manipolazioni dei dati richieste possano essere gestiti in modo affidabile, incorporando una piattaforma di messaggi in streaming e segmentando la logica di gestione dei messaggi in componenti dedicati.

Lo schema Messaggi passati funziona segmentando la logica di gestione dei messaggi in più componenti:

• Un componente gestisce l'instradamento dei messaggi, determinando le trasformazioni richieste e la destinazione finale.

• Un insieme separato di componenti gestisce diversi livelli di trasformazione dei messaggi (ad esempio, mappature di campi, relazioni tra oggetti e così via).

• L'ultimo componente scrive il messaggio finale modificato.

Alcuni produttori generano uno stream continuo di eventi. Un esempio comune è lo streaming multimediale, che prevede interazioni utente che si verificano naturalmente come eventi discreti. Più sistemi devono reagire contemporaneamente allo stesso comportamento dell'utente senza bloccare l'esperienza di streaming core.

Considerare gli eventi per una piattaforma di streaming musicale. Questi possono includere:

• Monitoraggio degli eventi avviati/messi in pausa/saltati

• Eventi della sessione di ascolto con indicazioni orarie

• Eventi di creazione/modifica della playlist

• Eventi di condivisione sociale

• Download per l'ascolto offline

Nello schema Streaming, gli abbonati accedono a ogni stream di eventi ed elaborano gli eventi nell'ordine esatto in cui vengono ricevuti. Copie univoche di ogni stream di messaggi vengono inviate a ogni abbonato, consentendo di fornire contenuti specifici dell'abbonato e di identificare gli abbonati che ricevono quali stream.

Perché uno stream abbia senso, tutti gli eventi e i messaggi associati devono essere nell'ordine corretto. Se i dati provengono da stream di sistemi diversi, sarà necessario incorporare ulteriore logica di ordinamento come parte del processo di progettazione.

I casi d'uso di aree di attesa sono onnipresenti. Gli esempi includono:

• Connessioni Internet di bassa qualità: Le organizzazioni di Field Service o altre organizzazioni in cui i team con dispositivi mobili devono lavorare in aree con accesso a Internet di bassa qualità o intermittente traggono vantaggio dall'inserimento in area di attesa poiché le applicazioni su questi dispositivi possono connettersi alle aree di attesa e recuperare tutti i messaggi pertinenti quando viene ripristinata la connettività.

• Buffering dei messaggi: Quando il volume dei messaggi occasionalmente supera la capacità di elaborazione di un abbonato e la latenza aumentata non crea ulteriori problemi, le aree di attesa possono fungere da buffer per memorizzare i messaggi in eccesso e impedire la perdita di dati.

• Gestione dei trasporti: Le organizzazioni logistiche che devono monitorare i propri parchi veicoli possono utilizzare questo schema per visualizzare i percorsi che ogni veicolo sta seguendo quasi in tempo reale e assicurarsi che i conducenti siano il più efficienti possibile.

• Dispositivi IoT: I produttori utilizzano spesso sistemi che generano flussi rapidi di dati e questi flussi possono avere effetti a valle su sistemi aggiuntivi. Questo schema può essere utilizzato per identificare sequenze di eventi che richiedono l'intervento umano prima che si verifichino guasti catastrofici che interessano più sistemi.

Nello schema Area di attesa, i produttori inviano messaggi alle aree di attesa, che li conservano fino a quando gli abbonati non li recuperano. La maggior parte delle aree di attesa dei messaggi segue l'ordine first-in, first-out (FIFO) ed elimina ogni messaggio dopo che è stato recuperato. Ogni abbonato ha un'area di attesa univoca, che richiede ulteriori fasi di impostazione ma consente di garantire la consegna e identificare gli abbonati che hanno ricevuto quali messaggi.

A causa della natura asincrona dello schema di inserimento in area di attesa, può verificarsi un lungo ritardo tra l'aggiunta di un messaggio a un'area di attesa e il recupero del messaggio. Le aree di attesa richiedono memoria o spazio di memoria per contenere i messaggi, quindi non possono crescere all'infinito, il che significa che un abbonato offline a tempo indeterminato può causare un errore se nell'area di attesa si accumula un numero sufficiente di messaggi. Il buffering dei messaggi può avere lo stesso effetto se i tempi di elaborazione dell'abbonato diventano troppo lunghi, causando volumi elevati di messaggi nelle aree di attesa. Per ridurre questi rischi, eseguire un'analisi approfondita dei requisiti di memoria per tutte le aree di attesa dei messaggi e, se necessario, progettare processi che eliminino e disabilitino le aree di attesa se i messaggi non vengono recuperati entro un determinato periodo di tempo o raggiungono un volume predeterminato.

Anche se si è pienamente convinti che un'architettura basata sugli eventi sia adatta alla propria organizzazione, è possibile iniziare con un panorama che include già un gran numero di integrazioni da punto a punto. Ottenere finanziamenti per un progetto che sostituisca tutte le integrazioni contemporaneamente può essere difficile e potrebbe anche non essere possibile utilizzare un'architettura basata sugli eventi direttamente con alcuni sistemi legacy. In questi scenari, è possibile adottare un approccio incrementale alla migrazione a un'architettura più vagamente accoppiata convertendo prima le applicazioni più critiche per l'azienda, quindi convertendo altri sistemi man mano che vengono aggiornati o sostituiti nei progetti futuri. Questo approccio semplifica l'aggiunta di nuove applicazioni al bus degli eventi e consente al panorama IT complessivo di rimanere scalabile e resiliente man mano che i sistemi continuano ad essere aggiunti nel tempo.

Come architetti, sappiamo che ogni architettura ha dei compromessi. Un'architettura basata sugli eventi non fa eccezione. Mentre un panorama pieno di sistemi vagamente accoppiati è altamente scalabile e resistente, ci sono anche alcuni compromessi da considerare:

• Strategia di integrazione generale: Indipendentemente dagli strumenti e dagli schemi che si decide di utilizzare, è importante iniziare creando una strategia per la condivisione dei dati tra i vari sistemi nel panorama dell'organizzazione. Questa strategia deve includere gli obiettivi dell'organizzazione per i propri dati, il modo in cui i dati possono essere condivisi e gli schemi utilizzati, nonché le fonti di dati, i target, le strutture e i requisiti di proprietà e accesso.

• Supporto per i sistemi legacy: L'organizzazione potrebbe avere sistemi legacy che semplicemente non supportano schemi di architettura basati sugli eventi. Benché sia possibile creare soluzioni alternative (ad esempio, con un processo che funge da pass-through abbonandosi agli eventi e quindi inviando l'output al sistema di destinazione tramite un mezzo diverso di trasferimento dei dati), è possibile considerare altri metodi di integrazione in questo caso.

• Modifiche strutturali ai messaggi: Una volta definita e concordata la struttura iniziale dei messaggi tra publisher e abbonati, può essere difficile modificarla, soprattutto se gli abbonati sono esterni. Esistono diversi modi per risolvere questo problema. È possibile utilizzare gli endpoint con versione, ma assicurarsi di definire e comunicare un ciclo di vita chiaro per ogni versione in modo che gli sviluppatori non debbano gestire troppe versioni contemporaneamente. Se Apache Kafka su Heroku fa parte del paesaggio, è anche possibile considerare un registro di schema o uno strumento simile, ma assicurarsi che anche gli altri sistemi nel paesaggio supportino (e utilizzino).

• Mancanza di visibilità tra publisher e abbonati: Nella maggior parte degli schemi di architettura basati sugli eventi, i publisher non sono consapevoli dello stato dei propri abbonati. Pertanto, se un publisher invia un messaggio critico mentre tutti gli abbonati sono offline, il messaggio potrebbe non essere mai consegnato. È possibile risolvere questo problema utilizzando la funzionalità replay o aggiungendo abbonati ridondanti eseguiti su server separati per tutti i messaggi critici.

• Colli di bottiglia delle prestazioni: Man mano che un'architettura basata sugli eventi aumenta, il bus degli eventi può diventare un collo di bottiglia per la consegna dei messaggi se viene sovraccaricato da troppi publisher che tentano di inviare messaggi a troppi abbonati contemporaneamente. È possibile risolvere questo problema aumentando la memoria e le risorse di elaborazione allocate al bus degli eventi o utilizzando più bus degli eventi per elaborare diversi tipi di messaggi in parallelo.

Prima di implementare un'architettura basata sugli eventi, valutare se è davvero necessario utilizzarne una. La sezione precedente descrive scenari aziendali comuni adatti a ogni schema di architettura basato sugli eventi. Ulteriori informazioni sono disponibili in Ben progettato - Interoperabilità. Esaminare le sfide da considerare durante l'implementazione delle architetture basate sugli eventi per determinare se gli schemi previsti sono più adatti ai propri casi d'uso specifici.

Tenere presente che, sebbene la maggior parte degli scenari descritti in questa guida preveda integrazioni, le architetture basate sugli eventi possono essere utilizzate anche per inviare messaggi all'interno di una singola organizzazione Salesforce, ad esempio tramite l'uso di eventi piattaforma. Assicurarsi di tenere presenti gli eventuali limiti di allocazione applicabili quando si progettano processi che utilizzano gli eventi piattaforma come sistema di messaggistica interno.

Spesso, gli schemi anti-pattern relativi alle architetture basate sugli eventi derivano dall'utilizzo degli eventi come soluzione per le comunicazioni interne all'interno di un'organizzazione Salesforce. Gli anti-schemi comuni includono:

• Pubblicazione di eventi da trigger Apex associati allo stesso oggetto evento: Questo risulterà in un loop trigger infinito.

• La pubblicazione di eventi da Apex prima che una transazione DML completi: Se una transazione non riesce e viene ritirata, tutti gli eventi pubblicati con il comportamento di pubblicazione Pubblica immediatamente non verranno inclusi nel comportamento di ritiro.

• Pubblicazione di eventi in Flusso per orchestrare l'automazione successiva: Il modo migliore per coordinare la logica in più automazioni è utilizzare i sottoflussi o Flow Orchestrator.

• Creazione di dipendenze di runtime: Non pubblicare eventi per facilitare la comunicazione tra i pacchetti senza eseguire i passaggi appropriati per eliminare le dipendenze in fase di esecuzione.

• Carichi utili non necessari: Quando si effettuano richieste, è consigliabile inviare e ricevere la minor quantità di dati possibile nel payload. Ogni azione di un utente potrebbe generare più richieste ed è importante che vengano elaborate in modo efficiente. L'invio di più dati del necessario può contribuire a rallentare il trasporto e ad aumentare il tempo di elaborazione.

• Gestione non selettiva degli eventi applicazione: Quando sono presenti più componenti in ascolto per un evento applicazione, gli sviluppatori devono assicurarsi che l'handler evento venga eseguito solo quando è effettivamente desiderato e utile. Ad esempio, in Lightning Console, i componenti contenuti nelle schede che non sono attivati possono essere ancora in ascolto anche se non sono visibili. Uno sviluppatore può utilizzare varie tecniche, ad esempio utilizzare un elemento utilità in background come unico ascoltatore o chiamare getEnclosingTabId() per determinare se questa istanza del componente è racchiusa nella scheda attivata per garantire che ogni evento venga gestito solo quando previsto.

• Il comportamento di pubblicazione degli eventi piattaforma non è corretto: Gli eventi piattaforma hanno due comportamenti di pubblicazione: Pubblica immediatamente e Pubblica dopo l'impegno. Può essere utile utilizzare gli eventi piattaforma in tempo reale per casi d'uso come Registrazione, in cui si desidera pubblicare l'evento di registrazione indipendentemente dal fatto che la transazione abbia esito positivo o meno. Tuttavia, utilizzare con molta attenzione Pubblica immediatamente con gli eventi piattaforma in tempo reale. Gli eventi possono essere consumati dagli abbonati all'interno della stessa transazione e causare blocchi delle righe o altre condizioni di gara.

Quando si implementa un'architettura basata sugli eventi, una delle chiavi del successo è definire gli standard per la progettazione degli eventi stessi. Le specifiche variano a seconda dei casi d'uso dell'organizzazione, ma di seguito sono riportate alcune linee guida generali:

• Determinare la struttura ottimale per i payload degli eventi. Mentre le dimensioni più piccole dei messaggi riducono i tempi di elaborazione, bombardare gli abbonati con volumi elevati di messaggi può causare colli di bottiglia nelle prestazioni. Può essere necessario ripetere le dimensioni e le strutture del payload per trovare il giusto equilibrio. MuleSoft e strumenti ESB simili offrono la possibilità di progettare payload personalizzati nei messaggi associati agli eventi, che possono aiutare a visualizzare le strutture di dati per migliorare le prestazioni sul lato abbonato. (Per ulteriori informazioni, vedere Ben progettato - Gestione API).

• Pensare ai processi end-to-end. Assicurarsi di non creare scenari di "loop senza fine", che possono essere difficili da individuare una volta implementate le integrazioni. Ad esempio, due sistemi pubblicano gli eventi quando i record vengono aggiornati, ascoltando anche gli eventi degli altri, che attivano ulteriori eventi pubblicati quando vengono elaborati.

  È possibile correggere questo tipo di anti-schema aggiungendo una logica a entrambi i sistemi che garantisca che le modifiche apportate a seguito di un evento consumato non determinino la pubblicazione di un nuovo evento. Assicurarsi inoltre di documentare tutti gli eventi, i trigger associati e i sistemi a valle che potrebbero essere interessati. Utilizzare questa documentazione come riferimento durante le sessioni di progettazione per individuare i loop infiniti e gli scenari simili il prima possibile. (Per ulteriori informazioni, vedere Progettazione di processi ben progettata).

• Utilizzare le convenzioni di denominazione comuni nei vari sistemi. Convenzioni di denominazione coerenti sono una procedura ottimale per tutto lo sviluppo software, incluse le architetture basate sugli eventi. Documentare una serie di standard per i nomi degli eventi, le strutture, gli oggetti associati e i processi di gestione degli errori per garantire la coerenza tra i sistemi. (Per ulteriori informazioni, vedere Well-Architected - Design Standards).