Что такое соединители в Azure Logic Apps
При создании рабочего процесса с помощью Azure Logic Apps можно использовать соединитель для работы с данными, событиями и ресурсами в других приложениях, службах, системах и платформах без написания кода. Соединитель предоставляет одну или несколько предварительно созданных операций, которые используются в качестве шагов в рабочем процессе.
В соединителе каждая операция — это условие триггера , которое запускает рабочий процесс или последующее действие , выполняющее определенную задачу, а также свойства, которые можно настроить. Хотя многие соединители имеют триггеры и действия, некоторые соединители предлагают только триггеры, а другие предоставляют только действия.
В Azure Logic Apps соединители доступны в встроенной версии, управляемой версии или обоих. Многие соединители обычно требуют, чтобы сначала создать и настроить подключение к базовой службе или системе, чтобы можно было пройти проверку подлинности доступа к учетной записи пользователя. Если соединитель недоступен для службы или системы, к которой вы хотите получить доступ, можно отправить запрос с помощью универсальной операции HTTP или создать пользовательский соединитель.
В этом обзоре представлены общие сведения о соединителях и принципы их работы. Дополнительные сведения о соединителе см. в следующей документации:
- Общие сведения о соединителях для таких служб, как Power Automate и Power Apps
- Общие сведения о встроенных соединителях для Azure Logic Apps
- Общие сведения об управляемых соединителях для Azure Logic Apps
- Справочник по управляемым соединителям для Azure Logic Apps
Встроенные соединители и управляемые соединители
В Azure Logic Apps соединители являются встроенными или управляемыми. Некоторые соединители имеют обе версии. Доступные версии зависят от того, создаете рабочий процесс приложения логики потребления , который выполняется в мультитенантном рабочем процессе Azure Logic Apps или рабочем процессе приложения логики уровня "Стандартный ", который выполняется в azure Logic Apps с одним клиентом. Дополнительные сведения о типах ресурсов приложения логики см. в разделе "Типы ресурсов" и различия среды узла.
Встроенные соединители предназначены для непосредственного и собственного запуска в Azure Logic Apps.
Управляемые соединители развертываются, размещаются и управляются в Azure корпорацией Майкрософт. Управляемые соединители в основном предоставляют прокси-сервер или оболочку вокруг API, используемого базовой службой или системой для взаимодействия с Azure Logic Apps.
В рабочем процессе потребления управляемые соединители отображаются в конструкторе под метками Standard или Enterprise на основе их ценовой категории.
В рабочем процессе "Стандартный" все управляемые соединители отображаются в конструкторе под меткой Azure .
Дополнительные сведения см. в следующей документации:
Триггеры
Триггер указывает условие, которое должно соответствовать рабочему процессу, и всегда является первым шагом в любом рабочем процессе. Каждый триггер также следует определенному шаблону срабатывания, который управляет тем, как триггер отслеживает события и реагирует на них. Обычно триггер следует шаблону опроса или шаблону push-отправки . Иногда доступны обе версии триггеров.
Опрашивающие триггеры регулярно проверяют определенную службу или систему по указанному расписанию, чтобы определить наличие новых данных или определенного события. Если доступны новые данные или произошло определенное событие, эти триггеры создают и запускают новый экземпляр рабочего процесса. Новый экземпляр затем использует данные, передаваемые в качестве входных.
Примечание.
Для соединителей, управляемых Корпорацией Майкрософт, размещенных и работающих в Azure, триггеры опроса используют только значения интервала и частоты для вычисления следующего повторения. Они не используют расширенные параметры планирования, такие как "В эти часы " и "В эти дни". Эти параметры работают только со встроенными триггерами опроса, которые выполняются непосредственно с средой выполнения Azure Logic Apps, такими как повторение, скользящее окно и триггеры HTTP .
Триггеры push-перехватчика или веб-перехватчики прослушивают новые данные или событие, не выполняя опрос. Если доступны новые данные или произошло определенное событие, эти триггеры создают и запускают новый экземпляр рабочего процесса. Новый экземпляр затем использует данные, передаваемые в качестве входных.
Например, предположим, что вы хотите создать рабочий процесс, который выполняется при отправке файла на FTP-сервер. В качестве первого шага рабочего процесса можно добавить триггер FTP с именем "При добавлении или изменении файла", который следует шаблону опроса. Затем вы указываете расписание для регулярной проверки событий отправки.
При срабатывании триггера триггер обычно передает выходные данные событий для последующих действий для ссылки и использования. В примере FTP триггер автоматически выводит такие сведения, как имя файла и путь. Вы также можете настроить триггер для включения содержимого файла. Таким образом, для обработки этих данных необходимо добавить действия в рабочий процесс.
Действия
Действие указывает задачу для выполнения и всегда отображается в качестве последующего шага в рабочем процессе. В рабочем процессе можно использовать несколько действий. Например, можно запустить рабочий процесс с триггером SQL Server, который проверяет наличие новых данных клиента в базе данных SQL. После триггера рабочий процесс может иметь действие SQL Server, которое получает данные клиента. После этого действия SQL Server рабочий процесс может использовать другое действие, которое обрабатывает данные, например действие "Операции данных", которое создает таблицу CSV.
Разрешения подключения
В рабочем процессе приложения логики потребления, прежде чем создавать ресурсы приложения логики, рабочие процессы и их подключения, вам потребуются определенные разрешения. Дополнительные сведения об этих разрешениях см. в статье "Безопасные операции — безопасный доступ и данные" в Azure Logic Apps.
Создание подключения, настройка и проверка подлинности
Прежде чем использовать операции соединителя в рабочем процессе, многие соединители должны сначала создать подключение к целевой службе или системе. Чтобы создать подключение из конструктора рабочих процессов, необходимо выполнить проверку подлинности удостоверения с учетными данными учетной записи и иногда другими сведениями о подключении.
Например, прежде чем ваш рабочий процесс сможет получить доступ к учетной записи электронной почты Office 365 Outlook и работать с ней, необходимо авторизовать подключение для этой учетной записи. Для некоторых встроенных соединителей и управляемых соединителей можно настроить и применить управляемое удостоверение для проверки подлинности вместо предоставления учетных данных.
Несмотря на то, что подключения создаются внутри рабочего процесса, они представляют собой отдельные ресурсы Azure с собственными определениями. Чтобы просмотреть эти определения ресурсов подключения, выполните следующие действия в зависимости от того, есть ли у вас рабочий процесс "Потребление" или "Стандартный":
Потребление
Сведения о просмотре этих подключений и управлении ими в портал Azure см. в разделе "Просмотр подключений для рабочих процессов потребления" в портал Azure.
Сведения о просмотре и управлении этими подключениями в Visual Studio см. в статье "Управление рабочими процессами потребления" с помощью Visual Studio и скачивание ресурса приложения логики из Azure в Visual Studio.
Дополнительные сведения об определениях ресурсов подключения для рабочих процессов потребления см. в определениях ресурсов подключения.
Стандартные
Сведения о просмотре и управлении этими подключениями в портал Azure см. в разделе "Просмотр подключений для стандартных рабочих процессов" в портал Azure.
Сведения о просмотре и управлении этими подключениями в Visual Studio Code см. в статье "Просмотр рабочего процесса приложения логики" в Visual Studio Code. Файл connections.json содержит необходимую конфигурацию для подключений, создаваемых соединителями.
Безопасность и шифрование подключения
Сведения о конфигурации подключений, такие как адрес сервера, имя пользователя и пароль, учетные данные и секреты, шифруются и хранятся в защищенной среде Azure. Эти сведения можно использовать только в ресурсах приложений логики и в клиентах с разрешениями на ресурс подключения, которые применяются через связанные проверки доступа. Подключения, использующие открытую проверку подлинности Microsoft Entra ID (Microsoft Entra ID OAuth), такие как Office 365, Salesforce и GitHub, требуют входа, но Azure Logic Apps сохраняет только маркеры доступа и обновления как секреты, а не учетные данные входа.
Установленные подключения могут обращаться к целевой службе или системе в течение времени, допустимого для этой службы или системы. Для служб, использующих подключения OAuth с идентификатором Microsoft Entra ID, например Office 365 и Dynamics, Azure Logic Apps обновляет маркеры доступа на неопределенный срок. Другие службы могут иметь ограничения по времени, в течение которого Logic Apps может использовать маркер без обновления. Некоторые действия, например изменение пароля, делают недействительными все маркеры доступа.
Примечание.
Если в вашей организация запрещен доступ к конкретным ресурсам через соединители Logic Apps, вы можете заблокировать возможность создания таких подключений с помощью Политики Azure.
Дополнительные сведения о защите рабочих процессов и подключений приложений логики см. в статье "Безопасный доступ и данные" в Azure Logic Apps.
Доступ через брандмауэр для подключений
Если вы используете брандмауэр, ограничивающий трафик, и для рабочего процесса приложения логики требуется обмен данными через брандмауэр, нужно разрешить на этом брандмауэре доступ к входящим и исходящим IP-адресам службы Logic Apps или среды выполнения в том регионе Azure, где размещены рабочие процессы приложения логики.
Если рабочие процессы также используют управляемые соединители, такие как соединитель Outlook Office 365 или соединитель SQL, или пользовательские соединители, брандмауэр также должен разрешить доступ ко всем исходящим IP-адресам управляемого соединителя в регионе Azure приложения логики. Дополнительные сведения см. в разделе "Конфигурация брандмауэра".
Пользовательские соединители и интерфейсы API
В рабочих процессах потребления для мультитенантных azure Logic Apps можно вызывать ИНТЕРФЕЙСы API на основе Swagger или SOAP, которые недоступны как встроенные соединители. Вы также можете запустить пользовательский код, создав пользовательские приложения API. Дополнительные сведения см. в следующей документации:
Пользовательские соединители на основе Swagger или SOAP для рабочих процессов потребления
Создайте настраиваемый соединитель на основе Swagger или SOAP, который делает эти API доступными для любого рабочего процесса приложения логики потребления в подписке Azure.
Чтобы пользовательские приложения API или соединители были доступными для любого пользователя в Azure, отправьте соединители на сертификацию Майкрософт.
В рабочих процессах уровня "Стандартный" для Azure Logic Apps можно создавать собственные встроенные соединители на основе поставщика служб, доступные для любого рабочего процесса приложения логики "Стандартный". Дополнительные сведения см. в следующей документации:
Настраиваемые соединители на основе поставщика услуг для стандартных рабочих процессов
Создание настраиваемых соединителей на основе поставщика услуг для стандартных рабочих процессов
Известные проблемы
В следующей таблице содержатся известные проблемы для соединителей в Azure Logic Apps:
Сообщение об ошибке | Описание | Решение |
---|---|---|
Error: BadGateway. Client request id: '{GUID}' |
Эта ошибка приводит к обновлению тегов в ресурсе приложения логики, где одно или несколько подключений не поддерживают проверку подлинности OAuth Microsoft Entra ID, например SFTP ad SQL, нарушая эти подключения. | Чтобы это предотвратить, старайтесь не обновлять эти теги. |