Preguntas frecuentes generales de Bot Framework

Algunos canales no admiten actualizaciones de escritura transitorias en su cliente.

La biblioteca Connector es la exposición de la API REST. La biblioteca Builder agrega el modelo de programación de diálogos conversacionales y otras características como avisos, cascadas, cadenas y relleno guiado de formularios. La biblioteca Builder también proporciona acceso a los servicios de Azure AI, como el reconocimiento del lenguaje natural.

Cuando el usuario envía un mensaje por un canal, el servicio web de Bot Framework emitirá una solicitud HTTPS POST al punto de conexión de servicio web del bot. El bot puede enviar cero, uno o varios mensajes al usuario en ese canal emitiendo una solicitud HTTPS POST independiente a Bot Framework por cada mensaje que envía.

Desde la perspectiva del bot, "reactivo" significa que el usuario inicia la conversación enviando un mensaje al bot y el bot reacciona respondiendo a ese mensaje. En cambio, "proactivo" significa que el bot inicia la conversación enviando el primer mensaje al usuario. Por ejemplo, un bot puede enviar un mensaje proactivo que notifique al usuario cuando un temporizador expira o se produce un evento.

Para obtener ejemplos que muestran cómo enviar mensajes proactivos, consulte los ejemplos de C# V4 y los ejemplos de Node.js V4 del repositorio BotBuilder-Samples en GitHub.

Una ETag es un mecanismo para el control de simultaneidad optimista. El almacenamiento de las bolsas de datos del bot utiliza ETags para evitar actualizaciones conflictivas de los datos. Un error de ETag con el código de estado HTTP 412 "Error de condición previa" indica que se recibieron varios mensajes en paralelo antes de que el bot pudiera finalizar su primera operación. La pila de diálogos y el estado se almacenan en bolsas de datos del bot. Por ejemplo, es posible que vea el error de ETag "Error en la condición previa" si el bot todavía está procesando un mensaje anterior cuando recibe un nuevo mensaje para esa conversación.

El servicio Bot Framework debe protegerse a sí mismo y a sus clientes contra patrones de llamada abusivos (p. ej., ataque por denegación de servicio), de modo que ningún bot pueda afectar negativamente al rendimiento de otros bots. Para lograr este tipo de protección, se han agregado límites de velocidad (también conocidos como limitaciones) a los puntos de conexión. Al aplicar un límite de velocidad, podemos restringir la frecuencia con la que un cliente o un bot pueden realizar una llamada específica. Por ejemplo: al habilitar la limitación de frecuencia, si un bot quiere publicar un gran número de actividades, deberá hacerlo a intervalos durante un período de tiempo. El propósito de limitación de volumen no es limitar el volumen total de un bot. Está diseñado para evitar el abuso de la infraestructura de conversación que no sigue los patrones de conversación humana. Por ejemplo, desbordar dos conversaciones con más contenido de lo que dos personas podrían consumir.

Ajustamos continuamente los límites de velocidad para que sean tan flexibles como sea posible y al mismo tiempo para proteger nuestro servicio y a nuestros usuarios. Dado que en ocasiones los umbrales cambiarán, no publicamos las cifras por el momento. Por último, si hospeda el bot en una instancia de App Service, el bot se enlaza a las limitaciones de App Service. Para más información, consulte Resumen del Acuerdo de Nivel de Servicio para los servicios de Azure Si se ve afectado por la limitación de volumen, no dude en ponerse en contacto con nosotros en bf-reports@microsoft.com.

Algunos canales tienen límites en el tamaño o el tipo de archivos que se pueden enviar. Por ejemplo, Direct Line y Facebook limitan las cargas de actividad a 262 144 bytes, mientras que Bot Framework Emulator no tiene límite. Estos límites se imponen por el canal. Si envía un mensaje que supera este límite, puede obtener un error, como: La longitud del contenido de la solicitud superó el límite de 262 144 bytes. Sin embargo, puede proporcionar un vínculo al recurso como elementos adjuntos de Internet. Para obtener más información sobre el envío de elementos adjuntos, vea cómo agregar elementos multimedia a los mensajes.

Es poco probable que experimente una limitación de volumen, incluso en grandes volúmenes. La mayoría de limitaciones de frecuencia ocurren debido al envío masivo de actividades (desde un bot o desde un cliente), pruebas de carga extrema o un error. Cuando se limita una solicitud, se devuelve una respuesta HTTP 429 (demasiadas solicitudes) junto con un encabezado Retry-After que indica el tiempo (en segundos) que se debe esperar para que el reintento de la solicitud se realice correctamente. Puede recopilar esta información habilitando los análisis para el bot a través de Azure Application Insights. O bien, puede agregar un código en el bot para registrar los mensajes.

La limitación de volumen se debe a cualquiera de las condiciones siguientes:

• Un bot envía mensajes con demasiada frecuencia
• Un cliente de un bot envía mensajes con demasiada frecuencia
• Los clientes de Direct Line solicitan un nuevo socket web con demasiada frecuencia.

En ocasiones, es necesario transferir (entregar) una conversación de un bot a un ser humano, como cuando el bot no entiende al usuario o la solicitud no se puede automatizar. En estos casos, el bot proporciona una transición a los seres humanos. Bot Framework SDK admite la transferencia a un usuario. Hay algunos tipos de eventos para indicar las operaciones de transferencia. Estos eventos se intercambian entre un bot y un centro de agentes, también denominado centro de interacción. Este centro de agentes se define como una aplicación o un sistema que permite a los agentes, normalmente humanos, recibir y controlar solicitudes de usuarios y solicitudes de escalación de bots. Para más información, consulte el artículo Conversaciones de transición un bot a una persona.