Riktlinjer för felsökning

GÄLLER FÖR: SDK v4

Robotar är komplexa appar, där många delar fungerar tillsammans. Precis som andra komplexa appar kan detta leda till några intressanta buggar eller leda till att din robot beter sig annorlunda än förväntat.

Felsökning, din robot kan ibland vara en svår uppgift. Varje utvecklare har sitt eget föredragna sätt att utföra den uppgiften. Riktlinjerna nedan är förslag som gäller för de flesta robotar.

När du har kontrollerat att roboten fungerar är nästa steg att ansluta den till en kanal. För att göra detta kan du distribuera roboten till en mellanlagringsserver och skapa en egen direktlinjeklient som roboten kan ansluta till. Mer information finns i Ansluta en robot till en Direct Line.

Genom att skapa en egen klient kan du definiera kanalens inre funktion och testa hur roboten svarar på vissa aktivitetsutbyten. När du är ansluten till klienten kör du dina tester för att konfigurera robottillståndet och verifiera dina funktioner. Om din robot använder en funktion som tal kan du använda dessa kanaler för att verifiera den funktionen.

Anteckning

När du distribuerar en robot till Azure etableras den Webbchatt kanalen som standard.

Användning av både Bot Framework Emulator och Webbchatt via Azure Portal här kan ge ytterligare insikt i hur din robot fungerar när du interagerar med olika kanaler.

Felsökning av din robot fungerar på samma sätt som andra appar med flera trådar, med möjlighet att ange brytpunkter eller använda funktioner som det omedelbara fönstret.

Robotar följer ett händelsedrivet programmeringsparadigm, vilket kan vara svårt att rationalisera om du inte är bekant med det. Tanken på att din robot är tillståndslös, har flera trådar och hanterar async/await-anrop kan resultera i oväntade buggar. När du felsöker din robot fungerar på samma sätt som andra appar med flera trådar går vi igenom några förslag, verktyg och resurser som kan hjälpa dig.

Förstå robotaktiviteter med emulatorn

Din robot hanterar olika typer av aktiviteter förutom den normala meddelandeaktiviteten . Att förstå dessa aktiviteter hjälper dig att koda din robot effektivt och gör att du kan verifiera att de aktiviteter som din robot skickar och tar emot är vad du förväntar dig. Med emulatorn visas vad dessa aktiviteter är, när de händer och vilken information de innehåller. Mer information finns i Felsöka med emulatorn.

Spara och hämta användarinteraktioner med avskrifter

Azure Blob Transcript Storage tillhandahåller en specialiserad resurs där du både kan lagra och hämta transkriptioner som innehåller interaktioner mellan dina användare och din robot.

När användarindatainteraktioner har lagrats kan du dessutom använda Azures "storage explorer" för att manuellt visa data som finns i avskrifter som lagras i blobavskriftsarkivet. I följande exempel öppnas "storage explorer" från inställningarna för "mynewtestblobstorage". Om du vill öppna en sparad användarinmatning väljer du: Blob Container > ChannelId > TranscriptId > ConversationId

Då öppnas indata för lagrade användarkonversationer i JSON-format. Användarindata bevaras tillsammans med nyckeln "text:". Mer information om hur du skapar och använder en robotavskriftsfil finns i Felsöka din robot med hjälp av transkriptionsfiler.

Så här fungerar mellanprogram

Mellanprogram kanske inte är intuitivt när du först försöker använda det, särskilt när det gäller fortsättning, eller kortslutning, av körning. Mellanprogram kan köras på den inledande eller avslutande kanten av en sväng, med ett anrop till ombudet next() som dikterar när körningen skickas till robotlogik.

Om du använder flera mellanprogram och din pipeline är orienterad kan ombudet skicka körningen till ett annat mellanprogram. Information om robotens pipeline för mellanprogram kan hjälpa dig att göra den idén tydligare.

Om ombudet next() inte anropas kallas det kortslutningsroutning. Detta inträffar när mellanprogrammet uppfyller den aktuella aktiviteten och fastställer att det inte är nödvändigt att vidarebefordra körningen.

Att förstå när, och varför, kortslutna mellanprogram kan hjälpa dig att ange vilken bit mellanprogram som ska komma först i pipelinen. Dessutom är det viktigt att förstå vad du kan förvänta dig för inbyggda mellanprogram som tillhandahålls av SDK:t eller andra utvecklare. Vissa tycker att det är bra att försöka skapa egna mellanprogram först för att experimentera lite innan du dyker in i det inbyggda mellanprogrammet.

Mer information om hur du felsöker en robot med hjälp av mellanprogram för inspektion finns i Felsöka en robot med mellanprogram för inspektion.

Förstå tillstånd

Att hålla reda på tillstånd är en viktig del av roboten, särskilt för komplexa uppgifter. I allmänhet är bästa praxis att bearbeta aktiviteter så snabbt som möjligt och låta bearbetningen slutföras så att tillståndet bevaras. Aktiviteter kan skickas till din robot nästan samtidigt och det kan leda till förvirrande buggar på grund av den asynkrona arkitekturen.

Viktigast av allt är att se till att tillståndet bevaras på ett sätt som matchar dina förväntningar. Beroende på var ditt bevarade tillstånd finns kan lagringsemulatorer för Cosmos DB och Azure Table Storage hjälpa dig att verifiera det tillståndet innan du använder produktionslagring.

Viktigt

Cosmos DB-lagringsklassen har blivit inaktuell. Containrar som ursprungligen skapades med CosmosDbStorage hade ingen partitionsnyckeluppsättning och fick standardpartitionsnyckeln _/partitionKey.

Containrar som skapats med Cosmos DB-lagring kan användas med Cosmos DB-partitionerad lagring. Mer information finns i Partitionering i Azure Cosmos DB .

Observera också att cosmos DB-partitionerad lagring, till skillnad från den äldre Cosmos DB-lagringen, inte automatiskt skapar en databas i ditt Cosmos DB-konto. Du måste skapa en ny databas manuellt, men hoppa över att skapa en container manuellt eftersom CosmosDbPartitionedStorage skapar containern åt dig.

Använda aktivitetshanterare

Aktivitetshanterare kan introducera ytterligare ett lager av komplexitet, särskilt eftersom varje aktivitet körs på en oberoende tråd (eller webbarbetare, beroende på ditt språk). Beroende på vad dina hanterare gör kan detta orsaka problem där det aktuella tillståndet inte är vad du förväntar dig.

Inbyggt tillstånd skrivs i slutet av en tur, men alla aktiviteter som genereras av den svängen körs oberoende av turpipelinen. Detta påverkar oss ofta inte, men om en aktivitetshanterare ändrar tillstånd behöver vi det tillstånd som skrivs för att innehålla ändringen. I så fall kan turpipelinen vänta på aktiviteten för att slutföra bearbetningen innan den slutförs för att se till att den registrerar rätt tillstånd för den svängen.

Metoden skicka aktivitet och dess hanterare utgör ett unikt problem. Om du bara anropar skicka aktivitet inifrån hanteraren för på-skicka-aktiviteter orsakas en oändlig förgrening av trådar. Det finns sätt att kringgå problemet, till exempel genom att lägga till ytterligare meddelanden i utgående information eller skriva ut till en annan plats som konsolen eller en fil för att undvika att krascha din robot.

Felsöka en produktionsrobot

När roboten är i produktion kan du felsöka roboten från valfri kanal med ngrok. Den sömlösa anslutningen av din robot till flera kanaler är en viktig funktion som är tillgänglig i Bot Framework. Mer information finns i Felsöka en robot från valfri kanal med ngrok och Felsöka en färdighets- eller färdighetskonsument.

Nästa steg

Så här samlar du testrobotar

Ytterligare resurser

• Felsökning i Visual Studio
• Felsökning, spårning och profilering för robotramverket
• Använd ConditionalAttribute för metoder som du inte vill inkludera i produktionskoden
• Använda verktyg som Fiddler för att se nätverkstrafik
• Felsöka allmänna problem och andra felsökningsartiklar i det avsnittet