Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into communication-services-articles

Author: paulth1

articles/api-center/configure-environments-deployments.md

@@ -73,9 +73,9 @@ Here you add a deployment by associating one of your APIs with the environment y
 
 1. In the left menu, under **Assets**, select **APIs**.
 
-1. Select an API, for example, the *Demo Conference API*.
+1. Select an API, for example, the *Conference API*.
 
-1. On the **Demo Conference API** page, under **Details**, select **Deployments** > **+ Add deployment**.
+1. On the **Conference API** page, under **Details**, select **Deployments** > **+ Add deployment**.
 
 1. In the **Add deployment** page, add the following information. If you previously defined the custom *Line of business* metadata or other metadata assigned to environments, you'll see them at the bottom of the page.
 
@@ -85,7 +85,7 @@ Here you add a deployment by associating one of your APIs with the environment y
     |**Identification**|After you enter the preceding title, Azure API Center generates this identifier, which you can override.| Azure resource name for the deployment.|
     | **Description** | Optionally enter a description. | Description of the deployment. |
     | **Environment** | Make a selection from the dropdown, such as *My Testing*, or optionally select **Create new**.| New or existing environment where the API version is deployed. |
-    | **Definition** | Select or add a definition file for a version of the Demo Conference API. | API definition file. |
+    | **Definition** | Select or add a definition file for a version of the Conference API. | API definition file. |
     | **Runtime URL** | Enter a base URL, for example, `https://api.contoso.com`. | Base runtime URL for the API in the environment.  |
     | **Line of business** | If you added this custom metadata, optionally make a selection from the dropdown, such as **IT**. | Custom metadata that identifies the business unit that manages APIs in the environment. |
 

articles/api-center/media/configure-environments-deployments/add-deployment.png

@@ -27,7 +27,7 @@ In this tutorial, you learn how to use the portal to:
 * One or more APIs that you want to register in your API center. Here are two examples, with links to their OpenAPI definitions:
 
     * [Swagger Petstore API](https://github.com/swagger-api/swagger-petstore/blob/master/src/main/resources/openapi.yaml)
-    * [Azure Demo Conference API](https://conferenceapi.azurewebsites.net?format=json)
+    * [Conference API](https://bigconference.azurewebsites.net)
 
 * Complete the previous tutorial, [Define custom metadata](add-metadata-properties.md), to define custom metadata for your APIs.
 
@@ -41,7 +41,7 @@ When you register (add) an API in your API center, the API registration includes
 
 After registering an API, you can add versions and definitions to the API.
 
-The following steps register two sample APIs: Swagger Petstore API and Demo Conference API (see [Prerequisites](#prerequisites)). If you prefer, register APIs of your own.
+The following steps register two sample APIs: Swagger Petstore API and Conference API (see [Prerequisites](#prerequisites)). If you prefer, register APIs of your own.
 
 1. In the [portal](https://portal.azure.com), navigate to your API center.
 
@@ -70,7 +70,7 @@ The following steps register two sample APIs: Swagger Petstore API and Demo Conf
 
 1. Select **Create**. The API is registered.
 
-1. Repeat the preceding three steps to register another API, such as the Demo Conference API.
+1. Repeat the preceding three steps to register another API, such as the Conference API.
 
 > [!TIP]
 > When you register an API in the portal, you can select any of the predefined API types or enter another type of your choice. 
@@ -89,9 +89,9 @@ Here you add a version to one of your APIs:
 
 1. In the portal, navigate to your API center.
 
-1. In the left menu, select **APIs**, and then select an API, for example, *Demo Conference API*.
+1. In the left menu, select **APIs**, and then select an API, for example, *Swagger Petstore*.
 
-1. On the Demo Conference API page, under **Details**, select **Versions** > **+ Add version**.
+1. On the API page, under **Details**, select **Versions** > **+ Add version**.
 
     :::image type="content" source="media/register-apis/add-version.png" alt-text="Screenshot of adding an API version in the portal." lightbox="media/register-apis/add-version.png":::
 
@@ -126,9 +126,9 @@ To add an API definition to your version:
         |**Title**| Enter a title of your choice, such as *v2 Definition*.|Name you choose for the API definition.|
         |**Identification**|After you enter the preceding title, Azure API Center generates this identifier, which you can override.| Azure resource name for the definition.|
         | **Description** | Optionally enter a description. | Description of the API definition. |
-        | **Specification name** | For the Demo Conference API, select **OpenAPI**. | Specification format for the API.|
-        | **Specification version** | Enter a version identifier of your choice, such as *2.0*. | Specification version. |
-        |**Document**        | Browse to a local definition file for the Demo Conference API, or enter a URL. Example URL: `https://conferenceapi.azurewebsites.net?format=json`   |  API definition file.     |
+        | **Specification name** | For the Petstore API, select **OpenAPI**. | Specification format for the API.|
+        | **Specification version** | Enter a version identifier of your choice, such as *3.0*. | Specification version. |
+        |**Document**        | Browse to a local definition file for the Petstore API, or enter a URL. Example URL: `https://raw.githubusercontent.com/swagger-api/swagger-petstore/refs/heads/master/src/main/resources/openapi.yaml`   |  API definition file.     |
 
         :::image type="content" source="media/register-apis/add-definition.png" alt-text="Screenshot of adding an API definition in the portal." lightbox="media/register-apis/add-definition.png" :::
 

articles/api-center/media/register-apis/add-definition.png

@@ -60,7 +60,7 @@ Maintenance operations upgrade machines iteratively while App Service monitors t
 
 ### Are business hours reflected?
 
-Maintenance operations are optimized to start outside the standard business hours of 9 AM to 5 PM. Statistically, that's the best time for any interruptions and restarts of workloads because there's less stress on the system (in customer applications and transitively on the platform itself). For App Service plans and App Service Environment v2, maintenance can continue into business hours during longer maintenance events.
+Yes, business hours are reflected for the time zone of the region. Maintenance operations are optimized to start outside the standard business hours of 9 AM to 5 PM. Statistically, that's the best time for any interruptions and restarts of workloads because there's less stress on the system (in customer applications and transitively on the platform itself). If resources are still upgrading by 9 AM in a given region, the upgrade will safely pause before the next critical step and until the end of business hours. 
 
 ### What are my options to control routine maintenance?
 

articles/api-center/media/register-apis/add-version.png

@@ -1,6 +1,6 @@
 ---
-title: Route traffic using parameter based path selection in portal - Azure Application Gateway
-description: Learn how to use the Azure portal to configure an Azure Application Gateway to choose the backend pool based on the value of a header, part of URL, or query string in the request.
+title: Route traffic using parameter-based path selection in portal - Azure Application Gateway
+description: Use the Azure portal to configure an application gateway to choose the backend pool based on the value of a header, part of a URL, or a query string in the request.
 services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
@@ -9,51 +9,47 @@ ms.date: 09/10/2024
 ms.author: greglin
 ms.custom: mvc
 ---
-# Perform parameter based path selection with Azure Application Gateway - Azure portal
+# Perform parameter-based path selection with Azure Application Gateway - Azure portal
 
-This article describes how to use the Azure portal to configure an [Application Gateway v2 SKU](./application-gateway-autoscaling-zone-redundant.md) instance to perform parameter based path selection by combining the capabilities of URL Rewrite with path-based routing.
+This article describes how to use the Azure portal to configure an [Azure Application Gateway v2 SKU](./application-gateway-autoscaling-zone-redundant.md) instance to perform parameter-based path selection by combining the capabilities of URL Rewrite with path-based routing.
 
 If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.
 
 ## Before you begin
 
-You need to have an Application Gateway v2 SKU instance to complete the steps in this article. URL rewrite and rewriting headers aren't supported in the v1 SKU. If you don't have the v2 SKU, create an [Application Gateway v2 SKU](./tutorial-autoscale-ps.md) instance before you begin.
-
+You need to have an Application Gateway v2 SKU instance to finish the steps in this article. URL Rewrite and rewriting headers aren't supported in the v1 SKU. If you don't have the v2 SKU, create an [Application Gateway v2 SKU](./tutorial-autoscale-ps.md) instance before you begin.
 
 ## Sign in to Azure
 
 Sign in to the [Azure portal](https://portal.azure.com/) with your Azure account.
 
-## Configure parameter based path selection
-
-For this example, you have a shopping website and the product category is passed as query string in the URL, and you want to route the request to backend based on the query string, then:
-
-**Step 1:**  Create a path-map as shown in the following image:
+## Configure parameter-based path selection
 
-:::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-1.png" alt-text="A screenshot of URL rewrite scenario 1-1.":::
+For this example, you have a shopping website. The product category is passed as a query string in the URL. To route the request to the backend based on the query string, follow these steps.
 
-**Step 2 (a):** Create a rewrite set which has 3 rewrite rules: 
+1. Create a path map.
 
-* The first rule has a condition that checks the *query_string* variable for *category=shoes* and has an action that rewrites the URL path to /*listing1* and has **Reevaluate path map** enabled
+   :::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-1.png" alt-text="Screenshot that shows a URL Rewrite scenario 1-1.":::
 
-* The second rule has a condition that checks the *query_string* variable for *category=bags* and has an action that rewrites the URL path to /*listing2*  and has **Reevaluate path map** enabled
+1. Create a rewrite set that has three rewrite rules:
 
-* The third rule has a condition that checks the *query_string* variable for *category=accessories* and has an action that rewrites the URL path to /*listing3* and has **Reevaluate path map** enabled
+   * The first rule has a condition that checks the `query_string` variable for `category=shoes`. An action rewrites the URL path to `/listing1`. **Reevaluate path map** is enabled.
+   * The second rule has a condition that checks the `query_string` variable for `category=bags`. An action rewrites the URL path to `/listing2`. **Reevaluate path map** is enabled.
+   * The third rule has a condition that checks the `query_string` variable for `category=accessories`. An action rewrites the URL path to `/listing3`. **Reevaluate path map** is enabled.
 
-    :::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-2.png" alt-text="A screenshot of URL rewrite scenario 1-2.":::
+     :::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-2.png" alt-text="Screenshot that shows the URL Rewrite scenario 1-2.":::
 
- 
-**Step 2 (b):** Associate this rewrite set with the default path of the previous path-based rule:
+1. Associate this rewrite set with the default path of the previous path-based rule.
 
-:::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-3.png" alt-text="A screenshot of URL rewrite scenario 1-3.":::
+   :::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-3.png" alt-text="Screenshot that shows the URL rewrite scenario 1-3.":::
 
-If the user requests *contoso.com/listing?category=any*, then it's matched with the default path since none of the path patterns in the path map (/listing1, /listing2, /listing3) are matched. Since you associated the previous rewrite set with this path, this rewrite set is evaluated. Because the query string doesn't match the condition in any of the 3 rewrite rules in this rewrite set, no rewrite action takes place. Therefore, the request is routed unchanged to the backend associated with the default path (which is *GenericList*).
+If the user requests `contoso.com/listing?category=any`, it's matched with the default path because the path patterns in the path map (`/listing1`, /`listing2`, /`listing3`) don't match. Because you associated the previous rewrite set with this path, this rewrite set is evaluated. The query string doesn't match the condition in any of the three rewrite rules in this rewrite set, so no rewrite action takes place. The request is routed unchanged to the backend associated with the default path (which is `GenericList`).
 
-If the user requests *contoso.com/listing?category=shoes*, then the default path is matched. However, in this case, the condition in the first rule matches. Therefore, the action associated with the condition is executed, which rewrites the URL path to /*listing1*  and reevaluates the path-map. When the path-map is reevaluated, the request matches the path associated with pattern */listing1* and the request is routed to the backend associated with this pattern (ShoesListBackendPool).
+If the user requests `contoso.com/listing?category=shoes`, the default path is matched. In this case, the condition in the first rule matches. The action associated with the condition is executed, which rewrites the URL path to `/listing1` and reevaluates the path map. When the path map is reevaluated, the request matches the path associated with the pattern `/listing1`. The request is routed to the backend associated with this pattern (`ShoesListBackendPool`).
 
 > [!NOTE]
-> This scenario can be extended to any header or cookie value, URL path, query string or server variables based on the conditions defined and essentially enables you to route requests based on those conditions.
+> You can extend this scenario to any header or cookie value, URL path, query string, or server variables based on the conditions defined. You can then route requests based on those conditions.
 
-## Next steps
+## Related content
 
-To learn more about how to set up some common use cases, see [common header rewrite scenarios](./rewrite-http-headers-url.md).
+To learn more about how to set up some common use cases, see [Common header rewrite scenarios](./rewrite-http-headers-url.md).