Hantera tillstånd

GÄLLER FÖR: SDK v4

Tillstånd i en robot följer samma paradigmer som moderna webbappar, och via Bot Framework SDK tillhandahålls vissa abstraktioner som kan göra tillståndshanteringen enklare.

Precis som webbappar är en robot tillståndslös till sin natur. En annan instans av din robot kan hantera vilken del som helst av konversationen. För vissa robotar är den här enkelheten att föredra – roboten kan antingen fungera utan ytterligare information, eller så är den information som krävs garanterat inom det inkommande meddelandet. För andra är tillstånd (till exempel var konversationen slutade eller data som tidigare tagits emot om användaren) nödvändigt för att roboten ska ha en användbar konversation.

Varför behöver jag tillstånd?

Om du underhåller tillståndet kan din robot ha mer meningsfulla konversationer genom att komma ihåg vissa saker om en användare eller konversation. Om du till exempel har pratat med en användare tidigare kan du spara tidigare information om dem, så att du inte behöver fråga efter den igen. Tillståndet behåller också data längre än den aktuella svängen, så att din robot behåller information under en konversation med flera turer.

När det gäller robotar finns det några lager för att använda tillstånd: lagringsskiktet, tillståndshantering (som finns i robottillståndet i diagrammet nedan) och tillståndsegenskapsåtkomster. Det här diagrammet illustrerar delar av interaktionssekvensen mellan dessa lager, med de fasta pilarna som representerar ett metodanrop och de streckade pilarna som representerar svaret (med eller utan returvärde).

Sekvensdiagram som illustrerar hur tillståndet läses in, cachelagras och lagras varje sväng.

Flödet i det här diagrammet förklaras i följande avsnitt med information om vart och ett av dessa lager.

Lagringslager

Från serverdelen, där tillståndsinformationen faktiskt lagras, är lagringsskiktet. Detta kan betraktas som din fysiska lagring, till exempel minnesintern, Azure eller en server från tredje part.

Bot Framework SDK innehåller några implementeringar för lagringsskiktet:

  • Minneslagring implementerar minnesintern lagring i testsyfte. Minnesintern datalagring är endast avsedd för lokal testning eftersom den här lagringen är instabil och tillfällig. Data rensas varje gång roboten startas om.
  • Azure Blob Storage ansluter till en Azure Blob Storage objektdatabas.
  • Partitionerad Azure Cosmos DB-lagring ansluter till en partitionerad Cosmos DB NoSQL-databas.

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.

Anvisningar om hur du ansluter till andra lagringsalternativ finns i skriva direkt till lagring.

Tillståndshantering

Tillståndshantering automatiserar läsning och skrivning av robotens tillstånd till det underliggande lagringsskiktet. Tillståndet lagras som tillståndsegenskaper, vilket i praktiken är nyckel/värde-par som roboten kan läsa och skriva via tillståndshanteringsobjektet utan att bekymra sig om den specifika underliggande implementeringen. Dessa tillståndsegenskaper definierar hur den informationen lagras. När du till exempel hämtar en egenskap som du har definierat som en specifik klass eller ett objekt, vet du hur dessa data kommer att struktureras.

Dessa tillståndsegenskaper klumpas ihop i begränsade "buckets", som bara är samlingar för att organisera dessa egenskaper. SDK:et innehåller tre av dessa "buckets":

  • Användartillstånd
  • Konversationstillstånd
  • Privat konversationstillstånd

Alla dessa bucketar är underklasser i robottillståndsklassen , som kan härledas för att definiera andra typer av bucketar med olika omfång.

Dessa fördefinierade bucketar är begränsade till en viss synlighet, beroende på bucketen:

  • Användartillstånd är tillgängligt i alla lägen som roboten samtalar med den användaren på kanalen, oavsett konversationen
  • Konversationstillstånd är tillgängligt i valfri tur i en specifik konversation, oavsett användare, till exempel i gruppkonversationer
  • Privat konversationstillstånd är begränsat till både den specifika konversationen och för den specifika användaren

Tips

Både användar- och konversationstillståndet begränsas av kanalen. Samma person som använder olika kanaler för att komma åt din robot visas som olika användare, en för varje kanal och var och en med ett distinkt användartillstånd.

Nycklarna som används för var och en av dessa fördefinierade bucketar är specifika för användaren och konversationen, eller båda. När du anger värdet för din tillståndsegenskap definieras nyckeln internt, med information som finns i turn-kontexten för att säkerställa att varje användare eller konversation placeras i rätt bucket och egenskap. Mer specifikt definieras nycklarna på följande sätt:

  • Användartillståndet skapar en nyckel med hjälp av kanal-ID:t och från ID:t. Till exempel {Activity.ChannelId}/users/{Activity.From.Id}#YourPropertyName
  • Konversationstillståndet skapar en nyckel med hjälp av kanal-ID :t och konversations-ID:t. Till exempel {Activity.ChannelId}/conversations/{Activity.Conversation.Id}#YourPropertyName
  • Det privata konversationstillståndet skapar en nyckel med hjälp av kanal-ID:t, från ID :t och konversations-ID:t. Till exempel {Activity.ChannelId}/conversations/{Activity.Conversation.Id}/users/{Activity.From.Id}#YourPropertyName

När du ska använda varje typ av tillstånd

Konversationstillstånd är bra för att spåra konversationens kontext, till exempel:

  • Om roboten ställde en fråga till användaren och vilken fråga som var
  • Vad det aktuella konversationsämnet är eller vad det sista var

Användartillstånd är bra för att spåra information om användaren, till exempel:

  • Icke-kritisk användarinformation, till exempel namn och inställningar, en larminställning eller en aviseringsinställning
  • Information om den senaste konversationen de hade med roboten
    • Till exempel kan en produktsupportrobot spåra vilka produkter som användaren har frågat om.

Privat konversationstillstånd är bra för kanaler som stöder gruppkonversationer, men där du vill spåra både användar- och konversationsspecifik information. Om du till exempel hade en chattrobot i klassrummet:

  • Roboten kan aggregera och visa elevsvar för en viss fråga.
  • Roboten kan aggregera varje elevs prestanda och privat vidarebefordra den tillbaka till dem i slutet av sessionen.

Mer information om hur du använder dessa fördefinierade bucketar finns i artikeln instruktioner för tillstånd.

Ansluta till flera databaser

Om roboten behöver ansluta till flera databaser skapar du ett lagringslager för varje databas. Du kan välja att använda flera databaser om roboten samlar in information som har olika säkerhets-, samtidighets- eller dataplatsbehov.

För varje lagringslager skapar du de tillståndshanteringsobjekt som du behöver för att stödja dina tillståndsegenskaper.

Tillståndsegenskapsåtkomster

Tillståndsegenskapsåtkomster används för att faktiskt läsa eller skriva en av dina tillståndsegenskaper och tillhandahålla metoder för att hämta, ange och ta bort för åtkomst till dina tillståndsegenskaper inifrån en sväng. Om du vill skapa en accessor måste du ange egenskapsnamnet, som vanligtvis äger rum när du initierar roboten. Sedan kan du använda den accessorn för att hämta och ändra egenskapen för robotens tillstånd.

Med åtkomstservrarna kan SDK:t hämta tillstånd från den underliggande lagringen och uppdatera robotens tillståndscache åt dig. Tillståndscacheminnet är en lokal cache som hanteras av roboten och som lagrar tillståndsobjektet åt dig, vilket tillåter läs- och skrivåtgärder utan att komma åt den underliggande lagringen. Om den inte redan finns i cacheminnet hämtar anroparens get-metod tillstånd och placerar det även i cacheminnet. När den har hämtats kan tillståndsegenskapen ändras precis som en lokal variabel.

Accessorns borttagningsmetod tar bort egenskapen från cachen och tar även bort den från den underliggande lagringen.

Viktigt

För det första anropet till en accessors get-metod måste du ange en fabriksmetod för att skapa objektet om det ännu inte finns i ditt tillstånd. Om ingen fabriksmetod anges får du ett undantag. Information om hur du använder en fabriksmetod finns i instruktionsartikeln tillstånd.

Om du vill spara alla ändringar som du gör i tillståndsegenskapen som du får från accessorn måste egenskapen i tillståndscachen uppdateras. Du kan göra det via ett anrop till metoden accessoruppsättning , som anger värdet för din egenskap i cacheminnet, och är tillgänglig om det behöver läsas eller uppdateras senare i den svängen. Om du vill spara dessa data i den underliggande lagringen (och därmed göra dem tillgängliga efter den aktuella svängen) måste du spara ditt tillstånd.

Så här fungerar accessormetoderna för tillståndsegenskap

Accessor-metoderna är det primära sättet för roboten att interagera med tillståndet. Hur varje arbete och hur de underliggande lagren interagerar är följande:

  • Accessorns get-metod :
    • Accessor begär egenskapen från tillståndscacheminnet.
    • Om egenskapen finns i cacheminnet returnerar du den. Annars hämtar du det från tillståndshanteringsobjektet. (Om den ännu inte är i tillståndet använder du den fabriksmetod som anges i accessorerna för att hämta anropet.)
  • Accessorns uppsättningsmetod :
    • Uppdatera tillståndscacheminnet med det nya egenskapsvärdet.
  • Metoden spara ändringar för tillståndshanteringsobjektet:
    • Kontrollera ändringarna av egenskapen i tillståndscacheminnet.
    • Skriv egenskapen till lagring.

Tillstånd i dialogrutor

Dialogrutebiblioteket använder en egenskapsåtkomst för dialogläge, definierad för robotens konversationstillstånd, för att behålla en dialogrutas plats i konversationen. Dialogrutans tillståndsegenskap gör det också möjligt för varje dialogruta att lagra tillfällig information mellan svängarna.

Anpassningsbara dialogrutor har en mer detaljerad struktur för minnesomfång, vilket bland annat gör det enklare att komma åt konfigurations- och igenkänningsresultat. Dialoghanteraren använder användar- och konversationstillståndshanteringsobjekt för att tillhandahålla dessa minnesomfång.

Information om dialogrutebiblioteket finns i dialogrutans biblioteksartikel .

Spara tillstånd

När du anropar åtkomstorns angivna metod för att registrera det uppdaterade tillståndet har den tillståndsegenskapen ännu inte sparats i din sparade lagring och sparas i stället bara i robotens tillståndscache. Om du vill spara ändringar i tillståndscacheminnet till ditt sparade tillstånd måste du anropa tillståndshanteringsobjektets save changes-metod , som är tillgänglig vid implementeringen av robottillståndsklassen som nämns ovan (till exempel användartillstånd eller konversationstillstånd).

Om du anropar metoden spara ändringar för ett tillståndshanteringsobjekt (till exempel de bucketar som nämns ovan) sparas alla egenskaper i tillståndscacheminnet som du har konfigurerat till den punkten för bucketen, men inte för någon av de andra bucketarna som du kan ha i robotens tillstånd.

Tips

Bottillståndet implementerar beteendet "senaste skrivning vinner", där den senaste skrivning kommer att stämpla över det tidigare skrivna tillståndet. Detta kan fungera för många program men har konsekvenser, särskilt i utskalade scenarier, där det kan finnas en viss nivå av samtidighet eller svarstid i spelet.

Om du har några anpassade mellanprogram som kan uppdatera tillståndet när din turhanterare har slutförts bör du överväga att hantera tillståndet i mellanprogram.

Ytterligare resurser