Sdílet prostřednictvím

Pokyny k ladění

  • Článek

PLATÍ PRO: SDK v4

Roboti jsou složité aplikace s mnoha částmi, které spolupracují. Stejně jako každá jiná složitá aplikace to může vést k zajímavým chybám nebo může způsobit, že se robot bude chovat jinak, než se čekalo.

Ladění robota může být někdy obtížné. Každý vývojář má svůj vlastní upřednostňovaný způsob, jak tento úkol provést. Níže uvedené pokyny jsou návrhy, které platí pro většinu robotů.

Po ověření, že robot funguje, je dalším krokem jeho připojení ke kanálu. Uděláte to tak, že robota nasadíte na přípravný server a vytvoříte vlastního přímého klienta, ke kterému se bude robot připojovat. Další informace najdete v tématu Připojení robota k Direct Line.

Vytvoření vlastního klienta vám umožní definovat vnitřní fungování kanálu a otestovat, jak robot reaguje na určité výměny aktivit. Po připojení ke klientovi spusťte testy, nastavte stav robota a ověřte funkce. Pokud váš robot využívá funkci, jako je řeč, může vám použití těchto kanálů nabídnout způsob, jak tuto funkci ověřit.

Poznámka

Při nasazování robota do Azure se ve výchozím nastavení zřídí kanál Webový chat.

Použití Bot Framework Emulator i Webový chat prostřednictvím Azure Portal může poskytnout další přehled o tom, jak robot funguje při interakci s různými kanály.

Ladění robota funguje podobně jako jiné aplikace s více vlákny a umožňuje nastavit zarážky nebo používat funkce, jako je okamžité okno.

Roboti se řídí programovacím paradigmatem řízeným událostmi, které může být obtížné racionalizovat, pokud ho neznáte. Představa robota, který je bezstavový, má vícevláknový přístup a zpracovává asynchronní/await volání, může vést k neočekávaným chybám. I když ladění robota funguje podobně jako jiné aplikace s více vlákny, probereme několik návrhů, nástrojů a prostředků, které vám pomůžou.

Principy aktivit robota pomocí emulátoru

Váš robot se kromě běžné aktivity zpráv zabývá různými typy aktivit. Pochopení těchto aktivit vám pomůže efektivně kódovat robota a umožní vám ověřit, že aktivity, které robot odesílá a přijímá, jsou takové, jaké očekáváte. Pomocí emulátoru se dozvíte, co jsou tyto aktivity, kdy k nim dochází a jaké informace obsahují. Další informace najdete v tématu Ladění pomocí emulátoru.

Ukládání a načítání uživatelských interakcí s přepisy

Úložiště přepisů objektů blob v Azure poskytuje specializovaný prostředek, ve kterém můžete ukládat i načítat přepisy obsahující interakce mezi uživateli a robotem.

Po uložení uživatelských vstupních interakcí navíc můžete pomocí Průzkumníka úložiště Azure ručně zobrazit data obsažená v přepisech uložených v úložišti přepisů objektů blob. Následující příklad otevře průzkumníka úložiště z nastavení pro mynewtestblobstorage. Pokud chcete otevřít uložený uživatelský vstup, vyberte: Blob Container > ChannelId > TranscriptId > ConversationId

Příklad záznamu přepisu uloženého v úložišti přepisů objektů blob

Tím se otevře uložený vstup konverzace uživatele ve formátu JSON. Uživatelský vstup se zachová společně s klíčem "text:". Další informace o vytváření a používání souboru s přepisem robota najdete v tématu Ladění robota pomocí souborů přepisu.

Jak funguje middleware

Middleware nemusí být při prvním pokusu o jeho použití intuitivní, zejména pokud jde o pokračování nebo zkratování spuštění. Middleware se může spouštět na úvodním nebo koncovém okraji zatáčení s voláním next() delegáta, který diktuje, když je spuštění předáno do logiky robota.

Pokud používáte více částí middlewaru a je to způsob, jakým je váš kanál orientovaný, může delegát předat provádění jiné části middlewaru. Podrobnosti o kanálu middlewaru robota vám můžou pomoct, aby byla tato myšlenka jasnější.

Pokud delegát next() není volána, označuje se to jako zkratové směrování. K tomu dochází, když middleware splní aktuální aktivitu a zjistí, že není nutné předávat provádění.

Pochopení, kdy a proč zkratování middlewaru vám může pomoct určit, která část middlewaru by měla být ve vašem kanálu na prvním místě. Kromě toho je důležité pochopit, co očekávat, u integrovaného middlewaru poskytovaného sadou SDK nebo jinými vývojáři. Pro některé je užitečné, když si nejdřív zkusíte vytvořit vlastní middleware a trochu experimentovat, než se ponoříte do integrovaného middlewaru.

Další informace o ladění robota pomocí kontrolního middlewaru najdete v tématu Ladění robota pomocí kontrolního middlewaru.

Vysvětlení stavu

Sledování stavu je důležitou součástí robota, zejména u složitých úloh. Obecně platí, že osvědčeným postupem je zpracovat aktivity co nejrychleji a nechat zpracování dokončit, aby se stav zachoval. Aktivity se můžou robotovi odesílat téměř ve stejnou dobu, a to může způsobovat matoucí chyby kvůli asynchronní architektuře.

A co je nejdůležitější, ujistěte se, že stav přetrvává způsobem, který odpovídá vašim očekáváním. V závislosti na tom, kde se váš trvalý stav nachází, vám můžou emulátory úložiště pro Cosmos DB a Azure Table Storage pomoct ověřit tento stav před použitím produkčního úložiště.

Důležité

Třída úložiště Cosmos DB je zastaralá. Kontejnery původně vytvořené pomocí služby CosmosDbStorage neměly nastavený žádný klíč oddílu a dostaly výchozí klíč oddílu _/partitionKey.

Kontejnery vytvořené s úložištěm Cosmos DB je možné použít s děleným úložištěm Cosmos DB. Další informace najdete v tématu Dělení ve službě Azure Cosmos DB .

Všimněte si také, že na rozdíl od starší verze úložiště Cosmos DB nevytvoří dělené úložiště Cosmos DB automaticky databázi v rámci vašeho účtu Cosmos DB. Novou databázi musíte vytvořit ručně, ale přeskočte ruční vytváření kontejneru, protože CosmosDbPartitionedStorage vytvoří kontejner za vás.

Jak používat obslužné rutiny aktivit

Obslužné rutiny aktivit mohou zavést další vrstvu složitosti, zejména proto, že každá aktivita běží v nezávislém vlákně (nebo webových pracovních procesů v závislosti na vašem jazyce). V závislosti na tom, co vaše obslužné rutiny dělají, to může způsobit problémy, kdy aktuální stav není takový, jaký očekáváte.

Předdefinovaný stav se zapíše na konci tahu, ale všechny aktivity vygenerované tímto otočením se spouští nezávisle na kanálu otočení. Často to nemá vliv na nás, ale pokud obslužná rutina aktivity změní stav, potřebujeme stav napsaný tak, aby obsahoval tuto změnu. V takovém případě může kanál turn počkat na dokončení zpracování aktivity, aby se zajistilo, že zaznamená správný stav tohoto otočení.

Metoda aktivity odesílání a její obslužné rutiny představují jedinečný problém. Jednoduché volání aktivity odeslání z obslužné rutiny aktivit při odesílání způsobí nekonečné forking vláken. Existují způsoby, jak tento problém vyřešit, například připojením dalších zpráv k odchozím informacím nebo zápisem do jiného umístění, jako je konzola nebo soubor, abyste se vyhnuli chybovému ukončení robota.

Ladění produkčního robota

Když je robot v produkčním prostředí, můžete ho ladit z libovolného kanálu pomocí nástroje ngrok. Bezproblémové připojení robota k více kanálům je klíčovou funkcí dostupnou v Bot Frameworku. Další informace najdete v tématech Ladění robota z libovolného kanálu pomocí nástroje ngrok a Ladění dovednosti nebo uživatele dovedností.

Další kroky

Postup jednotek testovacích robotů

Další materiály