Software intermedio

Se aplica a: SDK v4

El middleware es simplemente una clase que se encuentra entre el adaptador y la lógica del bot, que se agrega a la colección de middleware del adaptador durante la inicialización. El SDK le permite escribir su propio middleware o agregar middleware creado por terceros. Todas las actividades que entran y salen de su bot pasan por el middleware.

El adaptador procesa y dirige las actividades entrantes en a través de la canalización de middleware del bot a la lógica del bot y, a continuación, vuelve a salir. Cuando las actividades entran y salen de los bots, cada fragmento de software intermedio puede inspeccionar o actuar sobre la actividad, tanto antes como después de que se ejecute la lógica del bot.

Antes de pasar al middleware, es importante comprender los bots en general y cómo procesan las actividades.

Usos de middleware

La pregunta suele aparecer: "¿Cuándo debo implementar acciones como middleware frente al uso de la lógica normal del bot?" El middleware proporciona oportunidades adicionales para interactuar con el flujo de conversación de los usuarios tanto antes como después de procesar cada turno de la conversación. El middleware también permite almacenar y recuperar información sobre la conversación y llamar a lógica de procesamiento adicional cuando sea necesario. A continuación se muestran algunos escenarios comunes que muestran dónde puede resultar útil el middleware.

Examinar o actuar en cada actividad

Hay muchas situaciones que requieren que el bot haga algo en cada actividad o para cada actividad de un tipo determinado. Por ejemplo, es posible que quiera registrar todas las actividades de mensaje que recibe el bot o proporcionar una respuesta alternativa si el bot no ha generado una respuesta en este turno. El middleware es un excelente lugar para estos procesos, con su capacidad de actuar tanto antes como después de que se haya ejecutado el resto de la lógica del bot.

Modificación o mejora del contexto de turno

Algunas conversaciones pueden ser mucho más fructificantes si el bot tiene más información de lo que se proporciona en la actividad. En este caso, el middleware podría examinar la información de estado de conversación que tiene hasta ahora, consultar un origen de datos externo y anexarlo al objeto de contexto de turno antes de pasar la ejecución a la lógica del bot.

El SDK define un middleware de registro que puede registrar las actividades entrantes y salientes, pero también puedes definir tu propio middleware.

Flujo de procesos intermedios del bot

Para cada actividad, el adaptador llama al middleware en el orden en que lo agregó. El adaptador pasa el objeto de contexto para el turno y un delegado siguiente , y el middleware llama al delegado para pasar el control al siguiente middleware de la canalización. El middleware también tiene la oportunidad de realizar acciones después de que el delegado siguiente regrese, pero antes de que se complete el método. Imagina que cada objeto de middleware tiene la primera y última oportunidad de actuar en relación con los objetos de middleware que le siguen en la canalización.

Por ejemplo:

• El manejador de turno del primer objeto de middleware ejecuta código antes de llamar a next.
  • El segundo controlador de turnos del objeto de middleware ejecuta código antes de llamar a next.
    • El controlador de turnos del bot se ejecuta y devuelve.
  • El segundo controlador de turnos del objeto de middleware ejecuta cualquier código restante antes de devolverlo.
• El primer controlador de turnos del objeto de middleware ejecuta cualquier código restante antes de devolverlo.

Si el middleware no llama al siguiente delegado, el adaptador no llama a ninguno de los manejadores de turnos de bot o middleware subsecuente y la canalización se interrumpe.

Una vez completada la canalización de middleware del bot, el turno se termina y el contexto del turno sale de alcance.

El middleware o el bot pueden generar respuestas y registrar controladores de eventos de respuesta, pero tenga en cuenta que las respuestas se controlan en procesos independientes.

Orden del middleware

Dado que el orden en el que se agrega middleware determina el orden en el que el middleware procesa una actividad, es importante decidir la secuencia que se debe agregar.

El middleware que se encarga de las tareas de nivel más bajo y que debe ser agregado primero a la canalización de middleware para cada bot. Algunos ejemplos son el registro, el control de excepciones y la traducción. Ordene estos en función de sus necesidades, como si desea que el mensaje entrante se traduzca primero, antes de que se almacenen los mensajes o si el almacenamiento de mensajes debe producirse primero, lo que podría significar que los mensajes almacenados no se traducirían.

El middleware específico del bot debe agregarse al final de la canalización de middleware. Este middleware se implementa para realizar algún procesamiento en cada mensaje enviado a su bot. Si el middleware utiliza información de estado u otra información establecida en el contexto del bot, agrégalo a la canalización de middleware después del middleware que modifique el estado o el contexto.

Cortocircuitos

Una idea importante en torno al middleware y los controladores de respuesta es el cortocircuito. Si se desea que la ejecución continúe a través de las capas que la siguen, se requiere el uso de middleware (o un controlador de respuesta) para transferir la ejecución mediante una llamada a su next delegado. Si no se llama al siguiente delegado dentro de ese middleware (o controlador de respuesta), no se ejecutan los circuitos cortos de canalización asociados ni las capas posteriores. Esto significa que se omite toda la lógica del bot y cualquier intermediario más en el proceso. Hay una diferencia sutil entre que el middleware y el controlador de respuesta interrumpan un turno.

Cuando el middleware interrumpe un turno, no se llamará al controlador de turnos del bot, pero todo el código de middleware ejecutado antes de este punto de la canalización se seguirá ejecutando hasta su finalización.

En el caso de los controladores de eventos, no llamar a next significa que se cancela el evento, lo cual es muy diferente de omitir la lógica de middleware. Al no procesar el resto del evento, el adaptador nunca lo envía.

Controladores de eventos de respuesta

Además de la lógica de la aplicación y del middleware, los controladores de respuesta (también denominados a veces controladores de eventos o controladores de eventos de actividad) se pueden agregar al objeto de contexto. Se llama a estos controladores cuando se produce la respuesta asociada en el objeto de contexto actual, antes de ejecutar la respuesta real. Estos controladores son útiles cuando sabes que querrás hacer algo, ya sea antes o después del evento real, en cada actividad de ese tipo durante el resto de la respuesta actual.

Recuerde que cada nueva actividad recibe un nuevo hilo para ejecutarse. Cuando se crea el subproceso para procesar la actividad, la lista de controladores de esa actividad se copia en ese nuevo subproceso. No se agregarán controladores después de ese punto para ese evento de actividad específico. Los controladores registrados en un objeto de contexto se controlan de forma similar a cómo administra el adaptador la canalización de middleware. Es decir, se llama a los controladores en el orden en que se agregan y la llamada al siguiente delegado pasa el control al siguiente controlador de eventos registrado. Si un controlador no llama al siguiente delegado, ninguno de los controladores de eventos siguientes se llama, el evento se interrumpe y el adaptador no envía la respuesta al canal.

Control del estado en middleware

Un método común para guardar el estado es llamar al método save changes al final del controlador de turnos. Este es un diagrama con un enfoque en la llamada.

El problema con este enfoque es que cualquier actualización de estado realizada desde algún middleware personalizado que ocurra después de que el controlador de turnos del bot haya finalizado no se guardará en el almacenamiento duradero. La solución consiste en mover la llamada al método de guardar cambios a después de que el middleware personalizado se haya completado, agregando una instancia del middleware de autoguardar cambios al principio de la pila de middleware, o al menos antes de cualquier middleware que pueda actualizar el estado. La ejecución se muestra a continuación.

Agregue los objetos de administración de estado que necesitarán actualizar a un objeto de conjunto de estado del bot y después úselo al crear el middleware de cambios de guardado automático.

Recursos adicionales

Puede echar un vistazo al middleware del registrador de transcripciones, tal como se implementa en Bot Framework SDK [C# | JS].