Partilhar via


Manipular mensagens grandes em fluxos de trabalho usando fragmentação nos Aplicativos Lógicos do Azure

Aplica-se a: Azure Logic Apps (Consumo e Standard)

Os Aplicativos Lógicos do Azure impõem limites de tamanho diferentes no conteúdo da mensagem que as operações podem manipular em fluxos de trabalho de aplicativos lógicos. Esses limites variam com base no tipo de recurso do aplicativo lógico e no ambiente onde um fluxo de trabalho é executado. Os limites também ajudam a reduzir qualquer sobrecarga resultante do armazenamento e processamento de mensagens grandes. Para obter mais informações sobre limites de tamanho de mensagem, consulte Limites de mensagem em Aplicativos Lógicos do Azure.

Se você usar ações HTTP internas ou ações específicas do conector gerenciado para trabalhar com mensagens maiores do que os limites padrão, poderá habilitar o fragmentamento. Essa abordagem divide uma mensagem grande em mensagens menores, para que você ainda possa transferir arquivos grandes sob condições específicas.

Para essas ações HTTP internas e ações específicas do conector gerenciado, a fragmentação é a única maneira pela qual os Aplicativos Lógicos do Azure podem consumir mensagens grandes. A troca de mensagens HTTP subjacente entre os Aplicativos Lógicos do Azure e outros serviços deve usar fragmentação de dados ou as conexões criadas pelos conectores geridos devem dar suporte à fragmentação de dados.

Observação

Devido ao aumento da sobrecarga da troca de várias mensagens, os Aplicativos Lógicos do Azure não oferecem suporte à fragmentação de gatilhos. Além disso, os Aplicativos Lógicos do Azure implementam o agrupamento para ações HTTP usando seu próprio protocolo, conforme descrito neste artigo. Mesmo que o seu sítio web ou serviço Web ofereça suporte a fragmentação de dados, eles não são compatíveis com fragmentação de ações HTTP.

Para usar o agrupamento de ações HTTP com seu site ou serviço Web, implemente o mesmo protocolo usado pelos Aplicativos Lógicos do Azure. Caso contrário, não habilite o agrupamento na ação HTTP.

Este artigo fornece uma visão geral sobre o significado de mensagens grandes, como o chunking funciona e como configurar o chunking em ações com suporte nos Aplicativos Lógicos do Azure.

O que torna as mensagens "grandes"?

As mensagens são consideradas grandes dependendo do serviço que as processa. O limite de tamanho exato em mensagens grandes difere entre os Aplicativos Lógicos do Azure e as ações do conector. Os Aplicativos Lógicos do Azure e os conectores não podem consumir diretamente mensagens grandes sem fragmentação.

Para o limite de tamanho de mensagem dos Aplicativos Lógicos do Azure, consulte Limites e configuração dos Aplicativos Lógicos do Azure. Para o limite de tamanho de mensagem de cada conector, consulte Referência do conector.

Tratamento de mensagens em bloco para Aplicativos Lógicos do Azure

Azure Logic Apps não podem usar diretamente saídas de mensagens fragmentadas que sejam maiores do que o limite de tamanho da mensagem. Somente ações que suportam fragmentação podem acessar o conteúdo da mensagem nessas saídas. Uma ação que lida com mensagens grandes deve atender a um dos seguintes critérios:

  • A ação deve suportar nativamente a fragmentação de dados quando pertence a um conector.
  • A ação deve ter o suporte a fragmentação habilitado na configuração de tempo de execução dessa ação.

Caso contrário, você receberá um erro de tempo de execução ao tentar acessar uma saída de conteúdo grande.

Tratamento de mensagens fragmentadas para conectores

Os serviços que se comunicam com os Aplicativos Lógicos do Azure podem ter seus próprios limites de tamanho de mensagem. Esses limites geralmente são menores do que o limite dos Aplicativos Lógicos do Azure. Por exemplo, se um conector der suporte a fragmentação, um conector poderá considerar uma mensagem de 30 MB como grande, enquanto os Aplicativos Lógicos do Azure não. Para cumprir o limite desse conector, os Aplicativos Lógicos do Azure dividem qualquer mensagem maior que 30 MB em partes menores.

Para conectores que suportam fragmentação, o protocolo de fragmentação subjacente é invisível para os usuários finais. Nem todos os conectores suportam fragmentação. Os conectores que não oferecem suporte geram erros de tempo de execução quando as mensagens recebidas excedem os limites de tamanho do conector.

Para ações que suportam e estão ativadas para fragmentação, não é possível utilizar corpos de acionamento, variáveis e expressões como triggerBody()?['Content']. O uso de qualquer uma dessas entradas impede que a operação de fragmentação aconteça. Em vez disso, use a ação Compor. Especificamente, crie um body campo usando a ação Compor para armazenar os dados de saída do corpo do acionador, variável, expressão, e assim por diante, por exemplo:

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

Para fazer referência aos dados, na ação de fragmentação, use a expressão body('Compose'), por exemplo:

"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"
},

Configurar divisão em blocos sobre HTTP

Em cenários HTTP genéricos, você pode dividir grandes downloads e uploads de conteúdo por HTTP para que seu fluxo de trabalho possa trocar mensagens grandes com um ponto de extremidade externo. Você deve dividir as mensagens da maneira que os Aplicativos Lógicos do Azure esperam.

Se um endereço externo estiver configurado para dividir downloads ou uploads em partes, as ações HTTP no seu fluxo de trabalho dividirão automaticamente mensagens grandes. Caso contrário, deve configurar o suporte de fragmentação no endpoint. Se você não possui ou controla o ponto de extremidade, talvez não consiga configurar o fragmentamento.

Se uma ação HTTP ainda não tiver o chunking habilitado, você deverá configurar o chunking através da propriedade da runTimeConfiguration ação. Você pode configurar essa propriedade na definição de ação usando o editor de exibição de código, conforme descrito mais tarde, ou no designer de fluxo de trabalho, conforme descrito aqui:

  1. No designer, selecione a ação HTTP para abrir o painel de informações da ação e, em seguida, selecione Configurações.

  2. Em Transferência de conteúdo, defina Permitir fragmentação como Ativado.

    A captura de tela mostra as configurações de uma ação HTTP, com a opção Permitir fragmentação selecionada. Ative o chunking.

  3. Para concluir a configuração de chunking para downloads ou uploads, prossiga com as seções seguintes.

Baixar conteúdo em partes

Quando você baixa conteúdo de um ponto de extremidade externo usando uma solicitação HTTP GET, muitos pontos de extremidade externos enviam mensagens grandes automaticamente em partes. Esse comportamento requer que o ponto de extremidade ofereça suporte a solicitações de conteúdo parciais ou downloads fragmentados. Portanto, se uma ação no seu fluxo de trabalho enviar uma solicitação HTTP GET para fazer o download de conteúdo de um ponto de extremidade externo e o ponto de extremidade responder com o código de status 206 Conteúdo Parcial, a resposta conterá conteúdo em partes segmentadas.

Os Aplicativos Lógicos do Azure não podem controlar se um ponto de extremidade externo dá suporte a solicitações de conteúdo parcial. Quando a ação solicitante no seu fluxo de trabalho recebe a primeira resposta com o código de status 206 Conteúdo Parcial, essa ação envia automaticamente várias solicitações para baixar todo o conteúdo.

Para verificar se um ponto de extremidade externo suporta conteúdo parcial, envie uma solicitação HTTP HEAD, que solicita uma resposta apenas com a linha de status e a seção de cabeçalho, omitindo o corpo da resposta. Essa solicitação ajuda a determinar se a resposta contém o Accept-Ranges cabeçalho.

Se o ponto de extremidade oferecer suporte a conteúdo parcial como downloads em partes, mas não enviar conteúdo em partes, você poderá sugerir essa opção definindo o Range cabeçalho em sua solicitação HTTP GET.

As etapas a seguir descrevem o processo que os Aplicativos Lógicos do Azure usam para baixar conteúdo em partes de um ponto de extremidade externo para seu fluxo de trabalho:

  1. No seu fluxo de trabalho, uma ação envia uma solicitação HTTP GET para o endpoint.

    O cabeçalho da solicitação pode, opcionalmente, incluir um Range campo que descreve um intervalo de bytes para solicitar blocos de conteúdo.

  2. O endpoint responde com o código de estado 206 e o corpo da mensagem HTTP.

    Os detalhes sobre o conteúdo deste bloco aparecem no cabeçalho da Content-Range resposta. Esses detalhes incluem informações que ajudam os Aplicativos Lógicos do Azure a determinar o início e o fim do bloco, além do tamanho total de todo o conteúdo antes do fragmentamento.

  3. A ação envia automaticamente solicitações HTTP GET de acompanhamento até que todo o conteúdo seja recuperado.

Por exemplo, a definição de ação a seguir mostra uma solicitação HTTP GET que define o Range cabeçalho. O cabeçalho sugere que o ponto de extremidade deve responder com conteúdo fragmentado:

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

A solicitação GET define o cabeçalho Range como bytes=0-1023 para especificar o intervalo de bytes. Se o ponto de extremidade suportar solicitações de conteúdo parcial, o ponto de extremidade responderá com um bloco de conteúdo do intervalo solicitado. Com base no ponto de extremidade, o formato exato do Range campo de cabeçalho pode diferir.

Carregar conteúdo em partes

Para carregar conteúdo em partes a partir de uma ação HTTP, você deve configurar o suporte a fragmentação definindo a propriedade da runtimeConfiguration ação. Essa configuração permite que a ação inicie o protocolo de fragmentação.

A ação pode então enviar uma mensagem inicial POST ou PUT para o ponto de extremidade externo. Depois que o endpoint responde com um tamanho de fatia sugerido, a ação continua enviando solicitações HTTP PATCH que contêm as fatias de conteúdo.

As etapas a seguir descrevem o processo detalhado que os Aplicativos Lógicos do Azure usam para carregar conteúdo em partes de uma ação em seu fluxo de trabalho para um ponto de extremidade externo:

  1. No seu fluxo de trabalho, uma ação envia uma solicitação HTTP POST ou PUT inicial com um corpo de mensagem vazio.

    O cabeçalho da solicitação inclui as seguintes informações sobre o conteúdo que seu aplicativo lógico deseja carregar em partes:

    Campo de cabeçalho da solicitação Valor Tipo Descrição
    x-ms-transfer-mode fragmentado Cordão Indica que o conteúdo é carregado em partes
    x-ms-content-length < content-length> Número inteiro O tamanho total do conteúdo em bytes antes de fragmentar
  2. O endpoint responde com o código de sucesso 200 e as seguintes informações:

    Campo de cabeçalho de resposta do endpoint Tipo Obrigatório Descrição
    Localização Cordão Yes O local da URL para onde enviar as mensagens HTTP PATCH
    x-ms-chunk-size Número inteiro Não O tamanho de bloco sugerido em bytes
  3. A ação de fluxo de trabalho cria e envia mensagens HTTP PATCH de acompanhamento, cada uma com as seguintes informações:

    • Um bloco de conteúdo baseado em x-ms-chunk-size ou algum tamanho calculado internamente até que todo o conteúdo que totaliza x-ms-content-length seja carregado sequencialmente

    • As seguintes informações de cabeçalho sobre o bloco de conteúdo enviado em cada mensagem PATCH:

      Campo de cabeçalho da solicitação Valor Tipo Descrição
      Intervalo de conteúdo < gama> Cordão O intervalo de bytes para o bloco de conteúdo atual, incluindo o valor inicial, o valor final e o tamanho total do conteúdo, por exemplo: bytes=0-1023/10100
      Tipo de conteúdo < tipo de conteúdo> Cordão O tipo de conteúdo fragmentado
      Content-Length < Content-Length> Cordão O comprimento do tamanho em bytes do bloco atual
  4. Após cada solicitação PATCH, o endpoint confirma o recebimento de cada fragmento respondendo com o código de status 200 e os seguintes cabeçalhos de resposta:

    Campo de cabeçalho de resposta do endpoint Tipo Obrigatório Descrição
    Intervalo Cordão Yes O intervalo de bytes para o conteúdo recebido pelo ponto de extremidade, por exemplo: bytes=0-1023
    x-ms-chunk-size Número inteiro Não O tamanho de bloco sugerido em bytes

Por exemplo, a definição de ação a seguir mostra uma solicitação HTTP POST para transferir conteúdo fragmentado para um endpoint. Na propriedade da runTimeConfiguration ação, a contentTransfer propriedade define transferMode como chunked:

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