Now in Public Preview: System events for data-plane in API Management gateway
We’re excited to announce the public preview of new data-plane system events in Azure Event Grid for the Azure API Management managed gateway (starting with classic tiers). This new capability provides near-real-time visibility into critical operations within your data-plane, helping you extend your API traffic with monitoring, automate responses, and prevent disruptions. These data-plane events complement the existing control-plane events available in Azure Event Grid system topics, marking the beginning of expanded event-driven capabilities in Azure API Management. What’s New? 1. Circuit Breaker Events: Our managed gateway now publishes circuit breaker status changes to Event Grid, so you can act before issues escalate. Microsoft.ApiManagement.Gateway.CircuitBreakerOpened Triggered when the failure threshold is reached, and traffic to a backend is temporarily blocked. Microsoft.ApiManagement.Gateway.CircuitBreakerClosed Indicates recovery and that traffic has resumed to the previously blocked backend. 2. Self-Hosted Gateway Token Events: Stay informed about authentication token status to ensure deployed gateways do not become disconnected. Microsoft.ApiManagement.Gateway.TokenNearExpiry Published 7 days before a token’s expiration to prompt proactive key rotation. Microsoft.ApiManagement.Gateway.TokenExpired Indicates a failed authentication attempt due to an expired token—preventing synchronization with the cloud instance. (note: API traffic is not disrupted). And this is just the beginning! We're continuously expanding event-driven capabilities in Azure API Management. Stay tuned for more system events coming soon! Why This Matters? With system events for data-plane, managed gateway now offer near-real-time extensibility via Event Grid. This allows customers to: Detect and respond to failures instantly. Automate alerts and workflows for proactive issue resolution. Ensure smooth operations with timely token management. Public Preview Limitations Single-Instance Scope: Events are scoped to the individual gateway instance where they occur. No cross-instance aggregation yet. Available in classic tiers only: This feature is currently supported only on the classic Developer, Basic, Standard, and Premium tiers of API Management. Get Started Today Start monitoring your APIs in real-time with event-driven architecture today. Follow the event schema and samples to build subscribers and handlers. Review integration guidance with Event Grid to wire up your automation pipelines. For a full list of supported Azure API Management system events and integration guidance, visit the Azure Event Grid integration docs.
🧩 Use Index + Direct Access to pull data across loops in Data Mapper
When working with repeating structures in Logic Apps Data Mapper, you may run into situations where two sibling loops exist under the same parent. What if you need to access data from one loop while you’re inside the other? This is where the Direct Access function, used in combination with Index, can save the day. 🧪 Scenario In this pattern, we’re focusing on the schema nodes shown below: 📸 Source & Destination Schemas (with loops highlighted) In the source schema: Under the parent node VehicleTrips, we have two sibling arrays: Vehicle → contains VehicleRegistration Trips → contains trip-specific values like VehicleID, Distance, and Duration In the destination schema: We're mapping into the repeating node Looping/Trips/Trip It expects each trip’s data along with a flattened VehicleRegistration value that combines both: The current trip’s VehicleID The corresponding vehicle’s VehicleRegistration The challenge? These two pieces of data live in two separate sibling arrays. 🧰 Try it yourself 📎 Download the sample files from GitHub Place them into the following folders in your Logic Apps Standard project: Artifacts → Source, destination and dependency schemas (.xsd) Map Definitions → .lml map file Maps → The .xslt file generated when you save the map Then right-click the .lml file and select “Open with Data Mapper” in VS Code. 🛠️ Step-by-step Breakdown ✅ Step 1: Set up the loop over Trips Start by mapping the repeating Trips array from the source to the destination's Trip node. Within the loop, we map: Distance Duration These are passed through To String functions before mapping, as the destination schema expects them as string values. As you map the child nodes, you will notice a loop automatically added on parent nodes (Trips->Trip) 📸 Mapping Distance and Duration nodes (context: we’re inside Trips loop) 🔍 Step 2: Use Index and Direct Access to bring in sibling loop values Now we want to map the VehicleRegistration node at the destination by combining two values: VehicleID (from the current trip) VehicleRegistration (from the corresponding vehicle) ➡️ Note: Before we add the Index function, delete the auto-generated loop from Trips to Trip To fetch the matching VehicleRegistration: Use the Index function to capture the current position within the Trips loop 📸 Index setup for loop tracking Use the Direct Access function to retrieve VehicleRegistration from the Vehicle array. 📘 Direct Access input breakdown The Direct Access function takes three inputs: Index – from the Index function, tells which item to access Scope – set to Vehicle, the array you're pulling from Target Node – VehicleRegistration, the value you want This setup means: “From the Vehicle array, get the VehicleRegistration at the same index as the current trip.” 📸 Direct Access setup 🔧 Step 3: Concatenate and map the result Use the Concat function to combine: VehicleID (from Trips) VehicleRegistration (from Vehicle, via Direct Access) Map the result to VehicleRegistration in the destination. 📸 Concat result to VehicleRegistration ➡️ Note: Before testing, delete the auto-generated loop from Vehicle to Trip 📸 Final map connections view ✅ Step 4: Test the output Once your map is saved, open the Test panel and paste a sample payload. You should see each Trip in the output contain: The original Distance and Duration values (as strings) A VehicleRegistration field combining the correct VehicleID and VehicleRegistration from the sibling array 📸 Sample Trip showing the combined nodes 💬 Feedback or ideas? Have feedback or want to share a mapping challenge? Open an issue on GitHubLog Ingestion to Azure Log Analytics Workspace with Logic App Standard
Currently, to send logs to Azure Log Analytics, the recommended method involves using the Azure Log Analytics Data Collector. This is a managed connector that typically requires public access to your Log Analytics Workspace (LAW). Consequently, this connector does not function if your LAW has Virtual Network (VNet) integration, as outlined in the Azure Monitor private link security documentation. Solution: Logic App Standard for VNet Integrated Log Analytics Workspace To address this limitation, a solution has been developed using Logic App Standard to directly connect to the LAW ingestion http endpoint. The relevant API documentation for this endpoint can be found here: Log Analytics REST API | Microsoft Learn. It's important to note that the current version of this endpoint exclusively supports authentication via a shared key, as detailed in the Log Analytics REST API Reference | Microsoft Learn. Any request to the Log Analytics HTTP Data Collector API must include the Authorization header. To authenticate a request, you must sign the request with either the primary or secondary key for the workspace that is making the request and pass that signature as part of the request. Implementing Shared Key Authentication with C# Inline Script The proposed solution involves building a small C# inline script within the Logic App Standard to handle the shared key authentication process. Sample code for this implementation has been uploaded to my GitHub: LAWLogIngestUsingHttp string dateString = DateTime.UtcNow.ToString("r"); byte[] content = Encoding.UTF8.GetBytes(jsonData); int contentLength = content.Length; string method = "POST"; string contentType = "application/json"; string resource = "/api/logs"; string stringToSign = $"{method}\n{contentLength}\n{contentType}\nx-ms-date:{dateString}\n{resource}"; byte[] sharedKeyBytes = Convert.FromBase64String(connection.SharedKey); using HMACSHA256 hmac = new HMACSHA256(sharedKeyBytes); byte[] stringToSignBytes = Encoding.UTF8.GetBytes(stringToSign); byte[] signatureBytes = hmac.ComputeHash(stringToSignBytes); string signature = Convert.ToBase64String(signatureBytes); HTTP Action Configuration Subsequently, an HTTP action within the Logic App Standard is configured to call the Log Analytics ingestion endpoint using an HTTP POST method. The endpoint URL follows this format: https://{WorkspaceId}.ods.opinsights.azure.com/api/logs?api-version=2016-04-01 Remember to replace {WorkspaceId} with your actual Log Analytics Workspace ID. the custom table name will be in the log-type headerAzure API Management Your Auth Gateway For MCP Servers
The Model Context Protocol (MCP) is quickly becoming the standard for integrating Tools 🛠️ with Agents 🤖 and Azure API Management is at the fore-front, ready to support this open-source protocol 🚀. You may have already encountered discussions about MCP, so let's clarify some key concepts: Model Context Protocol (MCP) is a standardized way, (a protocol), for AI models to interact with external tools, (and either read data or perform actions) and to enrich context for ANY language models. AI Agents/Assistants are autonomous LLM-powered applications with the ability to use tools to connect to external services required to accomplish tasks on behalf of users. Tools are components made available to Agents allowing them to interact with external systems, perform computation, and take actions to achieve specific goals. Azure API Management: As a platform-as-a-service, API Management supports the complete API lifecycle, enabling organizations to create, publish, secure, and analyze APIs with built-in governance, security, analytics, and scalability. New Cool Kid in Town - MCP AI Agents are becoming widely adopted due to enhanced Large Language Model (LLM) capabilities. However, even the most advanced models face limitations due to their isolation from external data. Each new data source requires custom implementations to extract, prepare, and make data accessible for any model(s). - A lot of heavy lifting. Anthropic developed an open-source standard - the Model Context Protocol (MCP), to connect your agents to external data sources such as local data sources (databases or computer files) or remote services (systems available over the internet through e.g. APIs). MCP Hosts: LLM applications such as chat apps or AI assistant in your IDEs (like GitHub Copilot in VS Code) that need to access external capabilities MCP Clients: Protocol clients that maintain 1:1 connections with servers, inside the host application MCP Servers: Lightweight programs that each expose specific capabilities and provide context, tools, and prompts to clients MCP Protocol: Transport layer in the middle At its core, MCP follows a client-server architecture where a host application can connect to multiple servers. Whenever your MCP host or client needs a tool, it is going to connect to the MCP server. The MCP server will then connect to for example a database or an API. MCP hosts and servers will connect with each other through the MCP protocol. You can create your own custom MCP Servers that connect to your or organizational data sources. For a quick start, please visit our GitHub repository to learn how to build a remote MCP server using Azure Functions without authentication: https://aka.ms/mcp-remote Remote vs. Local MCP Servers The MCP standard supports two modes of operation: Remote MCP servers: MCP clients connect to MCP servers over the Internet, establishing a connection using HTTP and Server-Sent Events (SSE), and authorizing the MCP client access to resources on the user's account using OAuth. Local MCP servers: MCP clients connect to MCP servers on the same machine, using stdio as a local transport method. Azure API Management as the AI Auth Gateway Now that we have learned that MCP servers can connect to remote services through an API. The question now rises, how can we expose our remote MCP servers in a secure and scalable way? This is where Azure API Management comes in. A way that we can securely and safely expose tools as MCP servers. Azure API Management provides: Security: AI agents often need to access sensitive data. API Management as a remote MCP proxy safeguards organizational data through authentication and authorization. Scalability: As the number of LLM interactions and external tool integrations grows, API Management ensures the system can handle the load. Security remains to be a critical piece of building MCP servers, as agents will need to securely connect to protected endpoints (tools) to perform certain actions or read protected data. When building remote MCP servers, you need a way to allow users to login (Authenticate) and allow them to grant the MCP client access to resources on their account (Authorization). MCP - Current Authorization Challenges State: 4/10/2025 Recent changes in MCP authorization have sparked significant debate within the community. 🔍 𝗞𝗲𝘆 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀 with the Authorization Changes: The MCP server is now treated as both a resource server AND an authorization server. This dual role has fundamental implications for MCP server developers and runtime operations. 💡 𝗢𝘂𝗿 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻: To address these challenges, we recommend using 𝗔𝘇𝘂𝗿𝗲 𝗔𝗣𝗜 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 as your authorization gateway for remote MCP servers. 🔗For an enterprise-ready solution, please check out our azd up sample repo to learn how to build a remote MCP server using Azure API Management as your authentication gateway: https://aka.ms/mcp-remote-apim-auth The Authorization Flow The workflow involves three core components: the MCP client, the APIM Gateway, and the MCP server, with Microsoft Entra managing authentication (AuthN) and authorization (AuthZ). Using the OAuth protocol, the client starts by calling the APIM Gateway, which redirects the user to Entra for login and consent. Once authenticated, Entra provides an access token to the Gateway, which then exchanges a code with the client to generate an MCP server token. This token allows the client to communicate securely with the server via the Gateway, ensuring user validation and scope verification. Finally, the MCP server establishes a session key for ongoing communication through a dedicated message endpoint. Diagram source: https://aka.ms/mcp-remote-apim-auth-diagram Conclusion Azure API Management (APIM) is an essential tool for enterprise customers looking to integrate AI models with external tools using the Model Context Protocol (MCP). In this blog, we've emphasized the simplicity of connecting AI agents to various data sources through MCP, streamlining previously complex implementations. Given the critical role of secure access to platforms and services for AI agents, APIM offers robust solutions for managing OAuth tokens and ensuring secure access to protected endpoints, making it an invaluable asset for enterprises, despite the challenges of authentication. API Management: An Enterprise Solution for Securing MCP Servers Azure API Management is an essential tool for enterprise customers looking to integrate AI models with external tools using the Model Context Protocol (MCP). It is designed to help you to securely expose your remote MCP servers. MCP servers are still very new, and as the technology evolves, API Management provides an enterprise-ready solution that will evolve with the latest technology. Stay tuned for further feature announcements soon! Acknowledgments This post and work was made possible thanks to the hard work and dedication of our incredible team. Special thanks to Pranami Jhawar, Julia Kasper, Julia Muiruri, Annaji Sharma Ganti Jack Pa, Chaoyi Yuan and Alex Vieira for their invaluable contributions. Additional Resources MCP Client Server integration with APIM as AI gateway Blog Post: https://aka.ms/remote-mcp-apim-auth-blog Sequence Diagram: https://aka.ms/mcp-remote-apim-auth-diagram APIM lab: https://aka.ms/ai-gateway-lab-mcp-client-auth Python: https://aka.ms/mcp-remote-apim-auth .NET: https://aka.ms/mcp-remote-apim-auth-dotnet On-Behalf-Of Authorization: https://aka.ms/mcp-obo-sample 3rd Party APIs – Backend Auth via Credential Manager: Blog Post: https://aka.ms/remote-mcp-apim-lab-blog APIM lab: https://aka.ms/ai-gateway-lab-mcp YouTube Video: https://aka.ms/ai-gateway-lab-demoHybrid deployment model for Logic Apps- Performance Analysis and Optimization recommendations
A few weeks ago, we announced the Public Preview Refresh release of Logic Apps hybrid deployment model that allows customers to run Logic Apps workloads on a customer managed infrastructure. This model provides the flexibility to execute workflows, either on-premises or in any cloud environment, thereby offering enhanced control over the operation of logic apps. By utilizing customer-managed infrastructure, organizations can adhere to regulatory compliance requirements and optimize performance according to their specific needs. As customers consider leveraging hybrid environments, understanding the performance of logic apps under various configurations and scenarios becomes critical. This document offers an in-depth performance evaluation of Azure Logic Apps within a hybrid deployment framework. It examines, several key factors such as CPU and memory allocation and scaling mechanisms, providing valuable insights aimed at maximizing the application’s efficiency and performance. Achieving Optimal Logic Apps Performance in Hybrid Deployments In this section, we will explore the key aspects that affect Logic Apps performance when deployed in a hybrid environment. Factors such as the underlying infrastructure of the Kubernetes environment, SQL configuration and scaling configuration can significantly impact the efficiency of workflows and the overall performance of the applications. The following blog entry provides details of the scaling mechanism of Hybrid deployment model - Scaling mechanism in hybrid deployment model for Azure Logic Apps Standard | Microsoft Community Hub Configure Container Resource allocation: When you create a Logic App, a default value of 0.5 vCPU and 1GiB of memory would be allocated. From the Azure Portal, you can modify this allocation from the Container blade. - Create Standard logic app workflows for hybrid deployment - Azure Logic Apps | Microsoft Learn Currently, the maximum allocation is set to 2vCPU and 4 GiB memory per app. In the future, there would be a provision made to choose higher allocations. For CPU intense/memory intense processing like custom code executions, select a higher value for these parameters. In the next section, we will be comparing the performance with different values of the CPU and memory allocation. This allocation would impact the billing calculation of the Logic App resource. Refer vCPU calculation for more details on the billing impact. Optimize the node count and size in the Kubernetes cluster. Kubernetes runs application workloads by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. A node pool is a group of nodes that share the same configuration (CPU, Memory, Networking, OS, maximum number of pods, etc.). You can choose the capacity (cores and memory), minimum node count and maximum node count for each node pool of the Kubernetes cluster. We recommend allocating a higher capacity for processing CPU intense, or memory intense applications Configure Scale rule settings: For a Logic App resource, we recommend you configure the maximum and minimum replicas which could be scaled out when a scale event occurs. A higher value for the max replicas helps in sudden spikes in the number of application requests. The interval with which the scaler checks for the scaling event and the cooldown period for the scaling event can also be configured from the Scale blade of Logic Apps resource. These parameters impact the scaling pattern. Optimize the SQL server configuration: The hybrid deployment model uses Microsoft SQL for runtime storage. As such, there are lot of SQL operations performed throughout the execution of the workflow and SQL capacity has a significant impact on the performance of the app. Microsoft SQL server could either be a SQL server on Windows, or an Azure SQL database. Few recommendations on the SQL configuration for better performance: If you are using, Azure SQL database, run it on a SQL elastic pool. If you are using SQL server on Windows, run with at least 4vCPU configuration. Scale out the SQL server once the CPU usage of the SQL server hits 60-70% of the total available CPU. Performance analysis: For this performance analysis exercise, we have used a typical enterprise integration scenario which includes the below components. Data transformation: XSLT transformation, validation, and XML parsing actions Data routing: File system connector for storing the transformed content in a file share. Message queuing: RabbitMQ connector for sending the transformation result to Rabbit MQ queue endpoint. Control operations: For-each loop for looping through multiple records, condition execution, Scope, and error handling blocks. Request response: The XML data transmitted via HTTP request, and the status returned as a response. Summary: For these tests, we used the following environment settings: Kubernetes cluster: AKS cluster with Standard D2sV3 (2vCPU, 8GiBmemory) Max replicas: 20 Cooldown period: 300 seconds Polling interval: 30 With the above environment and settings, we have performed multiple application tests with different configuration of SQL server, resource allocation and test durations using Azure load testing tool. In the following table, we have summarized the response time, throughput, and the total vCPU consumption for each of these configurations. You can check each scenario for detailed information. Configuration Results Scenario SQL CPU and Memory allocation per Logic App Test duration Load 90 th Percentile Response time Throughput Total vCPU consumed Scenario 1 SQL general purpose V2 1vCPU/2GiB Memory 10 minutes with 50 users 503 requests 68.62 seconds 0.84/s 3.42 Scenario 2 SQL Elastic pool-4000DTU 1vCPU/2GiB Memory 10 minutes with 50 users 1004 requests 40.74 seconds 1.65/s 3 Scenario 3 SQL Elastic pool-4000DTU 2vCPU/4GiB Memory 10 minutes with 50 users 997 requests 40.63 seconds 1.66/s 4 Scenario 4 SQL Elastic pool-4000DTU 2vCPU/4GiB Memory 30 minutes with 50 users 3421 requests 26.6Seconds 1.9/s 18.6 Scenario 5 SQL Elastic pool-4000DTU 0.5vCPU/1GiB Memory 30 minutes with 50 users 3055 requests 31.38 seconds 1.7/s 12.4 Scenario 6 SQL 2022 Enterprise on Standard D4s V3 VM 0.5vCPU/1GiB Memory 30 minutes with 50 users 4105 requests 27.15 seconds 2.28/s 10 Scenario 1: SQL general purpose V2 with 1vCPU and 2 GiB Memory – 10 minutes test with 50 users In this scenario, we conducted a load test for 10 minutes with 50 users with the Logic App configuration of: 1 vCPU and 2 GiB Memory and Azure SQL database running on General purpose V2 plan. There were 503 requests with multiple records in each payload and it achieved the 68.62 seconds as the 90 th percentile response time and a throughput of 0.84 requests per second. Scaling: The Kubernetes nodes scaled out to 12 nodes and in total 3.42 vCPUs used by the app for the test duration. SQL Metrics: The CPU usage of the SQL server reached 90% of CPU usage quite early and stayed above 90% for the remaining duration of the test. From our backend telemetry as well, we observed that the actions executions were faster, but there was latency between the actions, which indicates SQL bottlenecks. Scenario 2: SQL elastic pool, with 1vCPU and 2 GiB memory- 10 minutes test with 50 users In this scenario, we conducted a load test for 10 minutes with 50 users with the Logic App configuration of: 1 vCPU and 2 GiB Memory and Azure SQL database running on a SQL elastic pool with 4000 DTU. There were 1004 requests with multiple records in each payload and it achieved the 40.74 seconds as the 90 th percentile response time and a throughput of 1.65 requests per second. Scaling: The Kubernetes nodes scaled out to 15 nodes and in total 3 vCPUs used by the app for the test duration. SQL Metrics: The SQL server’s CPU utilization peaked to 2% of the elastic pool. Scenario 3: SQL elastic pool, with 2vCPU and 4 GiB memory- 10 minutes test with 50 users In this scenario, we conducted a load test for 10 minutes with 50 users with the Logic App configuration of 2 vCPU and 4 GiB Memory and Azure SQL database running on a SQL elastic pool with 4000 DTU. There were 997 requests with multiple records in each payload and it achieved the 40.63 seconds as the 90 th percentile response time and a throughput of 1.66 requests per second. Scaling: The Kubernetes nodes scaled out to 21 nodes and in total 4 vCPUs used by the app for the test duration. SQL Metrics: The SQL server’s CPU utilization peaked to 5% of the elastic pool. Scenario 4: SQL elastic pool, with 2vCPU and 4 GiB memory- 30 minutes test with 50 users In this scenario, we conducted a load test for 30 minutes with 50 users with the Logic App configuration of: 2 vCPU and 4 GiB Memory and Azure SQL database running on a SQL elastic pool with 4000 DTU. There were 3421 requests with multiple records in each payload and it achieved the 26.67 seconds as the 90 th percentile response time and a throughput of 1.90 requests per second. Scaling: The Kubernetes nodes scaled out to 20 nodes and in total 18.6 vCPUs used by the app for the test duration. SQL Metrics: The SQL server’s CPU utilization peaked to 4.7% of the elastic pool. Scenario 5: SQL Elastic pool, with 0.5vCPU and 1 GiB memory- 30 minutes test with 50 users In this scenario, we have conducted a load test for 30 minutes with 50 users with the Logic App configuration of 0.5 vCPU and 1 GiB Memory and Azure SQL database running on a SQL elastic pool with 4000 DTU. There were 3055 requests with multiple records in each payload and it achieved the 31.38 seconds as the 90 th percentile response time and a throughput of 1.70 requests per second. Scaling: The Kubernetes nodes scaled out to 18 nodes and in total 12.4 vCPUs used by the app for the test duration. SQL Metrics: The SQL server’s CPU utilization peaked to 8.6% of the elastic pool CPU. Scenario 6: SQL 2022 Enterprise Gen2 on Windows 2022 on Standard D4s v3 image, with 0.5vCPU and 1 GiB memory- 30 minutes test with 50 users In this scenario, we conducted a load test for 30 minutes with 50 users with the Logic App configuration of: 0.5 vCPU and 1 GiB Memory and Azure SQL database running on an on-premises SQL 2022 Enterprise Gen2 version running on a Windows 2022 OS with Standard D4s v3 image (4 vCPU and 16GIB memory) There were 4105 requests with multiple records in each payload and it achieved the 27.15 seconds as the 90 th percentile response time and a throughput of 2.28 requests per second. Scaling: The Kubernetes nodes scaled out to 8 nodes and in total 10 vCPUs used by the app for the test duration. SQL metrics: The CPU usage of the SQL server went above 90% after few minutes and there was latency on few runs. Findings and recommendations: The following are the findings and recommendations for this performance exercise. Consider that this load test was conducted using unique conditions. If you conduct a similar test, the results and findings might vary, depending on factors such as workflow complexity, configuration, resource allocation and network configuration. The KEDA scaler performs the scale-out and scale-in operations faster, as such, while the total vCPU usage remains quite low, though the nodes scaled out in the range of 1-20 nodes. The SQL configuration plays a crucial role in reducing the latency between the action executions. For a satisfactory load test, we recommend starting with at least 4vCPU configuration on SQL server and scale out once CPU usage of the SQL server hits 60-70% of the total available CPU. For critical applications, we recommend having a dedicated SQL database for better performance. Increasing the dedicated vCPU allocation of the Logic App resource is helpful for the SAP connector, Rules Engine, .NET Framework based custom code operations and for the applications with many complex workflows. As a general recommendation, regularly monitor performance metrics and adjust configurations to meet evolving requirements and follow the coding best practices of Logic Apps standard. Consider reviewing the following article, for recommendations to optimize your Azure Logic Apps workloads: https://techcommunity.microsoft.com/blog/integrationsonazureblog/logic-apps-standard-hosting--performance-tips/3956971AI Gateway Enhancements: LLM policies, Real-Time API support, Content Safety, and more
As AI becomes more deeply integrated into applications, managing and governing Large Language Models (LLMs) is more important than ever. Today, we’re excited to announce several major updates to AI Gateway in Azure API Management, including the general availability of LLM policies, expanded real-time API support, new integrations for semantic caching and content safety, and a streamlined UI experience to make it even easier to get started. Plus, you can now opt in to early access for the latest AI Gateway features. Let’s dive into what’s new! General Availability of LLM policies AI Gateway has already proven essential in addressing the unique challenges of managing and governing access to Large Language Models (LLMs), such as Azure OpenAI, specifically around tracking and controlling token usage. Last year, we expanded AI Gateway’s capabilities by introducing a preview of new LLM-focused policies for models available through the Azure AI Model Inference API. Today, we’re excited to announce the general availability of these LLM policies: llm-token-limit, llm-emit-metric, llm-content-safety, and semantic caching policies. With this release, you can now apply these policies not only to models listed in the Azure AI Foundry model catalog but also to OpenAI-compatible models served through third-party inference providers or even to models hosted in your own infrastructure. These capabilities give you greater flexibility, improved governance, and deeper insights across your LLM deployments, regardless of where your models are running. Integration with Azure AI Content Safety As LLMs are increasingly integrated into customer-facing applications, ensuring content safety has become essential for maintaining ethical and legal standards. To help safeguard users from harmful, offensive, or misleading content. With the integration of Azure AI Content Safety into AI Gateway, you can now automatically moderate all incoming user requests by configuring the llm-content-safety policy with specific sensitive categories. Learn more about llm-content-safety policy. Track and limit token consumption for Azure OpenAI Real Time API Azure OpenAI GPT-4o Realtime API for speech and audio is part of the GPT-4o model family that supports low-latency, "speech in, speech out" conversational interactions. The GPT-4o audio Realtime API is designed to handle real-time, low-latency conversational interactions, making it a great fit for use cases involving live interactions between a user and a model, such as customer support agents, voice assistants, and real-time translators. We’re adding extending models supported in llm-token-limit and llm-token-metric policies to support WebSocket-based Realtime API. This enhancement allows you to safely provide access to the GPT-4o Realtime API for your developers while maintaining full visibility and control over token consumption across your organization. General Availability of Semantic Caching After months of working closely with customers during the preview, we’re excited to announce the general availability of semantic caching capabilities in AI Gateway. We’ve seen a wide range of real-world usage scenarios, and this feedback has helped us refine the experience. With this GA release, we’re also extending support to Azure Managed Redis (currently in preview), which can now be used as the backend for semantic caching in AI Gateway. Learn more about llm-semantic-caching policies. Import Azure OpenAI Improvements As we continue to add more powerful capabilities to AI Gateway in Azure API Management, we recognize that not everyone is deeply familiar with configuring policies manually. To simplify adoption, we previously introduced a one-click import experience that allows you to bring in existing Azure OpenAI endpoints with basic configuration for token limiting and token tracking policies – all directly from the UI. Today, we’re making that experience even more seamless. The import workflow now supports automatic configuration for semantic caching policies. You can easily select a compatible Redis cache and an embeddings model from a dropdown, and Azure APIM will configure the semantic caching policies for you. AI Gateway Update Group Keep an eye out as we roll out these updates across all regions where Azure API Management is available. Don’t want to wait for the latest AI Gateway features to reach your instance? You can now configure service update settings for your Azure API Management instances. By selecting the AI Gateway Early (GenAI Release) update group, you’ll get early access to the newest AI Gateway features and improvements – before they reach the broader update groups. Learn more about update groups.
Using Graph API to assign roles to logic app managed identity
1. Need to enable logic app Managed Identity, and copy the Object ID Logic app -> identity -> System assigned 2. Find the role related service principle ID and role ID: For example, if we want to have a role: 'WindowsDefenderATP.MachineIsolate' roles Reference: List servicePrincipals - Microsoft Graph v1.0 | Microsoft Learn Method: Get URL: https://graph.microsoft.com/v1.0/servicePrincipals?$filter=displayName eq 'WindowsDefenderATP' 3. Copy The Id 4. Searching "Machine.Isolate", Copy role ID: (make sure you are copying the one which Origin is "Application" 5. Invoke a Post request to grant permission: Reference: List appRoleAssignments granted for a service principal - Microsoft Graph v1.0 | Microsoft Learn Method: POST URL:https://graph.microsoft.com/v1.0/servicePrincipals/(replace This with your identity's ID from Step1)/appRoleAssignedTo Body: { "principalId": "(replace This with your identity's ID from Step1)", "resourceId": "(replace this ID with your own ID got from step 3)", "appRoleId": "(replace this ID with your own ID got from step 4)" } If execute successfully, you will see the permission is added to your system assigned managed identity.
How to send Excel file via HTTP in Logic App
In this article, we will transfer an Excel file from a OneDrive to the other OneDrive using HTTP action. It is not required to be OneDrive only, but I just used for an example. It could be SharePoint documents, SFTP server, blob storage, or any other places you prefer, which applied to both source and destination. 1. The first step is retrieving file from OneDrive, and here I am using OneDrive Connector action "Get file content using path". Make sure you set "Infer Content Type" to "No". Note that, if you mark "Infer Content Type" as "Yes", it will get file content as XLSX format thus we cannot transfer it using HTTP properly; If you mark "Infer Content Type" as "No", then received content type is base64 encoded binary, and that is what we need. 2. Then comes to HTTP action, there are two key points here: 1) make sure we set the "Content-Type" to "application/octet-stream" which stands for binary content; 2) the POST body should be "@base64ToBinary(body('Get_file_content_using_path')?['$content'])" which converted base64 content back to binary for transferring. 3. The last step is receiving the content and creating the Excel file in destination. Make sure the request trigger body is purely empty to ensure binary content received. Then you can simply create ".xlsx" file with content "triggerBody()" with your appropriate name. This should also apply to any other binary content transfer scenario, and hope this article could help especially when transferring cross tenants and services.Unleash Innovation with a Modern Integration Platform and an API-First Strategy
Join us for a two-day global virtual event where you’ll discover how to unlock the full potential of your data and APIs to drive intelligent, agile growth with Azure Integration Services and an API-first strategy. In the first session of our series, we explored why this event is a must-attend highlighting how modernizing legacy systems is the essential first step in any successful digital transformation. By breaking free from outdated architectures, organizations can lay the groundwork for long-term agility and innovation. Now, we’re taking the next step: unlocking the full potential of your data and APIs to build a truly connected enterprise. Whether you're unifying siloed systems, enabling real-time insights, or scaling secure API ecosystems, this event will show you how to accelerate your API-first journey and equip your business to move faster, operate smarter, and innovate more securely. Fuel Business Growth with Real-Time Insights and Smarter Decision Making Your enterprise data holds the key to innovation but it’s often stuck in silos. Learn how Azure Integration Services empowers you to connect your apps, data, and services in real-time to deliver insights that accelerate smarter decisions. Whether you’re optimizing operations, enhancing customer experiences, or automating processes, real-time integration gives your business the agility to innovate at scale. Customer spotlight: DocuSign is already using real-time data integration to transform operations and reach new heights in productivity and growth. Unlock the Power of an API-First Strategy APIs are no longer just developer tools, they’re strategic assets for accelerating innovation. In this session, we’ll show you how Azure API Management helps you scale your API initiatives while staying secure and compliant. You’ll discover: How the Developer Portal offers a seamless, self-service experience for internal teams and external partners How to adopt a federated API management model to scale across teams and environments with centralized control The latest strategies to secure your APIs against emerging threats—without slowing down innovation Hear from the leaders: Gain insights from Transcard, Moneris, Heineken, and CareFirst BlueCross BlueShield as they share how Azure API Management is enabling faster, smarter, and more secure operations. Maximize the Value of Your APIs with Forrester Insights How do you measure the true value of APIs? We’ll walk through exclusive findings from Forrester’s Total Economic Impact™ (TEI) study, revealing how organizations are: Reducing operational costs Streamlining development and IT workflows Unlocking new business value through scalable, governed API strategies Learn how to create an API roadmap that increases agility, improves ROI, and fuels long-term business success. Why Attend? By joining this event, you’ll gain: A practical roadmap for driving innovation through integration and APIs First-hand insights from Microsoft experts and industry leaders A look at how leading companies are transforming with API-first strategies Real-world use cases, expert-led demos, and actionable guidance Reserve Your Spot Now! This is your chance to hear directly from Microsoft experts and industry leaders, dive into API-first strategies, and discover how to optimize integration to drive smarter growth and innovation. Don’t miss this event, where you’ll learn how to build the API ecosystems and workflows that will shape the future of your business. US/Canada: Reserve your seat today! Day 1: Tuesday, 29 April 2025 | 9:00 AM – 12:30 PM PDT Day 2: Wednesday, 30 April 2025 | 9:00 AM – 12:30 PM PDT Australia/New Zealand: Reserve Your Seat Today! Day 1: Wednesday, 30 April 2025 | 9:00 AM – 12:30 PM AEDT Day 2: Thursday, 1 May 2025 | 9:00 AM – 12:30 PM AEDT Europe: Reserve Your Seat Today! Day 1: Tuesday, 29 April 2025 | 9:00am – 12:30pm BST Day 2: Wednesday, 30 April 2025 | 9:00am – 12:30pm BSTEnhancing AI Integrations with MCP and Azure API Management
As AI Agents and assistants become increasingly central to modern applications and experiences, the need for seamless, secure integration with external tools and data sources is more critical than ever. The Model Context Protocol (MCP) is emerging as a key open standard enabling these integrations - allowing AI models to interact with APIs, Databases and other services in a consistent, scalable way. Understanding MCP MCP utilizes a client-host-server architecture built upon JSON-RPC 2.0 for messaging. Communication between clients and servers occurs over defined transport layers, primarily: stdio: Standard input/output, suitable for efficient communication when the client and server run on the same machine. HTTP with Server-Sent Events (SSE): Uses HTTP POST for client-to-server messages and SSE for server-to-client messages, enabling communication over networks, including remote servers. Why MCP Matters While Large Language Models (LLMs) are powerful, their utility is often limited by their inability to access real-time or proprietary data. Traditionally, integrating new data sources or tools required custom connectors/ implementations and significant engineering efforts. MCP addresses this by providing a unified protocol for connecting agents to both local and remote data sources - unifying and streamlining integrations. Leveraging Azure API Management for remote MCP servers Azure API Management is a fully managed platform for publishing, securing, and monitoring APIs. By treating MCP server endpoints as other backend APIs, organizations can apply familiar governance, security, and operational controls. With MCP adoption, the need for robust management of these backend services will intensify. API Management retains a vital role in governing these underlying assets by: Applying security controls to protect the backend resources. Ensuring reliability. Effective monitoring and troubleshooting with tracing requests and context flow. n this blog post, I will walk you through a practical example: hosting an MCP server behind Azure API Management, configuring credential management, and connecting with GitHub Copilot. A Practical Example: Automating Issue Triage To follow along with this scenario, please check out our Model Context Protocol (MCP) lab available at AI-Gateway/labs/model-context-protocol Let's move from theory to practice by exploring how MCP, Azure API Management (APIM) and GitHub Copilot can transform a common engineering workflow. Imagine you're an engineering manager aiming to streamline your team's issue triage process - reducing manual steps and improving efficiency. Example workflow: Engineers log bugs/ feature requests as GitHub issues Following a manual review, a corresponding incident ticket is generated in ServiceNow. This manual handoff is inefficient and error prone. Let's see how we can automate this process - securely connecting GitHub and ServiceNow, enabling an AI Agent (GitHub Copilot in VS Code) to handle triage tasks on your behalf. A significant challenge in this integration involves securely managing delegated access to backend APIs, like GitHub and ServiceNow, from your MCP Server. Azure API Management's credential manager solves this by centralizing secure credential storage and facilitating the secure creation of connections to your third-party backend APIs. Build and deploy your MCP server(s) We'll start by building two MCP servers: GitHub Issues MCP Server Provides tools to authenticate on GitHub (authorize_github), retrieve user infromation (get_user ) and list issues for a specified repository (list_issues). ServiceNow Incidents MCP Server Provides tools to authenticate with ServiceNow (authorize_servicenow), list existing incidents (list_incidents) and create new incidents (create_incident). We are using Azure API Management to secure and protect both MCP servers, which are built using Azure Container Apps. Azure API Management's credential manager centralizes secure credential storage and facilitates the secure creation of connections to your backend third-party APIs. Client Auth: You can leverage API Management subscriptions to generate subscription keys, enabling client access to these APIs. Optionally, to further secure /sse and /messages endpoints, we apply the validate-jwt policy to ensure that only clients presenting a valid JWT can access these endpoints, preventing unauthorized access. (see: AI-Gateway/labs/model-context-protocol/src/github/apim-api/auth-client-policy.xml) After registering OAuth applications in GitHub and ServiceNow, we update APIM's credential manager with the respective Client IDs and Client Secrets. This enables APIM to perform OAuth flows on behalf of users, securely storing and managing tokens for backend calls to GitHub and ServiceNow. Connecting your MCP Server in VS Code With your MCP servers deployed and secured behind Azure API Management, the next step is to connect them to your development workflow. Visual Studio Code now supports MCP, enabling GitHub Copilot's agent mode to connect to any MCP-compatible server and extend its capabilities. Open Command Pallette and type in MCP: Add Server ... Select server type as HTTP (HTTP or Server-Sent Events) Paste in the Server URL Provide a Server ID This process automatically updates your settings.json with the MCP server configuration. Once added, GitHub Copilot can connect to your MCP servers and access the defined tools, enabling agentic workflows such as issue triage and automation. You can repeat these steps to add the ServiceNow MCP Server. Understanding Authentication and Authorization with Credential Manager When a user initiates an authentication workflow (e.g, via the authorize_github tool), GitHub Copilot triggers the MCP server to generate an authorization request and a unique login URL. The user is redirected to a consent page, where their registered OAuth application requests permissions to access their GitHub account. Azure API Management acts as a secure intermediary, managing the OAuth flow and token storage. Flow of authorize_github: Step 1 - Connection initiation: GitHub Copilot Agent invokes a sse connection to API Management via the MCP Client (VS Code) Step 2 - Tool Discovery: APIM forwards the request to the GitHub MCP Server, which responds with available tools Step 3 - Authorization Request: GitHub Copilot selects and executes authorize_github tool. The MCP server generates an authorization_id for the chat session. Step 4 - User Consent: If it's the 1st login, APIM requests a login redirect URL from the MCP Server The MCP Server sends the Login URL to the client, prompting the user to authenticate with GitHub Upon successful login, GitHub redirects the client with an authorization code Step 5 - Token Exchange and Storage: The MCP Client sends the authorization code to API Management APIM exchanges the code for access and refresh tokens from GitHub APIM securely stores the token and creates an Access Control List (ACL) for the service principal. Step 6 - Confirmation: APIM confirms successful authentication to the MCP Client, and the user can now perform authenticated actions, such as accessing private repositories. Check out the python logic for how to implement it: AI-Gateway/labs/model-context-protocol/src/github/mcp-server/mcp-server.py Understanding Tool Calling with underlaying APIs in API Management Using the list_issues tool, Connection confirmed APIM confirms the connection to the MCP Client Issue retrieval: The MCP Client requests issues from the MCP server The MCP Server attaches the authorization_id as a header and forwards the request to APIM The list of issues is returned to the agent You can use the same process to add the ServiceNow MCP Server. With both servers connected, GitHub Copilot Agent can extract issues from a private repo in GitHub and create new incidences in ServiceNow, automating your triage workflow. You can define additional tools such as suggest_assignee tool, assign_engineer tool, update_incident_status tool, notify_engineer tool, request_feedback tool and other to demonstrate a truly closed-loop, automated engineering workflow - from issue creation to resolution and feedback. Take a look at this brief demo showcasing the entire end-to-end process: Summary Azure API Management (APIM) is an essential tool for enterprise customers looking to integrate AI models with external tools using the Model Context Protocol (MCP). In this blog, we demonstrated how Azure API Management's credential manager solves the secure creation of connections to your backend APIs. By integrating MCP servers with VS Code and leveraging APIM for OAuth flows and token management, you can enable secure, agenting automation across your engineering tools. This approach not only streamlines workflows like issues triage and incident creation but also ensures enterprise-grade security and governance for all APIs. Additional Resources Using Credential Manager will help with managing OAuth 2.0 tokens to backend services. Client Auth for remote MCP servers: AZD up: https://aka.ms/mcp-remote-apim-auth AI lab Client Auth: AI-Gateway/labs/mcp-client-authorization/mcp-client-authorization.ipynb Blog Post: https://aka.ms/remote-mcp-apim-auth-blog If you have any questions or would like to learn more about how MCP and Azure API Management can benefit your organization, feel free to reach out to us. We are always here to help and provide further insights. Connect with us on LinkedIn (Julia Kasper & Julia Muiruri) and follow for more updates, insights, and discussions on AI integrations and API management.
