Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für: Azure Logic Apps (Verbrauch + Standard)
Azure Logic Apps legt unterschiedliche Größenbeschränkungen für den Nachrichteninhalt fest, den Vorgänge in Logik-App-Workflows verarbeiten können. Diese Grenzwerte variieren je nach Dem Ressourcentyp der Logik-App und der Umgebung, in der ein Workflow ausgeführt wird. Grenzwerte tragen auch dazu bei, den Aufwand zu reduzieren, der sich aus dem Speichern und Verarbeiten großer Nachrichten ergibt. Weitere Informationen zu Grenzwerten für nachrichtengröße finden Sie unter Nachrichtenbeschränkungen in Azure Logic Apps.
Wenn Sie integrierte HTTP-Aktionen oder bestimmte verwaltete Connector-Aktionen verwenden, um mit Nachrichten zu arbeiten, die größer als die Standardgrenzwerte sind, können Sie Chunking aktivieren. Dieser Ansatz teilt eine große Nachricht in kleinere Nachrichten auf, sodass Sie weiterhin große Dateien unter bestimmten Bedingungen übertragen können.
Für diese integrierten HTTP-Aktionen und spezifischen verwalteten Connectoraktionen ist das Chunking die einzige Möglichkeit, wie Azure Logic Apps große Nachrichten verarbeiten können. Entweder muss der zugrunde liegende HTTP-Nachrichtenaustausch zwischen Azure Logic Apps und anderen Diensten eine segmentierte Übertragung verwenden, oder die von den verwalteten Konnektoren erstellten Verbindungen müssen segmentierte Übertragung unterstützen.
Hinweis
Aufgrund der erhöhten Mehrbelastung durch den Austausch mehrerer Nachrichten unterstützt Azure Logic Apps die Segmentierung bei Triggern nicht. Darüber hinaus implementiert Azure Logic Apps Chunking für HTTP-Aktionen mithilfe eines eigenen Protokolls, wie in diesem Artikel beschrieben. Selbst wenn Ihre Website oder Ihr Webdienst Chunking unterstützt, funktionieren sie also nicht mit HTTP Action Chunking.
Um HTTP-Aktionsabschnitte mit Ihrer Website oder Ihrem Webdienst zu verwenden, implementieren Sie dasselbe Protokoll, das von Azure Logic Apps verwendet wird. Andernfalls sollten Sie das Chunking für die HTTP-Aktion nicht aktivieren.
Dieser Artikel bietet einen Überblick darüber, was große Nachrichten bedeuten, wie die Teilung funktioniert und wie Sie Chunking für unterstützte Aktionen in Azure Logic Apps einrichten.
Was macht Nachrichten „groß“?
Nachrichten sind umfangreich abhängig von dem Dienst, der diese Nachrichten verarbeitet. Die genaue Größenbeschränkung für große Nachrichten unterscheidet sich bei Azure Logic Apps und Connectoraktionen. Sowohl Azure Logic Apps als auch Konnektoren können große Nachrichten ohne Aufteilung nicht direkt verarbeiten.
Informationen zum Grenzwert für die Nachrichtengröße von Azure Logic Apps finden Sie unter Azure Logic Apps-Grenzwerte und -Konfiguration. Informationen zum Grenzwert für die Nachrichtengröße jedes Connectors finden Sie unter Connectorverweis.
Verarbeitung von segmentierten Nachrichten für Azure Logic Apps
Azure Logic Apps kann Ausgaben von Nachrichten, die wegen der Überschreitung der Nachrichtengrößenbeschränkung in Blöcke aufgeteilt wurden, nicht direkt verwenden. Nur Aktionen, die das Chunking unterstützen, können auf den Nachrichteninhalt in diesen Ausgaben zugreifen. Eine Aktion, die große Nachrichten verarbeitet, muss einem der folgenden Kriterien entsprechen:
- Diese Aktion muss die Blockerstellung nativ unterstützen, wenn diese Aktion zu einem Connector gehört.
- Die Aktion muss die Chunking-Unterstützung in ihrer Laufzeitkonfiguration aktiviert haben.
Andernfalls wird beim Versuch, auf eine große Inhaltsausgabe zuzugreifen, ein Laufzeitfehler angezeigt.
Connector-Verarbeitung von Nachrichten, die in Blöcke aufgeteilt sind
Dienste, die mit Azure Logic Apps kommunizieren, können eigene Grenzwerte für die Nachrichtengröße aufweisen. Diese Grenzwerte sind häufig kleiner als der Grenzwert für Azure Logic Apps. Wenn ein Connector z. B. Blöcke unterstützt, kann ein Connector eine 30-MB-Nachricht als groß betrachten, während Azure Logic Apps nicht. Um das Limit dieses Connectors einzuhalten, teilt Azure Logic Apps jede Nachricht, die größer als 30 MB ist, in kleinere Abschnitte auf.
Für Connectors, die Chunking unterstützen, ist das darunterliegende Chunking-Protokoll für Endbenutzer unsichtbar. Nicht alle Connectors unterstützen das Chunking. Connectors, die es nicht unterstützen, generieren Laufzeitfehler, wenn eingehende Nachrichten die Grenzwerte für die Connectorgröße überschreiten.
Für Aktionen, die das Chunking unterstützen und dafür aktiviert sind, können Sie keine Triggertexte, Variablen und Ausdrücke wie triggerBody()?['Content'] verwenden. Durch die Verwendung dieser Eingaben wird verhindert, dass der Segmentierungsprozess ausgeführt wird. Verwenden Sie stattdessen die Verfassen-Aktion. Erstellen Sie insbesondere ein body-Feld mithilfe der Aktion Erstellen, um die Daten aus dem Trigger-Körper, der Variablen, dem Ausdruck usw. zu speichern, zum Beispiel:
"Compose": {
"inputs": {
"body": "@variables('myVar1')"
},
"runAfter": {
"Until": [
"Succeeded"
]
},
"type": "Compose"
},
Um auf die Daten zu verweisen, verwenden Sie in der Chunking-Aktion den Ausdruck body('Compose'), wie z. B.:
"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"
},
Einrichten von Blockerstellung über HTTP
In generischen HTTP-Szenarien können Sie große Inhaltsdownloads und Uploads über HTTP aufteilen, damit Ihr Workflow große Nachrichten mit einem externen Endpunkt austauschen kann. Sie müssen Nachrichten auf die Art und Weise blöcken, wie Azure Logic Apps erwartet.
Wenn ein externer Endpunkt für Blockdownloads oder Uploads eingerichtet ist, werden die HTTP-Aktionen in Ihrem Workflow automatisch große Nachrichten blöcken. Andernfalls müssen Sie Blockerstellungsunterstützung auf dem Endpunkt einrichten. Wenn Sie den Endpunkt nicht besitzen oder steuern, können Sie möglicherweise keine Segmentierung einrichten.
Wenn für eine HTTP-Aktion das Chunking noch nicht aktiviert ist, müssen Sie das Chunking über die runTimeConfiguration-Eigenschaft der Aktion einrichten. Sie können diese Eigenschaft in der Aktionsdefinition einrichten, indem Sie den Codeansichts-Editor verwenden, wie weiter unten beschrieben oder im Workflow-Designer wie hier beschrieben:
Wählen Sie im Designer die HTTP-Aktion aus, um den Aktionsinformationsbereich zu öffnen, und wählen Sie dann "Einstellungen" aus.
Legen Sie unter ContentübertragungChunking erlauben auf Ein fest.
Setzen Sie das Einrichten des Chunking für Downloads oder Uploads mit den folgenden Abschnitten fort.
Herunterladen von Inhalten in Blöcken
Wenn Sie Inhalte von einem externen Endpunkt mithilfe einer HTTP GET-Anforderung herunterladen, senden viele externe Endpunkte große Nachrichten automatisch in Blöcken. Dieses Verhalten erfordert, dass der Endpunkt partielle Inhaltsanforderungen oder blockierte Downloads unterstützt. Wenn also eine Aktion in Ihrem Workflow eine HTTP GET-Anforderung sendet, um Inhalte von einem externen Endpunkt herunterzuladen, und der Endpunkt mit dem 206 Partial Content-Statuscode antwortet, enthält die Antwort fragmentierte Inhalte.
Azure Logic Apps kann nicht steuern, ob ein externer Endpunkt partielle Inhaltsanforderungen unterstützt. Wenn die anfordernde Aktion in Ihrem Workflow die erste Antwort mit dem 206 Partiellen Inhaltsstatuscode erhält, sendet diese Aktion automatisch mehrere Anforderungen, um alle Inhalte herunterzuladen.
Um zu überprüfen, ob ein externer Endpunkt Teilinhalte unterstützt, senden Sie eine HTTP HEAD-Anforderung, die eine Antwort nur mit der Statuszeile und dem Kopfzeilenabschnitt anfordert und den Antworttext ausgelassen. Mit dieser Anforderung können Sie ermitteln, ob die Antwort den Accept-Ranges Header enthält.
Wenn der Endpunkt Teilinhalte als blockierte Downloads unterstützt, aber keine blockierten Inhalte sendet, können Sie diese Option vorschlagen , indem Sie den Range Header in Ihrer HTTP GET-Anforderung festlegen.
Die folgenden Schritte beschreiben den Prozess, den Azure Logic Apps zum Herunterladen von gestückelten Inhalten von einem externen Endpunkt in Ihren Workflow verwendet:
In Ihrem Workflow sendet eine Aktion eine HTTP GET-Anforderung an den Endpunkt.
Der Anforderungsheader kann optional ein
RangeFeld enthalten, das einen Bytebereich zum Anfordern von Inhaltsblöcken beschreibt.Der Endpunkt antwortet mit dem
206Statuscode und einem HTTP-Nachrichtentext.Details zum Inhalt dieses Abschnitts
Content-Rangewerden im Header der Antwort angezeigt. Zu diesen Details gehören Informationen, mit denen Azure Logic Apps den Start und das Ende des Blocks sowie die Gesamtgröße des gesamten Inhalts vor der Blockerstellung ermitteln kann.Die Aktion sendet automatisch Nachverfolgungs-HTTP GET-Anforderungen, bis alle Inhalte abgerufen werden.
Die folgende Aktionsdefinition zeigt z. B. eine HTTP GET-Anforderung an, die den Range Header festlegt. Im Header wird vorgeschlagen, dass der Endpunkt mit segmentiertem Inhalt antwortet:
"getAction": {
"inputs": {
"headers": {
"Range": "bytes=0-1023"
},
"method": "GET",
"uri": "http://myAPIendpoint/api/downloadContent"
},
"runAfter": {},
"type": "Http"
}
Die GET-Anforderung legt den Range Header auf bytes=0-1023 fest, um den Bytebereich anzugeben. Wenn der Endpunkt Anforderungen für teilweise Inhalte unterstützt, antwortet der Endpunkt mit einem Inhaltsabschnitt aus dem angeforderten Bereich. Basierend auf dem Endpunkt kann sich das genaue Format für das Range Kopfzeilenfeld unterscheiden.
Hochladen von Inhalten in Blöcken
Um Inhalte in Teilen aus einer HTTP-Aktion hochzuladen, müssen Sie die Unterstützung für Chunking konfigurieren, indem Sie die Eigenschaft der Aktion runtimeConfiguration festlegen. Diese Einstellung versetzt die Aktion in die Lage, das Blockerstellungsprotokoll zu starten.
Die Aktion kann dann eine anfängliche POST- oder PUT-Nachricht an den externen Endpunkt senden. Nachdem der Endpunkt mit einer vorgeschlagenen Blockgröße reagiert hat, folgt die Aktion, indem HTTP PATCH-Anforderungen gesendet werden, die die Inhaltsblöcke enthalten.
Die folgenden Schritte beschreiben den detaillierten Prozess, den Azure Logic Apps zum Hochladen von gestückelten Inhalten aus einer Aktion in Ihrem Workflow auf einen externen Endpunkt verwendet:
In Ihrem Workflow sendet eine Aktion eine anfängliche HTTP POST- oder PUT-Anforderung mit einem leeren Nachrichtentext.
Der Anforderungsheader enthält die folgenden Informationen zu den Inhalten, die Ihre Logik-App in Blöcken hochladen möchte:
Fehld für Anforderungsheader Wert Typ BESCHREIBUNG x-ms-transfer-mode chunked Schnur Gibt an, dass der Inhalt in Blöcken hochgeladen wird. x-ms-content-length < Inhaltslänge> Integer Der Gesamtgröße des Inhalts in Bytes vor der Blockerstellung Der Endpunkt antwortet mit
200dem Erfolgsstatuscode und den folgenden Informationen:Endpunktfeld für Antwortheader Typ Erforderlich BESCHREIBUNG Ort Schnur Ja Der URL-Speicherort, an den die HTTP PATCH-Nachrichten gesendet werden sollen x-ms-chunk-size Integer Nein Die vorgeschlagene Blockgröße in Byte Die Workflowaktion erstellt und sendet nachfolgende HTTP PATCH-Nachrichten, die jeweils die folgenden Informationen enthalten:
Ein Inhaltsblock basierend auf x-ms-chunk-size oder einer intern berechneten Größe, bis alle Inhalte mit einer Gesamtlänge von x-ms-content-length sequenziell hochgeladen werden.
Die folgenden Header-Informationen über den in jeder PATCH-Nachricht gesendeten Content Chunk:
Fehld für Anforderungsheader Wert Typ BESCHREIBUNG Inhaltsbereich < Bereich> Schnur Der Bytebereich für den aktuellen Inhaltsabschnitt, einschließlich Startwert, Endwert und Gesamtinhaltsgröße, z. B.: bytes=0-1023/10100Content-Type < Inhaltstyp> Schnur Der Typ des segmentierten Inhalts Content-Length < Inhaltslänge> Schnur Die Länge des aktuellen Blocks in Bytes
Nach jeder PATCH-Anforderung bestätigt der Endpunkt den Empfang für jeden Abschnitt, indem er mit dem
200Statuscode und den folgenden Antwortheadern antwortet:Endpunktfeld für Antwortheader Typ Erforderlich BESCHREIBUNG Bereich Schnur Ja Der Bytebereich für vom Endpunkt empfangene Inhalte, z. B.: bytes=0-1023x-ms-chunk-size Integer Nein Die vorgeschlagene Blockgröße in Byte
Die folgende Aktionsdefinition zeigt beispielsweise eine HTTP POST-Anforderung zum Hochladen von gestückelten Inhalten an einen Endpunkt. In der runTimeConfiguration-Eigenschaft der Aktion wird die contentTransfer-Eigenschaft transferMode auf chunked festgelegt:
"postAction": {
"runtimeConfiguration": {
"contentTransfer": {
"transferMode": "chunked"
}
},
"inputs": {
"method": "POST",
"uri": "http://myAPIendpoint/api/action",
"body": "@body('getAction')"
},
"runAfter": {
"getAction": ["Succeeded"]
},
"type": "Http"
}