Integrare con sistemi esterni external-systems
Questa pagina presenta i diversi guardrail forniti da Journey Optimizer durante l’integrazione di un sistema esterno, nonché le best practice: come ottimizzare la protezione del sistema esterno utilizzando l’API di limitazione di utilizzo, come configurare il timeout del percorso e come funzionano i nuovi tentativi.
Journey Optimizer consente di configurare connessioni a sistemi esterni tramite origini dati personalizzate e azioni personalizzate. Ciò ti consente, ad esempio, di arricchire i tuoi percorsi con dati provenienti da un sistema di prenotazione esterno o di inviare messaggi utilizzando un sistema di terze parti come Epsilon o Facebook.
Quando si integra un sistema esterno, è possibile riscontrare diversi problemi, il sistema può essere lento, può smettere di rispondere o potrebbe non essere in grado di gestire un volume di grandi dimensioni. Journey Optimizer offre diversi guardrail per proteggere il sistema dal sovraccarico.
Tutti i sistemi esterni sono diversi in termini di prestazioni. Devi adattare la configurazione ai tuoi casi d’uso.
Quando Journey Optimizer esegue una chiamata a un’API esterna, i guardrail tecnici vengono eseguiti come segue:
-
Vengono applicate le regole di limitazione o limitazione: se viene raggiunta la velocità massima, le chiamate rimanenti vengono scartate o messe in coda.
-
Timeout e nuovo tentativo: se la regola di limitazione o limite viene soddisfatta, Journey Optimizer tenta di eseguire la chiamata fino al raggiungimento della fine della durata del timeout.
cacheDuration di Journey Optimizer , soprattutto in caso di carichi di lavoro pesanti, per evitare incongruenze di scadenza ed errori 401.Limitazione e limitazione delle API capping
Informazioni sulle api di limitazione e limitazione
Durante la configurazione di un’origine dati o di un’azione, viene stabilita una connessione a un sistema per recuperare informazioni aggiuntive da utilizzare nei percorsi oppure per inviare messaggi o chiamate API.
Le API dei percorsi supportano fino a 5.000 eventi al secondo, ma alcuni sistemi o API esterni potrebbero non avere una velocità effettiva equivalente. Per evitare di sovraccaricare questi sistemi, puoi utilizzare le API Capping e Throttling per limitare il numero di eventi inviati al secondo.
Ogni volta che una chiamata API viene eseguita dai percorsi, passa attraverso il motore API. Se viene raggiunto il limite impostato nell’API, la chiamata viene rifiutata se utilizzi l’API di limitazione di utilizzo, oppure viene messa in coda per un massimo di 6 ore ed elaborata il prima possibile nell’ordine in cui è stata ricevuta se utilizzi l’API di limitazione.
Ad esempio, supponiamo che tu abbia definito una regola di limitazione o limitazione di 200 chiamate al secondo per il sistema esterno. Il sistema viene chiamato da un’azione personalizzata in 10 percorsi diversi. Se un percorso riceve 300 chiamate al secondo, utilizza i 200 slot disponibili ed elimina o mette in coda i 100 slot rimanenti. Poiché il limite massimo è stato superato, gli altri 9 percorsi non avranno più alcuno slot. Questa granularità aiuta a proteggere il sistema esterno da sovraccarichi e arresti anomali.
Per ulteriori informazioni su come utilizzare le API, consulta le sezioni seguenti:
Una descrizione dettagliata delle API è disponibile nella documentazione delle API di Adobe Journey Optimizer
Origini dati e capacità di azioni personalizzate capacity
Per le origini dati esterne, il numero massimo di chiamate al secondo è limitato a 15. Se questo limite viene superato, tutte le chiamate aggiuntive vengono scartate o messe in coda a seconda dell’API in uso. È possibile aumentare questo limite per le origini dati esterne private contattando Adobe per includere l’endpoint nell’elenco Consentiti, ma questa non è un’opzione per le origini dati esterne pubbliche. * Informazioni su come configurare le origini dati esterne.
Per le azioni personalizzate, è necessario valutare la capacità dell’API esterna. For example, if Journey Optimizer sends 1000 calls per second and your system can only support 200 calls per second, you need to define a capping or throttling configuration so that your system does not saturate. Informazioni su come configurare le azioni
Endpoints with slow response time response-time
When an endpoint has a response time greater than 0.75 seconds, its custom action calls are routed through a dedicated slow custom action service instead of the default service.
This slow custom action service applies a capping limit of 150,000 calls every 30 seconds. The limit is enforced using a sliding window, which can begin at any millisecond within that 30-second period. Once the window is full, additional calls are rejected with capping errors. The system does not wait for the next fixed interval but begins capping immediately after the 30-second threshold is reached.
Because slow endpoints can cause delays across all queued actions in the pipeline, it is recommended not to configure custom actions with endpoints that have slow response times. Routing such actions to the slow service helps protect overall system performance and prevents added latency for other custom actions.
Timeout and retries timeout
If the capping or throttling rule is fulfilled, then the timeout rule is applied.
In each journey, you can define a timeout duration. This allows you to set a maximum duration when calling an external system. Timeout duration is configured in the properties of a journey. Consulta questa pagina.
This timeout is global to all external calls (external API calls in custom actions and custom data sources). By default, it is set to 30 seconds.
During the defined timeout duration, Journey Optimizer tries to call the external system. After the first call, a maximum of three retries can be performed until the end of timeout duration is reached. The number of retries cannot be changed.
Each retry uses one slot. If you have a capping of 100 calls per second and each of your calls require two retries, the rate drops to 30 calls per second (each call uses 3 slots: the first call and two retries).
The timeout duration value depends on the use case. If you want to send your message quickly, for example when the client enters the store, then you do not want to set up a long timeout. Also, the longer the timeout is, the more items will be placed in queue. Questo può avere un notevole impatto sulle prestazioni. Se Journey Optimizer esegue 1000 chiamate al secondo, la conservazione di 5 o 15 secondi di dati può sopraffare rapidamente il sistema.
Prendiamo un esempio per un timeout di 5 secondi.
-
La prima chiamata dura meno di 5 secondi: la chiamata ha esito positivo e non viene eseguito un nuovo tentativo.
-
La prima chiamata dura più di 5 secondi: la chiamata viene annullata e non è possibile riprovare. Viene conteggiato come errore di timeout nel reporting.
-
La prima chiamata non riesce dopo 2 secondi (il sistema esterno restituisce un errore): rimangono 3 secondi per i nuovi tentativi, se sono disponibili slot di limitazione.
- Se uno dei tre tentativi ha esito positivo prima della fine dei 5 secondi, la chiamata viene eseguita e non si verifica alcun errore.
- Se durante i nuovi tentativi viene raggiunta la fine della durata del timeout, la chiamata viene annullata e conteggiata come un errore di timeout nel reporting.
Domande frequenti faq
Di seguito sono riportate le domande frequenti sull’integrazione di Journey Optimizer con sistemi esterni.
Hai bisogno di altri dettagli? Utilizza le opzioni di feedback nella parte inferiore di questa pagina per porre la tua domanda o connetterti alla community Adobe Journey Optimizer.
Il proxy in uscita fornisce un indirizzo IP statico per le chiamate in uscita da azioni personalizzate di Journey Optimizer ai sistemi esterni. Utilizzalo quando gli endpoint di terze parti richiedono l’inserire nell’elenco Consentiti dell’IP.
Importante: Il proxy di uscita NON controlla la velocità effettiva, i limiti di velocità o il numero di connessioni simultanee. Per gestire il volume di chiamate e i limiti di connessione, utilizzare l’API di limitazione o l’API di limitazione.
Utilizza il proxy di uscita per:
- Inserire nell’elenco Consentiti un IP statico sul firewall o sull’endpoint di terze parti
Usa API di limitazione/limitazione per:
- Limitazione del numero di chiamate API al secondo
- Controllo delle connessioni simultanee all’endpoint
- Protezione del sistema esterno da sovraccarichi
Contatta Adobe per abilitare il proxy di uscita per la tua organizzazione, se hai bisogno di un IP statico a scopo di inserire nell’elenco Consentiti di un’organizzazione. Per favore, contatta l’amministratore di sistema.
Con il proxy IP abilitato e una configurazione di limitazione definita sull’endpoint di destinazione, il numero di connessioni si basa sulla frequenza (stime, numeri non garantiti):
- tra 200 e 2000 c/s: 50 collegamenti
- tra 2000 e 3000: 75 collegamenti
- tra 3000 e 4000: 100 collegamenti
- tra 4000 e 5000: 125 collegamenti
Se non è definita alcuna configurazione di limitazione su un endpoint, il motore di Journey Optimizer è progettato per aumentare la scalabilità e può raggiungere un numero elevato di connessioni (più di 2.000). Per ottenere un numero limitato di connessioni, i clienti devono utilizzare una configurazione di limitazione.