Подключение к Службе шины Azure из рабочих процессов в Azure Logic Apps

Область применения: Azure Logic Apps (Потребление + Стандарт)

В этом руководстве показано, как получить доступ к ресурсам служебной шины в служебной шине Azure из рабочих процессов автоматизации и интеграции в Azure Logic Apps с помощью соединителя служебной шины. События шины обмена сообщениями могут запускать рабочий процесс или выполнять действия, которые взаимодействуют с элементами шины обмена сообщениями, например:

• Отслеживание момента прибытия (автозавершение) или получения сообщений (с блокировкой при извлечении) в очередях, темах и подписках на темы.
• Отправляет сообщения.
• Создает и удаляет подписки на разделы.
• Управляет сообщениями в очередях и подписках на разделы, например, выполняет такие действия, как получение сообщения, получение отложенного сообщения, заполнение, отложение, прерывание и размещение недоставленных сообщений.
• Обновите блокировки на сообщения и сеансы в очередях и подписках на темы.
• Закрывает сеансы в очередях и разделах.

Вы можете использовать триггеры и действия, которые получают ответы из служебной шины Azure, а затем сделать выходные данные доступными для других действий в рабочих процессах.

Технический справочник по соединителю

Соединитель Service Bus имеет разные версии, основанные на типе рабочего процесса логического приложения и среде размещения.

Предварительные условия

• Учетная запись и подписка Azure. Получите бесплатную учетную запись Azure.

• Пространство имен служебной шины и сущность обмена сообщениями, например очередь.

  Дополнительные сведения можно найти здесь

  • Создайте пространство имен служебной шины
  • Создайте пространство имен и очередь для служебной шины
  • Создать пространство имен и тему Service Bus с подпиской

• Ресурс приложения логики и рабочий процесс, в котором требуется получить доступ к пространству имен служебной шины и сущности обмена сообщениями.

  • Чтобы запустить рабочий процесс с триггером служебной шины, создайте пустой рабочий процесс. Чтобы использовать действие служебной шины в рабочем процессе, запустите рабочий процесс с любым триггером, который лучше всего подходит для вашего сценария.

  • Если ресурс логического приложения использует управляемое удостоверение для аутентификации доступа к пространству имен служебной шины и объекта обмена сообщениями, назначьте необходимые разрешения роли на соответствующих уровнях. Например, для доступа к очереди управляемой учетной записи требуется роль с необходимыми разрешениями для этой очереди.

    • Каждый ресурс логического приложения может использовать только одно управляемое удостоверение, даже если рабочий процесс логического приложения обращается к различным сущностям для обмена сообщениями.

    • Каждое управляемое удостоверение, которое имеет доступ к подписке очереди или подписке на тему, должно использовать собственное подключение к API служебной шины.

    • Каждая операция служебной шины, которая обменивается сообщениями с различными сущностями обмена сообщениями и требует различных разрешений, необходимо использовать собственное подключение API служебной шины.

    Дополнительные сведения об управляемых удостоверениях см. в статье "Проверка подлинности доступа к ресурсам Azure с помощью управляемых удостоверений в Azure Logic Apps".

• По умолчанию встроенные операции соединителя служебной шины являются без состояния. Чтобы выполнять эти операции в режиме отслеживания состояния, см. раздел "Включить режим отслеживания состояния для встроенных соединителей без возможности отслеживания состояния".

Рекомендации по работе с Azure Service Bus

Бесконечные циклы

Ограничение на сохраненные сеансы в кэше соединителей

Для каждой сущности обмена сообщениями служебной шины, например подписки или топика, коннектор служебной шины может сохранять до 1500 уникальных сеансов в кэше коннектора. Если число сеансов превышает это ограничение, кэш соединителя удаляет старые сеансы. Дополнительные сведения см. в статье Сеансы обмена сообщениями.

Отправка коррелированных сообщений по порядку

Когда нужно отправлять связанные сообщения в определенном порядке, создайте рабочий процесс с помощью соединителя служебной шины и последовательного шаблона конвоя. Коррелированные сообщения имеют свойство, которое определяет связь между этими сообщениями, например, идентификатор сеанса в Azure Service Bus.

При создании рабочего процесса приложения логики потребления можно выбрать коррелированную доставку по заказу с помощью шаблона сеансов служебной шины, который реализует шаблон последовательного конвоя. Дополнительные сведения см. в разделе Отправка связанных сообщений по порядку.

Поддержка больших сообщений

Поддержка больших сообщений имеется только для стандартных рабочих процессов при использовании встроенного соединителя Service Bus. Например, вы можете получать и обрабатывать большие сообщения с помощью встроенных триггеров и действий соответственно.

Для управляемого соединителя Service Bus максимальный размер сообщения ограничен 1 МБ, даже если вы используете пространство имен Service Bus уровня "Премиум".

Увеличение времени ожидания для получения и отправки сообщений

В стандартных рабочих процессах, которые используют встроенные операции Service Bus, можно увеличить время ожидания для получения и отправки сообщений. Например, чтобы увеличить время ожидания получения сообщения, измените параметр в следующем примере кода в расширении Функций Azure:

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

Чтобы увеличить время ожидания отправки сообщения, добавьте параметр приложения ServiceProviders.ServiceBus.MessageSenderOperationTimeout.

триггеры управляемых соединителей для служебной шины

Все триггеры управляемого коннектора Service Bus используют шаблон длинного опроса. Этот тип триггера обрабатывает все сообщения, а затем ожидает 30 секунд, чтобы больше сообщений отображалось в очереди или подписке раздела. Если на протяжении 30 секунд новые сообщения не поступают, триггер больше не срабатывает. В противном случае триггер продолжит считывать сообщения, пока очередь или подписка на тему не опустеет. Следующий опрос триггера основывается на интервале повторения, установленном в свойствах триггера.

Некоторые триггеры возвращают одно или несколько сообщений, например триггер Когда одно или несколько сообщений поступает в очередь (автозавершение). Когда такие триггеры срабатывают, они возвращают от одного до нескольких сообщений. Количество сообщений определяется в свойстве триггера Максимальное число сообщений.

Service Bus: встроенные триггеры соединителя

Для встроенного соединителя служебной шины триггеры без сеанса соответствуют шаблону триггера непрерывного опроса , который соединитель полностью управляет. В этом шаблоне триггер постоянно проверяет наличие сообщений в очереди или подписке на раздел. Напротив, триггеры сессий следуют схеме триггера длинного опроса. Параметр Функций Azure, clientRetryOptions:tryTimeout, управляет их конфигурацией. Расширение узла Функций Azure, определённое в файле host.json вашего приложения логики, и настройки триггера, заданные в рабочем процессе вашего приложения логики, которые вы настроили с помощью конструктора или представления кода, совместно используют параметры конфигурации встроенного триггера служебной шины. В этом разделе рассматриваются оба расположения параметров. Обратите внимание на следующие детали о триггерах Service Bus.

• Некоторые встроенные триггеры, такие как "Когда сообщения доступны в триггере очереди ", могут возвращать одно или несколько сообщений. При срабатывании этих триггеров они возвращают количество сообщений в диапазоне от одного до заданного числа.

• Встроенный триггер с именем "Когда сообщения доступны в очереди ( версия 1) не поддерживает параметр с именем "Максимальный размер пакета сообщений". Если этот параметр используется, вместо этого необходимо использовать версию 2. Чтобы использовать триггер, в котором параметр не поддерживается, можно управлять количеством сообщений, полученных путем добавления maxMessageBatchSize параметра в определение триггера в файле host.json . Чтобы найти этот файл, см. раздел "Изменение параметров узла и приложения для логических приложений Standard".

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

• Вы можете включить параллелизм в триггере служебной шины либо с помощью конструктора, либо в коде, например:

  "runtimeConfiguration": {
     "concurrency": {
          "runs": 50
      }
  }
  

  • Если вы настроили параллелизм с помощью пакета, сохраните число параллельных запусков больше общего размера пакета. Таким образом, прочитанные сообщения не переходят в состояние ожидания и всегда обрабатываются при чтении. В некоторых случаях триггер может иметь размер вдвое больший, чем размер пакета.

  • Если включить параллелизм в триггере с именем Когда сообщения доступны в очереди (V1), и вы отправляете в очередь 100 или более сообщений, триггер направляет все сообщения в очередь недоставленных сообщений.

  • Если включить параллелизм, ограничение на обсуждение или разделение поведения уменьшается до 100 элементов. Это поведение верно для всех триггеров, а также для триггера Service Bus. Убедитесь, что указанный размер пакета меньше этого ограничения для любого триггера, в котором можно включить параллелизм.

  • Если включить параллелизм, по умолчанию между считыванием пакета существует задержка в 30 секунд. Эта задержка замедляет триггер для достижения следующих целей:

    • Уменьшите количество вызовов хранилища, отправляемых для проверки количества запусков, к которым применяется параллелизм.

    • Имитируйте поведение триггера управляемого соединителя Service Bus, который делает 30-секундный опрос, когда сообщения не найдены.

      Хотя эту задержку можно изменить, убедитесь, что вы тщательно протестируете все изменения в значении по умолчанию:

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

  • Некоторые сценарии существуют, когда триггер может превышать параметры параллелизма. Вместо сбоя этих запусков Azure Logic Apps помещает их в ожидание до тех пор, пока они не будут запущены. Параметр maximumWaitingRuns определяет количество запусков, разрешенных в состоянии ожидания:

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

    С помощью триггера служебная шина убедитесь, что вы тщательно протестируете эти изменения, чтобы запуски не ждали больше времени ожидания, чем время ожидания блокировки сообщения. Дополнительные сведения о значениях по умолчанию см. в разделе "Ограничения параллелизма и отмены пакетной обработки".

Шаг 1. Проверьте доступ к пространству имен Service Bus.

Чтобы убедиться, что ресурс приложения логики имеет разрешения на доступ к пространству имен служебной шины, выполните следующие действия.

1. В портале Azure откройте пространство имен служебной шины.

2. На боковой панели пространства имен в разделе "Параметры" выберите политики общего доступа. В разделе Утверждения убедитесь, что у вас есть разрешения на управление для этого пространства имен.

   

Шаг 2. Получение требований к проверке подлинности подключения

При первом добавлении триггера или действия служебной шины вам будет предложено получить сведения о подключении, включая тип проверки подлинности подключения. В зависимости от типа рабочего процесса приложения логики, версии соединителя служебной шины и выбранного типа проверки подлинности вам потребуются элементы, описанные в следующих разделах.

Аутентификация управляемого соединителя (потребительская и стандартная схемы рабочих процессов)

Встроенная проверка подлинности соединителя (только стандартные рабочие процессы)

Получение строки подключения для пространства имен Service Bus

Чтобы создать подключение при добавлении триггера или действия служебной шины, вам потребуется строка подключения для пространства имен служебной шины. Строка подключения начинается с префикса sb://.

1. В портале Azure откройте пространство имен служебной шины.

2. На боковой панели пространства имен в разделе "Параметры" выберите политики общего доступа.

3. В области Политики общего доступа щелкните RootManageSharedAccessKey.

4. Рядом с основной или вторичной строкой подключения выберите кнопку копирования.

   

   Примечание.

   Чтобы убедиться, что строка используется для пространства имен, а не для определенной сущности обмена сообщениями, выполните поиск строки подключения для EntityPath параметра. Если вы найдете этот параметр, строка подключения предназначена для определенной сущности и не является правильной строкой для использования с рабочим процессом.

5. Сохраните строку подключения для дальнейшего использования.

Получение URL-адреса конечной точки для пространства имен Service Bus

Если вы используете управляемый соединитель Service Bus, этот URL-адрес конечной точки требуется, если выбрать тип проверки подлинности для интегрированного с Microsoft Entra или управляемого удостоверения Logic Apps, интегрированного с Microsoft Entra. "URL конечной точки начинается с sb:// префикса."

1. В портале Azure откройте пространство имен служебной шины.

2. На боковой панели пространства имен разверните раздел Параметры, а затем выберите Свойства.

3. В разделе Essentials рядом с идентификатором скопируйте и сохраните URL-адрес конечной точки для последующего использования.

Получить полное имя для пространства имен Service Bus

1. В портале Azure откройте пространство имен служебной шины.

2. На боковой панели пространства имен выберите "Обзор".

3. На странице «Обзор» разверните раздел Essentials и найдите свойство Имя хоста.

4. Скопируйте и сохраните полное имя, которое выглядит как <your-Service-Bus-namespace.servicebus.windows.net> для последующего использования.

Шаг 3. Вариант 1. Добавление триггера Service Bus

Следующие действия используют портал Azure, но с помощью соответствующего расширения Azure Logic Apps можно использовать Visual Studio Code для создания рабочих процессов приложения логики:

• Рабочие процессы потребления: создание рабочих процессов приложения логики потребления с помощью Visual Studio Code
• Стандартные рабочие процессы: Создание рабочих процессов стандартного логического приложения с помощью Visual Studio Code

Шаг 3. Вариант 2. Добавить действие для службы шина сообщений

Следующие действия используют портал Azure, но с помощью соответствующего расширения Azure Logic Apps можно использовать Visual Studio Code для создания рабочих процессов приложения логики:

• Рабочие процессы потребления: создание рабочих процессов приложения логики потребления с помощью Visual Studio Code
• Стандартные рабочие процессы приложений логики: создание процессов уровня Standard с помощью Visual Studio Code

Встроенные параметры приложения для соединителя Service Bus

В ресурсе приложения логики уровня "Стандартный" встроенный соединитель служебной шины включает параметры приложения, которые управляют различными пороговыми значениями. Например, эти параметры определяют время ожидания отправки сообщений и количество отправителей сообщений на ядро процессора в пуле сообщений. Дополнительные сведения см. в разделе "Справочник по параметрам приложения" — local.settings.json.

Чтение сообщений из очереди мертвых писем с помощью встроенных триггеров Service Bus

В стандартных рабочих процессах для чтения сообщения из очереди недоставленных писем в очереди или подписке раздела выполните следующие действия с помощью указанных триггеров:

1. В вашем пустом рабочем процессе, в зависимости от вашего сценария, добавьте встроенный триггер соединителя Service Bus с именем "Когда сообщения доступны в очереди" или "Когда сообщение доступно в подписке на тему (peek-lock)".

2. В триггере задайте следующие значения параметров, чтобы указать очередь недоставленных писем по умолчанию для подписки темы, доступ к которой можно получить так же, как к любой другой очереди.

   • Если сообщения доступны в триггере очереди : задайте для параметра имени очереди значение queuename/$deadletterqueue.

   • Если сообщение доступно в триггере подписки раздела (peek-lock): задайте параметру имени раздела значение topicname/Subscriptions/subscriptionname/$deadletterqueue.

   Дополнительные сведения см. в служебная шина обзоре очередей недоставленных писем.

Устранение неполадок

Задержки в обновлении рабочего процесса в силу

Если интервал опроса триггера Service Bus невелик, например 10 секунд, обновления рабочего процесса могут вступать в силу не сразу, а только через 10 минут. Чтобы обойти эту проблему, отключите ресурс приложения логики, внесите изменения и повторно включите ресурс приложения логики.

Сеанс недоступен или другой получатель заблокировал его

Иногда такие операции, как завершение сообщения или продление сеанса, могут привести к следующей ошибке в управляемом соединителе:

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

Иногда триггер на основе сеанса может завершиться ошибкой в управляемом соединителе:

{
  "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."
  }
}

Иногда такие операции, как завершение сообщения или продление сеанса, создают следующую ошибку во встроенном соединителе:

{
  "code": "ServiceProviderActionFailed",
  "message": "The service provider action failed with error code 'ServiceOperationFailed' and error message 'The Service Bus session was not found to perform operation 'getMessagesFromQueueSession' on session id '11115555'.'."
}

Соединитель Service Bus использует кэш в памяти для поддержки всех операций, связанных с работой сеансов. Получатель сообщений служебной шины кэшируется в памяти экземпляра роли виртуальной машины, принимающего сообщения. Чтобы обработать все запросы, все вызовы подключения направляются в тот же экземпляр роли. Это поведение необходимо, так как для всех операций Шины обслуживания в рамках сеанса требуется один и тот же получатель, который принимает сообщения для конкретного сеанса.

Из-за таких причин, как обновление инфраструктуры, развертывание соединителя и т. д., может возникнуть ситуация, когда запросы не маршрутизируются в тот же самый экземпляр роли. Если это событие произойдет, запросы завершаются ошибкой по одной из следующих причин:

• Приемник, выполняющий операции в сеансе, недоступен в экземпляре роли, обрабатывающем запрос.

• Новый экземпляр роли пытается получить сеанс, время которого истекло в старом экземпляре роли, либо он не был закрыт.

Это поведение может произойти как в управляемом соединителе, так и во встроенном соединителе. При возникновении ошибки сообщение все еще сохраняется в шине служб. Следующий триггер или рабочий процесс пытается снова обработать сообщение. Если эта ошибка происходит лишь изредка, это ожидаемое явление.

Связанный контент

• Управляемые соединители в Azure Logic Apps
• Встроенные соединители в Azure Logic Apps
• Что такое соединители в Azure Logic Apps