Обработка больших сообщений в рабочих процессах с помощью фрагментирования в Azure Logic Apps

Статья
2025-04-18

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

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

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

Замечание

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

В этой статье содержатся общие сведения о том, как работает блокирование в Azure Logic Apps и как настроить блоки для поддерживаемых действий.

Что делает сообщения "большими"?

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

Обработка блокированных сообщений для Azure Logic Apps

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

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

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

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

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

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

Для действий, поддерживающих и включенных для блокирования, нельзя использовать тела триггеров, переменные и выражения, такие как triggerBody()?['Content'] использование любого из этих входных данных, не позволяет выполнять операцию блокирования. Вместо этого используйте действие Compose. В частности, необходимо создать body поле с помощью действия Compose для хранения выходных данных из тела триггера, переменной, выражения и т. д., например:

"Compose": {
    "inputs": {
        "body": "@variables('myVar1')"
    },
    "runAfter": {
        "Until": [
            "Succeeded"
        ]
    },
    "type": "Compose"
},

Чтобы ссылаться на данные, в действии сегментации используйте выражение body('Compose'), например:

"Create_file": {
    "inputs": {
        "body": "@body('Compose')",
        "headers": {
            "ReadFileMetadataFromServer": true
        },
        "host": {
            "connection": {
                "name": "@parameters('$connections')['sftpwithssh_1']['connectionId']"
            }
        },
        "method": "post",
        "path": "/datasets/default/files",
        "queries": {
            "folderPath": "/c:/test1/test1sub",
            "name": "tt.txt",
            "queryParametersSingleEncoded": true
        }
    },
    "runAfter": {
        "Compose": [
            "Succeeded"
        ]
    },
    "runtimeConfiguration": {
        "contentTransfer": {
            "transferMode": "Chunked"
        }
    },
    "type": "ApiConnection"
},

Настройка фрагментирования по протоколу HTTP

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

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

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

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

Скачивание содержимого в блоках

Многие конечные точки автоматически отправляют большие сообщения в блоки при скачивании через HTTP-запрос GET. Чтобы скачать фрагментированные сообщения из конечной точки по протоколу HTTP, конечная точка должна поддерживать частичные запросы содержимого или фрагментированные загрузки. Когда приложение логики отправляет HTTP-запрос GET в конечную точку для скачивания содержимого, а конечная точка отвечает с кодом состояния "206", ответ содержит фрагментированное содержимое. Azure Logic Apps не может контролировать, поддерживает ли конечная точка частичные запросы. Однако, когда приложение логики получает первый ответ "206", приложение логики автоматически отправляет несколько запросов для скачивания всего содержимого.

Чтобы проверить, может ли конечная точка поддерживать частичное содержимое, отправьте запрос HEAD. Этот запрос помогает определить, содержит ли ответ заголовок Accept-Ranges. Таким образом, если конечная точка поддерживает фрагментированные скачиваемые файлы, но не отправляет фрагментированного содержимого, можно предложить этот параметр, задав Range заголовок в HTTP-запросе GET.

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

Рабочий процесс отправляет HTTP-запрос GET в конечную точку.

Заголовок запроса может опционально включать Range поле, описывающее диапазон байтов для запроса частей содержимого.
Конечная точка отвечает с кодом состояния "206" и текстом HTTP-сообщения.

Сведения о содержимом этого блока отображаются в заголовке ответа Content-Range . Эти сведения включают сведения, помогающие Azure Logic Apps определить начало и конец блока, а также общий размер всего содержимого перед фрагментированием.
Приложение логики автоматически отправляет последующие HTTP-запросы GET.

Приложение логики отправляет последующие запросы GET до получения всего содержимого.

Например, это определение действия демонстрирует HTTP-запрос GET, который устанавливает заголовок Range. Заголовок предполагает, что конечная точка должна отвечать фрагментированным содержимом:

"getAction": {
    "inputs": {
        "headers": {
            "Range": "bytes=0-1023"
        },
       "method": "GET",
       "uri": "http://myAPIendpoint/api/downloadContent"
    },
    "runAfter": {},
    "type": "Http"
}

Запрос GET задает заголовок "Range" со значением "байты=0-1023", что соответствует диапазону байтов. Если конечная точка поддерживает запросы на частичное содержимое, конечная точка отвечает с фрагментом содержимого из запрошенного диапазона. В зависимости от конечной точки, точный формат поля заголовка "Range" может отличаться.

Отправка содержимого в блоках

Чтобы отправить фрагментированный контент из действия HTTP, действие должно включить поддержку фрагментации через свойство действия runtimeConfiguration. Этот параметр позволяет действию запустить протокол сегментации. Затем приложение логики может отправить исходное сообщение POST или PUT в целевую конечную точку. После того как конечная точка ответит с предложенным размером блока, приложение логики продолжает, отправляя HTTP-запросы PATCH, которые содержат фрагменты содержимого.

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

Рабочий процесс отправляет исходный запрос HTTP POST или PUT с пустым текстом сообщения.

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

Поле заголовка запроса	Ценность	Тип	Описание
X-ms-transfer-mode	разбитый на части	Струна	Указывает, что содержимое отправляется в блоки
x-ms-content-length	< длина содержимого>	Целое число	Весь размер содержимого в байтах перед разбиением на части

Конечная точка отвечает кодом статуса успешного выполнения «200» и следующей информацией:

Поле заголовка ответа конечной точки	Тип	Обязательно	Описание
Местонахождение	Струна	Да	Расположение URL-адреса для отправки сообщений HTTP PATCH
x-ms-chunk-size	Целое число	нет	Предлагаемый размер блока в байтах

Рабочий процесс создает и отправляет последующие сообщения HTTP PATCH— каждый из которых содержит следующие сведения:

Блок содержимого, основанный на x-ms-chunk-size или некотором внутреннем вычисляемом размере, будет последовательно загружаться до тех пор, пока все содержимое не достигнет итоговой длины, равной значению x-ms-content-length.

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

Поле заголовка запроса	Ценность	Тип	Описание
Диапазон содержимого	< диапазон>	Струна	Диапазон байтов для текущего блока содержимого, включая начальное значение, конечное значение и общий размер содержимого, например "байт=0-1023/10100".
Тип содержимого	< тип контента>	Струна	Тип фрагментированного содержимого
Длина содержимого	< длина содержимого>	Струна	Размер текущего блока в байтах

После каждого запроса PATCH конечная точка подтверждает получение каждого блока, отвечая кодом состояния "200" и следующими заголовками ответа:

Поле заголовка ответа конечной точки	Тип	Обязательно	Описание
Диапазон	Струна	Да	Диапазон байтов для содержимого, полученного конечной точкой, например "байт=0-1023"
x-ms-chunk-size	Целое число	нет	Предлагаемый размер блока в байтах

Например, это определение действия показывает HTTP-запрос POST для отправки фрагментированного содержимого в конечную точку. В свойстве runTimeConfiguration действия contentTransfer задается transferMode на chunked:

"postAction": {
    "runtimeConfiguration": {
        "contentTransfer": {
            "transferMode": "chunked"
        }
    },
    "inputs": {
        "method": "POST",
        "uri": "http://myAPIendpoint/api/action",
        "body": "@body('getAction')"
    },
    "runAfter": {
    "getAction": ["Succeeded"]
    },
    "type": "Http"
}