Настраиваемые соединители в Azure Logic Apps

  • Статья

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

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

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

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

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

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

Приложения логики потребления

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

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

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

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

Встроенные соединители на основе поставщика службы

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

Напротив, встроенные соединители, не являющиеся поставщиками услуг, имеют следующие атрибуты:

  • Не основан на модели расширяемости Функций Azure.

  • Напрямую реализуется как задание в среде выполнения Azure Logic Apps, например как операции расписания, HTTP, запросов или XML.

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

В следующем разделе более подробно описаны принципы работы модели расширяемости для настраиваемых встроенных соединителей.

Модель расширяемости встроенных соединителей

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

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

Концептуальная схема, демонстрирующая инфраструктуру поставщиков служб на основе Функций Azure.

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

IServiceOperationsProvider

Этот интерфейс содержит методы, предоставляющие манифест операций для настраиваемого встроенного соединителя.

  • Манифест операций

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

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

    Дополнительные сведения об этих методах и их реализации см. в разделе Методы реализации далее в этой статье.

  • Вызовы операций

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

    • Если триггер основан на Функциях Azure, среда выполнения в Azure Logic Apps будет использовать метод GetBindingConnectionInformation() для предоставления необходимых параметров подключения привязке триггера Функций Azure.

    • Если соединитель содержит действия, среда выполнения будет использовать метод InvokeOperation() для вызова каждого действия в соединителе, совершенного во время выполнения рабочего процесса. Если это не так, реализовывать этот метод не нужно.

Дополнительные сведения об этих методах и их реализации см. в разделе Методы реализации далее в этой статье.

IServiceOperationsTriggerProvider

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

  • Метод GetFunctionTriggerType() необходим для возврата строки с тем же параметром type, что и у привязки триггера Функций Azure.

  • У GetFunctionTriggerDefinition() есть реализация по умолчанию, поэтому явно реализовывать этот метод не нужно. Однако, если необходимо обновить поведение триггера по умолчанию, например предоставить дополнительные параметры, не указанные в конструкторе, можно реализовать этот метод и переопределить поведение по умолчанию.

Методы реализации

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

GetService()

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

public ServiceOperationApi GetService()
{
   return this.{custom-service-name-apis}.ServiceOperationServiceApi();
}

Дополнительные сведения см. в примере CosmosDbServiceOperationProvider.cs.

GetOperations()

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

public IEnumerable<ServiceOperation> GetOperations(bool expandManifest)
{
   return expandManifest ? serviceOperationsList : GetApiOperations();
}

Дополнительные сведения см. в примере CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

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

public string GetBindingConnectionInformation(string operationId, InsensitiveDictionary<JToken> connectionParameters)
{
   return ServiceOperationsProviderUtilities
      .GetRequiredParameterValue(
         serviceId: ServiceId,
         operationId: operationID,
         parameterName: "connectionString",
         parameters: connectionParameters)?
      .ToValue<string>();
}

Дополнительные сведения см. в примере CosmosDbServiceOperationProvider.cs.

InvokeOperation()

Если настраиваемый встроенный соединитель содержит только триггер, реализовывать этот метод не нужно. Однако, если соединитель содержит действия, необходимо реализовать метод InvokeOperation(), который вызывается для каждого действия в соединителе, совершенного во время выполнения рабочего процесса. Можно использовать любой клиент, например FTPClient, HTTPClient и т. д., в зависимости от требований действий соединителя. В этом примере используется HTTPClient.

public Task<ServiceOperationResponse> InvokeOperation(string operationId, InsensitiveDictionary<JToken> connectionParameters, ServiceOperationRequest serviceOperationRequest)
{
   using (var client = new HttpClient())
   {
      response = client.SendAsync(httpRequestMessage).ConfigureAwait(false).ToJObject();
   }
   return new ServiceOperationResponse(body: response);
}

Дополнительные сведения см. в примере CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

Чтобы использовать в соединителе триггер на основе Функций Azure, необходимо вернуть строку, которая совпадает с параметром type в привязке триггера Функций Azure.

В следующем примере возвращается строка для стандартного встроенного триггера Azure Cosmos DB "type": "cosmosDBTrigger":

public string GetFunctionTriggerType()
{
   return "CosmosDBTrigger";
}

Дополнительные сведения см. в примере CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerDefinition()

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

Дальнейшие действия

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