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 roboten beter sig annorlunda än förväntat.

Felsökning kan din robot 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 ansluter nästa steg 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 direktlinje.

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

Kommentar

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

Användning av både Bot Framework-emulatorn 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 asynkrona/väntande 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 kontrollera att de aktiviteter som din robot skickar och tar emot är vad du förväntar dig. När du använder emulatorn visas vad dessa aktiviteter är, när de inträffar 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 avskrifter som innehåller interaktioner mellan dina användare och din robot.

När interaktionen med användarindata 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". Öppna en sparad användarinmatning genom att välja: 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 intuitiva 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 det är så 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 skicka körningen vidare.

Att förstå när, och varför, kortslutningar för mellanprogram kan hjälpa dig att ange vilken bit mellanprogram som ska komma först i din pipeline. 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 prova att 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 kontrollmellanprogram 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 kvarstår 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 den cosmos DB-partitionerade lagringen, 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 manuellt skapa en container 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 sväng, 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 tillståndet skrivet för att innehålla ändringen. I så fall kan turpipelinen vänta på att aktiviteten ska 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. Att bara anropa sändningsaktiviteten inifrån aktivitetshanteraren på skicka orsakar en oändlig förgrening av trådar. Det finns sätt att kringgå det problemet, till exempel genom att lägga till ytterligare meddelanden till den utgående informationen eller skriva ut till en annan plats som konsolen eller en fil för att undvika att krascha roboten.

Felsöka en produktionsrobot

När roboten är i produktion kan du felsöka roboten från valfri kanal med hjälp av Dev Tunnels. Den sömlösa anslutningen av roboten 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 devtunnel och Felsöka en kunskaps- eller kunskapskonsument.

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