In questa pagina: invia chiamate API di test reali per convalidare le configurazioni delle azioni personalizzate in modo da poter rilevare gli errori prima di utilizzarle nei percorsi live.
Puoi verificare le azioni personalizzate inviando chiamate API dalla sezione amministrazione dell’interfaccia utente di Journey Optimizer. Questa funzionalità consente di risolvere i problemi relativi alle azioni personalizzate prima o dopo il loro utilizzo in un percorso.
In qualità di amministratore, utilizza la funzionalità Invia richiesta di test per convalidare le configurazioni delle azioni personalizzate effettuando chiamate API reali direttamente da Adobe Journey Optimizer. Questa funzione assicura che la struttura della richiesta, le intestazioni, l’autenticazione e il payload siano formattati correttamente prima di essere utilizzati in un percorso.
Utilizza questa funzionalità per semplificare il processo di test e convalida, garantendo il corretto funzionamento delle azioni personalizzate nei percorsi live.
Prerequisiti troubleshoot-custom-action-prereq
Per utilizzare la funzionalità Invia richiesta di test, è necessario preconfigurare un’azione personalizzata con un URL, intestazioni e impostazioni di autenticazione.
Affinché gli amministratori possano utilizzare questa funzionalità, sono necessarie le seguenti autorizzazioni:
- Gli utenti devono disporre dell’autorizzazione Manage journeys events, data sources and actions.
- Questa autorizzazione è inclusa nel ruolo Amministratori di Percorso.
- La sola autorizzazione View journeys events non è sufficiente.
Ulteriori informazioni sulle autorizzazioni di percorso in questa sezione.
Come utilizzare la funzione Send test request troubleshoot-custom-action-use
Per testare un’azione personalizzata, effettua le seguenti operazioni:
-
Passa alla schermata di configurazione Azioni e seleziona un’azione personalizzata.
-
Fai clic sul pulsante Invia richiesta test nella parte inferiore della schermata di configurazione dell’azione.
-
Nella finestra pop-up, che consente di specificare i parametri della richiesta:
-
Se il metodo di azione personalizzato è GET, non è richiesto alcun payload.
-
Se il metodo di azione personalizzato è POST, è necessario fornire un payload JSON.
note NOTE Adobe Journey Optimizer genererà un errore se la struttura di questo JSON non è corretta, ma non lo farà in caso di mancata corrispondenza con un tipo di dati. Ad esempio, non si verifica alcun errore se si utilizza un parametro intero per quella che deve essere una stringa. -
Se è definita l’autenticazione, verrà richiesto di immettere i dettagli di autenticazione.
-
-
Fai clic su Invia per eseguire la richiesta.
-
La risposta dall’API, incluse le intestazioni e i codici di stato, verrà visualizzata nell’interfaccia.
Gestione dell’autenticazione troubleshoot-custom-action-auth
Quando un’azione personalizzata include l’autenticazione, Adobe Journey Optimizer richiede all’utente di immettere i dettagli di autenticazione per ogni richiesta di test:
- Autenticazione di base: L’utente deve fornire la password.
- Autenticazione chiave API: L’utente deve immettere la chiave API value.
- Autenticazione personalizzata: L’utente deve fornire i parametri di autenticazione nella richiesta bodyParam. In questo caso vengono aggiunte due sezioni: Richiesta di autenticazione e Risposta di autenticazione.
Vantaggi chiave troubleshoot-custom-action-benefits
In qualità di amministratore di Journey Optimizer, puoi anche utilizzare strumenti esterni (ad esempio, Postman) per testare le azioni personalizzate. Di seguito sono elencati i principali vantaggi della funzionalità di risoluzione dei problemi interna al prodotto rispetto a un test esterno:
-
La richiesta di test viene eseguita da AJO Percorsi, ovvero:
- Viene utilizzata la struttura esatta della richiesta (comprese le intestazioni specifiche di Adobe Journey Optimizer).
- L’IP sorgente e le intestazioni corrispondono a quelle utilizzate nei percorsi live.
-
La funzionalità Invia richiesta di test può essere utilizzata per la risoluzione dei problemi di percorsi live, in quanto l’azione personalizzata è già distribuita.
-
Questa funzionalità di test interna al prodotto elimina la necessità di copiare manualmente i dettagli di configurazione tra gli strumenti, riducendo il rischio di errori.
Risoluzione dei problemi troubleshoot-custom-action-check
Se la richiesta non riesce, puoi controllare:
- Credenziali di autenticazione immesse nel test.
- Il metodo di richiesta (GET vs. POST) e il payload corrispondente.
- L’endpoint API e le intestazioni definiti nell’azione personalizzata.
- Utilizza i dati di risposta per identificare potenziali configurazioni errate.
Gestione degli eventi di eliminazione e dei timeout di inattività handling-discard-events-and-idle-timeouts
Quando un’azione personalizzata in un percorso attiva un evento che deve iniziare un secondo percorso, assicurati che il secondo percorso sia in uno stato valido e che l’evento sia riconosciuto. Se l’evento non soddisfa le condizioni di ingresso del secondo percorso, può essere scartato e comparire nei registri con codici come notSuitableInitialEvent. I timeout di inattività possono verificarsi se il secondo percorso non è pronto e causare l’eliminazione degli eventi nei registri.
Cause comuni:
-
Qualificazione evento non soddisfatta - Il secondo percorso utilizza un evento basato su regole con una condizione di qualifica (ad esempio, un campo obbligatorio non deve essere vuoto, ad esempio
isNotEmptyin un campo specifico). Se il payload dell’evento non soddisfa tale condizione (ad esempio, se il campo è vuoto o mancante), l’evento viene ricevuto ma scartato e il secondo percorso non viene attivato. Questo è il comportamento previsto; la documentazione e i registri confermano che se la condizione di qualifica non viene soddisfatta, l’evento verrà scartato e il percorso non verrà attivato per quel profilo. Verifica che il payload inviato dall’azione personalizzata includa tutti i campi e i valori richiesti dalla configurazione dell’evento del secondo percorso. Scopri come configurare gli eventi basati su regole e risolvere i problemi di ricezione degli eventi nell’esecuzione del percorso. -
Secondo percorso non pronto - Possono verificarsi timeout di inattività se il secondo percorso non è ancora attivo (ad esempio, non in modalità di test o non è attivo) o se esiste un intervallo di tempo tra l’attivazione dell’azione personalizzata e il secondo percorso pronto per la ricezione. Assicurati che il percorso target sia pubblicato o in modalità di test prima di attivare l’azione personalizzata.
-
Diagnostica degli eventi di eliminazione - Se nei registri vengono visualizzati eventi di eliminazione, controllare i registri di percorso e le tracce di Splunk per verificare se l’evento è stato ricevuto ma scartato a causa della qualifica (il payload non soddisfa la regola) o della tempistica. Verificare che la data di inizio e la configurazione del secondo percorso siano corrette e che il percorso si trovi all’interno della relativa finestra di date attiva.
Per evitare di ignorare gli eventi durante il concatenamento dei percorsi tramite azioni personalizzate, convalida il payload dell’evento in base alla regola dell’evento del secondo percorso e conferma che il percorso di destinazione sia attivo o in test e all’interno della relativa finestra di data attiva.
Risorse aggiuntive
Consulta le sezioni seguenti per ulteriori informazioni sulla configurazione e sull’utilizzo delle azioni personalizzate:
- Introduzione alle azioni personalizzate: scopri cos’è un’azione personalizzata e come ti aiuta a connetterti ai sistemi di terze parti
- Configura le azioni personalizzate - Scopri come creare e configurare un’azione personalizzata
- Usa azioni personalizzate - Scopri come utilizzare le azioni personalizzate nei tuoi percorsi
- Trasmettere le raccolte nei parametri delle azioni personalizzate - Scopri come trasmettere una raccolta nei parametri delle azioni personalizzate compilata dinamicamente in fase di esecuzione
This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.
For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.
- TL;DR: This page explains how to use the Send test request capability to validate custom action configurations by making real API calls directly from Journey Optimizer, before or after using them in live journeys.
Intents:
- Send a real test API call to validate a custom action configuration
- Provide the correct payload depending on whether the method is GET or POST
- Enter authentication details required for each test request
- Understand the benefits of in-product testing compared to external tools
- Diagnose discard events and idle-timeouts when chaining journeys via custom actions
Glossary:
- Send test request: The capability administrators use to validate a custom action configuration by making real API calls directly from Adobe Journey Optimizer, checking request structure, headers, authentication, and payload (product-specific)
- Discard event: An event that is received but discarded, appearing in logs with codes such as notSuitableInitialEvent, when it does not meet the second journey’s entry conditions (product-specific)
- Idle timeout: A timeout that may occur if the second journey is not ready, leading to discard events in the logs (product-specific)
- IP (egress) proxy: A proxy that, when enabled for your organization, is bypassed by the Send test request call (product-specific)
Guardrails:
- To use the Send test request capability, a custom action must be pre-configured with a URL, headers, and authentication settings.
- Users must have the Manage journeys events, data sources and actions permission, which is included in the Journey Administrators role; the View journeys events permission alone is not sufficient.
- If the custom action method is GET, no payload is required; if the method is POST, you must provide a JSON payload.
- Adobe Journey Optimizer raises an error if the structure of the JSON is incorrect, but not if there is a mismatch with a data type; for instance, no error is raised if an integer parameter is used for what should be a string.
- If your organization has the IP (egress) proxy enabled, the Send test request call bypasses it; to confirm proxy routing, run a test or live journey.
- For chained journeys, the second journey must be published or in test mode before the custom action is triggered, and within its active date window.
Terminology:
- Canonical name: Send test request — Acronym: n/a — variants: test request, in-product troubleshooting capability
- Synonyms: “AJO Journey” = “the executor of the test request, using the exact request structure and Adobe Journey Optimizer specific headers”
- Do not confuse: “Basic Authentication” (user provides the password) ≠ “API Key Authentication” (user enters the API key value) ≠ “Custom Authentication” (user supplies parameters in the request bodyParam)
- Do not confuse: “GET” method (no payload required) ≠ “POST” method (JSON payload required)
FAQ:
- Q: What does the Send test request capability do? — It validates a custom action configuration by making real API calls directly from Adobe Journey Optimizer, ensuring the request structure, headers, authentication, and payload are correctly formatted before being used in a journey.
- Q: What permissions are required? — Users must have the Manage journeys events, data sources and actions permission, included in the Journey Administrators role; the View journeys events permission alone is not sufficient.
- Q: Do I need a payload for the test request? — If the custom action method is GET, no payload is required; if the method is POST, you must provide a JSON payload.
- Q: Does Journey Optimizer validate the payload data types? — It raises an error if the JSON structure is incorrect, but not if there is a data type mismatch, so an integer used where a string is expected does not raise an error.
- Q: Can I use this capability for live journeys? — Yes, the Send test request capability can be used for troubleshooting live journeys, as the custom action is already deployed.
- Q: Why is an event discarded when chaining journeys? — The event can be received but discarded, appearing in logs with codes such as notSuitableInitialEvent, when it does not meet the second journey’s qualification condition or the second journey is not ready.