Branding and clarity updates

Author: ecfan

articles/logic-apps/logic-apps-handle-large-messages.md

@@ -28,17 +28,12 @@ This article provides an overview about how chunking works in Azure Logic Apps a
 
 ## What makes messages "large"?
 
-Messages are "large" based on the service handling those messages.
-The exact size limit on large messages differs across Logic Apps and connectors.
-Both Logic Apps and connectors can't directly consume large messages,
-which must be chunked. For the Logic Apps message size limit,
-see [Logic Apps limits and configuration](../logic-apps/logic-apps-limits-and-config.md).
-For each connector's message size limit, see the
-[connector's reference documentation](/connectors/connector-reference/connector-reference-logicapps-connectors).
+Messages are "large" based on the service handling those messages. The exact size limit on large messages differs across Azure Logic Apps and connectors. Both Azure Logic Apps and connectors can't directly consume large messages, which must be chunked. For the Azure Logic Apps message size limit, see [Azure Logic Apps limits and configuration](../logic-apps/logic-apps-limits-and-config.md).
+For each connector's message size limit, see the [connector's reference documentation](/connectors/connector-reference/connector-reference-logicapps-connectors).
 
-### Chunked message handling for Logic Apps
+### Chunked message handling for Azure Logic Apps
 
-Logic Apps can't directly use outputs from chunked
+Azure Logic Apps can't directly use outputs from chunked
 messages that are larger than the message size limit.
 Only actions that support chunking can access the message content in these outputs.
 So, an action that handles large messages must meet *either* these criteria:
@@ -51,17 +46,16 @@ To enable chunking, see [Set up chunking support](#set-up-chunking).
 
 ### Chunked message handling for connectors
 
-Services that communicate with Logic Apps can have their own message size limits.
-These limits are often smaller than the Logic Apps limit. For example, assuming that
+Services that communicate with Azure Logic Apps can have their own message size limits.
+These limits are often smaller than the Azure Logic Apps limit. For example, assuming that
 a connector supports chunking, a connector might consider a 30-MB message as large,
-while Logic Apps does not. To comply with this connector's limit,
-Logic Apps splits any message larger than 30 MB into smaller chunks.
+while Azure Logic Apps does not. To comply with this connector's limit, Azure Logic Apps splits any message larger than 30 MB into smaller chunks.
 
 For connectors that support chunking, the underlying chunking protocol is invisible to end users.
 However, not all connectors support chunking, so these connectors generate runtime
 errors when incoming messages exceed the connectors' size limits.
 
-For actions that support and are enabled for chunking, you can't use trigger bodies, variables, and expressions such as `@triggerBody()?['Content']` because using any of these inputs prevents the chunking operation from happening. Instead, use the [**Compose** action](../logic-apps/logic-apps-perform-data-operations.md#compose-action). Specifically, you must create a `body` field by using the **Compose** action to store the data output from the trigger body, variable, expression, and so on, for example:
+For actions that support and are enabled for chunking, you can't use trigger bodies, variables, and expressions such as **`triggerBody()?['Content']`** because using any of these inputs prevents the chunking operation from happening. Instead, use the [**Compose** action](../logic-apps/logic-apps-perform-data-operations.md#compose-action). Specifically, you must create a **`body`** field by using the **Compose** action to store the data output from the trigger body, variable, expression, and so on, for example:
 
 ```json
 "Compose": {
@@ -76,7 +70,8 @@ For actions that support and are enabled for chunking, you can't use trigger bod
     "type": "Compose"
 },
 ```
-Then, to reference the data, in the chunking action, use `@body('Compose')` .
+
+To reference the data, in the chunking action, use the expression **`body('Compose')`**, for example:
 
 ```json
 "Create_file": {
@@ -118,17 +113,17 @@ Then, to reference the data, in the chunking action, use `@body('Compose')` .
 
 In generic HTTP scenarios, you can split up large content downloads and uploads over HTTP,
 so that your logic app and an endpoint can exchange large messages. However,
-you must chunk messages in the way that Logic Apps expects.
+you must chunk messages in the way that Azure Logic Apps expects.
 
 If an endpoint has enabled chunking for downloads or uploads,
 the HTTP actions in your logic app automatically chunk large messages. Otherwise,
 you must set up chunking support on the endpoint. If you don't own or control
 the endpoint or connector, you might not have the option to set up chunking.
 
 Also, if an HTTP action doesn't already enable chunking,
-you must also set up chunking in the action's `runTimeConfiguration` property.
+you must also set up chunking in the action's **`runTimeConfiguration`** property.
 You can set this property inside the action, either directly in the code view
-editor as described later, or in the Logic Apps Designer as described here:
+editor as described later, or in the workflow designer as described here:
 
 1. In the HTTP action's upper-right corner,
 choose the ellipsis button (**...**),
@@ -155,7 +150,7 @@ or *chunked downloads*. When your logic app sends an HTTP GET
 request to an endpoint for downloading content,
 and the endpoint responds with a "206" status code,
 the response contains chunked content.
-Logic Apps can't control whether an endpoint supports partial requests.
+Azure Logic Apps can't control whether an endpoint supports partial requests.
 However, when your logic app gets the first "206" response,
 your logic app automatically sends multiple requests to download all the content.
 
@@ -166,18 +161,18 @@ That way, if the endpoint supports chunked downloads but
 doesn't send chunked content, you can *suggest*
 this option by setting the `Range` header in your HTTP GET request.
 
-These steps describe the detailed process Logic Apps uses for
-downloading chunked content from an endpoint to your logic app:
+These steps describe the detailed process that Azure Logic Apps uses for
+downloading chunked content from an endpoint to your workflow:
 
-1. Your logic app sends an HTTP GET request to the endpoint.
+1. Your workflow sends an HTTP GET request to the endpoint.
 
    The request header can optionally include a `Range` field that
    describes a byte range for requesting content chunks.
 
 2. The endpoint responds with the "206" status code and an HTTP message body.
 
     Details about the content in this chunk appear in the response's `Content-Range` header,
-    including information that helps Logic Apps determine the start and end for the chunk,
+    including information that helps Azure Logic Apps determine the start and end for the chunk,
     plus the total size of the entire content before chunking.
 
 3. Your logic app automatically sends follow-up HTTP GET requests.
@@ -218,45 +213,41 @@ Your logic app can then send an initial POST or PUT message to the target endpoi
 After the endpoint responds with a suggested chunk size, your logic app follows
 up by sending HTTP PATCH requests that contain the content chunks.
 
-The following steps describe the detailed process Logic Apps uses for uploading
+The following steps describe the detailed process that Azure Logic Apps uses for uploading
 chunked content from your logic app to an endpoint:
 
-1. Your logic app sends an initial HTTP POST or PUT request with an empty message body. The request header, includes the following information about the content that your logic app wants to upload in chunks:
+1. Your workflow sends an initial HTTP POST or PUT request with an empty message body. The request header, includes the following information about the content that your logic app wants to upload in chunks:
 
-   | Logic Apps request header field | Value | Type | Description |
-   |---------------------------------|-------|------|-------------|
+   | Request header field | Value | Type | Description |
+   |----------------------|-------|------|-------------|
    | **x-ms-transfer-mode** | chunked | String | Indicates that the content is uploaded in chunks |
    | **x-ms-content-length** | <*content-length*> | Integer | The entire content size in bytes before chunking |
-   ||||
 
 1. The endpoint responds with "200" success status code and the following information:
 
    | Endpoint response header field | Type | Required | Description |
    |--------------------------------|------|----------|-------------|
    | **Location** | String | Yes | The URL location where to send the HTTP PATCH messages |
    | **x-ms-chunk-size** | Integer | No | The suggested chunk size in bytes |
-   ||||
 
-1. Your logic app creates and sends follow-up HTTP PATCH messages - each with the following information:
+1. Your workflow creates and sends follow-up HTTP PATCH messages - each with the following information:
 
    * A content chunk based on **x-ms-chunk-size** or some internally calculated size until all the content totaling **x-ms-content-length** is sequentially uploaded
 
    * The following header information about the content chunk sent in each PATCH message:
 
-     | Logic Apps request header field | Value | Type | Description |
-     |---------------------------------|-------|------|-------------|
+     | Request header field | Value | Type | Description |
+     |----------------------|-------|------|-------------|
      | **Content-Range** | <*range*> | String | The byte range for the current content chunk, including the starting value, ending value, and the total content size, for example: "bytes=0-1023/10100" |
      | **Content-Type** | <*content-type*> | String | The type of chunked content |
      | **Content-Length** | <*content-length*> | String | The length of size in bytes of the current chunk |
-     |||||
 
 1. After each PATCH request, the endpoint confirms the receipt for each chunk by responding with the "200" status code and the following response headers:
 
    | Endpoint response header field | Type | Required | Description |
    |--------------------------------|------|----------|-------------|
    | **Range** | String | Yes | The byte range for content that has been received by the endpoint, for example: "bytes=0-1023" |
    | **x-ms-chunk-size** | Integer | No | The suggested chunk size in bytes |
-   ||||
 
 For example, this action definition shows an HTTP POST request for uploading chunked content to an endpoint. In the action's `runTimeConfiguration` property,
 the `contentTransfer` property sets `transferMode` to `chunked`: