Bot Framework general
APPLIES TO: SDK v3
Some channels do not support transient typing updates in their client.
The Connector library is the exposition of the REST API. The Builder library adds the conversational dialog programming model and other features such as prompts, waterfalls, chains, and guided form completion. The Builder library also provides access to cognitive services such as LUIS.
When the user sends a message over a channel, the Bot Framework web service will issue an HTTPS POST to the bot's web service endpoint. The bot may send zero, one, or many messages back to the user on that channel, by issuing a separate HTTPS POST to the Bot Framework for each message that it sends.
Using the Bot Framework SDK for .NET, you can provide implementations of the IPostToBot
and IBotToUser
interfaces to the Autofac
dependency injection container. Using the Bot Framework SDK for any language, you can use middleware for much the same purpose. The BotBuilder-Azure repository contains C# and Node.js libraries that will log this data to an Azure table.
The primary purpose of IDialogStack.Forward
is to reuse an existing child dialog that is often "reactive", where the child dialog (in IDialog.StartAsync
) waits for an object T
with some ResumeAfter
handler. In particular, if you have a child dialog that waits for an IMessageActivity
T
, you can forward the incoming IMessageActivity
(already received by some parent dialog) by using the IDialogStack.Forward
method. For example, to forward an incoming IMessageActivity
to a LuisDialog
, call IDialogStack.Forward
to push the LuisDialog
onto the dialog stack, run the code in LuisDialog.StartAsync
until it schedules a wait for the next message, and then immediately satisfy that wait with the forwarded IMessageActivity
.
T
is usually an IMessageActivity
, since IDialog.StartAsync
is typically constructed to wait for that type of activity. You might use IDialogStack.Forward
to a LuisDialog
as a mechanism to intercept messages from the user for
some processing before forwarding the message to an existing LuisDialog
. Alternatively, you can also use DispatchDialog
with ContinueToNextGroup
for that purpose.
You would expect to find the forwarded item in the first ResumeAfter
handler (e.g. LuisDialog.MessageReceived
) that is scheduled by StartAsync
.
From the perspective of your bot, "reactive" means that the user initiates the conversation by sending a message to the bot, and the bot reacts by responding to that message. In contrast, "proactive" means that the bot initiates the conversation by sending the first message to the user. For example, a bot may send a proactive message to notify a user when a timer expires or an event occurs.
For examples that show how to send proactive messages, see the C# V4 samples and Node.js V4 samples within the BotBuilder-Samples repository on GitHub.
There are multiple options:
- Resolve the dependency through
Autofac
andFiberModule.Key_DoNotSerialize
. This is the cleanest solution. - Use NonSerialized and OnDeserialized attributes to restore the dependency on deserialization. This is the simplest solution.
- Do not store that dependency, so that it won't be serialized. This solution, while technically feasible, is not recommended.
- Use the reflection serialization surrogate. This solution may not be feasible in some cases and risks serializing too much.
An ETag is a mechanism for optimistic concurrency control. The bot data bag storage uses ETags to prevent conflicting updates to the data. An ETag error with HTTP status code 412 "Precondition Failed" indicates that there were multiple messages received in parallel before the bot could finish its first operation.
The dialog stack and state are stored in bot data bags. For example, you might see the "Precondition Failed" ETag error if your bot is still processing a previous message when it receives a new message for that conversation.
The Bot Framework service must protect itself and its customers against abusive call patterns (e.g., denial of service attack), so that no single bot can adversely affect the performance of other bots. To achieve this kind of protection, we've added rate limits (also known as throttling) to our endpoints. By enforcing a rate limit, we can restrict the frequency with which a client or bot can make a specific call. For example: with rate limiting enabled, if a bot wanted to post a large number of activities, it would have to space them out over a time period. Please note that the purpose of rate-limiting is not to cap the total volume for a bot. It is designed to prevent abuse of the conversational infrastructure that does not follow human conversation patterns. For example, flooding two conversations with more content than two human could ever consume.
We're continuously tuning the rate limits to make them as lenient as possible while at the same time protecting our service and our users. Because thresholds will occasionally change, we aren't publishing the numbers at this time. Finally, if you are hosting your bot on an App Service, the bot is bound to the limitations of the App Service. For more information, see SLA summary for Azure services If you are impacted by rate limiting, feel free to reach out to us at bf-reports@microsoft.com.
It is unlikely you'll experience rate limiting, even at high volume. Most rate limiting would only occur due to bulk sending of activities (from a bot or from a client), extreme load testing, or a bug. When a request is throttled, an HTTP 429 (Too Many Requests) response is returned along with a Retry-After header indicating the amount of time (in seconds) to wait before retrying the request would succeed. You can collect this information by enabling analytics for your bot via Azure Application Insights. Or, you can add code in your bot to log messages.
Rate limiting is caused by any of the following conditions:
- A bot sends messages too frequently
- A client of a bot sends messages too frequently
- Direct Line clients request a new Web Socket too frequently
At times it is necessary to transfer (handoff) a conversation from a bot to a human being. This happens for example if the bot does not understand the user, or if the request cannot be automated. In these cases, the bot provides a transition to humans.
The Bot Framework SDK supports handoff to a human. There a few event types for signaling handoff operations. These events are exchanged between a bot and an agent hub, also called engagement hub. This agent hub is defined as an application or a system that allows agents, typically humans, to receive and handle requests from users, as well as escalation requests from bots.
For detailed information, see Transition conversations from bot to human article.