Aangepaste acties oplossen troubleshoot-a-custom-action
U kunt uw aangepaste handelingen testen door API-aanroepen te verzenden vanuit de beheersectie van de gebruikersinterface van Journey Optimizer. Met deze functie kunt u uw aangepaste acties vóór of na het gebruik ervan tijdens een reis oplossen.
Als beheerder gebruikt u de Send test request -functie om uw aangepaste actieconfiguraties te valideren door rechtstreeks vanuit Adobe Journey Optimizer echte API-aanroepen te maken. Deze eigenschap zorgt ervoor dat de verzoekstructuur, de kopballen, de authentificatie, en de lading correct geformatteerd alvorens in een reis worden gebruikt.
Met deze functie stroomlijnt u het test- en validatieproces en zorgt u ervoor dat aangepaste handelingen correct werken tijdens live reizen.
Vereisten troubleshoot-custom-action-prereq
Om het Send test request vermogen te gebruiken, a douaneactie moet met een URL, kopballen, en authentificatiemontages worden pre-gevormd.
De beheerders kunnen deze mogelijkheid alleen gebruiken als ze beschikken over de volgende machtigingen:
- Gebruikers moeten de machtiging Manage journeys events, data sources and actions hebben.
- Deze toestemming is inbegrepen in de rol van de Beheerders van de Reis.
- De machtiging View journeys events alleen is niet voldoende.
Leer meer over reistoestemmingen in deze sectie .
Hoe te om de Send eigenschap van het testverzoek te gebruiken troubleshoot-custom-action-use
Voer de volgende stappen uit om een aangepaste handeling te testen:
-
Navigeer aan het scherm van de Acties configuratie, en selecteer een douaneactie.
-
Klik op de knop Send test request onder aan het actieconfiguratiescherm.
{width="70%"}
-
In het pop-upvenster kunt u aanvraagparameters opgeven:
-
Als de methode van de douaneactie GET is, wordt geen nuttige lading vereist.
-
Als de methode van de douaneactie POST is, moet u een nuttige lading JSON verstrekken.
note note NOTE Adobe Journey Optimizer zal een fout veroorzaken als de structuur van dit JSON onjuist is, maar zal het niet doen als er een mismatch met een gegevenstype is. Er treedt bijvoorbeeld geen fout op als een parameter integer wordt gebruikt voor wat een tekenreeks moet zijn. -
Als verificatie is gedefinieerd, wordt u gevraagd verificatiegegevens in te voeren.
-
-
Klik verzenden om het verzoek uit te voeren.
-
De reactie van de API, inclusief kopteksten en statuscodes, wordt weergegeven in de interface.
Verificatieverwerking troubleshoot-custom-action-auth
Wanneer een aangepaste handeling verificatie bevat, vereist Adobe Journey Optimizer dat de gebruiker voor elke testaanvraag verificatiegegevens invoert:
- Basisauthentificatie: de gebruiker moet het wachtwoord verstrekken.
- API Zeer belangrijke Authentificatie: de gebruiker moet de API sleutel waarde ingaan.
- Authentificatie van de Douane: de gebruiker moet de authentificatieparameters in het verzoek bodyParam leveren. Twee secties worden toegevoegd in dit geval: verzoek van de Authentificatie en de reactie van de Authentificatie.
Belangrijkste voordelen troubleshoot-custom-action-benefits
Als Journey Optimizer-beheerder kunt u ook externe gereedschappen (bijvoorbeeld Postman) gebruiken om aangepaste handelingen te testen. De belangrijkste voordelen van de mogelijkheden voor probleemoplossing in producten in vergelijking met externe tests worden hieronder vermeld:
-
Het testverzoek wordt uitgevoerd door Reis van AJO, betekenend:
- De exacte aanvraagstructuur (inclusief Adobe Journey Optimizer-specifieke headers) wordt gebruikt.
- De bron-IP en de kopballen passen die in levende reizen worden gebruikt.
-
Het Send test request vermogen kan voor het oplossen van problemen levende reizen worden gebruikt, aangezien de douaneactie reeds wordt opgesteld.
-
Met deze testfunctie voor in-product producten hoeft u geen configuratiedetails handmatig tussen gereedschappen te kopiëren, waardoor het risico op fouten kleiner wordt.
Problemen oplossen troubleshoot-custom-action-check
Als de aanvraag mislukt, kunt u controleren:
- De verificatiereferenties die in de test zijn ingevoerd.
- De aanvraagmethode (GET versus POST) en de bijbehorende lading.
- Het API eindpunt en de kopballen die in de douaneactie worden bepaald.
- Gebruik de reactiegegevens om potentiële misconfiguraties te identificeren.
Gebeurtenissen negeren en inactieve time-outs afhandelen handling-discard-events-and-idle-timeouts
Wanneer een douaneactie in één reis een gebeurtenis teweegbrengt die bedoeld is om a tweede reis te beginnen, zorg de tweede reis in een geldige staat is en de gebeurtenis wordt erkend. Als de gebeurtenis niet aan de de ingangsvoorwaarden van de tweede reis voldoet, kan de gebeurtenis worden verworpen en in logboeken met codes zoals notSuitableInitialEvent verschijnen. De inactieve onderbrekingen kunnen voorkomen als de tweede reis niet klaar is, die tot gebeurtenissen in de logboeken leiden te verwerpen.
Gemeenschappelijke oorzaken:
-
de kwalificatie van de Gebeurtenis niet voldaan aan - de tweede reis gebruikt een op regel-gebaseerde gebeurtenis met een kwalificatievoorwaarde (bijvoorbeeld, moet een vereist gebied niet-leeg zijn, zoals
isNotEmptyop een specifiek gebied). Als de gebeurtenislading niet aan die voorwaarde (bijvoorbeeld, is het gebied leeg of mist) voldoet, wordt de gebeurtenis ontvangen maar verworpen en de tweede reis wordt niet teweeggebracht. Dit wordt verwacht gedrag; de documentatie en het logboek bevestigen dat als de kwalificatievoorwaarde niet wordt voldaan aan, de gebeurtenis zal worden verworpen en de reis niet voor dat profiel zal teweeggebracht. Verifieer dat de lading die door de douaneactie wordt verzonden alle gebieden en waarden omvat die door de de gebeurtenisconfiguratie van de tweede reis worden vereist. Leer hoe te regel-gebaseerde gebeurtenissen vormen en gebeurtenisontvangst in reisuitvoering problemen oplossen. -
Tweede reis niet klaar - De nutteloze onderbrekingen kunnen voorkomen als de tweede reis (bijvoorbeeld, niet op testwijze of niet levend) nog niet actief is, of als er een tijdhiaat tussen de douaneactie die en de tweede reis klaar is te ontvangen is. Zorg ervoor dat de doelreis wordt gepubliceerd of in de testmodus voordat de aangepaste handeling wordt geactiveerd.
-
het Diagnose verwerpen gebeurtenissen - als u gebeurtenissen in logboeken ziet verwerpen, de logboeken van de controlereis en de sporen van het Splunk om te bevestigen of de gebeurtenis werd ontvangen maar wegens kwalificatie (lading voldeed niet aan de regel) of timing werd verworpen. Zorg ervoor dat de begindatum en configuratie van de tweede reis correct zijn en dat de reis binnen zijn actieve datumvenster is.
Om gebeurtenissen te vermijden die tijdens het ketenen van reizen via douaneacties worden verworpen, bevestig de gebeurtenislading tegen de tweede de gebeurtenisregel van de reis en bevestig de doelreis levend of in test en binnen zijn actief datumvenster is.
Aanvullende bronnen
Blader in de onderstaande secties voor meer informatie over het configureren en gebruiken van aangepaste handelingen:
- worden begonnen met douaneacties - leer wat een douaneactie is en hoe zij u met uw derdesystemen helpen verbinden
- vorm uw douaneacties - leer hoe te om een douaneactie tot stand te brengen en te vormen
- de douaneacties van het Gebruik - leer hoe te om douaneacties in uw reizen te gebruiken
- de inzamelingen van de pas in de parameters van de douaneactie - leer hoe te om een inzameling in de parameters van de douaneactie over te gaan die dynamisch bevolkt bij runtime is