Azure Bot Framework

The Bot Framework SDK

The Bot Framework SDK, developed by Microsoft, is a comprehensive set of software development tools and libraries that empower developers to create chatbots and conversational AI applications. It is designed to streamline the process of building, testing, and deploying intelligent and interactive bots for a wide range of use cases, such as customer support, virtual assistants, or information retrieval.

Bot application structure

A typical bot application structure, especially when using the Microsoft Bot Framework SDK, is organized into several key components that work together to create, manage, and interact with the chatbot.

Here is an overview of the primary components and their roles in a bot application structure:

• User: This is the starting point of the interaction. A user communicates with the bot through a device or channel, such as a smartphone, computer, or a specific platform like a chat service.

• Device/Channel: This is the medium through which the user sends input to and receives responses from the bot. Different channels may require different formats or protocols. For example, a message sent via SMS might be plain text, while a message on a smart speaker might involve audio.

• Azure Bot Service or other systems: This is a cloud-based service that provides an environment for the bot to run and facilitates the communication between the bot and user devices/channels. It can also provide integrations with other systems, whether they are first-party (developed by the same entity as the bot) or third-party services (external providers).

• Conversational app/bot: This is the main software application that defines the bot's behavior. It includes several layers:

  • Connectivity & protocol: This layer manages the connection between the bot and the Azure Bot Service or other platforms. It ensures that the bot can send and receive messages over the internet and that these messages are in the correct format for each channel.

  • Pipeline processing: Once a message is received, it enters the bot's processing pipeline. The pipeline might involve several steps, such as language detection, user authentication, or message logging. The exact components of the pipeline depend on the bot’s design and the tasks it needs to perform.

  • Reasoning: This is where the core logic of the bot resides. It consists of two main parts:

    • Input recognition: The bot uses natural language understanding (NLU) to interpret the user's intent from their message. It might involve parsing the text, recognizing the spoken language in an audio message, or identifying key entities like dates or product names.
    • Response generation: Based on the recognized intent and entities, and possibly using additional data from storage or other systems, the bot decides on the best response. This could involve selecting a response from a set of predefined answers, generating text using natural language generation (NLG), or executing a task like booking a ticket.

• Storage: This is where the bot can store and retrieve data needed during conversations. This might include user profiles, conversation histories, or other contextual information that helps the bot maintain a coherent dialogue over time.

The interactions between these components typically follow a cycle:

• The user sends a message through a device/channel.
• The Azure Bot Service receives this message and passes it to the bot.
• Inside the bot, the message goes through connectivity & protocol handling, then enters the pipeline processing.
• The reasoning components work to understand the message (input recognition) and formulate an appropriate response (response generation).
• The response might involve querying or updating storage to maintain context or access relevant data.
• The bot sends the response back through the Azure Bot Service.
• The Azure Bot Service delivers the response to the user through the original device/channel.

This cycle repeats with each user interaction, allowing the bot to have a continuous and context-aware conversation with the user.

HTTP Details

The interaction between a bot and the Bot Framework Service involves a sequence of HTTP POST requests and responses. The bot's responses must acknowledge the requests with a 200 status code, and it's essential to manage the turn context to avoid issues related to context disposal and asynchronous processing. This allows the bot to provide timely and coherent responses to user interactions.

The activity processing stack

The communication between a bot and the Bot Framework Service is based on HTTP POST requests and responses. Here's how the interaction works:

• Inbound Activity: When a user sends a message or interacts with a bot through a messaging channel (e.g., Microsoft Teams, Slack), the channel forwards the user's activity to the Azure AI Bot Service. This service then forwards the activity to the bot's messaging endpoint.
• Bot's Response: The bot processes the inbound activity, which may include user messages or other types of interactions. After processing the activity, the bot generates a response, typically in the form of an activity object.
• HTTP POST Response (Acknowledgment): The bot sends its response back to the Bot Framework Service. The bot must acknowledge the inbound POST request with a 200 HTTP status code. Similarly, when sending activities to the channel, the bot sends an HTTP POST request to the Bot Framework Service, which is also acknowledged with a 200 HTTP status code.
• Nested Request Pattern: While the HTTP protocol doesn't specify the order of these POST requests and their acknowledgments, it's common for these requests to be nested. In other words, the outbound HTTP request (from the bot to the Bot Framework Service) is made within the scope of the inbound HTTP request (from the channel to the bot). This pattern is often used to fit with common HTTP service frameworks.
• Response Time Limit: The bot is expected to respond within a certain time frame. Most channels give the bot 15 seconds to acknowledge the call with a 200 status code. If the bot fails to respond within this time frame, an HTTP Gateway Timeout error (504) occurs.
• Activity Processing Stack: The bot's message processing stack starts with the arrival of an HTTP POST request containing the activity's information as a JSON payload. This request arrives at the bot's web server. Depending on the bot's technology stack, frameworks like ASP.NET, Express (for Node.js), or Restify may be used.
• Adapter and Middleware: The Bot Framework SDK includes an adapter, which is a core component of the runtime. The adapter deserializes the JSON payload to create an activity object and then passes it to the bot through its "process activity" method. The adapter also creates a turn context for handling the activity.
• Turn Context: The turn context provides the mechanism for the bot to send outbound activities in response to an inbound activity. It offers methods like "send," "update," and "delete" for managing responses. These methods run asynchronously, and it's essential to await any activity calls to ensure the primary thread waits for the generated activity before finishing its processing.

Bot templates

Bot templates are pre-configured, reusable project templates and code scaffolding designed to help developers kickstart the creation of chatbots and conversational AI applications. These templates provide a foundation that includes common functionalities and structures, such as message handling, dialog management, and integration with the Bot Framework or other bot development frameworks.