Merge pull request #298844 from siddharth-ms/sap-timeout-fix-1

Update the connector differences with newly added feature to set the SAP timeout

Author: JillGrant615

articles/logic-apps/connectors/sap.md

@@ -7,7 +7,7 @@ author: daviburg
 ms.author: daviburg
 ms.reviewer: estfan, azla
 ms.topic: how-to
-ms.date: 04/14/2025
+ms.date: 04/25/2025
 
 #customer intent: As a developer, I want to know the prerequisites and details about using SAP with Azure Logic Apps, so I can connect to an SAP server from my Consumption or Standard workflow.
 ---
@@ -82,9 +82,11 @@ The SAP built-in connector significantly differs from the SAP managed connector
 
     This capability addresses a problem with the SAP managed connector where the outcome from the autocommit behavior is silent and observable only through logs.
 
-* A longer time out at 5 minutes compared to the managed connector.
+* A longer time-out compared to the SAP managed connector.
 
-  The SAP built-in connector doesn't use the shared or global connector infrastructure, which means time-outs are longer at 5 minutes compared to the SAP managed connector (two minutes). Long-running requests work without you having to implement the long-running webhook-based request action pattern.
+  The SAP built-in connector natively runs on the Azure Logic Apps runtime, unlike the SAP managed connector that runs on the shared, global, multitenant Azure infrastructure. This design difference means that you can change the default time-out value on the Standard logic app resource by using the **host.json** settings named [**Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout**](/azure/logic-apps/edit-app-settings-host-settings?tabs=azure-portal#run-actions) and [**functionTimeout**](/azure/logic-apps/edit-app-settings-host-settings?tabs=azure-portal#run-actions).
+
+  The capability to adjust the time-out value means that you can use the SAP built-in connector as-is for long-running synchronous requests. Otherwise, these requests have to use the action pattern for long-running webhook-based requests in the SAP managed connector, which has a much shorter two-minute time-out for synchronous requests.
 
 * By default, the SAP built-in connector operations are *stateless*. However, you can [enable stateful mode (affinity) for these operations](../../connectors/enable-stateful-affinity-built-in-connectors.md).
 
@@ -1185,7 +1187,7 @@ After your SAP operations run in your logic app workflow, you can review the tel
 
    :::image type="content" source="./media/sap/application-insights-query-panel.png" alt-text="Screenshot shows Azure portal with Application Insights open to the Logs page for creating queries." lightbox="./media/sap/application-insights-query-panel.png":::
 
-1. On the **Logs** page, you can create a [query](/kusto/query/) by using the [Kusto Query Language (KQL)](/kusto/concepts/) based on your specific requirements.
+1. On the **Logs** page, you can create a [query that uses Kusto Query Language (KQL)](/kusto/query/?view=azure-monitor&preserve-view=true), based on your specific requirements.
 
    You can use a query pattern similar to the following example query:
 

articles/logic-apps/edit-app-settings-host-settings.md

@@ -5,8 +5,9 @@ services: logic-apps
 ms.suite: integration
 ms.reviewer: estfan, azla
 ms.topic: how-to
-ms.date: 03/14/2025
+ms.date: 04/25/2025
 ms.custom: fasttrack-edit
+# Customer intent: As a logic app workflow developer, I want to learn about application settings and host settings that I can edit to customize the way that my Standard workflows run.
 ---
 
 # Edit host and app settings for Standard logic apps in single-tenant Azure Logic Apps
@@ -229,7 +230,30 @@ The following settings work only for workflows that start with a recurrence-base
 
 | Setting | Default value | Description |
 |---------|---------------|-------------|
-| `Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout` | `00:10:00` <br>(10 minutes) | Sets the amount of time for a workflow action job to run before timing out and retrying. |
+| `Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout` | `00:10:00` <br>(10 minutes) | Sets the duration for a workflow action job to run before timing out and retrying. To change the default time-out for a built-in operation such as SAP, also set the **`functionTimeout`** host setting. For more information, see the next entry. |
+| `functionTimeout` | `00:30:00` <br>(30 minutes) | Sets the duration to run before timing out for calls from Azure Functions and some built-in operations, such as SAP, that work as function calls. Standard logic apps use the same underlying design as function apps. So, the **`functionTimeout`** host setting in Azure Functions also affects built-in operations that run as function calls. For more information, see [**functionTimeout**](/azure/azure-functions/functions-host-json#functiontimeout). <br><br>**Note**: In the **host.json** file, the **`functionTimeout`** setting exists at the same level as the **`extensions`** object where the host settings exist for a Standard logic app. For more information, see the example in this section: [Change time-out value for function-based built-in operations](#change-time-out-value-for-function-based-built-in-operations). |
+
+#### Change time-out value for function-based built-in operations
+
+For built-in operations that run as function calls in Azure Functions, add both the **`Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout`** and **`functionTimeout`** host settings to your **host.json** file as shown in the following example:
+
+```json
+{
+   "version": "2.0",
+   "extensionBundle": {
+      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
+      "version": "[1.*, 2.0.0)"
+   },
+   "extensions": {
+      "workflow": {
+         "settings": {
+            "Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout": "01:00:00"
+         }
+      }
+   },
+   "functionTimeout": "01:00:00"
+}
+```
 
 <a name="inputs-outputs"></a>