Sdílet prostřednictvím

Pokyny pro ladění

  • Článek

PLATÍ PRO: SDK v4

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

Ladění může být někdy obtížné. Každý vývojář má svůj vlastní preferovaný 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 klienta přímého řádku, ke kterému se robot může připojit. Další informace najdete v tématu Připojení robota k direct line.

Vytvoření vlastního klienta umožňuje definovat vnitřní fungování kanálu a otestovat, jak robot reaguje na určité výměny aktivit. Po připojení k vašemu klientovi spusťte testy, abyste nastavili stav robota a ověřili funkce. Pokud váš robot využívá funkci, jako je řeč, může pomocí 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 Emulatoru i Webový chat prostřednictvím webu Azure Portal vám 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é vícevláknové aplikace s možností 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 s ním nejste obeznámeni. Myšlenka, že robot je bezstavový, vícevláknový a pracuje s voláními async/await, může vést k neočekávaným chybám. Při ladění robota funguje podobně jako jiné vícevláknové aplikace, budeme se zabývat některými návrhy, nástroji a prostředky, které vám pomůžou.

Principy aktivit robota pomocí emulátoru

Váš robot se zabývá různými typy aktivit kromě běžné aktivity zpráv. Porozumění těmto aktivitám vám pomůže efektivně zakódovat robota a umožní vám ověřit aktivity, které robot odesílá a přijímá, jsou to, co očekáváte. Použití emulátoru vám ukáže, co jsou tyto aktivity, kdy k nim dojde a jaké informace obsahují. Další informace naleznete v tématu Ladění pomocí emulátoru.

Ukládání a načítání interakcí uživatelů s přepisy

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

Kromě toho můžete po uložení interakcí se vstupem uživatele použít Průzkumníka úložiště Azure k ručnímu zobrazení dat obsažených v přepisech uložených v úložišti přepisů objektů blob. Následující příklad otevře průzkumníka služby Storage z nastavení pro mynewtestblobstorage. Pokud chcete otevřít uložený vstup uživatele, vyberte: Blob Container > ChannelId > TranscriptId ConversationId >

Příklad položky přepisu uložené v úložišti přepisu 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 přepisu 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í provádění. Middleware se může spustit na úvodním nebo koncovém okraji turnu s voláním next() delegování diktování při předání spuštění do logiky robota.

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

next() Pokud delegát není volána, označuje se to jako směrování krátkého okruhu. K tomu dochází, když middleware splňuje aktuální aktivitu a určí, že není nutné předat provádění.

Pochopení, kdy a proč můžou zkraty middlewaru pomoct indikovat, která část middlewaru by měla být ve vašem kanálu první. Pochopení toho, co očekávat, je navíc důležité pro integrovaný middleware poskytovaný sadou SDK nebo jinými vývojáři. Některé vám můžou pomoct vyzkoušet si nejprve vytvoření vlastního middlewaru, abyste mohli 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.

Principy 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 co nejrychleji zpracovávat aktivity a nechat zpracování dokončit, aby se tento stav zachoval. Aktivity se dají do robota odesílat téměř ve stejnou dobu a můžou způsobovat matoucí chyby kvůli asynchronní architektuře.

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 emulátory úložiště pro Cosmos DB a Azure Table Storage můžou pomoct ověřit 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 žádnou sadu klíčů oddílů a byly přiděleny výchozímu klíči 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 článku 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 se dělené úložiště Cosmos DB automaticky nevytvoří databázi v rámci vašeho účtu Cosmos DB. Potřebujete vytvořit novou databázi ručně, ale přeskočit ruční vytvoření kontejneru, protože CosmosDbPartitionedStorage za vás kontejner vytvoří.

Jak používat obslužné rutiny aktivit

Obslužné rutiny aktivit můžou představovat další vrstvu složitosti, zejména proto, že každá aktivita běží na 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í to, co očekáváte.

Předdefinovaný stav se zapíše na konci turnu, ale všechny aktivity vygenerované tímto otáčením se provádějí nezávisle na kanálu turn. Často to nemá vliv na nás, ale pokud obslužná rutina aktivity změní stav, potřebujeme, aby tento stav obsahoval. V takovém případě může kanál turn čekat na dokončení zpracování aktivity před dokončením, aby se zajistilo, že zaznamená správný stav tohoto turnu.

Metoda aktivity odesílání a její obslužné rutiny představují jedinečný problém. Jednoduše volání aktivity odesílání z obslužné rutiny aktivity pro odesílání způsobí nekonečné vytvoření forku 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, aby nedošlo k chybovému ukončení robota.

Ladění produkčního robota

Když je robot v produkčním prostředí, můžete robota ladit z libovolného kanálu pomocí Dev Tunnels. Bezproblémové připojení robota k více kanálům je klíčovou funkcí dostupnou v bot Frameworku. Další informace najdete v tématu Ladění robota z libovolného kanálu pomocí devtunnelu a ladění dovednosti nebo příjemce dovedností.

Další kroky

Postup testování jednotek robotů

Další materiály