Различия между приложениями логики с одним клиентом уровня "Стандартный" и мультитенантными приложениями логики потребления
Azure Logic Apps – это облачная платформа для создания и запуска автоматизированных рабочих процессов приложений логики, которые объединяют приложения, данные, службы и системы пользователя. С помощью этой платформы можно быстро разработать решения интеграции с высоким уровнем масштабируемости для сценариев корпоративного уровня и B2B. При создании ресурса приложения логики выберите вариант "Потребление " или "Стандартный ". Приложение логики потребления может иметь только один рабочий процесс, работающий в мультитенантных Azure Logic Apps. Приложение логики уровня "Стандартный" может иметь один или несколько рабочих процессов, выполняемых в Azure Logic Apps с одним клиентом или Среда службы приложений версии 3 (ASE версии 3).
Прежде чем выбрать ресурс приложения логики для создания, ознакомьтесь со следующим руководством, чтобы узнать, как типы рабочих процессов приложения логики сравниваются друг с другом. Затем вы можете выбрать, какой рабочий процесс приложения логики и среда лучше подходят для вашего сценария, требований к решению и назначения, в котором требуется развернуть и запустить рабочие процессы.
Если вы не знакомы с Azure Logic Apps, ознакомьтесь с тем, что такое Azure Logic Apps? И что такое рабочий процесс приложения логики?.
Типы и среды рабочих процессов приложения логики
В следующей таблице перечислены различия между рабочим процессом приложения логики потребления и рабочим процессом приложения логики "Стандартный". Вы также узнаете, как среда с одним клиентом отличается от мультитенантной среды для развертывания, размещения и выполнения рабочих процессов.
| Вариант размещения | Льготы | Общий доступ и использование ресурсов | Цены и модель выставления счетов | Управление ограничениями |
|---|---|---|---|---|
| Потребление Среда узла: Мультитенантное Azure Logic Apps |
- Проще всего приступить к работе - Оплата за то, что вы используете — Полная управляемость |
Один ресурс приложения логики может иметь только один рабочий процесс. Все приложения логики в клиентах Microsoft Entra используют одну и ту же обработку (вычисления), хранилище, сеть и т. д. Для обеспечения избыточности данные реплицируются в парном регионе. Для обеспечения высокой доступности включается геоизбыточное хранилище (GRS). |
Потребление (оплата за количество выполнений) | Azure Logic Apps управляет значениями по умолчанию для этих ограничений, но вы можете изменить некоторые из этих значений, если этот параметр существует для определенного ограничения. |
| Standard (план службы рабочих процессов) Среда узла: Azure Logic Apps с одним клиентом Примечание. Если для вашего сценария требуются контейнеры, создайте приложения логики на основе одного клиента с помощью Logic Apps с поддержкой Azure Arc. Дополнительные сведения см. в статье Что такое Azure Logic Apps с поддержкой Azure Arc. |
— более встроенные соединители, размещенные в среде выполнения с одним клиентом, для повышения пропускной способности и снижения затрат на масштабирование — Дополнительные возможности контроля и тонкой настройки для параметров среды выполнения и производительности — Интегрированная поддержка виртуальных сетей и частных конечных точек. — Возможность создания собственных встроенных соединителей. |
Один ресурс приложения логики может иметь несколько рабочих процессов без отслеживания состояния и отслеживания состояния. Рабочие процессы в одном приложении логики и клиенте совместно используют одни и те же ресурсы обработки (вычисления), хранилище, сеть и т. д. Данные остаются в том же регионе, где развертывается приложение логики. |
Стандартный: на основе плана размещения с выбранной ценовой категорией. При запуске рабочих процессов с отслеживанием состояния, использующих внешнее хранилище, среда выполнения Azure Logic Apps создает транзакции с хранилищем в соответствии с ценами на хранилище Azure. |
Вы можете изменить значения по умолчанию для многих ограничений в зависимости от потребностей вашего сценария. Важно: некоторые ограничения имеют жесткие верхние максимумы. В Visual Studio Code изменения, вносимые в значения ограничений по умолчанию в файлах конфигурации проекта приложения логики, не будут отображаться в конструкторе. Дополнительные сведения см. в разделе Изменение параметров приложения и среды для приложений логики в Azure Logic Apps с одним клиентом. |
| Standard (Среда службы приложений версии 3) Среда узла: Среда службы приложений версии 3 (ASEv3) — только планы Windows |
Те же возможности, что и один клиент , а также следующие преимущества: — Полная изоляция приложений логики. — Создание и запуск большего количества приложений логики, чем в среде Azure Logic Apps с одним клиентом. — Оплата только плана службы приложений ASE, независимо от количества создаваемых и выполняемых приложений логики. — Возможность включить автомасштабирование или выполнять масштабирование вручную с увеличением количества экземпляров виртуальных машин или переходом на другой план службы приложений. — Наследование настроек сети от выбранной среды ASEv3. Например, при развертывании в внутренней среде ASE рабочие процессы могут получить доступ к ресурсам в виртуальной сети, связанной с ASE, и иметь внутренние точки доступа. Примечание. Если доступ осуществляется из-за пределов внутренней среды ASE, у журналов выполнения для рабочих процессов в этой ASE нет доступа к входным и выходным данным операций. |
Одно приложение логики может иметь несколько рабочих процессов с отслеживанием состояния и без отслеживания состояния. Рабочие процессы в одном приложении логики и клиенте совместно используют одни и те же ресурсы обработки (вычисления), хранилище, сеть и т. д. Данные остаются в том же регионе, где вы развертываете приложения логики. |
План обслуживания приложения | Вы можете изменить значения по умолчанию для многих ограничений в зависимости от потребностей вашего сценария. Важно: некоторые ограничения имеют жесткие верхние максимумы. В Visual Studio Code изменения, вносимые в значения ограничений по умолчанию в файлах конфигурации проекта приложения логики, не будут отображаться в конструкторе. Дополнительные сведения см. в разделе Изменение параметров приложения и среды для приложений логики в Azure Logic Apps с одним клиентом. |
Стандартное приложение логики и рабочий процесс
Приложение логики уровня "Стандартный" и рабочий процесс работает на основе обновленной среды выполнения Azure Logic Apps с одним клиентом. Среда выполнения использует модель расширяемости службы "Функции Azure" и размещена в качестве расширения в среде выполнения "Функции Azure". Эта конструкция обеспечивает переносимость, гибкость и большую производительность для рабочих процессов приложения логики, а также другие возможности и преимущества, унаследованные от платформы Функции Azure и экосистемы служб приложение Azure. Например, можно создавать, развертывать и запускать приложения логики на основе одного клиента и их рабочие процессы в Среде службы приложений Azure версии 3 (только планы Windows).
Приложение логики уровня "Стандартный " представляет структуру ресурсов, которая может размещать несколько рабочих процессов, аналогично тому, как приложение-функция Azure может размещать несколько функций. При сопоставлении "один к нескольким" рабочие процессы в одном приложении логики и на одном клиенте совместно используют вычислительные и обрабатывающие ресурсы, обеспечивая лучшую производительность благодаря своему сходству. Эта структура отличается от ресурса приложения логики потребления , где имеется сопоставление между ресурсом приложения логики логики и рабочим процессом.
Дополнительные сведения о переносимости, гибкости и повышении производительности см. в следующих разделах. Дополнительные сведения о среде выполнения Azure Logic Apps с одним клиентом и Функции Azure расширяемости см. в следующей документации:
- Универсальные Azure Logic Apps — подробный обзор среды выполнения
- Общие сведения о Функциях Azure
- Azure Functions triggers and bindings (Триггеры и привязки в Функциях Azure)
Переносимость и гибкость
При создании приложения логики уровня "Стандартный" и рабочего процесса можно развернуть и запустить рабочий процесс в других средах, например приложение Azure среда службы версии 3 (только планы Windows). Если вы используете Visual Studio Code с расширением Azure Logic Apps (стандартный), вы можете локально разрабатывать, создавать и запускать рабочий процесс в среде разработки без необходимости развертывания в Azure. Если для вашего сценария требуются контейнеры, можно создать приложения логики одного клиента с помощью Azure Arc Logic Apps. Дополнительные сведения см. в статье о том, что такое Azure Arc с поддержкой Logic Apps?
Эти возможности обеспечивают значительные улучшения и существенные преимущества по сравнению с мультитенантной моделью, которая требует разработки для существующего работающего ресурса в Azure. Мультитенантная модель для автоматизации развертывания ресурсов приложения логики потребления основана на шаблонах Azure Resource Manager (шаблоны ARM), которые объединяют и обрабатывают подготовку ресурсов для приложений и инфраструктуры.
Благодаря ресурсу приложения логики уровня "Стандартный" развертывание становится проще, так как можно отделять развертывание приложений от развертывания инфраструктуры. Вы можете упаковыть среду выполнения Azure Logic Apps с одним клиентом и рабочие процессы вместе в рамках ресурса приложения логики или проекта. Можно использовать общие шаги или задачи, которые создают, собирают и архивируют ресурсы приложения логики в готовые к развертыванию артефакты. Для развертывания инфраструктуры по-прежнему можно использовать шаблоны ARM для отдельной подготовки этих ресурсов с другими процессами и конвейерами, которые используются для этих целей.
Чтобы развернуть приложение, скопируйте артефакты в среду узла, а затем запустите свои приложения для выполнения рабочих процессов. Или интегрируйте артефакты в конвейеры развертывания с помощью уже знакомых и ранее использованных средств и процессов. Таким образом, можно выполнить развертывание, используя выбранные пользователем инструменты, независимо от того, какой стек технологий используется для разработки.
Используя стандартные параметры сборки и развертывания, можно сосредоточиться на разработке приложений отдельно от развертывания инфраструктуры. В результате можно получить более общую модель проекта, в которой можно применять множество аналогичных или тех же параметров развертывания, которые используются для общего приложения. Кроме того, ваша работа становится более согласованной при создании конвейеров развертывания для приложений, а также при выполнении необходимых тестов и проверок перед публикацией в рабочей среде.
Производительность
С помощью приложения логики уровня "Стандартный " можно создавать и запускать несколько рабочих процессов в одном ресурсе приложения логики и клиенте. Благодаря этому сопоставлению "один к нескольким" эти рабочие процессы совместно используют ресурсы, такие как среда вычисления, обработки, хранилище и сеть, что обеспечивает лучшую производительность вследствие их сходства.
Ресурс приложения логики уровня "Стандартный" и среда выполнения 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, но приложения логики потребления отображаются в окне Azure в расширении "Использование Azure Logic Apps", а приложения логики "Стандартный" отображаются в разделе "Ресурсы".
Рабочие процессы с отслеживанием и без отслеживания состояния
В приложении логики уровня "Стандартный " можно создать следующие типы рабочих процессов:
С отслеживанием состояния
Создавайте рабочие процессы с отслеживанием состояния, когда вам нужно хранить и проверять данные из предыдущих событий, а также ссылаться на них. Эти рабочие процессы сохраняют все входные, выходные данные и состояния операций во внешнем хранилище. Эти сведения позволяют просмотреть сведения о выполнении рабочего процесса и его журнал после завершения каждого выполнения. Рабочие процессы с отслеживанием состояния обеспечивают высокую устойчивость при сбоях. После восстановления служб и систем можно воссоздать прерванные запуски из сохраненного состояния и перезапустить рабочие процессы для их завершения. Выполнение рабочих процессов с отслеживанием состояния может продолжаться намного дольше, чем выполнение рабочих процессов без отслеживания состояния.
По умолчанию рабочие процессы с отслеживанием состояния в мультитенантных и однотенантных Azure Logic Apps выполняются асинхронно. Все действия на основе HTTP следуют стандартной модели асинхронных операций. После того как действие HTTP вызовет или отправит запрос в конечную точку, службу, систему или API, получатель немедленно возвращает ответ 202 ACCEPTED (Принято). Этот код подтверждает, что получатель принял запрос, но еще не завершил обработку. Ответ может включать заголовок
location, указывающий URI и идентификатор обновления, который вызывающая сторона может использовать для опроса или проверки состояния асинхронного запроса до тех пор, пока получатель не прекратит обработку и не вернет сообщение об успешном завершении "200 OK" или другой ответ, отличный от 202. Однако вызывающей стороне не нужно ждать завершения обработки запроса, и можно продолжить выполнение следующего действия. Дополнительные сведения см. в разделе Асинхронная интеграция микрослужб обеспечивает автономность микрослужб.Без отслеживания состояния
Создавайте рабочие процессы без отслеживания состояния, если вам не нужно хранить и проверять данные из предыдущих событий во внешнем хранилище после завершения каждого запуска, а также ссылаться на них. Эти рабочие процессы сохраняют входные и выходные данные для каждого действия и сведения об их состоянии только в памяти, а не во внешнем хранилище. В результате рабочие процессы без отслеживания состояния выполняются быстрее (обычно 5 минут или менее), более производительны, имеют меньшее время отклика, более высокую пропускную способность и сниженные эксплуатационные затраты, так как им не нужно сохранять сведения о выполнении и журнал во внешнем хранилище. Однако при возникновении сбоев прерванные запуски не восстанавливаются автоматически, и оператору приходится восстанавливать их вручную.
Рабочий процесс без отслеживания состояния обеспечивает наилучшую производительность при обработке данных или содержимого, общий размер которых не превышает 64 КБ (например, файлов). Контент большого размера, например несколько больших вложений, могут значительно снизить производительность рабочего процесса или даже привести к его сбою из-за исключений, связанных с нехваткой памяти. Если рабочему процессу, возможно, придется обрабатывать контент большого размера, используйте рабочий процесс с отслеживанием состояния.
Примечание.
В рабочих процессах без отслеживания состояния можно использовать только триггеры push-уведомлений, в которых не указывается расписание для выполнения рабочего процесса. Эти триггеры на основе веб-перехватчика ожидают, когда событие произойдет или данные становятся доступными. Например, триггер повторения доступен только для рабочих процессов с отслеживанием состояния. Чтобы запустить рабочий процесс, выберите триггер push-отправки, например запрос, центры событий или триггер служебная шина. Дополнительные сведения об ограниченных, недоступных или неподдерживаемых триггерах, действиях и соединителях см. в разделе Измененные, ограниченные, недоступные или неподдерживаемые возможности.
Рабочие процессы без отслеживания состояния выполняются синхронно, поэтому они не используют стандартный шаблон асинхронной операции, используемый рабочими процессами с отслеживанием состояния. Вместо этого все действия на основе HTTP, которые возвращают ответ "202 ACCEPTED", переходит к следующему шагу выполнения рабочего процесса. Если ответ содержит заголовок
location, рабочий процесс без отслеживания состояния не опрашивает указанный URI для проверки состояния. Чтобы следовать стандартному шаблону асинхронной операции, вместо него следует использовать рабочий процесс с отслеживанием состояния.Для упрощения отладки можно включить журнал выполнения для рабочего процесса без отслеживания состояния, что влияет на производительность, а затем отключить журнал выполнения по завершении. Дополнительные сведения см. в статьях Создание рабочих процессов для одного клиента в Visual Studio Code или Создание рабочих процессов для одного клиента на портале Azure.
Внимание
Для реализации на этапе создания необходимо выбрать тип рабочего процесса — с отслеживанием или без отслеживания состояния. Изменение типа рабочего процесса после создания приводит к ошибкам среды выполнения.
Краткое описание различий между рабочими процессами с отслеживанием и без отслеживания состояния
| С отслеживанием состояния | Служба без отслеживания |
|---|---|
| Сохраняет журнал выполнения, входные и выходные данные | Не сохраняет журнал выполнения, входные и выходные данные по умолчанию |
| Триггеры управляемых соединителей доступны и разрешены | Триггеры управляемых соединителей недоступны или запрещены |
| Разделение на блоки поддерживается | Разделение на блоки не поддерживается |
| Асинхронные операции поддерживаются | Асинхронные операции не поддерживаются |
| Редактирование максимальной продолжительности выполнения по умолчанию в конфигурации узла | Лучше всего подходит для рабочих процессов с максимальной длительностью менее 5 минут |
| Обработка больших сообщений | Лучше всего подходит для обработки сообщений небольшого размера (до 64 Кб) |
Различия вложенного поведения между рабочими процессами с отслеживанием и без отслеживания состояния
Вы можете сделать рабочий процесс вызываемым из других рабочих процессов, существующих в том же приложении логики уровня "Стандартный", с помощью триггера запроса, триггера веб-перехватчика HTTP или управляемых соединителей, которые имеют тип ApiConnectionWebhook и могут получать HTTPS-запросы.
В следующем списке описаны шаблоны поведения, которым могут следовать вложенные рабочие процессы после того, как родительский рабочий процесс вызывает дочерний:
Шаблон асинхронного опроса
Родительский рабочий процесс не ожидает ответа дочернего рабочего процесса на их первоначальный вызов. Однако родительский объект постоянно проверяет журнал выполнения дочернего элемента, пока дочерний объект не завершит работу. По умолчанию рабочие процессы с отслеживанием состояния следуют этому шаблону, идеально подходящему для долго выполняющихся дочерних рабочих процессов, которые могут превысить пределы времени ожидания запроса.
Синхронный шаблон ("fire and forget")
Дочерний рабочий процесс подтверждает вызов родительского рабочего процесса, немедленно возвращая
202 ACCEPTEDответ. Однако родительский элемент не ожидает возврата результатов дочерним. Вместо этого родительский элемент продолжает следующее действие в рабочем процессе и получает результаты после завершения работы дочернего элемента. Дочерние рабочие процессы с отслеживанием состояния, которые не включают действие ответа, всегда соответствуют синхронному шаблону и предоставляют журнал выполнения для проверки.Чтобы включить это поведение, в определении JSON рабочего процесса задайте для свойства
operationOptionsзначениеDisableAsyncPattern. Дополнительные сведения см. в разделе Типы триггеров и действий — параметры операции.Активация и ожидание
Рабочие процессы без отслеживания состояния выполняются в памяти. Поэтому, когда родительский рабочий процесс вызывает дочерний без отслеживания состояния, родительский процесс ожидает ответа, который возвращает результаты из дочернего процесса. Этот шаблон работает подобно использованию встроенного триггера или действия HTTP для вызова дочернего рабочего процесса. Дочерние рабочие процессы без отслеживания состояния, которые не включают действие ответа, немедленно возвращают ответ
202 ACCEPTED, но родительский процесс ожидает выполнения дочернего процесса, прежде чем перейти к следующему действию. Это поведение применяется только к дочерним рабочим процессам без отслеживания состояния.
В следующей таблице указано поведение дочернего рабочего процесса в зависимости от типа родительского и дочернего рабочего процесса: с отслеживанием состояния, без отслеживания состояния или смешанный тип: Список после таблицы
| Родительский рабочий процесс | Дочерний рабочий процесс | Поведение дочернего рабочего процесса |
|---|---|---|
| С отслеживанием состояния | С отслеживанием состояния | Асинхронный или синхронный с параметром "operationOptions": "DisableAsyncPattern" |
| С отслеживанием состояния | Служба без отслеживания | Активация и ожидание |
| Служба без отслеживания | С отслеживанием состояния | Синхронная |
| Служба без отслеживания | Служба без отслеживания | Активация и ожидание |
Другие возможности модели с одним клиентом
Модель с одним клиентом и приложение логики "Стандартный " включают множество текущих и новых возможностей, например:
Создавайте приложения логики и их рабочие процессы с сотнями управляемых соединителей для приложений и служб типа "программное обеспечение как услуга" (SaaS) и "платформа как услуга" (Paas), а также соединителей для локальных систем.
Дополнительные управляемые соединители теперь доступны как встроенные соединители в стандартных рабочих процессах. Встроенные версии выполняются изначально в среде выполнения Azure Logic Apps с одним клиентом. Некоторые встроенные соединители также неофициально называются соединителями поставщика службы. Чтобы получить список, см. раздел Встроенные соединители уровня "Потребление" и "Стандартный".
Вы можете создавать собственные встроенные соединители для любой необходимой службы, используя платформу расширяемости Azure Logic Apps с одним клиентом. Подобно встроенным соединителям, таким как Служебная шина Azure и SQL Server, эти соединители обеспечивают более высокую пропускную способность, низкую задержку, локальное подключение и работают изначально в том же процессе, что и среда выполнения с одним арендатором. Но пользовательские встроенные соединители не похожи на пользовательские управляемые соединители, которые в настоящее время не поддерживаются. Дополнительные сведения см. в статье Общие сведения о настраиваемом соединителе и Создание пользовательских встроенных соединителей для приложений логики уровня "Стандартный" в Azure Logic Apps с одним арендатором.
Вы можете использовать указанные ниже действия для операций Liquid и операций XML без учетной записи интеграции. Перечень таких операций включает указанные ниже действия.
XML: Преобразование XML и Проверка XML
Liquid: Преобразование JSON в JSON, Преобразование JSON в текст, Преобразование XML в JSON и Преобразование XML в текст
Примечание.
Чтобы использовать эти действия в стандартных рабочих процессах, необходимо иметь карты Liquid, карты XML или схемы XML. Эти артефакты можно отправить на портале Azure из меню ресурсов вашего приложения логики в разделе Артефакты, в котором имеются разделы Схемы и Карты. Кроме того, можно добавить эти артефакты в папку Артефакты вашего проекта Visual Studio Code, используя соответствующие папки Карты и Схемы. Затем эти артефакты можно использовать в нескольких рабочих процессах в одном приложении логики.
Рабочие процессы приложения логики уровня "Стандартный" могут выполняться в любом месте, так как Azure Logic Apps создает подписанные URL-адреса (SAS) строка подключения, которые эти приложения логики могут использовать для отправки запросов в конечную точку среды выполнения облачных подключений. Azure Logic Apps сохраняет эти строка подключения с другими параметрами приложения, чтобы можно было легко хранить эти значения в Azure Key Vault при развертывании в Azure.
Рабочие процессы приложения логики уровня "Стандартный" поддерживают включение управляемого удостоверения, назначаемого системой, и нескольких управляемых удостоверений, назначаемых пользователем, одновременно, хотя можно выбрать только одно удостоверение для использования одновременно. Хотя встроенные соединители на основе поставщиков услуг поддерживают использование назначаемого системой удостоверения, в настоящее время не поддерживают выбор управляемых удостоверений, назначенных пользователем, для проверки подлинности, за исключением SQL Server и соединителей HTTP.
Примечание.
По умолчанию удостоверение, назначаемое системой, уже включено для проверки подлинности подключений во время выполнения. Это удостоверение отличается от учетных данных проверки подлинности или строки подключения, используемой при создании соединения. Если отключить это удостоверение, подключения не будут работать в среде выполнения. Чтобы просмотреть этот параметр, в меню приложения логики в разделе Параметры выберите Удостоверение.
Можно локально выполнять, тестировать и отлаживать приложения логики и их рабочие процессы в среде разработки Visual Studio Code.
Перед запуском и тестированием приложения логики можно упростить отладку, добавив точки останова внутри файла workflow.json для рабочего процесса. Однако точки останова пока поддерживаются только для действий, но не для триггеров. Дополнительные сведения см. в статье Создание рабочих процессов для одного клиента в редакторе Visual Studio Code.
Вы можете напрямую публиковать или развертывать приложения логики и их рабочие процессы из Visual Studio Code в разных средах размещения, например Azure и Logic Apps с поддержкой Azure Arc.
Включите функции ведения журнала диагностики и трассировки для приложения логики с помощью Application Insights, если это поддерживается в вашей подписке Azure и настройках приложения логики.
Получите доступ к сетевым возможностям, таким как подключение и интеграция в частном порядке с виртуальными сетями Azure, аналогично Функциям Azure, при создании и развертывании приложений логики с помощью плана Функций Azure категории "Премиум". Дополнительные сведения см. в следующей документации:
Повторно создайте ключи доступа для управляемых подключений, используемых отдельными рабочими процессами в приложении логики "Стандартный". Для этой задачи выполните те же действия для приложения логики потребления , но на уровне рабочего процесса, а не на уровне ресурса приложения логики.
Встроенные соединители для уровня "Стандартный"
Стандартный рабочий процесс может использовать множество встроенных соединителей, как рабочий процесс потребления, но не все. Наоборот, рабочий процесс уровня "Стандартный" имеет множество встроенных соединителей, которые недоступны в рабочем процессе потребления.
Например, рабочий процесс уровня "Стандартный" имеет управляемые соединители и встроенные соединители для BLOB-объектов Azure, Azure Cosmos DB, Центры событий Azure, Служебная шина Azure, DB2, FTP, MQ, SFTP, SQL Server и т. д. Хотя рабочий процесс потребления не имеет этих встроенных версий соединителей, доступны другие встроенные соединители, такие как Azure Управление API и службы приложение Azure.
В Azure Logic Apps с одним клиентом встроенный соединитель с определенными атрибутами неофициально называется поставщиком услуг. Некоторые встроенные соединители поддерживают только один способ проверки подлинности подключения в основной службе. Другие встроенные соединители могут предложить выбор, например использование строка подключения, идентификатора Microsoft Entra или управляемого удостоверения. Все встроенные соединители запускаются в том же процессе, что и усовершенствованная среда выполнения Azure Logic Apps. Дополнительные сведения см. в списке встроенных соединителей для рабочих процессов приложения логики уровня "Стандартный".
Внимание
Убедитесь в правильной настройке и тестировании любого триггера на основе поставщика услуг, чтобы подтвердить успешную операцию. Сбой триггер на основе поставщика услуг может создать ненужный масштабирование, что может значительно увеличить затраты на выставление счетов. Например, распространенная ошибка заключается в настройке триггера без предоставления приложению логики разрешения или доступа к месту назначения, например очереди служебная шина, служба хранилища Azure контейнера BLOB-объектов и т. д. Кроме того, убедитесь, что вы отслеживаете такие триггеры в любое время, чтобы быстро обнаруживать и устранять любые проблемы.
Измененные, ограниченные, недоступные или неподдерживаемые возможности
Для рабочего процесса приложения логики уровня "Стандартный" эти возможности изменились или в настоящее время ограничены, недоступны или неподдерживаются:
Триггеры и действия: встроенные триггеры и действия выполняются изначально в Azure Logic Apps, а управляемые соединители размещаются и запускаются с помощью общих ресурсов в Azure. Для стандартных рабочих процессов некоторые встроенные триггеры и действия в настоящее время недоступны, такие как скользящее окно, служба приложение Azure и Azure Управление API. Чтобы запустить рабочий процесс с сохранением или без сохранения состояния, используйте встроенный триггер, такой Запрос, Центры событий или Служебная шина. Триггер повторения доступен для рабочих процессов с отслеживанием состояния, но недоступен для рабочих процессов без отслеживания состояния. В конструкторе встроенные триггеры и действия отображаются с меткой "In-App ", а триггеры и действия управляемого соединителя отображаются с общей меткой.
Рабочие процессы без отслеживания состояния могут использовать только триггеры push-уведомлений, в которых не указывается расписание для выполнения рабочего процесса. Эти триггеры на основе веб-перехватчика ожидают, когда событие произойдет или данные становятся доступными. Например, триггер повторения доступен только для рабочих процессов с отслеживанием состояния. Чтобы запустить рабочий процесс, выберите триггер push-отправки, например запрос, центры событий или триггер служебная шина. Хотя вы можете включить управляемые соединители для рабочих процессов без отслеживания состояния, коллекция соединителей не отображает триггеры опроса управляемых соединителей для добавления.
Примечание.
Для локального запуска в Visual Studio Code для триггеров и действий на основе веб-перехватчика требуется дополнительная настройка. Дополнительные сведения см. в статье Создание рабочих процессов для одного клиента в редакторе Visual Studio Code.
Следующие триггеры и действия либо изменились, либо в настоящее время ограничены, неподдерживаются или недоступны:
Встроенное действие Функции Azure. Выбор функции Azure теперь Функции Azure операции — вызов функции Azure. В настоящее время это действие работает только для функций, созданных из шаблона Триггер HTTP.
На портале Azure можно выбрать функцию триггера HTTP, к которой необходимо получить доступ, создав соединение с помощью пользовательского интерфейса. Если проверить определение JSON действия функции в представлении кода или в файле workflow.json с помощью Visual Studio Code, действие будет ссылаться на функцию с использованием ссылки
connectionName. Эта версия абстрагирует сведения о функции в виде соединения, которое можно найти в файле проекта приложения логики connections.json, который доступен после создания соединения в редакторе Visual Studio Code.Примечание.
В модели с одним клиентом действие функции поддерживает только проверку подлинности строки запроса. Azure Logic Apps получает ключ по умолчанию из функции при подключении, сохраняет этот ключ в параметрах приложения и использует ключ для проверки подлинности при вызове функции.
Как и в мультитенантной модели, например при продлении этого ключа через Функции Azure интерфейс на портале, действие функции больше не работает из-за недопустимого ключа. Чтобы устранить эту проблему, необходимо повторно создать подключение к функции, которую необходимо вызвать, или обновить параметры приложения, указав новый ключ.
Встроенное действие Встроенный код представляет собой переименованное действие Операции встроенного кода; для него больше не требуется учетная запись и для него обновлены предельные значения.
Встроенное действие Azure Logic Apps — выбор рабочего процесса приложения логики теперь называется Операции рабочего процесса — вызов рабочего процесса в этом приложении рабочего процесса.
Сейчас соединитель Gmail не поддерживается.
Пользовательские управляемые соединители в настоящее время не поддерживаются. Однако можно создавать пользовательские встроенные операции при использовании редактора Visual Studio Code. Дополнительные сведения см. в статье Создание рабочих процессов для одного клиента в редакторе Visual Studio Code.
Рабочий процесс приложения логики уровня "Стандартный" может иметь только один триггер и не поддерживает несколько триггеров.
Проверка подлинности. В настоящее время для рабочих процессов уровня "Стандартный" недоступны следующие типы проверки подлинности:
Open Authentication (Microsoft Entra ID OAuth) для входящих вызовов триггеров на основе запросов, таких как триггер запроса и триггер веб-перехватчика HTTP.
Проверка подлинности управляемого удостоверения: доступна поддержка управляемого удостоверения, назначаемого системой, и назначаемого пользователем удостоверения. По умолчанию управляемое удостоверение, назначаемое системой, автоматически включается. Однако большинство встроенных соединителей на основе поставщиков услуг в настоящее время не поддерживают выбор управляемых удостоверений, назначенных пользователем для проверки подлинности.
Преобразование XML: в настоящее время поддерживается только XSLT 1.0.
Отладка с точками останова в Visual Studio Code. Хотя вы можете добавлять и использовать точки останова внутри файла workflow.json для рабочего процесса, точки останова пока поддерживаются только для действий, но не для триггеров. Дополнительные сведения см. в статье Создание рабочих процессов для одного клиента в редакторе Visual Studio Code.
Журнал триггеров и журнал выполнения. Для приложения логики уровня "Стандартный" журнал триггеров и журнал выполнения в портал Azure отображается на уровне рабочего процесса, а не на уровне ресурса приложения логики. Дополнительные сведения см. в статье Создание рабочих процессов для одного клиента на портале Azure.
Резервное копирование и восстановление журнала выполнения рабочего процесса. Стандартные приложения логики в настоящее время не поддерживают резервное копирование и восстановление для журнала выполнения рабочего процесса.
Шаблоны Terraform. Эти шаблоны нельзя использовать с ресурсом приложения логики "Стандартный" для полного развертывания инфраструктуры. Дополнительные сведения см. в статье "Что такое Terraform в Azure?
Azure Управление API. В настоящее время невозможно импортировать ресурс приложения логики уровня "Стандартный" в azure Управление API. Однако вы можете импортировать ресурс приложения логики потребления .
Ограничьте разрешения для сетевого трафика и брандмауэра
Если среда имеет строгие сетевые требования или брандмауэры, ограничивающие трафик, необходимо разрешить доступ для любых подключений триггеров или действий в рабочих процессах. При необходимости можно разрешить трафик из тегов служб и использовать тот же уровень ограничений или политик, что и Служба приложений Azure. Кроме того, необходимо найти и использовать полные доменные имена (FQDN) для подключений. Для получения дополнительных сведений ознакомьтесь с соответствующими разделами в следующих статьях документации.
- Разрешения брандмауэра для однотенантных приложений логики — портал Azure
- Разрешения брандмауэра для однотенантных приложений логики — Visual Studio Code
Следующие шаги
- Создание рабочих процессов для одного клиента на портале Azure
- Создание рабочих процессов для одного клиента в редакторе Visual Studio Code
Мы также хотели бы узнать о ваших впечатлениях от использования Azure Logic Apps с одним клиентом.
- При возникновении ошибок или проблем опубликуйте свою проблему на портале GitHub.
- Для вопросов, запросов, комментариев и других отзывов используйте эту форму обратной связи.