Conexión a Azure Service Bus desde Azure flujos de trabajo de Azure Logic Apps

Se aplica a: Azure Logic Apps (consumo + estándar)

En esta guía se muestra cómo acceder a Azure Service Bus desde un flujo de trabajo de Azure Logic Apps mediante el conector de Service Bus. A continuación, puede crear flujos de trabajo automatizados que se ejecuten cuando se desencadenen mediante eventos en una instancia de Service Bus o que ejecuten acciones para administrar elementos de Service Bus, por ejemplo:

• Supervisa los mensajes cuando llegan (autocompletar) o se reciben (bloqueo de información) en las colas, los temas y las suscripciones a los temas.
• Envía mensajes.
• Crea y elimina suscripciones a temas.
• Administra los mensajes de las colas y las suscripciones a temas, por ejemplo, realiza acciones como obtener, obtener los aplazados, completar, aplazar, abandonar y administrar los mensajes fallidos.
• Renueva los bloqueos de mensajes y sesiones en las colas y suscripciones a temas.
• Cierra sesiones en las colas y los temas.

Puede usar desencadenadores que obtengan respuestas de Azure Service Bus y pongan la salida a disposición de otras acciones en los flujos de trabajo. También puede hacer que otras acciones usen la salida de las de Service Bus.

Referencia técnica del conector

El conector de Service Bus tiene diferentes versiones, en función del tipo de flujo de trabajo de la aplicación lógica y del entorno de host.

Requisitos previos

• Una cuenta y una suscripción de Azure. Si no tiene una suscripción de Azure, regístrese para obtener una cuenta gratuita de Azure.

• Un espacio de nombres de Service Bus y una entidad de mensajería, como una cola. Para más información, revise la siguiente documentación:

  • Creación de un espacio de nombres de Service Bus

  • Creación de un espacio de nombres de Service Bus y una cola

  • Creación de un espacio de nombres de Service Bus y un tema con suscripción

• Flujo de trabajo de la aplicación lógica donde se conecta el espacio de nombres de Service Bus y la entidad de mensajería. Para iniciar el flujo de trabajo mediante un desencadenador de Service Bus, deberá empezar con un flujo de trabajo en blanco. Para usar una acción de Service Bus en el flujo de trabajo, inícielo con cualquier desencadenador.

• Si el recurso de aplicación lógica usa una identidad administrada para autenticar el acceso al espacio de nombres y a la entidad de mensajería de Service Bus, asegúrese de que ha asignado permisos de rol en los niveles correspondientes. Por ejemplo, para acceder a una cola, la identidad administrada requiere un rol con los permisos necesarios para esa cola.

  • Cada recurso de aplicación lógica debe usar solo una identidad administrada, incluso si el flujo de trabajo de la aplicación lógica accede a diferentes entidades de mensajería.

  • Cada identidad administrada que tenga acceso a una cola o una suscripción a temas debe usar su propia conexión de API de Service Bus.

  • Las operaciones de Service Bus que intercambian mensajes con diferentes entidades de mensajería y requieren permisos diferentes deben usar sus propias conexiones de API de Service Bus.

  Para más información sobre las identidades administradas, consulte Autenticación del acceso a los recursos de Azure con identidades administradas en Azure Logic Apps.

• De manera predeterminada, las operaciones del conector integrado de Service Bus son sin estado. Para ejecutar estas operaciones en modo con estado, consulte Habilitación del modo con estado para conectores integrados sin estado.

Consideraciones sobre las operaciones de Azure Service Bus

Bucles infinitos

Límite de sesiones guardadas en la memoria caché del conector

Por entidad de mensajería de Service Bus, como una suscripción o un tema, el conector de Service Bus puede ahorrar hasta 1500 sesiones únicas a la vez en la memoria caché del conector. Si el número de sesiones supera este límite, las sesiones antiguas se quitan de la caché. Para más información, consulte Sesiones de mensajes.

Envío de mensajes correlacionados en orden

Cuando necesite enviar mensajes relacionados en un orden específico, puede crear un flujo de trabajo mediante el conector de Service Bus y el patrón de convoy secuencial. Los mensajes correlacionados tienen una propiedad que define la relación entre esos mensajes, como el identificador de la sesión en Azure Service Bus.

Al crear un flujo de trabajo de aplicación lógica de consumo, puede seleccionar la plantilla Entrega ordenada y correlacionada mediante sesiones de Service Bus, que implementa el patrón de convoy secuencial. Para más información, vea Enviar mensajes relacionados en orden.

Compatibilidad con mensajes grandes

La compatibilidad con los mensajes grandes solo está disponible para los flujos de trabajo estándar cuando se usan las operaciones del conector integrado de Service Bus. Por ejemplo, puede recibir y enviar mensajes grandes mediante los desencadenadores y acciones integrados, respectivamente.

Para el conector administrado de Service Bus, el tamaño máximo del mensaje se limita a 1 MB, incluso cuando se usa un espacio de nombres de Service Bus de nivel Premium.

Aumento del tiempo de espera para recibir y enviar mensajes

En los flujos de trabajo estándar que usan las operaciones integradas de Service Bus, puede aumentar el tiempo de espera para recibir y enviar mensajes. Por ejemplo, para aumentar el tiempo de espera para recibir un mensaje, cambie la siguiente configuración en la extensión de Azure Functions:

{
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "serviceBus": {
         "batchOptions": {
            "operationTimeout": "00:15:00"
         }
      }  
   }
}

Para aumentar el tiempo de espera para enviar un mensaje, agregue la configuración de la aplicación ServiceProviders.ServiceBus.MessageSenderOperationTimeout.

Desencadenadores del conector administrado de Service Bus

• Para el conector administrado de Service Bus, todos los desencadenadores son sondeos largos. Este tipo de desencadenador procesa todos los mensajes y espera 30 segundos a que aparezcan más en la suscripción del tema o la cola. Si no es el caso, se omite la ejecución del desencadenador. De lo contrario, el desencadenador sigue leyendo mensajes hasta que la suscripción del tema o de la cola se queda vacía. El siguiente sondeo del desencadenador se basa en el intervalo de periodicidad especificado en las propiedades del desencadenador.

• Algunos desencadenadores, como Cuando llegan uno o más mensajes a una cola (autocompletar), pueden devolver uno o más mensajes. Cuando se activan estos desencadenadores, devuelven entre uno y el número de mensajes especificados por la propiedad Recuento máximo de mensajes del desencadenador.

  Nota:

  El desencadenador de autocompletar completa automáticamente un mensaje, pero el completado solo se produce en la siguiente llamada a Service Bus. Este comportamiento afecta al diseño de la aplicación lógica. Por ejemplo, evite cambiar la simultaneidad en el desencadenador de Autocompletar, ya que este cambio podría duplicar mensajes si el flujo de trabajo pasa a estado limitado. Al cambiar el control de simultaneidad se crean las condiciones siguientes:

  • Los desencadenadores limitados se omiten con el código WorkflowRunInProgress.

  • La operación de finalización no se ejecuta.

  • La siguiente ejecución del desencadenador se produce después del intervalo de sondeo.

  Debe establecer la duración del bloqueo de Service Bus en un valor que sea mayor que el intervalo de sondeo. Pero, a pesar de esta configuración, el mensaje todavía podría no completarse si el flujo de trabajo permanece en un estado limitado en el siguiente intervalo de sondeo.

  Sin embargo, si activa la configuración de simultaneidad de un desencadenador de Service Bus, el valor predeterminado de la propiedad maximumWaitingRuns es 10. Según la configuración de duración de bloqueo de la entidad de Service Bus y la duración de la ejecución del flujo de trabajo, este valor predeterminado podría ser demasiado grande y podría producir una excepción de tipo "bloqueo perdido". Para encontrar el valor óptimo para su escenario, inicie las pruebas con un valor de 1 o 2 para la propiedad maximumWaitingRuns. Para cambiar el valor máximo de ejecuciones en espera, revise Cambio del límite de ejecuciones de espera.

Desencadenadores del conector integrado de Service Bus

Para el conector integrado Service Bus, los desencadenadores que no son de sesión siguen un patrón de desencadenador de sondeo continuo que el conector administra completamente. Este patrón hace que el desencadenador compruebe constantemente si hay mensajes en la cola o en la suscripción de tema. Los desencadenadores de sesión siguen el patrón de desencadenador de sondeo largo, y su configuración se rige por la configuración de Azure Functions denominada clientRetryOptions:tryTimeout. Actualmente, las opciones de configuración del desencadenador integrado de Service Bus se comparten entre la extensión de host de Azure Functions, que se define en el archivo host.json de la aplicación lógica y la configuración de desencadenador definida en el flujo de trabajo de la aplicación lógica, que puede configurar a través del diseñador o la vista de código. En esta sección se tratan ambas ubicaciones de configuración.

• En flujos de trabajo estándar, algunos desencadenadores, como el desencadenador de cuando los mensajes están disponibles en una cola, pueden devolver uno o varios mensajes. Cuando se activan estos desencadenadores, devuelven entre uno y el número de mensajes. Para este tipo de desencadenador y donde no se admite el parámetro Maximum message count, todavía puede controlar el número de mensajes recibidos mediante la propiedad maxMessageBatchSize en el archivo host.json. Para encontrar este archivo, consulte Edición de la configuración del host y la aplicación para aplicaciones lógicas estándar.

  "extensions": {
    "serviceBus": {
        "maxMessageBatchSize": 25
    }
  }
  

• También puede habilitar la simultaneidad en el desencadenador de Service Bus, ya sea mediante el diseñador o en el código:

  "runtimeConfiguration": {
      "concurrency": {
          "runs": 100
      }
  }
  

  Al configurar la simultaneidad mediante un lote, mantenga el número de ejecuciones simultáneas mayores que el tamaño total del lote. De este modo, los mensajes de lectura no entran en un estado de espera y siempre se recogen cuando se leen. En algunos casos, el desencadenador puede tener hasta dos veces el tamaño del lote.

• Si habilita la simultaneidad, el límite SplitOn se reduce a 100 elementos. Este comportamiento es cierto para todos los desencadenadores, no solo para el desencadenador de Service Bus. Asegúrese de que el tamaño de lote especificado sea menor que este límite en cualquier desencadenador en el que habilite la simultaneidad.

• Existen algunos escenarios en los que el desencadenador puede superar la configuración de simultaneidad. En lugar de producir un error en estas ejecuciones, Azure Logic Apps las pone en cola en un estado de espera hasta que se puedan iniciar. El valor maximumWaitingRuns controla el número de ejecuciones permitidas en el estado de espera:

  "runtimeConfiguration": {
      "concurrency": {
          "runs": 100,
          "maximumWaitingRuns": 50
      }
  }
  

  Con el desencadenador de Service Bus, asegúrese de probar cuidadosamente estos cambios para que las ejecuciones no esperen más tiempo que el tiempo de espera del bloqueo de mensajes. Para obtener más información sobre los valores predeterminados, consulte Límites de simultaneidad y separación de lotes aquí.

• Si habilita la simultaneidad, existe un retraso de 30 segundos entre lecturas por lotes, de forma predeterminada. Este retraso ralentiza el desencadenador para lograr los siguientes objetivos:

  • Reducir el número de llamadas de almacenamiento enviadas para comprobar el número de ejecuciones en las que se va a aplicar la simultaneidad.

  • Imitar el comportamiento del desencadenador del conector administrado de Service Bus, que tiene un sondeo que dura 30 segundos cuando no se encuentra ningún mensaje.

  Puede cambiar este retraso, pero asegúrese de probar cuidadosamente los cambios en el valor predeterminado:

  "workflow": {
      "settings": {
          "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30"
      }
  }
  
  

Paso 1: Comprobación del acceso al espacio de nombres de Service Bus

Para confirmar que el recurso de la aplicación lógica tiene permisos para acceder al espacio de nombres de Service Bus, siga estos pasos:

1. En Azure Portal, abra el espacio de nombres de Service Bus.

2. En el menú del espacio de nombres, en Configuración, seleccione Directivas de acceso compartido. En Notificaciones, compruebe que tenga permisos de Administrador para ese espacio de nombres.

   

Paso 2: Obtención de los requisitos de autenticación de conexión

Más adelante, al agregar un desencadenador o una acción de Service Bus por primera vez, se le pedirá la información de conexión, incluido el tipo de autenticación de conexión. En función del tipo de flujo de trabajo de la aplicación lógica, la versión del conector de Service Bus y el tipo de autenticación seleccionado, necesitará los siguientes elementos:

Autenticación del conector administrado (flujos de trabajo estándar y de consumo)

Autenticación de conector integrada (solo flujos de trabajo estándar)

Obtención de la cadena de conexión para el espacio de nombres de Service Bus

Para crear una conexión al agregar un desencadenador o una acción de Service Bus, debe tener la cadena de conexión para el espacio de nombres de Service Bus. La cadena de conexión comienza con el prefijo sb://.

1. En Azure Portal, abra el espacio de nombres de Service Bus.

2. En el menú del espacio de nombres, en Configuración, seleccione Directivas de acceso compartido.

3. En el panel Directivas de acceso compartido, seleccione RootManageSharedAccessKey.

4. Al lado de la cadena de conexión principal o secundaria, seleccione el botón de copia.

   

   Nota:

   Para comprobar que la cadena es para el espacio de nombres, no para una entidad de mensajería específica, busque el parámetro EntityPath en la cadena de conexión. Si lo encuentra, la cadena de conexión es para una entidad específica y no es correcta para el flujo de trabajo.

5. Guarde la cadena de conexión para usarla más adelante.

Obtención de la dirección URL del punto de conexión para el espacio de nombres de Service Bus

Si usa el conector administrado de Service Bus, necesitará esta dirección URL del punto de conexión si selecciona el tipo de autenticación para la identidad integrada de Microsoft Entra o la identidad administrada de Logic Apps. La dirección URL del punto de conexión comienza con el prefijo sb://.

1. En Azure Portal, abra el espacio de nombres de Service Bus.

2. En el menú del espacio de nombres, en Configuración, seleccione Propiedades.

3. En Propiedades, junto al punto de conexión de Service Bus, copie la dirección URL del punto de conexión y guárdela para su uso posterior cuando tenga que proporcionarla.

Obtención del nombre completo para el espacio de nombres de Service Bus

1. En Azure Portal, abra el espacio de nombres de Service Bus.

2. En el menú del espacio de nombres, seleccione Información general.

3. En el panel Información general, busque la propiedad Nombre de host y copie el nombre completo, que tiene el aspecto <su-espacio-de-nombres-de-Service-Bus>.servicebus.windows.net.

Paso 3: opción 1: incorporación de un desencadenador de Service Bus

Aunque en los siguientes pasos se usa Azure Portal, también puede usar las siguientes herramientas para crear flujos de trabajo de aplicaciones lógicas si usa la extensión Azure Logic Apps adecuada:

• Flujos de trabajo de aplicaciones lógicas basados en consumo: Visual Studio o Visual Studio Code

• Flujos de trabajo de aplicaciones lógicas estándar: Visual Studio Code

Paso 3: opción 2: incorporación de una acción de Service Bus

Aunque en los siguientes pasos se usa Azure Portal, también puede usar las siguientes herramientas para crear flujos de trabajo de aplicaciones lógicas si usa la extensión Azure Logic Apps adecuada:

• Flujos de trabajo de aplicaciones lógicas basados en consumo: Visual Studio o Visual Studio Code

• Flujos de trabajo de aplicaciones lógicas estándar: Visual Studio Code

Configuración de la aplicación de conector integrada de Service Bus

En un recurso de aplicación lógica estándar, el conector integrado de Service Bus incluye la configuración de la aplicación que controla varios umbrales, como el tiempo de espera para enviar mensajes y el número de remitentes de mensajes por núcleo de procesador en el grupo de mensajes. Para más información,consulte Referencia de la configuración de aplicación: - local.settings.json.

Lectura de mensajes de colas de mensajes fallidos con desencadenadores integrados de Service Bus

En los flujos de trabajo estándar, para leer un mensaje de una cola de mensajes fallidos en una cola o una suscripción de tema, siga estos pasos con los desencadenadores especificados:

1. En el flujo de trabajo en blanco, en función de su escenario, agregue el desencadenador de conector integrado denominado Cuando los mensajes estén disponibles en una cola o Cuando un mensaje esté disponible en una suscripción de tema (inspección y bloqueo).

2. En el desencadenador, establezca los siguientes valores de parámetro para especificar la cola de mensajes fallidos predeterminada de la suscripción de tema o de la cola, a la que puede acceder como a cualquier otra cola:

   • Cuando los mensajes están disponibles en un desencadenador de cola: establezca el parámetro Nombre de cola en queuename/$deadletterqueue.

   • Cuando un mensaje está disponible en un desencadenador de suscripción a temas (inspección y bloqueo): establezca el parámetro Nombre del tema en topicname/Subscriptions/subscriptionname/$deadletterqueue.

   Para más información, consulte Introducción a las colas de mensajes fallidos de Service Bus.

Solución de problemas

Retrasos en el efecto de las actualizaciones del flujo de trabajo

Si el intervalo de sondeo de un desencadenador de Service Bus es pequeño —por ejemplo, 10 segundos— es posible que las actualizaciones del flujo de trabajo no surtan efecto hasta una vez transcurridos 10 minutos. Para solucionar este problema, puede deshabilitar el recurso de aplicación lógica, realizar los cambios y volver a habilitar el recurso de aplicación lógica.

No hay ninguna sesión disponible o podría estar bloqueada por otro receptor

En ocasiones, las operaciones como completar un mensaje o renovar una sesión producen el siguiente error:

{
  "status": 400,
  "error": {
    "message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
  }
}

En ocasiones, es posible que se produzca un error en un desencadenador basado en sesión con el siguiente error:

{
  "status": 400,
  "error": {
    "message": "Communication with the Service Bus namespace 'xxxx' and 'yyyy' entity failed. The requested session 'zzzz' cannot be accepted. It may be locked by another receiver."
  }
}

El conector de Service Bus usa el caché en memoria para admitir todas las operaciones asociadas a las sesiones. El receptor de mensajes de Service Bus se almacena en caché en la memoria de la instancia de rol (máquina virtual) que recibe los mensajes. Para procesar todas las solicitudes, todas las llamadas a la conexión se enrutan a esta misma instancia de rol. Este comportamiento es necesario porque todas las operaciones de Service Bus de una sesión requieren el mismo receptor que recibe los mensajes de una sesión específica.

Debido a motivos como una actualización de la infraestructura, la implementación del conector, etc., existe la posibilidad de que las solicitudes no se enruten a la misma instancia de rol. Si se produce este evento, se produce un error en las solicitudes por uno de los siguientes motivos:

• El receptor que realiza las operaciones en la sesión no está disponible en la instancia de rol que atiende la solicitud.

• La nueva instancia de rol intenta obtener la sesión, que agota el tiempo de espera en la instancia de rol anterior o no se cerró.

Mientras ocurra solo de manera ocasional, este error está dentro de lo esperado. Cuando se produce el error, el mensaje todavía se conserva en Service Bus. El siguiente desencadenador o ejecución de flujo de trabajo intenta volver a procesar el mensaje.

Pasos siguientes

• Desencadenadores y acciones integrados para Logic Apps
• Conectores integrados para Azure Logic Apps
• ¿Qué son los conectores en Azure Logic Apps?