Merge pull request #312061 from MicrosoftDocs/main

Auto Publish – main to live - 2026-02-20 12:00 UTC

Author: learn-build-service-prod[bot]

articles/api-management/api-management-gateways-overview.md

@@ -85,7 +85,7 @@ The following tables compare features available in the following API Management
 | [Managed domain certificates](configure-custom-domain.md?tabs=managed#domain-certificate-options) |  ✔️ | ❌ | ✔️ | ❌ | ❌ |
 | [TLS settings](api-management-howto-manage-protocols-ciphers.md) |  ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
 | **HTTP/2** (Client-to-gateway) | ✔️<sup>4</sup> | ✔️<sup>4</sup> |❌ | ✔️ | ❌ |
-| **HTTP/2** (Gateway-to-backend) |  ❌ | ✔️<sup>5</sup> | ❌ | ✔️<sup>5</sup> | ❌ |
+| **HTTP/2** (Gateway-to-backend) |  ❌ | ❌ | ❌ | ✔️<sup>5</sup> | ❌ |
 | API threat detection with [Defender for APIs](protect-with-defender-for-apis.md) | ✔️ | ✔️ |  ❌ | ❌ | ❌ |
 
 <sup>1</sup> Depends on how the gateway is deployed, but is the responsibility of the customer.<br/>
@@ -126,7 +126,7 @@ Managed and self-hosted gateways support all available [policies](api-management
 | Feature support  | Classic  |  V2  | Consumption | Self-hosted<sup>1</sup>  | Workspace |
 | --- | --- | ----- | ----- | ---------- | ----- |
 | [Dapr integration](api-management-policies.md#integration-and-external-communication) |  ❌ | ❌ |❌ | ✔️ | ❌ |
-| [Service Bus integration](send-service-bus-message-policy.md) (preview) |  ✔️ | ❌ | ❌ | ❌ | ❌ |
+| [Service Bus integration](send-service-bus-message-policy.md) (preview) |  ✔️ | ✔️ | ✔️ | ❌ | ❌ |
 | [GraphQL resolvers](api-management-policies.md#graphql-resolvers) and [GraphQL validation](api-management-policies.md#content-validation)|  ✔️ | ✔️ |✔️ | ❌ | ❌ |
 | [Get authorization context](get-authorization-context-policy.md) |  ✔️ |  ✔️ |✔️ | ❌ | ❌ |
 | [Authenticate with managed identity](authentication-managed-identity-policy.md) |  ✔️ |  ✔️ |✔️ | ✔️ | ❌ |

articles/iot-operations/develop-edge-apps/howto-build-wasm-modules-vscode.md

@@ -26,7 +26,7 @@ The extension is supported on the following platforms:
 
 - Linux
 - Windows Subsystem for Linux (WSL)
-- Windows
+- Windows (be sure to use a Windows shell such as PowerShell or Command Prompt when when you run the extension commands on Windows)
 
 To learn more about graphs and WASM in Azure IoT Operations, see:
 
@@ -48,8 +48,8 @@ Development environment:
 Docker images:
 
 ```bash
-docker pull mcr.microsoft.com/azureiotoperations/processor-app:1.1.4
-docker tag mcr.microsoft.com/azureiotoperations/processor-app:1.1.4 host-app
+docker pull mcr.microsoft.com/azureiotoperations/processor-app:1.1.5
+docker tag mcr.microsoft.com/azureiotoperations/processor-app:1.1.5 host-app
 
 docker pull mcr.microsoft.com/azureiotoperations/devx-runtime:0.1.8
 docker tag mcr.microsoft.com/azureiotoperations/devx-runtime:0.1.8 devx
@@ -78,7 +78,9 @@ This command builds all the operators in the workspace and creates `.wasm` files
 
 ### Run the graph application locally
 
-Press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Run Application Graph**. Select **release** as the run mode. This command runs the graph application locally by using the local execution environment with the `graph.dataflow.yaml` file in the workspace.
+To start the local execution environment, press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Start Development Environment**. Select **release** as the run mode.
+
+When the local execution environment is running, press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Run Application Graph**. Select **release** as the run mode. This command runs the graph application locally by using the local execution environment with the `graph.dataflow.yaml` file in the workspace.
 
 It also reads from `hostapp.env.list` to set the environment variable `TK_CONFIGURATION_PARAMETERS` for data flow operator configuration parameters.
 
@@ -291,6 +293,8 @@ connections:
 
 Copy the `data` folder that contains the sample data from the cloned samples repository `explore-iot-operations\samples\wasm\data` to the current workspace. The `data` folder contains three JSON files with sample input temperature data.
 
+If you previously stopped the local execution environment, press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Start Development Environment**. Select **release** as the run mode.
+
 Press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Run Application Graph**:
 
 1. Select the `graph.dataflow.yaml` graph file.
@@ -352,13 +356,11 @@ You can modify the test data in the `data/` folder to experiment with different
 
 ### Build and run the state store scenario
 
-1. Press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Build All Data Flow Operators**.
-
-1. Select **release** as the build mode. Wait for the build to complete.
+If you previously stopped the local execution environment, press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Start Development Environment**. Select **release** as the run mode.
 
-1. Press `Ctrl+Shift+P` again and search for **Azure IoT Operations: Run Application Graph**.
+1. Press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Build All Data Flow Operators**. Select **release** as the build mode. Wait for the build to complete.
 
-1. Select **release** as the run mode.
+1. Press `Ctrl+Shift+P` again and search for **Azure IoT Operations: Run Application Graph**. Select **release** as the run mode.
 
 1. Select the `data` folder in your VS Code workspace for your input data. The DevX container launches to run the graph with the sample input.
 
@@ -435,6 +437,8 @@ The `data/` folder contains three test files:
 
 ### Build and run the schema registry scenario
 
+If you previously stopped the local execution environment, press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Start Development Environment**. Select **release** as the run mode.
+
 1. Press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Build All Data Flow Operators**.
 
 1. Select **release** as the build mode. Wait for the build to complete.
@@ -459,13 +463,14 @@ After processing completes:
 
 This example shows how the schema registry validates incoming messages and filters out messages that don't conform to the defined schema.
 
+Stop the local execution environment when you're done testing in release mode by pressing `Ctrl+Shift+P` and searching for **Azure IoT Operations: Stop Development Environment**.
+
 ## Debug WASM modules using the VS Code extension
 
 This example shows you how to debug WASM modules locally using breakpoints and the integrated debugger in VS Code.
 
 ### Prerequisites
 
-
 Complete the [Schema registry support for WASM modules](#schema-registry-support-for-wasm-modules) example to set up the sample workspace.
 
 ### Set up debugging
@@ -491,6 +496,8 @@ Complete the [Schema registry support for WASM modules](#schema-registry-support
 
 ### Run with debugging enabled
 
+Press `Ctrl+Shift+P` to open the command palette and search for **Azure IoT Operations: Start Development Environment**. Select **debug** as the run mode.
+
 1. Press `Ctrl+Shift+P` and search for **Azure IoT Operations: Run Application Graph**.
 
 1. Select the `lldb-debug.graph.dataflow.yaml` graph file.
@@ -501,15 +508,6 @@ Complete the [Schema registry support for WASM modules](#schema-registry-support
 
 1. After the DevX container launches, you see the host-app container start with an `lldb-server` for debugging.
 
-You use a special debug graph file because the current debugger can attach to only one custom WASM operator in a debug session. The dedicated debug graph lets you keep your normal `graph.dataflow.yaml` and prevents the debugger from attaching unpredictably when multiple modules exist.
-
-To create your own debug graph file:
-
-1. Copy your regular `graph.dataflow.yaml` to a new file. Using the `lldb-` prefix is a convention but the name is arbitrary.
-1. Remove all other custom WASM operators except the one you want to debug.
-1. Rebuild the target operator in **debug** mode so the symbols are available.
-1. Run the debug graph with run mode set to **debug**. The extension launches an `lldb-server` and attaches VS Code automatically.
-
 ### Debug the WASM module
 
 1. The execution automatically stops at the breakpoint you set in the `filter` function.
@@ -558,6 +556,8 @@ This debugging capability enables you to troubleshoot issues, understand data fl
 
 - **Host app stability**: The local execution environment might occasionally stop working and require restarting to recover.
 
+- **Remote debugging limitations**: Currently, you can't remotely debug WASM modules running in Azure Linux 3.0 due to incompatible LLDB versions.
+
 ## Troubleshooting
 
 ### Viewing logs

articles/stream-analytics/includes/event-generator-app.md

@@ -1,16 +1,11 @@
 ---
-title: include file
-description: include file
+title: Event generator application
+description: This include file has steps for creating an event hub, event generator application, and Stream Analytics job to analyze the data generated by the event generator application.
 author: spelluru
 ms.service: azure-stream-analytics
 ms.topic: include
-ms.date: 02/14/2024
+ms.date: 02/19/2026
 ms.author: spelluru
-ms.custom:
-  - "include file"
-  - sfi-image-nochange
-  - sfi-ropc-nochange
-
 ---
 
 ## Sign in to Azure
@@ -38,10 +33,10 @@ Use the following steps to create an event hub and send call data to that event
         :::image type="content" source="media/event-generator-app/create-event-hub-namespace.png" alt-text="Screenshot showing the Create Namespace page.":::
     1. On the **Review + create** page of the namespace creation wizard, select **Create** at the bottom of the page after reviewing all settings. 
 5. After the namespace is deployed successfully, select **Go to resource** to navigate to the **Event Hubs Namespace** page.
-6. On the **Event Hubs Namespace** page, select **+Event Hub** on the command bar.
+6. On the **Event Hubs namespace** page, select **+Event Hub** on the command bar.
 
     :::image type="content" source="media/event-generator-app/add-event-hub-button.png" alt-text="Screenshot showing the Add event hub button on the Event Hubs Namespace page.":::    
-1. On the **Create Event Hub** page, enter a **Name** for the event hub. Set the **Partition Count** to 2.  Use the default options in the remaining settings and select **Review + create**. 
+1. On the **Create Event Hub** page, enter a **Name** for the event hub. Set the **Partition Count** to 2. Use the default options in the remaining settings and select **Review + create**. 
 
     :::image type="content" source="media/event-generator-app/create-event-hub-portal.png" alt-text="Screenshot showing the Create event hub page.":::    
 1. On the **Review + create** page, select **Create** at the bottom of the page. Then wait for the deployment to succeed.
@@ -50,7 +45,7 @@ Use the following steps to create an event hub and send call data to that event
 
 Before an application can send data to Azure Event Hubs, the event hub must have a policy that allows access. The access policy produces a connection string that includes authorization information.
 
-1. On the **Event Hubs Namespace** page, select **Shared access policies** on the left menu.
+1. On the **Event Hubs namespace** page, select **Shared access policies** on the left menu.
 1. Select **RootManageSharedAccessKey** from the list of policies. 
 
     :::image type="content" source="media/event-generator-app/select-key.png" alt-text="Screenshot that shows the Shared access policies page.":::
@@ -71,7 +66,7 @@ Before you start the TelcoGenerator app, you should configure it to send data to
 2. Open the `TelcoGenerator\TelcoGenerator\telcodatagen.exe.config` file in a text editor of your choice There's more than one `.config` file, so be sure that you open the correct one.
 3. Update the `<appSettings>` element in the config file with the following details:
 
-   * Set the value of the **EventHubName** key to the value of the **EntityPath** at the end of the connection string.
+   * Set the value of the **EventHubName** key to the name of the event hub you created in the previous section.
    * Set the value of the **Microsoft.ServiceBus.ConnectionString** key to the connection string to the namespace. If you use a connection string to an event hub, not a namespace, remove `EntityPath` value (`;EntityPath=myeventhub`) at the end. **Don't forget** to remove the semicolon that precedes the EntityPath  value. 
 4. Save the file.
 5. Next open a command window and change to the folder where you unzipped the TelcoGenerator application. Then enter the following command:
@@ -101,7 +96,9 @@ Before you start the TelcoGenerator app, you should configure it to send data to
 Now that you have a stream of call events, you can create a Stream Analytics job that reads data from the event hub.
 
 1. To create a Stream Analytics job, navigate to the [Azure portal](https://portal.azure.com/).
-2. Select **Create a resource** and search for **Stream Analytics job**. Select the **Stream Analytics job** tile and select **Create**.
+1. Select **All services** in the left menu, search for **Stream Analytics jobs**, hover the mouse over the **Stream Analytics jobs** tile, and then select **+** button or select **Create** in the pop-up window.
+
+    :::image type="content" source="media/event-generator-app/find-stream-analytics-resource.png" alt-text="Screenshot showing how to find Stream Analytics in the Azure portal.":::
 1. On the **New Stream Analytics job** page, follow these steps:
     1. For **Subscription**, select the subscription that contains the Event Hubs namespace.
     1. For **Resource group**, select the resource group you created earlier.
@@ -130,7 +127,7 @@ The next step is to define an input source for the job to read data using the ev
     1. For **Event hub name**, select the event hub you created in the previous section. All the event hubs available in the selected namespace are listed in the dropdown.
     1. For **Event hub consumer group**, keep the **Create new** option selected so that a new consumer group is created on the event hub. We recommend that you use a distinct consumer group for each Stream Analytics job. If no consumer group is specified, the Stream Analytics job uses the `$Default` consumer group. When a job contains a self-join or has multiple inputs, some inputs later might be read by more than one reader. This situation affects the number of readers in a single consumer group.
     1. For **Authentication mode**, select **Connection string**. It's easier to test the tutorial with this option.  
-    1. For **Event hub policy name**, select **Use existing**, and then select the policy you created earlier. 
+    1. For **Event hub policy name**, select **Use existing**, and then select the default policy: **RootManageSharedAccessKey**. 
     1. Select **Save** at the bottom of the page. 
 
         :::image type="content" source="media/event-generator-app/configure-stream-analytics-input.png" alt-text="Screenshot showing the Event Hubs configuration page for an input.":::