Sur cette page : envoyez des appels API de test réels pour valider vos configurations d’action personnalisées afin de pouvoir détecter des erreurs avant de les utiliser dans des parcours actifs.
Vous pouvez tester vos actions personnalisées en envoyant des appels API à partir de la section administration de l’interface d’utilisation de Journey Optimizer. Cette fonctionnalité vous permet de résoudre les problèmes liés à vos actions personnalisées avant ou après leur utilisation dans un parcours.
En tant qu’administrateur ou administratrice, utilisez la fonctionnalité Envoyer une demande de test pour valider vos configurations d’actions personnalisées en effectuant des appels API réels directement depuis Adobe Journey Optimizer. Cette fonctionnalité permet de s’assurer que la structure de la demande, les en-têtes, l’authentification et la payload sont correctement formatés avant leur utilisation dans un parcours.
L’utilisation de cette fonctionnalité simplifie le processus de test et de validation, en veillant au bon déroulement des actions personnalisées dans les parcours actifs.
Conditions préalables troubleshoot-custom-action-prereq
Pour utiliser la fonctionnalité Envoyer une demande de test, une action personnalisée doit être préconfigurée avec une URL, des en-têtes et des paramètres d’authentification.
Pour que l’administration puisse utiliser cette fonctionnalité, les autorisations suivantes sont requises :
- Les utilisateurs et utilisatrices doivent disposer de l’autorisation Manage journeys events, data sources and actions.
- Cette autorisation est incluse dans le rôle Administrateurs et administratrices de parcours.
- L’autorisation View journeys events seule n’est pas suffisante.
En savoir plus sur les autorisations de parcours dans cette section.
Utiliser la fonctionnalité Envoyer une demande de test troubleshoot-custom-action-use
Pour tester une action personnalisée, procédez comme suit :
-
Accédez à l’écran de configuration Actions et sélectionnez une action personnalisée.
-
Cliquez sur le bouton Envoyer une demande de test en bas de l’écran de configuration de l’action.
-
Dans la fenêtre contextuelle qui s’affiche, spécifiez les paramètres de la demande :
-
Si la méthode d’action personnalisée est GET, aucune payload n’est requise.
-
Si la méthode d’action personnalisée est POST, vous devez fournir une payload JSON.
note NOTE Adobe Journey Optimizer génère une erreur si la structure de ce fichier JSON est incorrecte, mais pas en cas d’incohérence avec un type de données. Par exemple, il n’y aura aucune erreur si un paramètre entier est utilisé au lieu d’une chaîne. -
Si l’authentification est définie, il vous est demandé de saisir les détails de l’authentification.
-
-
Cliquez sur Envoyer pour exécuter la demande.
-
La réponse de l’API, y compris les en-têtes et les codes d’état, s’affiche dans l’interface.
Gestion de l’authentification troubleshoot-custom-action-auth
Lorsqu’une action personnalisée comprend une authentification, Adobe Journey Optimizer exige que la personne saisisse les détails d’authentification pour chaque demande de test :
- Authentification de base : la personne doit fournir le mot de passe.
- Authentification par clé API : la personne doit saisir la valeur de la clé API.
- Authentification personnalisée : la personne doit fournir les paramètres d’authentification dans la demande bodyParam. Deux sections sont ajoutées dans ce cas : Demande d’authentification et Réponse d’authentification.
Avantages clés troubleshoot-custom-action-benefits
En tant qu’administrateur ou administratrice de Journey Optimizer, vous pouvez également utiliser des outils externes (par exemple, Postman) pour tester vos actions personnalisées. Les principaux avantages de la fonctionnalité de dépannage intégrée au produit par rapport à un test externe sont répertoriés ci-dessous :
-
La demande de test est exécutée par le Parcours AJO, ce qui offre les avantages suivants :
- La structure exacte de la requête (y compris les en-têtes spécifiques à Adobe Journey Optimizer) est utilisée.
- L’adresse IP source et les en-têtes correspondent à ceux utilisés dans les parcours actifs.
-
La fonctionnalité Envoyer une demande de test permet de résoudre les problèmes liés aux parcours actifs, car l’action personnalisée est déjà déployée.
-
Cette fonctionnalité de test intégrée au produit élimine la nécessité de copier manuellement les informations de configuration entre les outils, ce qui réduit le risque d’erreurs.
Résolution des problèmes troubleshoot-custom-action-check
Si la demande échoue, vous pouvez vérifier les éléments suivants :
- Les informations d’authentification saisies dans le test.
- La méthode de la demande (GET ou POST) et la payload correspondante.
- Le point d’entrée de l’API et les en-têtes définis dans l’action personnalisée.
- Utilisez les données de réponse pour identifier les erreurs de configuration potentielles.
Gestion des événements de rejet et des délais d’inactivité handling-discard-events-and-idle-timeouts
Lorsqu’une action personnalisée dans un parcours déclenche un événement destiné à démarrer un deuxième parcours, assurez-vous que le deuxième parcours est dans un état valide et que l’événement est reconnu. Si l’événement ne remplit pas les conditions d’entrée du deuxième parcours, il peut être rejeté et apparaître dans les journaux avec des codes tels que notSuitableInitialEvent. Les délais d’inactivité peuvent survenir si le deuxième parcours n’est pas prêt, ce qui entraîne le rejet des événements dans les journaux.
Causes fréquentes :
-
Qualification d’événement non remplie – Le deuxième parcours utilise un événement basé sur des règles avec une condition de qualification (par exemple, un champ obligatoire doit être non vide, comme
isNotEmptysur un champ spécifique). Si la payload de l’événement ne répond pas à cette condition (par exemple, le champ est vide ou manquant), l’événement est reçu, mais rejeté et le deuxième parcours n’est pas déclenché. Ce comportement est attendu. La documentation et les journaux confirment que si la condition de qualification n’est pas remplie, l’événement sera rejeté et le parcours ne sera pas déclenché pour ce profil. Vérifiez que la payload envoyée par l’action personnalisée inclut tous les champs et valeurs requis par la configuration d’événement du deuxième parcours. Découvrez comment configurer des événements basés sur des règles et résoudre les problèmes de réception d’événements dans l’exécution de parcours. -
Deuxième parcours non prêt – Des délais d’inactivité peuvent se produire si le deuxième parcours n’est pas encore actif (par exemple, pas en mode test ou actif) ou s’il existe un intervalle de temps entre le déclenchement de l’action personnalisée et la réception du deuxième parcours. Assurez-vous que le parcours cible est publié ou en mode test avant le déclenchement de l’action personnalisée.
-
Diagnostic des événements rejetés – Si vous voyez des événements rejetés dans les journaux, vérifiez les journaux de parcours et les traces Splunk pour confirmer si l’événement a été reçu mais rejeté en raison de la qualification (la payload ne respectait pas la règle) ou de la synchronisation. Assurez-vous que la date de début et la configuration du deuxième parcours sont correctes et que le parcours se trouve dans sa fenêtre de date active.
Pour éviter de rejeter des événements lors de l’association de parcours par le biais d’actions personnalisées, validez la payload de l’événement par rapport à la règle d’événement du deuxième parcours et confirmez que le parcours cible est actif ou en test et dans sa fenêtre de date active.
Ressources supplémentaires
Parcourez les sections ci-dessous pour en savoir plus sur la configuration et l’utilisation de vos actions personnalisées :
- Commencer avec les actions personnalisées : découvrez en quoi consiste une action personnalisée et comment elle vous permet de vous connecter à vos systèmes tiers.
- Configurer vos actions personnalisées : découvrez comment créer et configurer une action personnalisée.
- Utiliser des actions personnalisées : découvrez comment utiliser des actions personnalisées dans vos parcours.
- Transmettre des collections dans des paramètres d’action personnalisés : découvrez comment transmettre une collection dans des paramètres d’action personnalisés qui est renseignée dynamiquement au moment de l’exécution.
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.