Desencadenador de sondeo
Un desencadenador de sondeo es una implementación que llama regularmente al servicio de API de REST y busca nuevos datos. Una vez que la plataforma ha determinado que hay nuevos datos disponibles, el desencadenador se activa y pasa los nuevos datos recopilados a un flujo de nube o un flujo de trabajo de Logic Apps.
El siguiente diagrama muestra un flujo de proceso básico de cómo un desencadenador de sondeo adquiere nuevos datos.
Un desencadenador de sondeo comienza recuperando los datos y estableciendo un estado. Luego, buscará actualizaciones periódicamente solicitando todos los datos desde la última actualización de estado. Una vez que se han recuperado los nuevos datos, se establece el nuevo estado y el proceso continuará. La API debe poder devolver los datos de forma incremental, en función de un valor de parámetro. Power Automate o Azure Logic Apps mantienen el estado para que la API no tenga requisitos especiales de administración de estado.
A diferencia de un desencadenador de webhook, un desencadenador de sondeo no tiene requisitos de configuración o eliminación, y el procesamiento se puede detener en cualquier momento. La simplicidad de los requisitos es una de las principales ventajas del desencadenador de sondeo.
Requisitos de API
Un desencadenador de sondeo solo requiere que una API tenga un método de recuperación de datos que pueda filtrar los datos mediante un parámetro de cadena de consulta. También debe existir una forma de extraer el siguiente valor del parámetro de los datos devueltos. La implementación la puede proporcionar un método de acción dedicado o existente.
Por ejemplo, considere la implementación de una tienda en línea donde los pedidos tienen números de pedido cada vez mayores. La API de la tienda puede incluir un método llamado ListOrders que devuelva los pedidos que se crearon en la tienda.
ListOrders devuelve los pedidos que están ordenados por número de pedido en orden descendente. Como resultado, el número de pedido más alto pertenece al primer pedido de la lista.
ListOrders acepta un parámetro de cadena de consulta para recuperar los pedidos donde el número de pedido es mayor que el valor del parámetro.
Estas dos cualidades permiten que la acción se utilice como desencadenador de sondeo. La plataforma puede extraer el número de pedido más alto de los datos devueltos y pasarlo como parámetro a la siguiente solicitud. Efectivamente, el método "seleccionará todos los pedidos que se crearon desde el último".
Implementación
Un desencadenador de sondeo se crea mediante un asistente en Power Automate. El proceso incluye los siguientes pasos:
Defina la solicitud HTTP que se utilizará para recuperar los datos.
La cadena de consulta de la solicitud incluye el parámetro fromWidget, que permite la generación previa de la definición del parámetro. Este parámetro asegura que los datos devueltos sean incrementales, que "devolverán todos los widgets que se crearon desde el especificado en el parámetro".
Cambie la visibilidad de los parámetros a interna, lo que evitará que los usuarios realicen cambios en ellos, ya que solo lo usará el conector internamente.
Defina los datos que devuelve el servicio. Estos datos deben incluir la propiedad que se utilizará como valor para fromWidget en las solicitudes consecutivas.
En este ejemplo, la propiedad se llama Id..
Complete la Configuración del desencadenador. Seleccione el parámetro de consulta, defina un valor o expresión que devuelva un valor y luego seleccione una colección que contenga los datos de desencadenador.
En este ejemplo se incluyen los parámetros siguientes:
fromWidget se selecciona como el parámetro de consulta que recibirá el valor extraído de los resultados del laboratorio.
La expresión @{triggerBody().widgets[0].id} extrae el id. del widget más alto. Debido a que la colección devuelta se ordena según el valor de Id. de mayor a menor, al extraer el valor del primer elemento se garantiza que sea el id. más alto actualmente.
La expresión @triggerBody().widgets define la recopilación de datos.
Los parámetros deben extraerse y procesarse, y esta transformación solo se puede implementar mediante una directiva de conector. En consecuencia, la configuración del desencadenador de sondeo se almacena como una plantilla de directiva separada de la definición del conector OpenAPI. Una implicación es que no es posible editar manualmente todas las configuraciones de desencadenador de sondeo en el editor Swagger.
Una limitación que debe tener en cuenta es que el cuerpo del desencadenador no puede ser una matriz. Por ejemplo, considere un método llamado ListOrders que devuelva los siguientes datos:
[
{"value" : 42.00, "id" : "2", ... },
{"value" : 10.00, "id" : "1", ... }
]
El cuerpo del desencadenador no se procesará y el disparador generará un error en el flujo de Power Automate o el flujo de trabajo de Logic Apps en tiempo de ejecución.
En cambio, el método debe devolver una propiedad que contenga la matriz de registros, por ejemplo:
{
"orders": [
{ "value" : 42.00, "id" : "2", ... },
{ "value" : 10.00, "id" : "1", ... }
]
}
Esta estructura de datos se puede utilizar como parte de la implementación del desencadenador de sondeo.
Procesamiento por lotes
Similar a lo que sucede con el desencadenador de webhook, el desencadenador de sondeo lo define la extensión x-ms-trigger para OpenAPI. El valor definido por un desencadenador de sondeo es un lote, lo que indica que el método devolverá una matriz en lugar de un objeto individual, como lo hace en una respuesta de webhook.
/trigger/ListInvoices:
post:
x-ms-trigger: batch
Este proceso ocurre porque es posible tener varios registros que se devuelven desde una sola llamada al servicio. Cuando se utiliza un desencadenador de sondeo en Power Automate o Logic Apps, la opción Dividir en del el desencadenador permite configurar el modo de procesamiento.
La división de la matriz entrante en múltiples implementaciones paralelas se realiza por razones de rendimiento. Cada instancia del flujo de nube en este escenario recibirá un solo objeto. Si la opción Dividir en no está configurada, una sola instancia del flujo de nube recibirá una matriz de valores.
Los activadores de sondeo son más fáciles de definir que los activadores de webhook; sin embargo, son menos granulares y, a menudo, tampoco funcionan. La decisión de crear y utilizar un tipo de activador u otro depende de las características, la estructura y la funcionalidad de la API del servicio.