Различия между одноклиентскими приложениями логики уровня "Стандарт" и многопользовательскими приложениями логики уровня "Потребление"

Azure Logic Apps – это облачная платформа для создания и запуска автоматизированных рабочих процессов приложений логики, которые объединяют приложения, данные, службы и системы пользователя. С помощью этой платформы можно быстро разработать решения интеграции с высоким уровнем масштабируемости для сценариев корпоративного уровня и B2B. При создании ресурса приложения логики выберите вариант "Потребление " или "Стандартный ". Приложение логики потребления может иметь только один рабочий процесс, работающий в мультитенантных Azure Logic Apps. Приложение логики формата "Стандарт" может иметь один или несколько рабочих процессов, выполняемых в Azure Logic Apps для одного арендатора или в среде Среда службы приложений версии 3 (ASE v3).

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

Если вы не знакомы с Azure Logic Apps, ознакомьтесь с тем, что такое Azure Logic Apps? И что такое рабочий процесс приложения логики?

Типы и среды рабочих процессов приложения логики

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

Стандартное приложение логики и рабочий процесс

Приложение логики Стандарт и рабочий процесс запускаются на основе обновленной одноэкземплярной среды выполнения Azure Logic Apps. Среда выполнения использует модель расширяемости службы "Функции Azure" и размещена в качестве расширения в среде выполнения "Функции Azure". Эта архитектура обеспечивает переносимость, гибкость и большую производительность для рабочих процессов логического приложения, а также другие возможности и преимущества, унаследованные от платформы Функций Azure и экосистемы службы приложений Azure. Например, можно создавать, развертывать и запускать приложения логики на основе одного клиента и их рабочие процессы в Среде службы приложений Azure версии 3 (только планы Windows).

Приложение Standard логики использует ресурсную структуру, которая может размещать несколько рабочих процессов, аналогично тому, как приложение-функция Azure может размещать несколько функций. При сопоставлении "один к нескольким" рабочие процессы в одном приложении логики и на одном клиенте совместно используют вычислительные и обрабатывающие ресурсы, обеспечивая лучшую производительность благодаря своему сходству. Эта структура отличается от ресурса Consumption logic app, где существует соотношение 1 к 1 между ресурсом приложения логики и рабочим процессом.

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

• Azure Logic Apps, работающие где угодно — подробный обзор среды выполнения
• Общие сведения о Функциях Azure
• Функции Azure triggers and bindings (Триггеры и привязки в Функциях Azure)

Переносимость и гибкость

При создании приложения логики уровня "Стандартный" и рабочего процесса, можно развернуть и запустить рабочий процесс в других средах, например, среде службы приложений Azure версии 3 (только для планов Windows). Если вы используете Visual Studio Code с расширением Azure Logic Apps (стандартный), вы можете локально разрабатывать, создавать и запускать рабочий процесс в среде разработки без необходимости развертывания в Azure. Если для вашего сценария требуется локальное развертывание с помощью инфраструктуры, которую вы управляете, см. статью "Создание рабочих процессов приложения логики уровня "Стандартный" для гибридного развертывания в собственной инфраструктуре.

Эти возможности обеспечивают значительные улучшения и существенные преимущества по сравнению с мультитенантной моделью, которая требует разработки для существующего работающего ресурса в Azure. Мультитенантная модель для автоматизации развертывания ресурсов приложения логики потребления основана на шаблонах Azure Resource Manager (шаблоны ARM), которые объединяют и обрабатывают подготовку ресурсов для приложений и инфраструктуры.

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

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

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

Производительность

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

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

При использовании новых встроенных операций соединителя создаются подключения, называемые встроенными подключениями или подключениями поставщика услуг. Управляемые аналоги таких соединений называются подключениями через API, которые создаются и запускаются отдельно как ресурсы Azure, которые также необходимо будет развернуть с помощью шаблонов ARM. Встроенные операции и их соединения выполняются локально в том же процессе, что и рабочие процессы. Они размещаются в среде выполнения Azure Logic Apps с одним клиентом. В результате встроенные операции и их соединения обеспечивают лучшую производительность благодаря своему сходству с рабочими процессами. Данный дизайн также хорошо работает с конвейерами развертывания, поскольку подключения сервис-провайдера упаковываются в единый артефакт сборки.

Место расположения данных

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

Прямой доступ к ресурсам в виртуальных сетях Azure

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

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

Azure Logic Apps с однопользовательской архитектурой также предоставляет следующие преимущества:

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

• Увеличение ограничений на продолжительность выполнения, хранение хранилища, пропускную способность, время ожидания HTTP-запроса и ответа, размеры сообщений и пользовательские запросы соединителя. Дополнительные сведения см. в статье Ограничения и сведения о конфигурации для Azure Logic Apps.

Возможности создания, сборки и внедрения

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

Среда для одного клиента

Многотенантная среда

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

Например, на странице "Приложения логики" портала Azure отображаются ресурсы приложения логики "Потребление" и "Стандарт". В Visual Studio Code развернутые приложения логики отображаются в вашей подписке Azure, но приложения логики Consumption отображаются в окне Azure под расширением Azure Logic Apps (Consumption), а приложения логики Standard отображаются в разделе "Ресурсы".

Рабочие процессы с отслеживанием и без отслеживания состояния

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

• С отслеживанием состояния

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

  По умолчанию рабочие процессы с отслеживанием состояния в мультитенантных и однотенантных Azure Logic Apps выполняются асинхронно. Все действия на основе HTTP следуют стандартной модели асинхронных операций. После того как действие HTTP вызовет или отправит запрос в конечную точку, службу, систему или API, получатель немедленно возвращает ответ 202 ACCEPTED (Принято). Этот код подтверждает, что получатель принял запрос, но не завершена обработка. Ответ может включать заголовок location, указывающий URI и идентификатор обновления, который вызывающая сторона может использовать для опроса или проверки состояния асинхронного запроса до тех пор, пока получатель не прекратит обработку и не вернет сообщение об успешном завершении "200 OK" или другой ответ, отличный от 202. Однако вызывающей стороне не нужно ждать завершения обработки запроса, и можно продолжить выполнение следующего действия. Дополнительные сведения см. в разделе Асинхронная интеграция микрослужб обеспечивает автономность микрослужб.

• Без отслеживания состояния

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

  Рабочий процесс без отслеживания состояния обеспечивает наилучшую производительность при обработке данных или содержимого, общий размер которых не превышает 64 КБ (например, файлов). Контент большого размера, например несколько больших вложений, могут значительно снизить производительность рабочего процесса или даже привести к его сбою из-за исключений, связанных с нехваткой памяти. Если рабочему процессу, возможно, придется обрабатывать контент большого размера, используйте рабочий процесс с отслеживанием состояния.

  Примечание.

  В беспоcтоянных рабочих процессах можно использовать только push-триггеры, в которых не указывается расписание для выполнения рабочего процесса. Эти триггеры на основе вебхуков ожидают, когда событие произойдет или данные станут доступными. Например, триггер повторения доступен только для состоящихся рабочих процессов. Чтобы запустить рабочий процесс, выберите триггер push, например триггер запроса, триггер центров событий или триггер служебной шины. Дополнительные сведения об ограниченных, недоступных или неподдерживаемых триггерах, действиях и соединителях см. в разделе Измененные, ограниченные, недоступные или неподдерживаемые возможности.

  Рабочие процессы без отслеживания состояния выполняются синхронно, поэтому они не используют стандартный шаблон асинхронной операции, используемый рабочими процессами с отслеживанием состояния. Вместо этого все HTTP-основанные действия, которые возвращают ответ "202 ACCEPTED", переходят к следующему шагу выполнения рабочего процесса. Если ответ содержит заголовок location, рабочий процесс без отслеживания состояния не опрашивает указанный URI для проверки состояния. Чтобы следовать стандартному шаблону асинхронной операции, вместо него следует использовать рабочий процесс с отслеживанием состояния.

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

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

Различия во вложенном поведении между рабочими процессами с сохранением и без сохранения состояния.

Вы можете сделать рабочий процесс вызываемым из других рабочих процессов, существующих в том же приложении логики уровня "Стандартный", с помощью триггера запроса, триггера веб-перехватчика HTTP или управляемых соединителей, которые имеют тип ApiConnectionWebhook и могут получать HTTPS-запросы.

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

• Шаблон асинхронного опроса

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

• Синхронный шаблон ("запустил и забыл")

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

  Чтобы включить это поведение, в определении JSON рабочего процесса задайте для свойства operationOptions значение DisableAsyncPattern. Дополнительные сведения см. в разделе Типы триггеров и действий — параметры операции.

• Активация и ожидание

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

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

Другие возможности модели с одним клиентом

Модель с выделенным клиентом и логическое приложение Standard включают множество текущих и новых возможностей, например:

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

  • Дополнительные управляемые соединители теперь доступны как встроенные соединители в стандартных рабочих процессах. Встроенные версии выполняются изначально в среде выполнения Azure Logic Apps с одним клиентом. Некоторые встроенные соединители также неофициально называются соединителями поставщика службы. Чтобы получить список, см. раздел Встроенные соединители уровня "Потребление" и "Стандартный".

  • Вы можете создавать собственные встроенные соединители для любой необходимой службы, используя платформу расширяемости Azure Logic Apps с одним клиентом. Подобно встроенным соединителям, таким как Служебная шина Azure и SQL Server, пользовательские встроенные соединители обеспечивают более высокую пропускную способность, низкую задержку и локальное подключение, поскольку они работают в том же процессе, что и единоарендаторная среда выполнения. Но пользовательские встроенные соединители не похожи на пользовательские управляемые соединители, которые в настоящее время не поддерживаются. Дополнительную информацию см. в статье Общие сведения о пользовательском соединителе и Создание встроенных пользовательских соединителей для стандартных приложений логики в Azure Logic Apps с одним арендатором.

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

    • XML: преобразование XML, проверка XML, создание XML с помощью схемы и разбор XML с помощью схемы

    • Liquid: Преобразование JSON в JSON, Преобразование JSON в текст, Преобразование XML в JSON и Преобразование XML в текст

    Примечание.

    Чтобы использовать эти действия в стандартных рабочих процессах, необходимо иметь карты Liquid, карты XML или схемы XML. Эти артефакты можно отправить на портале Azure из меню ресурсов вашего приложения логики в разделе Артефакты, в котором имеются разделы Схемы и Карты. Кроме того, можно добавить эти артефакты в папку Артефакты вашего проекта Visual Studio Code, используя соответствующие папки Карты и Схемы. Затем эти артефакты можно использовать в нескольких рабочих процессах в том же логическом приложении.

  • Стандартные рабочие процессы логических приложений могут запускаться из любого места, так как Azure Logic Apps создает строки подключения с общей подписью доступа (SAS), которые эти логические приложения могут использовать для отправки запросов к конечной точке среды выполнения подключения к облаку. Azure Logic Apps сохраняет эти строки подключения с другими параметрами приложения, чтобы вы могли легко сохранить эти значения в Azure Key Vault при развертывании в Azure.

  • Рабочие процессы приложения логики уровня "Стандартный" поддерживают включение управляемого удостоверения, назначаемого системой, и нескольких управляемых удостоверений, назначаемых пользователем, одновременно, хотя можно выбрать только одно удостоверение для использования одновременно. Хотя встроенные соединители, основанные на поставщиках услуг, поддерживают использование системно назначенного удостоверения, большинство из них в настоящее время не поддерживают выбор управляемых удостоверений, назначенных пользователем, для проверки подлинности, за исключением соединителей SQL Server и HTTP.

    Примечание.

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

• Можно локально выполнять, тестировать и отлаживать приложения логики и их рабочие процессы в среде разработки Visual Studio Code.

  Перед запуском и тестированием приложения логики можно упростить отладку, добавив точки останова внутри файла workflow.json для рабочего процесса. Однако точки останова пока поддерживаются только для действий, но не для триггеров. Дополнительные сведения см. в статье Создание рабочих процессов для одного клиента в редакторе Visual Studio Code.

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

• Включите функции ведения журнала диагностики и трассировки для приложения логики с помощью Application Insights, если это поддерживается в вашей подписке Azure и настройках приложения логики.

• Получите доступ к сетевым возможностям, таким как подключение и интеграция в частном порядке с виртуальными сетями Azure, аналогично Функциям Azure, при создании и развертывании приложений логики с помощью плана Функций Azure категории "Премиум". Дополнительные сведения см. в следующей документации:

  • Параметры сети для Функций Azure

  • Azure Logic Apps везде - сетевые возможности Azure Logic Apps

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

Встроенные соединители для уровня "Стандартный"

Стандартный рабочий процесс может использовать множество встроенных соединителей, как потребительский рабочий процесс, но не все. Наоборот, рабочий процесс уровня "Стандарт" имеет множество встроенных соединителей, которые недоступны в рабочем процессе уровня "Потребление".

Например, рабочий процесс типа "Стандарт" имеет управляемые разъемы и встроенные разъемы для BLOB-объектов Azure, Azure Cosmos DB, Центров событий Azure, Служебной шины Azure, DB2, FTP, MQ, SFTP, SQL Server и т. д. Хотя рабочий процесс потребления не имеет таких же встроенных версий соединителей, доступны другие встроенные соединители, такие как Azure API Management и службы приложений Azure.

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

Измененные, ограниченные, недоступные или неподдерживаемые возможности

Для рабочего процесса приложения логики Стандарт следующие возможности отличаются от ожидаемого, в настоящее время ограничены, недоступны или не поддерживаются:

• Триггеры и действия: встроенные триггеры и действия выполняются изначально в Azure Logic Apps, а управляемые соединители размещаются и запускаются с помощью общих ресурсов в Azure. Для стандартных рабочих процессов некоторые встроенные триггеры и действия в настоящее время недоступны, например операции службы приложение Azure. Чтобы запустить рабочий процесс с сохранением состояния или без него, используйте встроенный триггер, такие, как триггер Запрос, триггер Event Hubs или триггер служебная шина. Триггер повторения доступен для рабочих процессов с отслеживанием состояния, но недоступен для рабочих процессов без отслеживания состояния. В коллекции соединителей встроенные триггеры и действия отображаются при выборе встроенного фильтра, а триггеры и действия управляемого соединителя отображаются при выборе общего фильтра.

  Рабочие процессы без отслеживания состояния могут использовать только триггеры push-уведомлений, в которых не указывается расписание для выполнения рабочего процесса. Эти триггеры на основе вебхуков ожидают, когда событие произойдет или данные станут доступными. Например, триггер повторения доступен только для состоящихся рабочих процессов. Чтобы запустить рабочий процесс, выберите триггер push, например триггер запроса, триггер центров событий или триггер служебной шины. Хотя вы можете включить управляемые соединители для рабочих процессов без отслеживания состояния, коллекция соединителей не отображает триггеры опроса управляемых соединителей для добавления.

  Примечание.

  Для запуска в локальной среде в Visual Studio Code триггеры и действия на основе веб-перехватчика требуют дополнительной конфигурации. Дополнительные сведения см. в статье Создание рабочих процессов для одного клиента в редакторе Visual Studio Code.

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

    • Встроенное действие Функции Azure — Выбор функции Azure теперь Функции Azure Operations — Вызов функции Azure. В настоящее время это действие работает только для функций, созданных из шаблона Триггер HTTP.

      На портале Azure можно выбрать функцию триггера HTTP, к которой необходимо получить доступ, создав соединение с помощью пользовательского интерфейса. Если вы проверите определение JSON действия функции в режиме просмотра кода или в файле workflow.json с помощью Visual Studio Code, то действие ссылается на функцию, используя connectionName ссылку. Эта версия абстрагирует сведения о функции в виде соединения, которое можно найти в файле проекта приложения логики connections.json, который доступен после создания соединения в редакторе Visual Studio Code.

      Примечание.

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

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

    • Встроенное действие Встроенный код представляет собой переименованное действие Операции встроенного кода; для него больше не требуется учетная запись и для него обновлены предельные значения.

    • Встроенное действие Azure Logic Apps — выбор рабочего процесса Logic App теперь называется Операции с рабочими процессами — запуск рабочего процесса в этом приложении.

    • В стандартных рабочих процессах без отслеживания состояния триггеры не поддерживают изменение уровня параллелизма триггера.

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

• Аутентификация

  • Некоторые триггеры на основе запросов, обрабатывающие входящие вызовы, такие как триггер Request, в настоящее время не поддерживают Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), а другие, такие как триггер веб-перехватчика HTTP, поддерживают её.

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

• Отладка с точками останова в Visual Studio Code. Хотя вы можете добавлять и использовать точки останова внутри файла workflow.json для рабочего процесса, точки останова пока поддерживаются только для действий, но не для триггеров. Дополнительные сведения см. в статье Создание рабочих процессов для одного клиента в редакторе Visual Studio Code.

• История триггеров и история выполнения: Для рабочего процесса приложения логики уровня Стандартный история триггеров и история выполнения в портале Azure отображается на уровне рабочего процесса, а не на уровне ресурсов логики приложения. Дополнительные сведения см. в статье Создание рабочих процессов для одного клиента на портале Azure.

• Terraform: Вы можете развернуть инфраструктуру ресурса приложения логики уровня «Стандартный» с помощью поставщика AzAPI Terraform, который обладает паритетом возможностей с шаблонами ARM и Bicep. Сведения о рекомендуемом модульном подходе см. в Azure Verified Modules (AVM) for Logic Apps Standard. Границы поддержки AVM см. в разделе Module support.

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

Ограничьте разрешения для сетевого трафика и брандмауэра

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

• Разрешения брандмауэра для приложений логики одного арендатора — портал Azure
• Разрешения брандмауэра для одиночных логических приложений — Visual Studio Code

Следующие шаги

• Создание рабочих процессов для одного клиента на портале Azure
• Создание рабочих процессов для одного клиента в редакторе Visual Studio Code

Мы также хотели бы узнать о ваших впечатлениях от использования Azure Logic Apps с одним клиентом.

• При возникновении ошибок или проблем опубликуйте свою проблему на портале GitHub.
• Для вопросов, запросов, комментариев и других отзывов используйте эту форму обратной связи.