Software intermedio

SE APLICA A: SDK v4

El software intermedio es simplemente una clase que se encuentra entre el adaptador y la lógica del bot, que se agrega a la colección de software intermedio 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 del software intermedio

La pregunta suele aparecer: "¿Cuándo debo implementar acciones como middleware frente al uso de la lógica de bot normal?" 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. También permite almacenar y recuperar información relativa a la conversación y llamar a una lógica de procesamiento adicional cuando sea necesario. A continuación encontrará algunos escenarios comunes que muestran situaciones en las que el middleware puede resultar útil.

Registrar o actuar sobre todas las actividades

Existen muchas situaciones que requieren que un bot haga algo en todas las actividades, o bien en las actividades de un tipo determinado. Por ejemplo, puede que quiera registrar cada actividad de mensaje que recibe el bot o proporcionar una respuesta de reserva si el bot no ha generado una respuesta de otro modo. 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.

Modificar o mejorar el contexto de turno

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

El SDK define el middleware de registro que puede grabar las actividades de entrada y salida, pero el usuario también puede definir su propio middleware.

La canalización de software intermedio del bot

Para cada actividad, el adaptador llama al middleware en el orden en que se ha agregado. El adaptador pasa el objeto de contexto para el turno y un delegado next, y el software intermedio llama al delegado para pasar el control al siguiente software intermedio de la canalización. El software intermedio también puede llevar a cabo acciones después de que se devuelva el delegado next antes de completar el método. Es como si cada objeto de software intermedio tuviese la oportunidad de actuar directamente sobre los objetos de software intermedio que lo siguen en la canalización.

Por ejemplo:

• El primer controlador de turnos del objeto de middleware ejecuta código antes de llamar a siguiente.
  • El segundo controlador de turnos del objeto de middleware ejecuta código antes de llamar a siguiente.
    • 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 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 controladores de turnos de bot o middleware posteriores y a los cortocircuitos de canalización.

Una vez que se ha completado la canalización de software intermedio del bot, el turno acaba y el contexto de turno sale del ámbito.

El software intermedio o el bot pueden generar respuestas y registrar los controladores de eventos de respuesta, pero debe tener en cuenta que las respuestas se controlan en procesos independientes.

Orden del software intermedio

Puesto que el orden en el que se agrega el software intermedio determina el orden en el que este procesa una actividad, es importante decidir la secuencia que se seguirá para agregar dicho software intermedio.

Nota

Esto está pensado para proporcionarle un patrón común que funcione para la mayoría de los bots, pero debe tener en cuenta cómo interactuará cada fragmento de software intermedio con los demás según su situación.

El middleware que se encarga primero de las tareas de nivel más bajo que se deben agregar a cada bot a la canalización de middleware. como 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 almacenar 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 a la canalización de middleware en último lugar, el middleware que implementa para realizar algún procesamiento en cada mensaje enviado al bot. Si el software intermedio usa información de estado u otra información definida en el contexto del bot, agréguela a la canalización de software intermedio después del software intermedio que modifica el estado o el contexto.

Cortocircuitos

Una idea importante relacionada con el middleware y los controladores de respuesta es el cortocircuito. Si la ejecución va a continuar por las capas siguientes, el middleware (o un controlador de respuestas) debe pasar la ejecución mediante una llamada al delegado next. Si no se llama al delegado siguiente dentro de ese middleware (o controlador de respuesta), no se ejecutan los circuitos cortos de canalización asociados y las capas posteriores. lo que significa que se omiten no solo toda la lógica del bot, sino también el middleware posterior de la canalización. Hay una diferencia sutil entre el middleware y el controlador de respuesta cortocircuitando un turno.

Cuando el middleware cortocircuita 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, que es muy diferente de la lógica de omisión del middleware. Al no procesar el resto del evento, el adaptador no lo envía nunca.

Sugerencia

Si provoca un cortocircuito en un evento de respuestas, como SendActivities, asegúrese de que es el comportamiento que tenía previsto. De lo contrario, puede resultar muy difícil solucionar los errores.

Controladores de eventos de respuesta

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

Advertencia

Tenga cuidado de no llamar a un método de respuesta de actividad desde su controlador de eventos de respuesta correspondiente, por ejemplo, mediante una llamada al método de actividad de envío desde un controlador de actividad de envío. Si lo hace, puede generar un bucle infinito.

Recuerde que cada actividad nueva obtiene un nuevo subproceso en el que se ejecuta. Cuando se crea el subproceso para procesar la actividad, la lista de controladores de esa actividad se copia en ese subproceso nuevo. No se ejecutará para ese evento de actividad específico ningún controlador agregado después de ese punto. 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 al llamar al delegado next se pasa el control al siguiente controlador de eventos registrado. Si un controlador no llama al delegado siguiente, no se llama a ninguno de los controladores de eventos posteriores, los cortocircuitos del evento y el adaptador no envía la respuesta al canal.

Control del estado en el middleware

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

El problema con este enfoque es que las actualizaciones de estado realizadas desde algún middleware personalizado que se produzca después de que el controlador de turnos del bot haya devuelto no se guardarán en un almacenamiento duradero. La solución es mover la llamada al método para guardar cambios a después de que el middleware personalizado se haya completado mediante la adición de una instancia del middleware para guardar cambios automáticamente al principio de la pila de middleware, o al menos antes de que cualquiera del estado del middleware se actualice. A continuación se muestra la ejecución.

Agregue los objetos de administración de estado que será necesario actualizar a un objeto conjunto de estados del bot y, después, úselos al crear el middleware para guardar cambios automáticamente.

Recursos adicionales

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