Conceptos básicos de Microsoft Bot Framework

SE APLICA A: SDK v4

Un bot es una aplicación con la que los usuarios interactúan de forma conversacional mediante texto, gráficos (tarjetas o imágenes) o voz. Servicio de Bot de Azure AI es una plataforma en la nube. Hospeda bots y los pone a disposición de canales como Microsoft Teams, Facebook o Slack.

Bot Framework Service, que es un componente del Servicio de Bot de Azure AI, envía información entre la aplicación del usuario conectada al bot y el bot. Cada canal puede incluir información adicional en las actividades que envía. Antes de crear bots, es importante entender cómo utiliza el bot los objetos de actividad para comunicarse con los usuarios.

En este diagrama se muestran dos tipos de actividad, actualización de conversación y mensaje, que pueden intercambiarse cuando un usuario se comunica con un bot de eco.

Bot Framework Service envía una actualización de conversación cuando una entidad se une a la conversación. Por ejemplo, al iniciar una conversación con Bot Framework Emulator, puede que vea dos actividades de actualización de conversación (una cuando el usuario se une a la conversación y otra cuando se une el bot). Para distinguir entre estas actividades de actualización de conversación, compruebe quién se incluye en la propiedad de miembros agregados de la actividad.

La actividad de mensaje lleva información de la conversación entre las partes. En un ejemplo de bot de eco, las actividades de mensaje llevan texto simple y el canal representará este texto. Como alternativa, la actividad de mensaje podría llevar texto hablado, acciones sugeridas o tarjetas para mostrar.

Sugerencia

Cada canal decide si implementar el protocolo de Bot Framework y la forma de hacerlo podría variar entre los distintos canales. Por ejemplo, algunos canales envían primero las actividades de actualización de conversación y otras envían las actividades de actualización de conversación después de enviar la primera actividad de mensaje. Un canal puede incluir tanto el bot como el usuario en una actividad de actualización de conversación, mientras que otro podría enviar dos actividades de actualización de conversación.

En este ejemplo, el bot crea y envía una actividad de mensaje como respuesta a la actividad de mensaje entrante que ha recibido. Sin embargo, un bot puede responder de otras maneras a una actividad de mensaje recibida y es habitual que un bot responda a una actividad de actualización de conversación enviando una actividad de mensaje con un texto de bienvenida. Para obtener más información, consulte cómo dar la bienvenida a un usuario.

SDK de Bot Framework

El SDK de Bot Framework permite generar bots que se pueden hospedar en Servicio de Bot de Azure AI. El servicio define una API de REST y un protocolo de actividad para determinar cómo pueden interactuar el bot y los canales o los usuarios. El SDK se basa en esta API de REST y proporciona una abstracción del servicio para que pueda centrarse en la lógica conversacional. Aunque no es necesario comprender el servicio de REST para usar el SDK, entender algunas de sus características puede resultar útil.

Los bots son aplicaciones que tienen una interfaz conversacional. Se pueden usar para desplazar las tareas simples y repetitivas, como reservar una mesa en un restaurante o recopilar información de un perfil, a sistemas automatizados que puede que no requieran intervención humana directa. Los usuarios conversan con los bot mediante texto, tarjetas interactivas y la voz. Una interacción con un bot puede ser tanto una pregunta y una respuesta rápidas como una conversación sofisticada que proporciona acceso a servicios de forma inteligente.

Nota:

La compatibilidad con las características proporcionadas por el SDK y la API de REST varía según el canal. Puede probar el bot mediante Bot Framework Emulator, pero también debe probar todas las características del bot en cada canal en el que quiera que el bot esté disponible.

Las interacciones implican el intercambio de actividades, que se controlan por turnos.

Actividades

Cada interacción entre el usuario (o un canal) y el bot se representa como una actividad. El esquema de actividad de Bot Framework define las actividades que se pueden intercambiar entre un usuario o canal y un bot. Las actividades pueden representar voz o texto humano, notificaciones de aplicación a aplicación, reacciones a otros mensajes, etc.

Turnos

En una conversación, la gente a menudo habla de uno en uno, haciendo turnos para hablar. Con un bot, por lo general reacciona a las entradas del usuario. En Bot Framework SDK, un turno consiste en la actividad de la entrada del usuario en el bot y en cualquier actividad que el bot devuelve al usuario como respuesta inmediata. Se puede pensar en un turno como el procesamiento asociado con la llegada de una actividad determinada al bot.

Por ejemplo, un usuario puede pedir a un bot que realice una tarea determinada. El bot puede responder con una pregunta para obtener más información sobre la tarea, en cuyo momento finaliza este turno. En el siguiente turno, el bot recibe un nuevo mensaje del usuario que podría contener la respuesta a la pregunta del bot o podría representar un cambio de tema o una solicitud para omitir la solicitud de la tarea inicial.

Estructura de la aplicación de bot

El SDK define una clase de bot que controla el razonamiento conversacional de la aplicación de bot. La clase de bot:

• Reconoce e interpreta la entrada del usuario.
• Reflexiona sobre la entrada y realiza las tareas pertinentes.
• Genera respuestas sobre lo que el bot está haciendo o ha hecho.

El SDK también define una clase de adaptador que controla la conectividad con los canales. El adaptador:

• Proporciona un método para controlar las solicitudes del canal del usuario y métodos para generar solicitudes en el mismo.
• Incluye una canalización de middleware, que abarca el procesamiento de turnos fuera del controlador de turnos del bot.
• Llama al controlador de turnos del bot y detecta errores que no se gestionan en el controlador de turnos.

Además, los bots suelen necesitar recuperar y almacenar el estado de cada turno. El estado se controla a través de las clases de almacenamiento, estado del bot y descriptor de acceso de propiedades. El SDK no proporciona almacenamiento integrado, pero sí abstracciones para el almacenamiento y algunas implementaciones de una capa de almacenamiento. En el tema de administración del estado se describen estas características de estado y almacenamiento.

El SDK no requiere que use una capa de aplicación específica para enviar y recibir solicitudes web. Bot Framework tiene plantillas y ejemplos para ASP.NET (C#), restify (JavaScript) y aiohttp (Python). Sin embargo, puede optar por usar una capa de aplicación diferente para la aplicación.

Al crear un bot mediante el SDK, se proporciona el código para recibir el tráfico HTTP y reenviarlo al adaptador. Bot Framework proporciona algunas plantillas y ejemplos que puede usar para desarrollar sus propios bots.

Nota:

Los SDK de JavaScript, C# y Python de Bot Framework seguirán siendo compatibles, pero el SDK de Java se va a retirar con la finalización del soporte técnico a largo plazo en noviembre de 2023. Solo se realizarán correcciones de errores y seguridad críticos en este repositorio.

Los bots existentes creados con el SDK de Java seguirán funcionando.

Para la nueva compilación de bots, considere la posibilidad de usar Power Virtual Agents y lea sobre cómo elegir la solución de bot de chat adecuada.

Para obtener más información, consulte El futuro de la construcción de bots.

Lógica del bot

El objeto de bot contiene la lógica o el razonamiento conversacional de un turno y expone un controlador de turnos, que es el método que puede aceptar las actividades entrantes del adaptador del bot.

El SDK proporciona un par de paradigmas diferentes para administrar la lógica del bot.

• Los controladores de actividad proporcionan un modelo controlado por eventos en el que los tipos y subtipos de actividad entrantes son los eventos. Considere utilizar un controlador de actividad para los bots que tienen interacciones cortas y limitadas con el usuario.
  • Use un controlador de actividad e implemente controladores para cada tipo o subtipo de actividad al que el bot reconocerá y reaccionará.
  • Use un controlador de actividad de Teams para crear bots que se puedan conectar al canal de Teams. (El canal de Teams requiere que el bot controle algunos comportamientos específicos del canal).
• La biblioteca de diálogos proporcionan un modelo basado en el estado para administrar una conversación de larga duración con el usuario.
  • Use un controlador de actividad y un diálogo de componente para conversaciones que sean en gran medida secuenciales. Para obtener más información, consulte Acerca de los diálogos de componente y en cascada.
• Implemente su propia clase de bot y proporcione su propia lógica para controlar cada turno. Para ver un ejemplo, consulte cómo crear sus propias solicitudes para recopilar entradas de usuario.

El adaptador de bot

El adaptador tiene un método de actividad de proceso para iniciar un turno.

• Toma el cuerpo de la solicitud (la carga de la solicitud traducida a una actividad) y el encabezado de solicitud como argumentos.
• Comprueba si el encabezado de autenticación es válido.
• Crea un objeto de contexto para el turno. El objeto de contexto incluye información sobre la actividad.
• Envía el objeto de contexto a través de su canalización de middleware.
• A continuación, envía el objeto de contexto al controlador de turnos del objeto de bot.

El adaptador también:

• Da formato y envía actividades de respuesta. Estas respuestas suelen ser mensajes para el usuario, pero también pueden incluir información que el canal del usuario consuma directamente.
• Expone otros métodos proporcionados por la API de REST de Bot Connector, como el mensaje de actualización y el mensaje de eliminación.
• Detecta errores o excepciones que no se detectan en caso contrario durante el turno.

El contexto de turno

El objeto de contexto de turno proporciona información acerca de la actividad, como el remitente y receptor, el canal y otros datos necesarios para procesar la actividad. También permite la adición de información durante el turno en las distintas capas del bot.

El contexto de turno es una de las abstracciones más importantes en el SDK. No solo lleva la actividad de entrada a todos los componentes de middleware y la lógica de la aplicación, sino que también proporciona el mecanismo mediante el cual los componentes de middleware y la lógica del bot pueden enviar actividades de salida.

Software intermedio

El middleware es muy similar a cualquier otro middleware de mensajería, incluye un conjunto lineal de componentes que se ejecutan en orden, dando a cada uno la oportunidad de operar en la actividad. La etapa final de la canalización del middleware es una devolución de llamada al controlador de turnos de la clase del bot que la aplicación ha registrado con el método process activity del adaptador. El middleware implementa un método durante el turno al que llama el adaptador.

El controlador de turnos toma un contexto de turno como argumento, normalmente la lógica de la aplicación que se ejecuta dentro de la función del controlador de turnos procesará el contenido de la actividad de entrada y generará una o varias actividades en respuesta, las cuales se envían con la función send activity en el contexto de turno. Una llamada a send activity en el contexto de turno hará que se invoque a los componentes de middleware en las actividades de salida. Los componentes de middleware se ejecutan antes y después de la función del controlador de turnos del bot. La ejecución es anidada de forma inherente y, por lo tanto, a veces se la compara con una cebolla.

En el tema sobre el middleware se describe esta característica con mayor detalle.

Estado y almacenamiento del bot

Al igual que otras aplicaciones web, un bot no tiene un estado inherente. El estado dentro de un bot sigue los mismos paradigmas que las aplicaciones web modernas, y el SDK de Bot Framework proporciona algunas abstracciones de administración del estado y capas de almacenamiento para facilitar la administración del estado.

En el tema de administración del estado se describen estas características de estado y almacenamiento.

Punto de conexión de mensajería y aprovisionamiento

Normalmente, la aplicación necesitará un punto de conexión de REST en el que recibir mensajes. También tendrá que aprovisionar recursos para el bot de acuerdo con la plataforma que decida usar.

Siga el inicio rápido Creación de un bot para crear y probar un bot de eco simple.

Detalles HTTP

Las actividades llegan al bot desde Bot Framework Service mediante una solicitud POST HTTP. El bot responde a la solicitud POST entrante con un código de estado HTTP 200. Las actividades que se envían desde el bot al canal se envían en una solicitud POST HTTP independiente a Bot Framework Service. Esta se confirma de vuelta con un código de estado HTTP 200.

El protocolo no especifica el orden en el que se realizan estas solicitudes POST y sus confirmaciones. Sin embargo, para ajustarse a los marcos de servicios HTTP comunes, normalmente estas solicitudes se anidan, lo que significa que el bot realiza la solicitud HTTP de salida en el ámbito de la solicitud HTTP de entrada. Este proceso se ilustra en el diagrama anterior. Puesto que hay dos conexiones HTTP distintas consecutivas, se debe proporcionar un modelo de seguridad para ambas.

Nota:

El bot tiene 15 segundos para confirmar la llamada con un estado 200 en la mayoría de los canales. Si el bot no responde en un plazo de 15 segundos, se produce un error HTTP GatewayTimeout (504).

Pila de procesamiento de actividades

Vamos a profundizar en el diagrama de secuencia anterior con el foco puesto en la llegada de una actividad de mensaje.

El canal envía el mensaje del usuario a Servicio de Bot de Azure AI y el servicio reenvía el mensaje al punto de conexión de mensajería del bot. La respuesta del bot se envía al usuario dentro del ámbito del turno.

En el ejemplo anterior, el bot respondió a la actividad de mensaje con otra actividad de mensaje que contenía el mismo mensaje de texto. El procesamiento comienza con la solicitud POST HTTP, con la información de la actividad en forma de una carga JSON que llega al servidor web. Se suelen usar proyectos de ASP.NET para los bots de C# y un marco popular como Express o restify para los bots de Node.js de JavaScript.

El adaptador, un componente integrado del SDK, es el núcleo del entorno de ejecución del SDK. La actividad se realiza como JSON en el cuerpo de la solicitud HTTP POST. Este código JSON se deserializa para crear el objeto de actividad que, a continuación, se pasa al adaptador a través su método para procesar la actividad. Tras la recepción de la actividad, el adaptador crea un contexto de turno y llama al middleware.

Como se ha indicado anteriormente, el contexto de turno proporciona el mecanismo para que el bot envíe las actividades de salida, muy frecuentemente en respuesta a una actividad de entrada. El contexto de turno proporciona métodos de respuesta para enviar, actualizar y eliminar una actividad. Cada método de respuesta se ejecuta en un proceso asincrónico.

Importante

El subproceso que administra el turno de bot principal se ocupa de desechar el objeto de contexto cuando termina. Asegúrese de usar await para las llamadas de actividad, para que el subproceso principal espere la actividad generada antes de finalizar su procesamiento y desechar el contexto de turno. De otro modo, si una respuesta (incluidos sus controladores) tarda mucho e intenta actuar sobre el objeto de contexto, es posible que reciba un error relativo a que el contexto se ha eliminado.

Plantillas de bot

Debe elegir el uso de la capa de aplicación para su aplicación, pero Bot Framework tiene plantillas y ejemplos para ASP.NET (C#), restify (JavaScript) y aiohttp (Python). La documentación se escribe suponiendo que use una de estas plataformas, pero el SDK no lo requiere. Consulte el inicio rápido Creación de un bot para obtener instrucciones sobre cómo acceder a las plantillas e instalarlas.

Un bot es una aplicación web y se proporcionan plantillas para cada idioma del SDK. Todas las plantillas proporcionan una implementación y un adaptador de punto de conexión predeterminados. Cada plantilla incluye lo siguiente:

• Aprovisionamiento de recursos
• La implementación de un punto de conexión HTTP específico del lenguaje que enruta las actividades entrantes a un adaptador.
• Un objeto de adaptador
• Un objeto de bot

La principal diferencia entre los distintos tipos de plantillas se encuentra en el objeto de bot. Las plantillas son las siguientes:

• Bot vacío
  • Incluye un controlador de actividad que da la bienvenida a un usuario en la conversación enviando un mensaje "Hola mundo" en el primer turno de la conversación.
• Bot de eco
  • Usa un controlador de actividad para dar la bienvenida a los usuarios y devolver la entrada del usuario.
• Bot principal
  • Reúne muchas características del SDK y muestra los procedimientos recomendados para un bot.
  • Usa un controlador de actividad para dar la bienvenida a los usuarios.
  • Usa un diálogo de componente y diálogos secundarios para administrar la conversación.
  • Los diálogos usan las características de reconocimiento del lenguaje (LUIS) y QnA Maker.

Nota:

Azure AI QnA Maker se retirará el 31 de marzo de 2025. A partir del 1 de octubre de 2022, no podrá crear nuevos recursos o bases de conocimiento de QnA Maker. Ya hay disponible una versión más reciente de la funcionalidad de preguntas y respuestas como parte de Lenguaje de Azure AI.

La respuesta a preguntas personalizada, una característica de Lenguaje de Azure AI, es la versión actualizada del servicio QnA Maker. Para obtener más información sobre la compatibilidad con preguntas y respuestas en el SDK de Bot Framework, consulte Reconocimiento del lenguaje natural.

Nota:

Reconocimiento del lenguaje (LUIS) se retirará el 1 de octubre de 2025. A partir del 1 de abril de 2023, no podrá crear nuevos recursos de LUIS. Hay disponible una versión más reciente del reconocimiento del lenguaje como parte de Lenguaje de Azure AI.

Reconocimiento del lenguaje conversacional (CLU), una característica del lenguaje de Azure AI, es la versión actualizada de LUIS. Para obtener más información sobre la compatibilidad con reconocimiento del lenguaje en el SDK de Bot Framework, consulte Reconocimiento del lenguaje natural.

Información adicional

Administración de recursos de bot

Deberá administrar los recursos del bot, como el identificador y la contraseña de su aplicación, así como la información de los servicios conectados. Al implementar el bot, necesitará un acceso seguro a esta información. Para evitar la complejidad, la mayoría de los artículos del SDK de Bot Framework no describen cómo administrar esta información.

• Para obtener información general sobre la seguridad, consulte Directrices de seguridad de Bot Framework.
• Para administrar las claves y los secretos de Azure, consulte Acerca de Azure Key Vault.

Adaptadores de canal

El SDK también le permite usar adaptadores de canal, en los que el propio adaptador también realiza las tareas que el servicio Bot Connector haría normalmente para un canal.

El SDK proporciona varios adaptadores de canal en algunos idiomas. Hay más adaptadores de canal disponibles a través de los repositorios Botkit y Community. Para obtener más información, consulte la tabla de canales y adaptadores del repositorio del SDK de Bot Framework.

La API de REST de Bot Connector

El SDK de Bot Framework se ajusta y se basa en la API de REST de Bot Connector. Si desea comprender las solicitudes HTTP subyacentes que admiten el SDK, consulte los artículos de autenticaciónde Connector y otros asociados. Las actividades que envía y recibe un bot se ajustan al esquema de actividad de Bot Framework.

Pasos siguientes

• Para conocer el rol del estado en los bots, consulte el artículo acerca de la administración de estados.
• Para comprender los conceptos clave del desarrollo de bots para Microsoft Teams, consulte Cómo funcionan los bots de Microsoft Teams.