Partager via


Gérer les messages volumineux dans les flux de travail à l’aide d’une segmentation dans Azure Logic Apps

S’applique à : Azure Logic Apps (Consommation + Standard)

Azure Logic Apps place des limites de taille différentes sur le contenu du message que les opérations peuvent gérer dans les flux de travail d’application logique. Ces limites varient en fonction du type de ressource d’application logique et de l’environnement dans lequel un flux de travail s’exécute. Les limites permettent également de réduire toute surcharge résultant du stockage et du traitement de messages volumineux. Pour plus d’informations sur les limites de taille des messages, consultez Limites des messages dans Azure Logic Apps.

Si vous utilisez des actions HTTP intégrées ou des actions de connecteur managé spécifiques pour travailler avec des messages supérieurs aux limites par défaut, vous pouvez activer la segmentation. Cette approche fractionne un message volumineux en messages plus petits, ce qui vous permet de transférer des fichiers volumineux dans des conditions spécifiques.

Pour ces actions HTTP intégrées et les actions de connecteur managé spécifiques, la segmentation est la seule façon dont Azure Logic Apps peut consommer des messages volumineux. Soit l’échange de messages HTTP sous-jacent entre Azure Logic Apps et d’autres services doit utiliser la segmentation, soit les connexions créées par les connecteurs managés doivent prendre en charge la segmentation.

Remarque

En raison d’une surcharge accrue de l’échange de plusieurs messages, Azure Logic Apps ne prend pas en charge la segmentation sur les déclencheurs. En outre, Azure Logic Apps implémente la segmentation pour les actions HTTP à l’aide de son propre protocole, comme décrit dans cet article. Même si votre site web ou service web prend en charge la segmentation, ils ne fonctionnent pas avec la segmentation des actions HTTP.

Pour utiliser la segmentation d’actions HTTP avec votre site web ou service web, implémentez le même protocole que celui utilisé par Azure Logic Apps. Sinon, n’activez pas la segmentation sur l’action HTTP.

Cet article fournit une vue d’ensemble de ce que signifient les messages volumineux, le fonctionnement de la segmentation et la configuration de la segmentation sur les actions prises en charge dans Azure Logic Apps.

Qu’est-ce qui rend les messages « volumineux » ?

Les messages sont volumineux en fonction du service qui gère ces messages. La limite de taille exacte des messages volumineux diffère entre les actions d’Azure Logic Apps et de connecteur. Azure Logic Apps et les connecteurs ne peuvent pas consommer directement de messages volumineux sans segmentation.

Pour connaître la limite de taille des messages Azure Logic Apps, consultez les limites et la configuration d’Azure Logic Apps. Pour connaître la limite de taille des messages de chaque connecteur, consultez la référence du connecteur.

Gestion des messages en bloc pour Azure Logic Apps

Azure Logic Apps ne peut pas utiliser directement les sorties des messages segmentés qui sont supérieurs à la limite de taille des messages. Seules les actions qui prennent en charge la segmentation peuvent accéder au contenu du message dans ces sorties. Une action qui gère les messages volumineux doit répondre à l’un des critères suivants :

  • L’action doit prendre en charge la segmentation en mode natif lorsque cette action appartient à un connecteur.
  • L’action doit avoir la prise en charge de la segmentation activée dans la configuration du runtime de cette action.

Sinon, vous obtenez une erreur d’exécution lorsque vous essayez d’accéder à une sortie de contenu volumineux.

Gestion des messages en bloc pour les connecteurs

Les services qui communiquent avec Azure Logic Apps peuvent avoir leurs propres limites de taille de message. Ces limites sont souvent plus petites que la limite Azure Logic Apps. Par exemple, si un connecteur prend en charge la segmentation, un connecteur peut considérer un message de 30 Mo comme volumineux, alors qu’Azure Logic Apps ne le fait pas. Pour respecter la limite de ce connecteur, Azure Logic Apps fractionne tout message de plus de 30 Mo en blocs plus petits.

Pour les connecteurs qui prennent en charge la segmentation, le protocole de segmentation sous-jacent est invisible pour les utilisateurs finaux. Tous les connecteurs ne prennent pas en charge la segmentation. Les connecteurs qui ne le prennent pas en charge génèrent des erreurs d’exécution lorsque les messages entrants dépassent les limites de taille du connecteur.

Pour les actions prenant en charge et activées pour le découpage, vous ne pouvez pas utiliser les corps de déclencheur, les variables et les expressions telles que triggerBody()?['Content']. L’utilisation de l’une de ces entrées empêche l’opération de segmentation de se produire. Utilisez plutôt l’action Composer. Plus précisément, créez un body champ à l’aide de l’action Compose pour stocker la sortie des données à partir du corps du déclencheur, de la variable, de l’expression, et ainsi de suite, par exemple :

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

Pour référencer les données, dans l’action de segmentation, utilisez l’expression body('Compose'), par exemple :

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

Configurer la segmentation sur HTTP

Dans les scénarios HTTP génériques, vous pouvez fractionner les téléchargements de contenu volumineux et les charger sur HTTP afin que votre flux de travail puisse échanger des messages volumineux avec un point de terminaison externe. Vous devez segmenter les messages de la façon dont Azure Logic Apps s’attend.

Si un point de terminaison externe est configuré pour segmenter les téléchargements ou les chargements, les actions HTTP dans votre workflow segmentent automatiquement les messages volumineux. Dans le cas contraire, vous devez configurer la prise en charge de la segmentation sur le point de terminaison. Si vous ne possédez pas ou ne contrôlez pas le point de terminaison, vous ne pourrez peut-être pas configurer la segmentation.

Si une action HTTP n’a pas encore activé la segmentation, vous devez configurer la segmentation par le biais de la propriété de runTimeConfiguration l’action. Vous pouvez configurer cette propriété dans la définition d’action à l’aide de l’éditeur de vue de code, comme décrit plus tard ou dans le concepteur de workflow, comme décrit ici :

  1. Dans le concepteur, sélectionnez l’action HTTP pour ouvrir le volet d’informations d’action, puis sélectionnez Paramètres.

  2. Sous Transfert de contenu, définissez Autoriser la segmentation sur Activé.

    Capture d’écran montrant les paramètres d’une action HTTP, avec l’option Autoriser la segmentation sélectionnée. Activez la segmentation.

  3. Pour terminer la configuration de la segmentation pour les téléchargements ou les téléversements, passez aux sections suivantes.

Télécharger du contenu en blocs

Lorsque vous téléchargez du contenu à partir d’un point de terminaison externe à l’aide d’une requête HTTP GET, de nombreux points de terminaison externes envoient automatiquement des messages volumineux en blocs. Ce comportement nécessite que le point de terminaison prend en charge les demandes de contenu partielles ou les téléchargements segmentés. Par conséquent, si une action dans votre flux de travail envoie une requête HTTP GET pour télécharger du contenu à partir d’un point de terminaison externe et que le point de terminaison répond avec le code d’état du contenu partiel 206 , la réponse contient du contenu segmenté.

Azure Logic Apps ne peut pas contrôler si un point de terminaison externe prend en charge les demandes de contenu partielles. Lorsque l’action de demande dans votre flux de travail obtient la première réponse avec le code d’état de contenu partiel 206 , cette action envoie automatiquement plusieurs requêtes pour télécharger tout le contenu.

Pour vérifier si un point de terminaison externe prend en charge le contenu partiel, envoyez une requête HTTP HEAD, qui demande une réponse avec uniquement la ligne d’état et la section d’en-tête, omettant le corps de la réponse. Cette demande vous aide à déterminer si la réponse contient l’en-tête Accept-Ranges .

Si le point de terminaison prend en charge le contenu partiel en tant que téléchargements segmentés, mais n’envoie pas de contenu segmenté, vous pouvez suggérer cette option en définissant l’en-tête Range dans votre requête HTTP GET.

Les étapes suivantes décrivent le processus qu’Azure Logic Apps utilise pour télécharger du contenu segmenté à partir d’un point de terminaison externe dans votre flux de travail :

  1. Dans votre flux de travail, une action envoie une requête HTTP GET au point de terminaison.

    L’en-tête de requête peut éventuellement inclure un Range champ qui décrit une plage d’octets pour demander des blocs de contenu.

  2. Le point de terminaison répond avec le code d’état 206 et un corps de message HTTP.

    Les détails sur le contenu de ce bloc apparaissent dans l’en-tête Content-Range de la réponse. Ces détails incluent des informations qui aident Azure Logic Apps à déterminer le début et la fin du bloc, ainsi que la taille totale du contenu entier avant la segmentation.

  3. L’action envoie automatiquement des requêtes HTTP GET de suivi jusqu’à ce que tout le contenu soit récupéré.

Par exemple, la définition d’action suivante montre une requête HTTP GET qui définit l’en-tête Range . L’en-tête suggère que le point de terminaison doit répondre avec un contenu en fragments :

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

La requête GET définit l’en-tête Range à bytes=0-1023 pour spécifier la plage d’octets. Si le point de terminaison prend en charge les demandes de contenu partiel, le point de terminaison répond avec un bloc de contenu de la plage demandée. En fonction du point de terminaison, le format exact du Range champ d’en-tête peut différer.

Charger du contenu en blocs

Pour charger du contenu dans des blocs à partir d’une action HTTP, vous devez configurer la prise en charge des blocs en définissant la propriété de l’action runtimeConfiguration . Ce paramètre permet à l’action de démarrer le protocole de segmentation.

L’action peut ensuite envoyer un message POST ou PUT initial au point de terminaison externe. Une fois que le point de terminaison répond avec une taille de bloc suggérée, l’action suit en envoyant des requêtes HTTP PATCH qui contiennent les blocs de contenu.

Les étapes suivantes décrivent le processus détaillé qu’Azure Logic Apps utilise pour charger du contenu segmenté à partir d’une action dans votre flux de travail vers un point de terminaison externe :

  1. Dans votre flux de travail, une action envoie une requête HTTP POST ou PUT initiale avec un corps de message vide.

    L’en-tête de requête inclut les informations suivantes sur le contenu que votre application logique souhaite charger en blocs :

    Champ d’en-tête de requête Valeur Type Description
    x-ms-transfer-mode segmenté Chaîne Indique que le contenu est chargé en blocs
    x-ms-content-length < longueur du contenu> Nombre entier Taille de contenu entière en octets avant la segmentation
  2. Le point de terminaison répond avec le code d’état de réussite 200 et les informations suivantes :

    Champ d'en-tête de réponse d'un terminal Type Obligatoire Description
    Emplacement Chaîne Oui Emplacement d’URL où envoyer les messages HTTP PATCH
    x-ms-chunk-size Nombre entier Non Taille de bloc suggérée en octets
  3. L’action de flux de travail crée et envoie des messages HTTP PATCH de suivi, chacun avec les informations suivantes :

    • Segment de contenu basé sur x-ms-chunk-size ou une taille calculée en interne jusqu’à ce que tout le contenu totalisant x-ms-content-length soit chargé séquentiellement

    • Les informations d’en-tête suivantes sur le bloc de contenu envoyé dans chaque message PATCH :

      Champ d’en-tête de requête Valeur Type Description
      Content-Range < gamme> Chaîne Plage d’octets pour le bloc de contenu actuel, y compris la valeur de départ, la valeur de fin et la taille totale du contenu, par exemple : bytes=0-1023/10100
      Content-Type < type de contenu> Chaîne Type de contenu segmenté
      Content-Length < longueur du contenu> Chaîne Taille du tronçon actuel en octets
  4. Après chaque requête PATCH, le point de terminaison confirme la réception de chaque bloc en répondant avec le 200 code d’état et les en-têtes de réponse suivants :

    Champ d'en-tête de réponse d'un terminal Type Obligatoire Description
    Plage Chaîne Oui Plage d’octets pour le contenu reçu par le point de terminaison, par exemple : bytes=0-1023
    x-ms-chunk-size Nombre entier Non Taille de bloc suggérée en octets

Par exemple, la définition d’action suivante montre une requête HTTP POST pour le chargement de contenu segmenté sur un point de terminaison. Dans la propriété de runTimeConfiguration de l'action, la propriété contentTransfer définit transferMode à chunked :

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