Nesta página: Envie chamadas de API de teste reais para validar suas configurações de ação personalizadas para que você possa detectar erros antes de confiar nelas no Live jornada.
Você pode testar suas ações personalizadas enviando chamadas de API da seção de administração da interface do usuário do Journey Optimizer. Esse recurso ajuda você a solucionar problemas de ações personalizadas antes ou depois de usá-las em uma jornada.
Como administrador, use o recurso Enviar solicitação de teste para validar as configurações de ação personalizadas fazendo chamadas de API reais diretamente do Adobe Journey Optimizer. Esse recurso garante que a estrutura de solicitação, os cabeçalhos, a autenticação e a carga sejam formatados corretamente antes de serem usados em uma jornada.
O uso desse recurso simplifica o processo de teste e validação, garantindo que as ações personalizadas funcionem corretamente nas jornadas ativas.
Pré-requisitos troubleshoot-custom-action-prereq
Para usar o recurso Enviar solicitação de teste, uma ação personalizada deve ser pré-configurada com uma URL, cabeçalhos e configurações de autenticação.
Para que os administradores usem esse recurso, são necessárias as seguintes permissões:
- Os usuários devem ter a permissão Manage journeys events, data sources and actions.
- Esta permissão está incluída na função Administradores do Jornada.
- A permissão View journeys events sozinha não é suficiente.
Saiba mais sobre permissões de jornada em esta seção.
Como usar o recurso Enviar solicitação de teste troubleshoot-custom-action-use
Para testar uma ação personalizada, siga estas etapas:
-
Navegue até a tela de configuração Ações e selecione uma ação personalizada.
-
Clique no botão Enviar solicitação de teste, na parte inferior da tela de configuração de ação.
-
Na janela pop-up, permitindo que você especifique parâmetros de solicitação:
-
Se o método de ação personalizado for GET, nenhuma carga será necessária.
-
Se o método de ação personalizado for POST, você deverá fornecer uma carga JSON.
note NOTE O Adobe Journey Optimizer levantará um erro se a estrutura desse JSON estiver incorreta, mas não o fará se houver uma incompatibilidade com um tipo de dados. Por exemplo, não haverá erro se um parâmetro inteiro for usado para o que deve ser uma string. -
Se a autenticação estiver definida, você será solicitado a inserir detalhes de autenticação.
-
-
Clique em Enviar para executar a solicitação.
-
A resposta da API, incluindo cabeçalhos e códigos de status, será exibida na interface.
Manuseio de autenticação troubleshoot-custom-action-auth
Quando uma ação personalizada inclui autenticação, o Adobe Journey Optimizer exige que o usuário insira detalhes de autenticação para cada solicitação de teste:
- Autenticação Básica: o usuário deve fornecer a senha.
- Autenticação da Chave de API: o usuário deve inserir a chave de API value.
- Autenticação Personalizada: o usuário deve fornecer os parâmetros de autenticação na solicitação bodyParam. Duas seções foram adicionadas neste caso: Solicitação de autenticação e Resposta de autenticação.
Principais benefícios troubleshoot-custom-action-benefits
Como administrador do Journey Optimizer, você também pode usar ferramentas externas (por exemplo, Postman) para testar suas ações personalizadas. Os principais benefícios do recurso de solução de problemas no produto em comparação a um teste externo estão listados abaixo:
-
A solicitação de teste é executada por Jornada AJO, significando:
- A estrutura de solicitação exata (incluindo cabeçalhos específicos do Adobe Journey Optimizer) é usada.
- O IP de origem e os cabeçalhos correspondem àqueles usados nas jornadas ativas.
-
O recurso Enviar solicitação de teste pode ser usado para solucionar problemas de jornadas em tempo real, pois a ação personalizada já foi implantada.
-
Esse recurso de teste no produto elimina a necessidade de copiar manualmente os detalhes de configuração entre as ferramentas, reduzindo o risco de erros.
Solução de problemas troubleshoot-custom-action-check
Se a solicitação falhar, você pode verificar:
- As credenciais de autenticação inseridas no teste.
- O método de solicitação (GET vs. POST) e a carga útil correspondente.
- O endpoint da API e os cabeçalhos definidos na ação personalizada.
- Use os dados de resposta para identificar possíveis erros de configuração.
Manipular eventos de descarte e tempos limite ociosos handling-discard-events-and-idle-timeouts
Quando uma ação personalizada em uma jornada aciona um evento que deve iniciar uma segunda jornada, verifique se a segunda jornada está em um estado válido e se o evento é reconhecido. Se o evento não atender às condições de entrada da segunda jornada, o evento poderá ser descartado e aparecer em logs com códigos como notSuitableInitialEvent. Os tempos limite de ociosidade podem ocorrer se a segunda jornada não estiver pronta, resultando no descarte de eventos nos logs.
Causas comuns:
-
Qualificação de evento não atendida - A segunda jornada usa um evento baseado em regras com uma condição de qualificação (por exemplo, um campo obrigatório não deve estar vazio, como
isNotEmptyem um campo específico). Se a carga do evento não atender a essa condição (por exemplo, o campo está vazio ou ausente), o evento será recebido, mas descartado, e a segunda jornada não será acionada. Esse é o comportamento esperado; a documentação e os registros confirmam que, se a condição de qualificação não for atendida, o evento será descartado e a jornada não será acionada para esse perfil. Verifique se o conteúdo enviado pela ação personalizada inclui todos os campos e valores exigidos pela configuração do evento da segunda jornada. Saiba como configurar eventos baseados em regras e solucionar problemas de recepção de eventos na execução da jornada. -
Segunda jornada não pronta - Os tempos limite de ociosidade poderão ocorrer se a segunda jornada ainda não estiver ativa (por exemplo, não em modo de teste ou não ativa) ou se houver um intervalo de tempo entre o acionamento da ação personalizada e a segunda jornada pronta para receber. Verifique se a jornada de destino foi publicada ou está no modo de teste antes da ação personalizada ser acionada.
-
Diagnosticando eventos de descarte - Se você vir eventos de descarte em logs, verifique os logs de jornada e os rastreamentos do Splunk para confirmar se o evento foi recebido, mas descartado devido à qualificação (a carga não atendia à regra) ou ao tempo. Verifique se a data de início e a configuração da segunda jornada estão corretas e se a jornada está dentro de sua janela de data ativa.
Para evitar o descarte de eventos ao encadear jornadas por meio de ações personalizadas, valide a carga do evento em relação à regra de evento da segunda jornada e confirme se a jornada de destino está ativa ou em teste e dentro de sua janela de data ativa.
Recursos adicionais
Navegue pelas seções abaixo para saber mais sobre como configurar e usar suas ações personalizadas:
- Introdução a ações personalizadas - Saiba o que é uma ação personalizada e como ela ajuda você a se conectar a sistemas de terceiros
- Configurar ações personalizadas - Saiba como criar e configurar uma ação personalizada
- Usar ações personalizadas - Saiba como usar ações personalizadas em suas jornadas
- Envio de coleções em parâmetros de ação personalizados - Saiba como enviar uma coleção em parâmetros de ação personalizados que é preenchida dinamicamente no tempo de execução
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.