Save state and access data
[This topic is pre-release documentation for V4 SDK content and is subject to change. You can find V3 SDK content here]
A key to good bot design is to track the context of a conversation, so that your bot remembers things like the answers to previous questions. Depending on what your bot is used for, you may even need to keep track of state or store information for longer than the lifetime of the conversation. A bot's state is information it remembers in order to respond appropriately to incoming messages. The Bot Builder SDK provides classes for storing and retrieving state data as an object associated with a user or a conversation.
- Conversation properties help your bot keep track of the current conversation the bot is having with the user. If your bot needs to complete a sequence of steps or switch between conversation topics, you can use conversation properties to manage steps in a sequence or track the current topic. Since conversation properties reflect the state of the current conversation, you typically clear them at the end of a session, when the bot receives an end of conversation activity.
- User properties can be used for many purposes, such as determining where the user's prior conversation left off or simply greeting a returning user by name. If you store a user's preferences, you can use that information to customize the conversation the next time you chat. For example, you might alert the user to a news article about a topic that interests her, or alert a user when an appointment becomes available. You should clear them if the bot receives a delete user data activity.
You can use Storage to read from and write to persistent storage. This enables your bot to do things such as update shared resources, record RSVPs or votes, or read historical weather data. In the same way an app uses storage to achieve its objectives, your bot can do so within the conversation with your user.
Types of underlying storage
The SDK provides bot state manager middleware to persist conversation and user state. State can be accessed using the bot's context. This state manager can use Azure Table Storage, file storage, or memory storage as the underlying data storage. You can also create your own storage components for your bot.
Bots built using Azure Table Storage can be designed to be stateless and scalable across multiple compute nodes.
File and memory storage won't scale across nodes.
Writing directly to storage
You can also use the Bot Builder SDK to write directly to storage, without using middleware. This enables you to read and write data outside the middleware pipeline or without using the bot context. This can be appropriate to data that your bot uses, that comes from a source outside your bot's conversation flow.
For example, let's say your bot allows the user to ask for the weather report, and your bot retrieves the weather report for a specified date, by reading it from an external database. The content of the weather database isn't dependent on user information or the conversation context, so you could just read it directly from storage instead of using the state manager. See How to write directly to storage for an example.
Next, lets get into how activities are processed, in depth, and how we respond to them.