Merge pull request #125588 from DieterGobeyn/main

Consistency updates and clarifications on application/x-www-form-urlencoded handling

Author: Court72

articles/logic-apps/ai-resources.md

@@ -161,7 +161,7 @@ For more information, see the following resources:
 
 ## Ingest documents and chat with data
 
-Data is the cornerstone for any AI application and unique for each organization. When you build any AI application, efficient data ingestion is critical for success. Regardless where your data resides and with little or no code, you can more easily integrate AI into new and existing business processes by building Standard workflows with Azure Logic Apps.
+Data is the cornerstone for any AI application and unique for each organization. When you build any AI application, efficient data ingestion is critical for success. No matter where your data resides, you can integrate AI into new and existing business processes using little or no code by building Standard workflows with Azure Logic Apps.
 
 With over 1,400 enterprise connectors and operations, Azure Logic Apps makes it possible for you to quickly access and perform tasks with a wide range of services, systems, applications, and databases. When you use these connectors alongside AI services, such as Azure OpenAI and Azure AI Search, your organization can transform workloads such as automating routine tasks, enhancing customer interactions with chat capabilities, providing access to organizational data when necessary, and generating intelligent insights or responses. Along with these operations, Azure Logic Apps also offers prebuilt workflow templates that ingest data from many common data sources, such as SharePoint, Azure File Storage, Blob Storage, SFTP, and more, to help you quickly build and your applications.
 

articles/logic-apps/handle-throttling-problems-429-errors.md

@@ -12,7 +12,7 @@ ms.date: 01/10/2024
 
 [!INCLUDE [logic-apps-sku-consumption-standard](../../includes/logic-apps-sku-consumption-standard.md)]
 
-If your logic app workflow experiences throttling, which happens when the number of requests exceed the rate at which the destination can handle over a specific amount of time, you get the ["HTTP 429 Too many requests" error](https://developer.mozilla.org/docs/Web/HTTP/Status/429). Throttling can create problems such as delayed data processing, reduced performance speed, and errors such as exceeding the specified retry policy.
+If your logic app workflow experiences throttling, which happens when the number of requests exceeds the rate at which the destination can handle over a specific amount of time, you get the ["HTTP 429 Too many requests" error](https://developer.mozilla.org/docs/Web/HTTP/Status/429). Throttling can create problems such as delayed data processing, reduced performance speed, and errors such as exceeding the specified retry policy.
 
 For example, the following SQL Server action in a Consumption workflow shows a 429 error, which reports a throttling problem:
 
@@ -80,7 +80,7 @@ To handle throttling at this level, you have the following options:
 
 * Refactor actions into multiple, smaller workflows.
 
-  As mentioned earlier, a Consumption logic app workflow is limited to a [default number of actions that can run over a 5-minute period](logic-apps-limits-and-config.md#throughput-limits). Although you can increase this limit by enabling [high throughput mode](logic-apps-limits-and-config.md#run-high-throughput-mode), you might also consider whether you want to break down your workflow's actions into smaller workflows so that the number of actions that run in each workflow stays under the limit. That way, you reduce the burden on a single workflow and distribute the load across multiple workflows. This solution works better for actions that handle large data sets or spin up so many concurrently running actions, loop iterations, or actions inside each loop iteration that they exceed action execution limit.
+  As mentioned earlier, a Consumption logic app workflow is limited to a [default number of actions that can run over a 5-minute period](logic-apps-limits-and-config.md#throughput-limits). Although you can increase this limit by enabling [high throughput mode](logic-apps-limits-and-config.md#run-high-throughput-mode), you might also consider whether you want to break down your workflow's actions into smaller workflows so that the number of actions that run in each workflow stays under the limit. That way, you reduce the burden on a single workflow and distribute the load across multiple workflows. This solution works better for actions that handle large data sets or spin up so many concurrently running actions, loop iterations, or actions inside each loop iteration that they exceed the action execution limit.
 
   For example, the following Consumption workflow does all the work to get tables from a SQL Server database and gets the rows from each table. The **For each** loop concurrently iterates through each table so that the **Get rows** action returns the rows for each table. Based on the amounts of data in those tables, these actions might exceed the limit on action executions.
 
@@ -162,7 +162,7 @@ To handle throttling at this level, you have the following options:
 
 While a connector has its own throttling limits, the destination service or system that's called by the connector might also have throttling limits. For example, some APIs in Microsoft Exchange Server have stricter throttling limits than the Office 365 Outlook connector.
 
-By default, a logic app's workflow instances and any loops or branches inside those instances, run *in parallel*. This behavior means that multiple instances can call the same endpoint at the same time. Each instance doesn't know about the other's existence, so attempts to retry failed actions can create [race conditions](https://en.wikipedia.org/wiki/Race_condition) where multiple calls try to run at same time, but to succeed, those calls must arrive at the destination service or system before throttling starts to happen.
+By default, a logic app's workflow instances and any loops or branches inside those instances, run *in parallel*. This behavior means that multiple instances can call the same endpoint at the same time. Each instance doesn't know about the other's existence, so attempts to retry failed actions can create [race conditions](https://en.wikipedia.org/wiki/Race_condition) where multiple calls try to run at the same time, but to succeed, those calls must arrive at the destination service or system before throttling starts to happen.
 
 For example, suppose you have an array that has 100 items. You use a "For each" loop to iterate through the array and turn on the loop's concurrency control so that you can restrict the number of parallel iterations to 20 or the [current default limit](logic-apps-limits-and-config.md#concurrency-looping-and-debatching-limits). Inside that loop, an action inserts an item from the array into a SQL Server database, which permits only 15 calls per second. This scenario results in a throttling problem because a backlog of retries builds up and never gets to run.
 
@@ -192,7 +192,7 @@ To handle throttling at this level, you have the following options:
 
   Why? A polling trigger continues to check the destination service or system at specific intervals. A very frequent interval, such as every second, can create throttling problems. However, a webhook trigger or action, such as [HTTP Webhook](../connectors/connectors-native-webhook.md), creates only a single call to the destination service or system, which happens at subscription time and requests that the destination notifies the trigger or action only when an event happens. That way, the trigger or action doesn't have to continually check the destination.
 
-  So, if the destination service or system supports webhooks or provides a connector that has a webhook version, this option is better than using the polling version. To identify webhook triggers and actions, confirm that they have the `ApiConnectionWebhook` type or that they don't require that you specify a recurrence. For more information, see [APIConnectionWebhook trigger](logic-apps-workflow-actions-triggers.md#apiconnectionwebhook-trigger) and [APIConnectionWebhook action](logic-apps-workflow-actions-triggers.md#apiconnectionwebhook-action).
+  So, if the destination service or system supports webhooks or provides a connector that has a webhook version, this option is better than using the polling version. To identify webhook triggers and actions, confirm that they have the `ApiConnectionWebhook` type or that they don't require that you specify a recurrence. For more information, see [ApiConnectionWebhook trigger](logic-apps-workflow-actions-triggers.md#apiconnectionwebhook-trigger) and [ApiConnectionWebhook action](logic-apps-workflow-actions-triggers.md#apiconnectionwebhook-action).
 
 ## Next steps
 

articles/logic-apps/logic-apps-author-definitions.md

@@ -42,7 +42,7 @@ Before you can work on a Consumption workflow definition in Visual Studio, make
 
 1. Open the Visual Studio solution, or [Azure Resource Group](/azure/azure-resource-manager/management/overview) project, that contains your logic app.
 
-1. Find and open your workflow definition, which by default, appears in an [Resource Manager template](/azure/azure-resource-manager/templates/overview), named **LogicApp.json**.
+1. Find and open your workflow definition, which by default, appears in a [Resource Manager template](/azure/azure-resource-manager/templates/overview), named **LogicApp.json**.
 
    You can use and customize this template for deployment to different environments.
 
@@ -133,7 +133,7 @@ These steps describe how this example processes this string, working from the in
 
 ## Map list items to property values, then use maps as parameters
 
-To get different results based a property's value, you can create a map that matches each property value to a result, then use that map as a parameter.
+To get different results based on a property's value, you can create a map that matches each property value to a result, then use that map as a parameter.
 
 For example, this workflow defines some categories as parameters and a map that matches those categories with a specific URL. First, the workflow gets a list of articles. Then, the workflow uses the map to find the URL matching the category for each article.
 

articles/logic-apps/logic-apps-azure-resource-manager-templates-overview.md

@@ -206,7 +206,7 @@ Here is the structure inside the parameters file, which includes a key vault ref
             "keyVault": {
                "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/Microsoft.KeyVault/vaults/<key-vault-name>"
             },
-            "secretName: "<secret-name>"
+            "secretName": "<secret-name>"
          }
       },
       <other-parameter-values>
@@ -405,7 +405,7 @@ This syntax shows where you can declare parameters at both the template and work
                      "type": "<trigger-type>",
                      "inputs": {
                          // Workflow definition parameter reference
-                         "<attribute-name>": "@parameters('<workflow-definition-parameter-name')"
+                         "<attribute-name>": "@parameters('<workflow-definition-parameter-name>')"
                      }
                   }
                },

articles/logic-apps/logic-apps-content-type.md

@@ -34,13 +34,13 @@ for example:
 ## application/json
 
 Logic Apps stores and handles any request with the *application/json* 
-content type as a JavaScript Notation (JSON) object. 
+content type as a JavaScript Object Notation (JSON) object. 
 By default, you can parse JSON content without any casting. 
 To parse a request that has a header with the "application/json" content type, 
 you can use an expression. This example returns the value `dog` from the 
 `animal-type` array without casting: 
 
-`@body('myAction')['animal-type'][0]` 
+`@body('myAction')['client']['animal-type'][0]` 
 
   ```json
   {
@@ -56,7 +56,7 @@ you can manually cast that data to JSON by using the
 [json() function](../logic-apps/workflow-definition-language-functions-reference.md#json), 
 for example: 
 
-`@json(triggerBody())['animal-type']`
+`@json(triggerBody())['client']['animal-type']`
 
 ### Create tokens for JSON properties
 
@@ -196,7 +196,7 @@ For example, if you receive an HTTP request
 where `Content-Type` set to `application/xml`, 
 such as this content:
 
-```html
+```xml
 <?xml version="1.0" encoding="UTF-8" ?>
 <CustomerName>Frank</CustomerName>
 ```

articles/logic-apps/logic-apps-control-flow-branches.md

@@ -21,7 +21,7 @@ This guide shows how to create parallel branches in a workflow and rejoin those
 > [!TIP]
 >
 > If your workflow trigger receives an array, and you want to run a workflow instance 
-> instance for each item in the array, rather than create parallel branches, you can 
+> for each item in the array, rather than create parallel branches, you can 
 > [*debatch* that array instead by using the **SplitOn** trigger property](logic-apps-workflow-actions-triggers.md#split-on-debatch).
 
 ## Prerequisites

articles/logic-apps/logic-apps-control-flow-conditional-statement.md

@@ -162,7 +162,7 @@ The following code shows the high-level JSON definition for the **Condition** ac
          "Condition": [
             "Succeeded"
          ]
-      },
+      }
    }
 },
 ```

articles/logic-apps/logic-apps-control-flow-loops.md

@@ -489,16 +489,13 @@ if any of the following conditions happen:
                "body": {
                   "resourceId": "@triggerBody()"
                },
-               "url": "https://domain.com/provisionResource/create-resource",
-               "body": {
-                  "resourceId": "@triggerBody()"
-               }
+               "url": "https://domain.com/provisionResource/create-resource"
             },
             "runAfter": {},
             "type": "ApiConnection"
          }
       },
-      "expression": "@equals(triggerBody(), 'Completed')",
+      "expression": "@equals(body('Create_new_resource'), 'Completed')",
       "limit": {
          "count": 10,
          "timeout": "PT2H"

articles/logic-apps/logic-apps-control-flow-switch-statement.md

@@ -55,7 +55,7 @@ email to an approver. Based on whether the approver selects
 
 ## Add a switch action
 
-1. For this example, add a switch action at the end 
+1. For this example, add a switch action at the end of 
 your sample workflow. After the last step, choose **New step**.
 
    When you want to add a switch action between steps, 

articles/logic-apps/logic-apps-create-api-app.md

@@ -24,7 +24,7 @@ that you can call from workflows:
 * Expand the reach, discoverability, and use for your service.
 
 Basically, connectors are web APIs that use REST for pluggable interfaces, 
-[Swagger metadata format](https://swagger.io/specification/) for documentation, 
+[OpenAPI metadata format](https://swagger.io/specification/) for documentation, 
 and JSON as their data exchange format. Because connectors are REST APIs 
 that communicate through HTTP endpoints, you can use any language to build connectors, 
 such as .NET, Java, Python, or Node.js. 
@@ -64,7 +64,7 @@ easy API hosting.
 
 Custom APIs and [custom connectors](../logic-apps/custom-connector-overview.md) 
 are web APIs that use REST for pluggable interfaces, 
-[Swagger metadata format](https://swagger.io/specification/) for documentation, 
+[OpenAPI metadata format](https://swagger.io/specification/) for documentation, 
 and JSON as their data exchange format. And because these APIs and connectors 
 are REST APIs that communicate through HTTP endpoints, you can use any language, 
 like .NET, Java, Python, or Node.js, for building custom APIs and connectors.
@@ -93,7 +93,7 @@ For more information, review the following documentation:
 ## Helpful tools
 
 A custom API works best with logic apps when the API also has a 
-[Swagger document](https://swagger.io/specification/) 
+[OpenAPI document](https://swagger.io/specification/) 
 that describes the API's operations and parameters.
 Many libraries, like [Swashbuckle](https://github.com/domaindrivendev/Swashbuckle), 
 can automatically generate the Swagger file for you.