Automated Test Framework - Missing Tests in Test Explorer
Have your tests created using the Logic Apps Standard Automated Test Framework disappeared from the Test Explorer in VS Code all of a sudden? The answer is a mismatch between the MSTest versions used. A recent update in the C# DevKit extension changed the minimum requirements for the MSTest library - it now requires the minimum of 3.7.*. The project scaffolding created byt the Logic Apps Standard extension uses 3.0.2. The good news is that you can fix this by just changing package versions on your project. Follow the instructions below to have this fixed: Open the .csproj that the extension created (e.g. LogicApps.csproj). Find the ItemGroup containing your package references. It should look like this: <ItemGroup> <PackageReference Include="MSTest" Version="3.2.0"/> <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0"/> <PackageReference Include="MSTest.TestAdapter" Version="3.2.0"/> <PackageReference Include="MSTest.TestFramework" Version="3.2.0"/> <PackageReference Include="Microsoft.Azure.Workflows.WebJobs.Tests.Extension" Version="1.0.0"/> <PackageReference Include="coverlet.collector" Version="3.1.2"/> </ItemGroup> Replace the package references with this new version: <ItemGroup> <PackageReference Include="Microsoft.Azure.Workflows.WebJobs.Tests.Extension" Version="1.*" /> <PackageReference Include="MSTest" Version="4.0.2" /> <PackageReference Include="coverlet.collector" Version="3.2.0" /> </ItemGroup> Once you make this change, restart VSCode window and rebuild your project - Test Explorer will start showing your tests again. Notice that this package reference is simplified as some of the previous references are already in the dependency chain, so don't need to be explicitly added. ℹ️ We are updating our extension to make sure that new projects are being generated with the new values, but you should make those changes manually on existing projects.Enforce or Audit Policy Inheritance in API Management
We’re excited to announce a new Azure Policy definition that lets you enforce or audit policy inheritance in Azure API Management. With this capability, platform and governance teams can ensure that API Management policies are always inherited across all policy scopes — operations, APIs, products, and workspaces — strengthening consistency, compliance, and security across your API estate. Why this matters In Azure API Management, the <base /> policy element plays a critical role: it ensures that a runtime policy inherits policies defined at a higher scope, such as product, workspace, or all APIs (global). Without <base />, developers can inadvertently (or intentionally) bypass important platform rules, for example: Security controls like authentication or IP restrictions Operational requirements such as logging, tracing, or rate-limiting Business policies such as quota enforcement The result can be inconsistent behavior, compliance drift, and gaps in governance. How the new policy helps With the new Azure Policy definition, you can automatically ensure that <base /> is located at the start of each API Management policy section — <inbound>, <outbound>, <backend>, and <on-error> — across policies configured on operations, APIs, products, and workspaces. You can set the effect parameter to: Audit: Identify operation, API, product, or workspace policies where <base /> is missing. Deny: Prevent deployment of policies that do not include <base />. Get started To enable this new Azure Policy definition: Navigate to Azure Policy in the Azure portal. Select “Definitions” from the menu and choose “API Management policies should inherit parent scope policies using <base />”. In the policy definition view, select “Assign”. Configure the policy assignment scope, parameter (audit or deny), and other details. View built-in Azure Policy definitions for API Management.Update To API Management Workspaces Breaking Changes: Built-in Gateway & Tiers Support
What’s changing? If your API Management service uses preview workspaces on the built-in gateway and meets the tier-based limits below, those workspaces will continue to function as-is and will automatically transition to general availability once built-in gateway support is fully announced. API Management tier Limit of workspaces on built-in gateway Premium and Premium v2 Up to 30 workspaces Standard and Standard v2 Up to 5 workspaces Basic and Basic v2 Up to 1 workspace Developer Up to 1 workspace Why this change? We introduced the requirement for workspace gateways to improve reliability and scalability in large, federated API environments. While we continue to recommend workspace gateways, especially for scenarios that require greater scalability, isolation, and long-term flexibility, we understand that many customers have established workflows using the preview workspaces model or need workspaces support in non-Premium tiers. What’s not changing? Other aspects of the workspace-related breaking changes remain in effect. For example, service-level managed identities are not available within workspaces. In addition to workspaces support on the built-in gateway described in the section above, Premium and Premium v2 services will continue to support deploying workspaces with workspace gateways. Resources Workspaces in Azure API Management Original breaking changes announcements Reduced tier availability Requirement for workspace gatewaysAnnouncing the availability of TLS 1.3 in Azure API Management in Preview
TLS 1.3 is the latest version of the internet’s most deployed security protocol, which encrypts data to provide a secure communication channel between two endpoints. TLS 1.3 support in Azure API Management is planned to rollout during the first week of February 2024. The rollout will happen in stages, this means some regions will get it first as we roll out globally.
🚀 New in Azure API Management: MCP in v2 SKUs + external MCP-compliant server support
Your APIs are becoming tools. Your users are becoming agents. Your platform needs to adapt. Azure API Management is becoming the secure, scalable control plane for connecting agents, tools, and APIs — with governance built in. -------------------------------------------------------------------------------------------------------------------------------------------------------------------- Today, we’re announcing two major updates to bring the power of the Model Context Protocol (MCP) in Azure API Management to more environments and scenarios: MCP support in v2 SKUs — now in public preview Expose existing MCP-compliant servers through API Management These features make it easier than ever to connect APIs and agents with enterprise-grade control—without rewriting your backends. Why MCP? MCP is an open protocol that enables AI agents—like GitHub Copilot, ChatGPT, and Azure OpenAI—to discover and invoke APIs as tools. It turns traditional REST APIs into structured, secure tools that agents can call during execution — powering real-time, context-aware workflows. Why API Management for MCP? Azure API Management is the single, secure control plane for exposing and governing MCP capabilities — whether from your REST APIs, Azure-hosted services, or external MCP-compliant runtimes. With built-in support for: Security using OAuth 2.1, Microsoft Entra ID, API keys, IP filtering, and rate limiting. Outbound token injection via Credential Manager with policy-based routing. Monitoring and diagnostics using Azure Monitor, Logs, and Application Insights. Discovery and reuse with Azure API Center integration. Comprehensive policy engine for request/response transformation, caching, validation, header manipulation, throttling, and more. …you get end-to-end governance for both inbound and outbound agent interactions — with no new infrastructure or code rewrites. ✅ What’s New? 1. MCP support in v2 SKUs Previously available only in classic tiers (Basic, Standard, Premium), MCP support is now in public preview for v2 SKUs — Basic v2, Standard v2, and Premium v2 — with no pre-requisites or manual enablement required. You can now: Expose any REST API as an MCP server in v2 SKUs Protect it with Microsoft Entra ID, keys or tokens Register tools in Azure API Center 2. Expose existing MCP-compliant servers (pass-through scenario) Already using tools hosted in Logic Apps, Azure Functions, LangChain or custom runtimes? Now you can govern those external tool servers by exposing them through API Management. Use API Management to: Secure external MCP servers with OAuth, rate limits, and Credential Manager Monitor and log usage with Azure Monitor and Application Insights Unify discovery with internal tools via Azure API Center 🔗 You bring the tools. API Management brings the governance. 🧭 What’s Next We’re actively expanding MCP capabilities in API Management: Tool-level access policies for granular governance Support for MCP resources and prompts to expand beyond tools 📚 Get Started 📘 Expose APIs as MCP servers 🌐 Connect external MCP servers 🔐 Secure access to MCP servers 🔎 Discover tools in API Center Summary Azure API Management is your single control plane for agents, tools and APIs — whether you're building internal copilots or connecting external toolchains. This preview unlocks more flexibility, less friction, and a secure foundation for the next wave of agent-powered applications. No new infrastructure. Secure by default. Built for the future.Workspaces Are Now Generally Available In Azure API Management Premium v2
We’re excited to announce the general availability of workspaces and workspace gateways in the Premium v2 tier of Azure API Management! Premium v2 tier remains in preview at the time of this announcement. Workspaces enable management and governance of APIs at scale. Whether you're supporting hundreds of APIs across teams or enabling new lines of business to independently manage their APIs, workspaces make it easier to adopt a federated API management model with central governance, observability, and security. To start using workspaces in Premium v2: Create an API Management Premium v2 service in a region where workspaces are available. Follow the documentation to create and set up workspaces. Learn more about workspaces.Announcing Federated Logging in Azure API Management
Managing APIs effectively requires robust security, governance, and deep operational visibility. With federated logging now available in Azure API Management, platform teams and API developers can monitor, troubleshoot, and optimize APIs more efficiently and without compromising security or collaboration. What is federated logging? As API ecosystems grow, maintaining centralized visibility while providing teams with the autonomy to manage and troubleshoot their APIs becomes a challenge. Federated logging centralizes insights for platform teams while empowering API teams with focused access to logs specific to their APIs, streamlining monitoring in large-scale API ecosystems. Centralized Monitoring for Platform Teams: Complete visibility into API health, performance, and usage trends across the organization. Autonomy for API Teams: Direct access to their own API logs, reducing reliance on platform teams and speeding up resolution times. Key Benefits Federated logging offers advantages for both platform and API teams, addressing their unique challenges and needs. For platform teams: Centralized Monitoring: Gain platform-wide visibility into API health, performance, and usage trends. Streamlined Troubleshooting: Quickly diagnose and resolve platform issues without dependency on individual API teams. Governance and Security: Ensure robust audit trails and compliance, supporting secure and scalable API management. For API teams: Faster Incident Resolution: Accelerate incident resolution thanks to immediate access to relevant logs, without waiting for the central platform team’s response. Actionable Insights: Track API growth, trends, and key performance metrics specific to your APIs to support reporting, planning, and strategic decision-making. Access Control: Limit access to logs to your API team only. How Federated Logging Works Federated logging is enabled using Azure Log Analytics and workspaces in Azure API Management: Platform teams configure logging to a centralized Log Analytics workspace for the entire API Management service, including individual workspaces. Platform teams can access centralized logs through the “Logs” page in the API Management service in the Azure portal or directly in the Log Analytics workspace. API teams can access logs for their workspace APIs through the “Logs” page in their API Management workspace in the Azure portal. Access control is enforced via Azure Log Analytics’ resource context mechanism, ensuring role-based log visibility. Get Started Today Federated logging in Azure API Management combines centralized monitoring and team autonomy, enabling efficient and effective operations. Start using federated logging by visiting the Azure API Management documentation.Introducing Workspace Gateway Metrics and Autoscale in Azure API Management
We’re excited to announce the availability of workspace gateway metrics and autoscale in Azure API Management, offering both real-time insights and automated scaling for your gateway infrastructure. This combination increases reliability, streamlines operations, and boosts cost efficiency. Monitor and Scale Gateway with New Metrics API Management workspace gateways now support two metrics: CPU Utilization (%): Represents CPU utilization across workspace gateway units. Memory Utilization (%): Represents memory utilization across workspace gateway units. Both metrics should be used together to make informed scaling decisions. For instance, if one of the metrics consistently exceeds a 70% threshold, adding an additional gateway unit to distribute the load can prevent outages during traffic increases. In most workloads, the CPU metric will determine scaling requirements. Automatically Scale Workspace Gateways In addition to manual scaling, Azure API Management workspace gateways now also feature autoscale, allowing for automatic scaling in or out based on metrics or a defined schedule. Autoscale provides several important benefits: Reliability: Autoscale ensures consistent performance by scaling out during periods of high traffic. Operational Efficiency: Automating scaling processes streamlines operations and eliminates manual and error-prone intervention. Cost Optimization: Autoscale scales down resources when traffic is lower, reducing unnecessary expenses. Access Metrics and Autoscale Settings You can access the new metrics in the “Metrics” page of your workspace gateway resource in the Azure portal or through Azure Monitor. Autoscale can be configured in the “Autoscale” page of your workspace gateway resource in the Azure portal or through the autoscale experience. Get Started Learn more about using metrics for scaling decisions.
Summing it up: Aggregating repeating nodes in Logic Apps Data Mapper 🧮
Logic Apps Data Mapper makes it easy to define visual, code-free transformations across structured JSON data. One pattern that's both powerful and clean: using built-in collection functions to compute summary values from arrays. This post walks through an end-to-end example: calculating a total from a list of items using just two functions — `Multiply` and `Sum`. 🧾 Scenario: Line Item Totals + Order Summary You’re working with a list of order items. For each item, you want to: Compute Total = Quantity × Price Then, compute the overall OrderTotal by summing all the individual totals 📥 Input { "orders" : [ { "Quantity" : 10, "Price" : 100 }, { "Quantity" : 20, "Price" : 200 }, { "Quantity" : 30, "Price" : 300 } ] } 📤 Output { "orders" : [ { "Quantity" : 10, "Price" : 100, "Total" : 1000 }, { "Quantity" : 20, "Price" : 200, "Total" : 4000 }, { "Quantity" : 30, "Price" : 300, "Total" : 9000 } ], "Summary": { "OrderTotal": 14000 } } 🔧 Step-by-step walkthrough 🗂️ 1. Load schemas in Data Mapper Start in the Azure Data Mapper interface and load: Source schema: contains the orders array with Quantity and Price Target schema: includes a repeating orders node and a Summary → OrderTotal field 📸 Docked schemas in the mapper 🔁 2. Recognize the repeating node The orders array shows a 🔁 icon on <ArrayItem>, marking it as a repeating node. 📸 Repeating node detection 💡 When you connect child fields like Quantity or Price, the mapper auto-applies a loop for you. No manual loop configuration needed. ➗ 3. Multiply Quantity × Price (per item) Drag in a Multiply function and connect: Input 1: Quantity Input 2: Price Now connect the output of Multiply directly to the Total node under Orders node in the destination. This runs once per order item and produces individual totals: [1000, 4000, 9000] 📸 Multiply setup ➕ 4. Aggregate All Totals Using Sum Use the same Multiply function output and pass it into a Sum function. This will combine all the individual totals into one value. Drag and connect: Input 1: multiply(Quantity, Price) Input 2: <ArrayItem> Connect the output of Sum to the destination node Summary → OrderTotal 1000 + 4000 + 9000 = 14000 📸 Sum function ✅ 5. Test the Output Run a test with your sample input by clicking on the Open test panel. Copy/paste the sample data and hit Test. The result should look like this: { "orders": [ { "Quantity": 10, "Price": 100, "Total": 1000 }, { "Quantity": 20, "Price": 200, "Total": 4000 }, { "Quantity": 30, "Price": 300, "Total": 9000 } ], "Summary": { "OrderTotal": 14000 } } 🧠 Why this pattern works 🔁 Repeating to repeating: You’re calculating Total per order 🔂 Repeating to non-repeating: You’re aggregating with Sum into a single node 🧩 No expressions needed — it’s all declarative This structure is perfect for invoices, order summaries, or reporting payloads where both detail and summary values are needed. 📘 What's coming We’re working on official docs to cover: All functions including collection (Join, Direct Access, Filter, etc.) that work on repeating nodes Behavior of functions inside loops Real-world examples like this one 💬 What should we cover next? We’re always looking to surface patterns that matter most to how you build. If there’s a transformation technique, edge case, or integration scenario you’d like to see explored next — drop a comment below and let us know. We’re listening. 🧡 Special thanks to Dave Phelps for collaborating on this scenario and helping shape the walkthrough.Announcing General Availability of Authoring API Management Policies with Microsoft Copilot in Azure
Earlier today, we announced the general availability of Microsoft Copilot in Azure. We're excited to share that authoring Azure API Management policies with Microsoft Copilot in Azure is also generally available, featuring localization, responsible AI, and enhancements to availability, performance, and capabilities. A Smarter Way to Author Policies If you’ve ever spent time wrestling with XML policy definitions or scoured documentation for guidance on applying the right transformations, you know that authoring policies in API Management can sometimes be a challenge. With Copilot in Azure, those days are becoming a thing of the past. By leveraging natural language prompts, Copilot helps you generate policy snippets, explain parts of your current configuration, or even convert policies from another platform without requiring you to be an expert on the policy syntax and details. Imagine simply asking, “Generate a policy to remove the X-AspNet-Version header” or “Explain this JWT validation policy,” and getting a contextually relevant answer right within the policy editing UI. That’s the power of Copilot now available to all developers. What Does This Mean for You? With this GA release, Microsoft Copilot’s policy authoring capabilities become a reliable tool in your API Management toolkit. Here’s what you can expect: Quick Policy Generation: No more searching for the right XML snippet or sifting through the documentation. Just type your requirements into the Copilot chat interface and let the AI generate a tailored policy for you. In-Depth Explanations: Whether you’re new to API Management or maintaining policies left behind by previous teams, Copilot can help explain how complex policies work, breaking down each section to provide clarity and context. Seamless Integration: Accessible straight from the policy editing experience in the APIs page of your API Management service in the Azure portal, Copilot is incorporated into your existing workflow. Productivity Boost for All Developers: From developers who are just starting out to seasoned architects, Copilot can accelerate the policy authoring process and reduce the time it takes to implement, optimize, or understand configurations. Developer Tips Here are a few tips for getting the most out of the policy authoring experience in Copilot. Experiment Freely: Experiment with different prompts. Try using Copilot not only to generate new policy code but also to recommend, explain, or improve policies. Customize Generated Code: While Copilot provides a solid starting point, remember that every API scenario is unique. Adjust the generated policies to fit your application’s needs. Provide Feedback: Use the thumbs up and thumbs down buttons on Copilot’s responses to help us improve. When giving thumbs down, check the option to log your prompt to allow us to troubleshoot, replicate, and understand the issue. This is the most effective way to share your feedback with Microsoft, so we can improve the product. Keep an Eye on Updates: As this service transitions from preview to GA, Microsoft continues to fine-tune its capabilities. We have improvements lined up to increase Copilot’s capabilities, accuracy, and latency and make it more discoverable in other parts of the API Management interface. How to Get Started Ready to give it a spin? Head over to your API Management service in the Azure portal to author policies with Copilot, learn more in the documentation, or watch it in action. Happy coding!
