Introducing Azure API Management Policy Toolkit
We’re excited to announce the early release of the Azure API Management Policy Toolkit, a set of libraries and tools designed to change how developers work with API Management policies, making policy management more approachable, testable, and efficient for developers. Empowering developers with Azure API Management Policy Toolkit Policies have always been at the core of Azure API Management, offering powerful capabilities to secure, change behavior, and transform requests and responses to the APIs. Recently, we've made the policies easier to understand and manage by adding Copilot for Azure features for Azure API Management. This allows you to create and explain policies with AI help directly within the Azure portal. This powerful tool lets developers create policies using simple prompts or get detailed explanations of existing policies. This makes it much easier for new users to write policies and makes all users more productive. Now, with the Policy Toolkit, we’re taking another significant step forward. This toolkit brings policy management even closer to the developer experience you know. Elevating policy development experience Azure API Management policies are written in Razor format, which for those unfamiliar with it can be difficult to read and understand, especially when dealing with large policy documents that include expressions. Testing and debugging policy changes requires deployment to a live Azure API Management instance, which slows down feedback loop even for small edits. The Policy Toolkit addresses these challenges. You can now author your policies in C#, a language that feels natural and familiar to many developers and write tests against them. This shift improves the policy writing experience for developers, makes policies more readable, and shortens the feedback loop for policy changes. Key toolkit features to transform your workflow: Consistent policy authoring. Write policies in C#. No more learning Razor syntax and mixing XML and C# in the same document. Syntax checking: Compile your policy documents to catch syntax errors and generate Razor-based equivalents. Unit testing: Write unit tests alongside your policies using your favorite unit testing framework. CI/CD integration: Integrate Policy Toolkit into automation pipelines for testing and compilation into Razor syntax for deployment. Current Limitations While we’re excited about the capabilities of the Policy Toolkit, we want to be transparent about its current limitation: Not all policies are supported yet, but we’re actively working on expanding the coverage. We are working on making the Policy Toolkit available as a NuGet package. In the meantime, you’ll need to build the solution on your own. Unit testing is limited to policy expressions and is not supported for entire policy documents yet. Get Started Today! We want you to try the Azure API Management Policy Toolkit and to see if it helps streamlining your policy management workflow. Check out documentation to get started. We’re eager to hear your feedback! By bringing policy management closer to the developer, we’re opening new possibilities to efficiently manage your API Management policies. Whether you’re using the AI-assisted approach with Copilot for Azure or diving deep into C# with the Policy Toolkit, we’re committed to making policy management more approachable and powerful.
Expose REST APIs as MCP servers with Azure API Management and API Center (now in preview)
As AI-powered agents and large language models (LLMs) become central to modern application experiences, developers and enterprises need seamless, secure ways to connect these models to real-world data and capabilities. Today, we’re excited to introduce two powerful preview capabilities in the Azure API Management Platform: Expose REST APIs in Azure API Management as remote Model Context Protocol (MCP) servers Discover and manage MCP servers using API Center as a centralized enterprise registry Together, these updates help customers securely operationalize APIs for AI workloads and improve how APIs are managed and shared across organizations. Unlocking the value of AI through secure API integration While LLMs are incredibly capable, they are stateless and isolated unless connected to external tools and systems. Model Context Protocol (MCP) is an open standard designed to bridge this gap by allowing agents to invoke tools—such as APIs—via a standardized, JSON-RPC-based interface. With this release, Azure empowers you to operationalize your APIs for AI integration—securely, observably, and at scale. 1. Expose REST APIs as MCP servers with Azure API Management An MCP server exposes selected API operations to AI clients over JSON-RPC via HTTP or Server-Sent Events (SSE). These operations, referred to as “tools,” can be invoked by AI agents through natural language prompts. With this new capability, you can expose your existing REST APIs in Azure API Management as MCP servers—without rebuilding or rehosting them. Addressing common challenges Before this capability, customers faced several challenges when implementing MCP support: Duplicating development efforts: Building MCP servers from scratch often led to unnecessary work when existing REST APIs already provided much of the needed functionality. Security concerns: Server trust: Malicious servers could impersonate trusted ones. Credential management: Self-hosted MCP implementations often had to manage sensitive credentials like OAuth tokens. Registry and discovery: Without a centralized registry, discovering and managing MCP tools was manual and fragmented, making it hard to scale securely across teams. API Management now addresses these concerns by serving as a managed, policy-enforced hosting surface for MCP tools—offering centralized control, observability, and security. Benefits of using Azure API Management with MCP By exposing MCP servers through Azure API Management, customers gain: Centralized governance for API access, authentication, and usage policies Secure connectivity using OAuth 2.0 and subscription keys Granular control over which API operations are exposed to AI agents as tools Built-in observability through APIM’s monitoring and diagnostics features How it works MCP servers: In your API Management instance navigate to MCP servers Choose an API: + Create a new MCP Server and select the REST API you wish to expose. Configure the MCP Server: Select the API operations you want to expose as tools. These can be all or a subset of your API’s methods. Test and Integrate: Use tools like MCP Inspector or Visual Studio Code (in agent mode) to connect, test, and invoke the tools from your AI host. Getting started and availability This feature is now in public preview and being gradually rolled out to early access customers. To use the MCP server capability in Azure API Management: Prerequisites Your APIM instance must be on a SKUv1 tier: Premium, Standard, or Basic Your service must be enrolled in the AI Gateway early update group (activation may take up to 2 hours) Use the Azure Portal with feature flag: ➤ Append ?Microsoft_Azure_ApiManagement=mcp to your portal URL to access the MCP server configuration experience Note: Support for SKUv2 and broader availability will follow in upcoming updates. Full setup instructions and test guidance can be found via aka.ms/apimdocs/exportmcp. 2. Centralized MCP registry and discovery with Azure API Center As enterprises adopt MCP servers at scale, the need for a centralized, governed registry becomes critical. Azure API Center now provides this capability—serving as a single, enterprise-grade system of record for managing MCP endpoints. With API Center, teams can: Maintain a comprehensive inventory of MCP servers. Track version history, ownership, and metadata. Enforce governance policies across environments. Simplify compliance and reduce operational overhead. API Center also addresses enterprise-grade security by allowing administrators to define who can discover, access, and consume specific MCP servers—ensuring only authorized users can interact with sensitive tools. To support developer adoption, API Center includes: Semantic search and a modern discovery UI. Easy filtering based on capabilities, metadata, and usage context. Tight integration with Copilot Studio and GitHub Copilot, enabling developers to use MCP tools directly within their coding workflows. These capabilities reduce duplication, streamline workflows, and help teams securely scale MCP usage across the organization. Getting started This feature is now in preview and accessible to customers: https://aka.ms/apicenter/docs/mcp AI Gateway Lab | MCP Registry 3. What’s next These new previews are just the beginning. We're already working on: Azure API Management (APIM) Passthrough MCP server support We’re enabling APIM to act as a transparent proxy between your APIs and AI agents—no custom server logic needed. This will simplify onboarding and reduce operational overhead. Azure API Center (APIC) Deeper integration with Copilot Studio and VS Code Today, developers must perform manual steps to surface API Center data in Copilot workflows. We’re working to make this experience more visual and seamless, allowing developers to discover and consume MCP servers directly from familiar tools like VS Code and Copilot Studio. For questions or feedback, reach out to your Microsoft account team or visit: Azure API Management documentation Azure API Center documentation — The Azure API Management & API Center TeamsWrite Logic Apps in C#: introducing the Logic Apps Standard SDK
The workflow you always wished you could write in code If you build on Logic Apps Standard, you already know the deal: the runtime is excellent at the unglamorous parts of integration - connecting to systems, retrying, scaling, keeping run history you can actually debug. What you sometimes wanted was a different front door. You're a .NET developer. You live in C#, source control, and pull requests. And for a long time, authoring a workflow meant leaving all of that behind for a visual designer and a JSON file. That's the gap the new Logic Apps Standard SDK closes. It lets you define Logic Apps Standard workflows in code - strongly typed, IntelliSense-guided C# - without giving up a single thing the runtime already does for you. What is the Logic Apps Standard SDK? The Logic Apps Standard SDK (Microsoft.Azure.Workflows.Sdk) is a NuGet package that gives you a fluent, code-first way to build workflow definitions in C#. Instead of dragging actions onto a canvas, you compose a workflow with method chaining: a trigger, then the actions that follow it, all the way to a response. Worth saying clearly, because people ask: this is a new way to define workflows - not a new runtime. The workflows you write with the SDK compile down to the same definitions and run on the same Logic Apps Standard runtime you use today. Same connectors. Same hosting. Same rich run history and monitoring. You're changing the authoring experience, not the engine underneath it. Why this matters for developers When your workflow lives in C#, it behaves like the rest of your code. A few things fall out of that almost for free: Type safety and IntelliSense - connector operations, triggers, and outputs are discoverable as you type, and the compiler catches mistakes before you run anything. Real source control and reviews - workflows diff like code, get reviewed in pull requests, and version alongside the services they orchestrate. Familiar tooling - refactor, debug with F5, and lean on the .NET ecosystem you already know. Extensibility on your terms — Compose your workflow declaratively with the fluent builder, then drop into plain imperative C# wherever a step needs logic that might be too complex to implement declaratively - loops, branching, a call into your own library, all encapsulated in a step of your workflow - without leaving the file or the language. And it isn't limited to one style of work. The SDK covers both enterprise integration workflows - the connect-systems-and-move-data scenarios Logic Apps is known for - and agentic workflows, where a conversational or autonomous AI agent drives the steps. Both are first-class in the same SDK, built from the same building blocks. There's one more angle worth calling out, because it's becoming hard to ignore: coding agents are simply better at writing imperative code than declarative JSON. And the reason is the same set of guardrails that helps you. Strong typing and a compilation step mean the code an agent produces is syntactically correct out of the gate — the type system and the compiler do the checking, so you don't have to. Layer unit tests on top and you've covered north of 90% of what matters; what's left is integration testing. Getting an LLM to the same level of accuracy against declarative JSON means building dedicated tooling to stand in for everything the compiler gives you for free. With code-first workflows, those guardrails are just there — which makes this a natural fit for an agent-assisted way of building. Getting started Everything here lives in the Logic Apps extension for VS Code. You'll want the Logic Apps Standard VS Code extension version 5.961.10 or later, which includes all the components you need to create code first workflows. Beyond that, the prerequisites are the ones you'd expect - VS Code with the Logic Apps extension, an Azure subscription you can create resources in, and a working comfort with C# and .NET. From a clean start, you're a handful of steps from a running workflow: Create the workspace — launch the Logic Apps extension and choose Create new Logic Apps workspace. Pick a folder, name the workspace and project, and when prompted for the workflow type, choose Logic Apps codeful - that's the code-first option that uses the SDK. Pick a workflow kind - name your first workflow and choose how it runs: Stateful, Autonomous agents (Preview), or Conversational agents (Preview). The agent options are where the agentic scenarios live. Enable connectors - when prompted, select Use connectors from Azure, choose your subscription and resource group, and pick Connection Keys for authentication. Managed identity is still in development, so connection keys are the way in for now. Find your way around - the project opens with Program.cs, which builds and starts the host, plus a workflow file (like workflow1.cs) where your trigger and actions are defined. The SDK compiles those definitions and runs them on the Logic Apps runtime. Run it - press F5 (or right-click Program.cs and pick Overview). The runtime starts locally and an overview page opens where you can fire triggers, watch run history, and inspect inputs and outputs. That last part is worth dwelling on: run history for SDK workflows uses the same rich visual view as designer-built ones. You author in code, but you monitor and troubleshoot exactly as you always have. A look at the capabilities Connectors and triggers Every workflow starts with a trigger and runs a series of actions. The SDK exposes both through two entry points - WorkflowTriggers and WorkflowActions - each split into BuiltIn and Managed. Built-in triggers and actions run directly in the runtime: HTTP request, recurrence, and the conversational agent trigger; actions like Compose, HTTP, Response, and custom code. Managed connectors give you the full Logic Apps connector catalog - Service Bus, SharePoint, SQL, and hundreds more - typed and ready to call. The managed surface is generated from the same connector definitions the designer uses, so the operations you know are right there: // Built-in trigger var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // Managed connector action — full catalog, strongly typed var getItems = WorkflowActions.Managed .Sharepointonline("sharepoint") .GetItems( dataset: () => "https://contoso.sharepoint.com", table: () => "orders-list-id") .WithName("GetOrders"); The fluent API streamlines the definition This is where it comes together. You compose a workflow by chaining operations with .Then(...). The shape of your code mirrors the shape of your workflow - read it top to bottom and you read the execution path. trigger .Then(validateOrder) .Then(getOrders) .Then(sendResponse); Control flow is part of the same fluent model. Built-in structures like Condition (if/else) and ForEach - along with Switch, Until, Scope, and Terminate - are just actions you chain in, each taking a small factory for the branch or loop body: var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => order.Total > 1000, trueBranch: () => requireApproval, falseBranch: () => autoApprove ).WithName("CheckOrderValue"); And ForEach takes the collection to iterate and a factory that builds the body for each item: var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => order.LineItems, actions: (item) => new WorkflowBuiltInActions() .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems"); Need parallel branches that fan back in? The same Then pattern handles branching and join - no JSON wiring, no run-after blocks to hand-edit. Extending workflows with custom code Some logic doesn't belong in a connector or an expression - it's just code. The CustomCode action lets you drop a real C# method into the middle of a workflow. It receives a WorkflowContext, so you can read the trigger payload or any earlier action's results and return a strongly typed value the next step can use: var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var trigger = await context.GetTriggerResults(); var order = await context.GetActionResults("GetOrders"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder"); That's the escape hatch that keeps you in flow: when a step needs custom transformation, validation, or a call into your own libraries, you write a method instead of bending an expression to do something it was never meant to. Handling failures: try/catch with run-after Real workflows have to deal with things going wrong, and the SDK gives you the same try/catch shape Logic Apps has always had - expressed in code. The .Then(...) overload takes a FlowStatus[] run-after condition, so a handler runs only when the step before it ends in a status you name. Wrap the risky work in a Scope (your try), then chain a handler that runs after it Failed or TimedOut (your catch): var tryProcess = WorkflowActions.BuiltIn.Control.Scope(() => callPaymentApi.Then(saveOrder) ).WithName("ProcessPayment"); var handleFailure = WorkflowActions.BuiltIn .Compose(inputs: () => "Payment failed — compensating") .WithName("HandleFailure"); trigger .Then(tryProcess) .Then(handleFailure, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut }); The status set is the whole vocabulary: Succeeded, Failed, Skipped, and TimedOut. Combine them however a step needs - a cleanup action that should run no matter what can list every status; a finally is just the union. The same idea scales to fan-in. When several parallel branches converge, the per-predecessor RunAfter overload lets the join wait on each branch independently - so you can require some to succeed and tolerate others failing: leftChain .Join(rightChain) .Then(merge, runAfter: new[] { new RunAfter(leftChain, FlowStatus.Succeeded), new RunAfter(rightChain, FlowStatus.Succeeded), }); Putting it together Here's a small but complete shape - an HTTP-triggered order workflow that validates input, branches on order value, loops over line items, runs custom code, and replies. The core steps live in a Scope so a single failure handler can catch anything that goes wrong, and a clean reply only runs when the work succeeds. Notice it's all one readable chain: namespace LogicApps { using Microsoft.Azure.Workflows.Sdk; using Microsoft.Azure.Workflows.Sdk.Connectors.Msnweather; using System.Net; public class OrderWorkflow : IWorkflowProvider { /// <summary> /// Gets the HTTP request/response workflow definition. /// </summary> public FlowDefinition[] GetWorkflows() { // --- Trigger ---------------------------------------------------- var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // --- Managed connector action (full catalog, strongly typed) ---- // Reused verbatim from the confirmed stateful1.cs pattern. var getWeather = WorkflowActions.Managed.Msnweather("msnweather").CurrentWeather( location: () => "98058", units: () => unitsInput.Imperial).WithName("GetWeather"); // --- Custom code: real C# in the middle of the workflow --------- var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var triggerResults = await context.GetTriggerResults(); var weather = await context.GetActionResults("GetWeather"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder"); // --- ForEach over a collection (control flow via .Control) ------- var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => trigger.TriggerOutput.Body["lineItems"], actions: (item) => WorkflowActions.BuiltIn .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems"); // --- Condition (if/else) (control flow via .Control) ------------ var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => true, trueBranch: () => processLines, falseBranch: () => WorkflowActions.BuiltIn .Compose(inputs: () => "Auto-approved").WithName("AutoApprove") ).WithName("CheckOrderValue"); // --- Scope groups the core steps so one handler catches failures - var processOrder = WorkflowActions.BuiltIn.Control.Scope(() => checkTotal .Then(getWeather) .Then(enrich) ).WithName("ProcessOrder"); // --- Responses -------------------------------------------------- var ok = WorkflowActions.BuiltIn.Response( responseBody: () => "Order processed").WithName("Reply"); var failed = WorkflowActions.BuiltIn.Response( statusCode: () => HttpStatusCode.InternalServerError, responseBody: () => "Order failed").WithName("ReplyFailed"); // --- Assemble --------------------------------------------------- // Happy path runs after the Scope Succeeded; the handler runs after // Failed or TimedOut. trigger .Then(processOrder) .Then(ok, runAfter: new[] { FlowStatus.Succeeded }) .Then(failed, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut }); return new[] { WorkflowFactory.CreateStatefulWorkflow("OrderWorkflow", trigger) }; } } } That last stretch is the best-practice shape in miniature: the happy-path Reply runs only after the Scope Succeeded, while a separate handler catches Failed or TimedOut and returns a 500 - no exception plumbing, just run-after conditions. You implement IWorkflowProvider, hand your trigger graph to WorkflowFactory as a stateful, stateless, or agent workflow, and the host registers it. Run it with F5 and the Logic Apps runtime starts locally - same as any Standard project. Before you build: preview realities I'd rather you go in clear-eyed. While the SDK is in public preview, keep these in mind: Service Provider connectors aren't supported yet - that connector type is coming in a future release. Dynamic schemas aren't supported - support is planned. Custom code supports callback methods only - inline lambdas aren't available in this version. Define and name actions before referencing them - name an action before using it as a dependency elsewhere. Managed identity authentication is in development - use connection keys for connectors in the meantime. Try it, and tell us what you think If you've ever wanted your workflows to live where the rest of your code lives - in C#, in source control, in your pull requests - this is for you. Install the Logic Apps extension for VS Code, create a Logic Apps codeful project, and build your first workflow in code. This is a preview, which means your feedback genuinely shapes where it goes - which capabilities come next, where the rough edges are. Bring issues, feature requests and feedback to our GitHub page. I read it. Let's make code-first workflows something you actually want to use. Related content Create Standard workflow projects with the SDK Logic Apps Standard SDK class libraryMicrosoft BizTalk Server Product Lifecycle Update
For more than 25 years, Microsoft BizTalk Server has supported mission-critical integration workloads for organizations around the world. From business process automation and B2B messaging to connectivity across industries such as financial services, healthcare, manufacturing, and government, BizTalk Server has played a foundational role in enterprise integration strategies. To help customers plan confidently for the future, Microsoft is sharing an update to the BizTalk Server product lifecycle and long-term support timelines. BizTalk Server 2020 will be the final version of BizTalk Server. Guidance to support long-term planning for mission-critical workloads This announcement does not change existing support commitments. Customers can continue to rely on BizTalk Server for many years ahead, with a clear and predictable runway to plan modernization at a pace that aligns with their business and regulatory needs. Lifecycle Phase End Date What’s Included Mainstream Support April 11, 2028 Security + non-security updates and Customer Service & Support (CSS) support Extended Support April 9, 2030 CSS support, Security updates, and paid support for fixes (*) End of Support April 10, 2030 No further updates or support (*) Paid Extended Support will be available for BizTalk Server 2020 between April 2028 and April 2030 for customers requiring hotfixes for non-security updates. CSS will continue providing their typical support. BizTalk Server 2016 is already out of mainstream support, and we recommend those customers evaluate a direct modernization path to Azure Logic Apps. Continued Commitment to Enterprise Integration Microsoft remains fully committed to supporting mission-critical integration, including hybrid connectivity, future-ready orchestration, and B2B/EDI modernization. Azure Logic Apps, part of Azure Integration Services — which includes API Management, Service Bus, and Event Grid — delivers the comprehensive integration platform for the next decade of enterprise connectivity. Host Integration Server: Continued Support for Mainframe Workloads Host Integration Server (HIS) has long provided essential connectivity for organizations with mainframe and midrange systems. To ensure continued support for those workloads, Host Integration Server 2028 will ship as a standalone product with its own lifecycle, decoupled from BizTalk Server. This provides customers with more flexibility and a longer planning horizon. Recognizing Mainframe modernization customers might be looking to integrate with their mainframes from Azure, Microsoft provides Logic Apps connectors for mainframe and midrange systems, and we are keen on adding more connectors in this space. Let us know about your HIS plans, and if you require specific features for Mainframe and midranges integration from Logic Apps at: https://aka.ms/lamainframe Azure Logic Apps: The Successor to BizTalk Server Azure Logic Apps, part of Azure Integration Services, is the modern integration platform that carries forward what customers value in BizTalk while unlocking new innovation, scale, and intelligence. With 1,400+ out-of-box connectors supporting enterprise, SaaS, legacy, and mainframe systems, organizations can reuse existing BizTalk maps, schemas, rules, and custom code to accelerate modernization while preserving prior investments including B2B/EDI and healthcare transactions. Logic Apps delivers elastic scalability, enterprise-grade security and compliance, and built-in cost efficiency without the overhead of managing infrastructure. Modern DevOps tooling, Visual Studio Code support, and infrastructure-as-code (ARM/Bicep) ensure consistent, governed deployments with end-to-end observability using Azure Monitor and OpenTelemetry. Modernizing Logic Apps also unlocks agentic business processes, enabling AI-driven routing, predictive insights, and context-aware automation without redesigning existing integrations. Logic Apps adapts to business and regulatory needs, running fully managed in Azure, hybrid via Arc-enabled Kubernetes, or evaluated for air-gapped environments. Throughout this lifecycle transition, customers can continue to rely on the BizTalk investments they have made while moving toward a platform ready for the next decade of integration and AI-driven business. Charting Your Modernization Path Microsoft remains fully committed to supporting customers through this transition. We recognize that BizTalk systems support highly customized and mission-critical business operations. Modernization requires time, planning, and precision. We hope to provide: Proven guidance and recommended design patterns A growing ecosystem of tooling supporting artifact reuse Unified Support engagements for deep migration assistance A strong partner ecosystem specializing in BizTalk modernization Potential incentive programs to help facilitate migration for eligible customers (details forthcoming) Customers can take a phased approach — starting with new workloads while incrementally modernizing existing BizTalk deployments. We’re Here to Help Migration resources are available today: Overview: https://aka.ms/btmig Best practices: https://aka.ms/BizTalkServerMigrationResources Video series: https://aka.ms/btmigvideo Feature request survey: https://aka.ms/logicappsneeds Reactor session: Modernizing BizTalk: Accelerate Migration with Logic Apps - YouTube Migration Agent (Complete refactoring from BizTalk to Logic Apps): Bringing all your Integration workloads to Logic Apps Standard | Microsoft Community Hub We encourage customers to engage their Microsoft accounts team early to assess readiness, identify modernization opportunities, and explore assistance programs. Your Modernization Journey Starts Now BizTalk Server has played a foundational role in enterprise integration success for more than two decades. As you plan ahead, Microsoft is here to partner with you every step of the way, ensuring operational continuity today while unlocking innovation tomorrow. To begin your transition, please contact your Microsoft account team or visit our migration hub. Thank you for your continued trust in Microsoft and BizTalk Server. We look forward to partnering closely with you as you plan the future of your integration platforms. Frequently Asked Questions Do I need to migrate now? No. BizTalk Server 2020 is fully supported through April 11, 2028, with paid Extended Support available through April 9, 2030, for non-security hotfixes. CSS will continue providing their typical support. You have a long and predictable runway to plan your transition. Will there be a new BizTalk Server version? No. BizTalk Server 2020 is the final version of the product. What happens after April 9, 2030? BizTalk Server will reach End of Support, and security updates or technical assistance will no longer be provided. Workloads will continue running but without Microsoft servicing. Is paid support available past 2028? Yes. Paid extended support will be available through April 2030 for BizTalk Server 2020 customers looking for non-security hotfixes. CSS will continue to provide the typical support. What is the end of sale date for BizTalk Server? We will announce an end of sale date for BizTalk Server on July 2026. What about BizTalk Server 2016 or earlier versions? Those versions are already out of mainstream support. We strongly encourage moving directly to Logic Apps rather than upgrading to BizTalk Server 2020. Will Host Integration Server continue? Yes. Host Integration Server (HIS) 2028 will be released as a standalone product with its own lifecycle and support commitments. Can I reuse BizTalk Server artifacts in Logic Apps? Yes. Most of BizTalk maps, schemas, rules, assemblies, and custom code can be reused with minimal effort using Microsoft and partner migration tooling. We welcome feature requests here: https://aka.ms/logicappsneeds Does modernization require moving fully to the cloud? No. Logic Apps supports hybrid deployments for scenarios requiring local processing or regulatory compliance, and fully disconnected environments are under evaluation. More information of the Hybrid deployment model here: https://aka.ms/lahybrid. Does modernization unlock AI capabilities? Yes. Logic Apps enables AI-driven automations through Agent Loop, improving routing, decisioning, and operational intelligence. Where do I get planning support? Your Microsoft account team can assist with assessment and planning. Migration resources are also linked in this announcement to help you get started. Microsoft Corporation🚀 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.Logic Apps Aviators Newsletter - July 25
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month July’s Ace Aviator: Şahin Özdemir What's your role and title? What are your responsibilities? I currently work for Rubicon Cloud Advisor, a Dutch company specialized in digital transformations, cloud adoption and AI implementation. At Rubicon I fulfil the role of Application and Integration architect, while also being a Professional Scrum Trainer at Scrum.org. Even though this sounds like two completely different roles, in practice both go closely hand in hand. I firmly believe that good architecture, a strong development process, and application of best practices are key pillars for delivering high-quality solutions to my clients. Therefore, both roles come in handy in my day-to-day job (combined with my strong background in software development).\ I work closely with companies and their teams in making their journey to Azure - especially Azure Integration Services - successful. Most of the time this journey starts with a business need or challenge, and I work with my clients to get a deeper understanding of their needs. This results in further analysis, capturing requirements, defining architecture, solution design, setting the stage for development (ALM) and being involved in quality assurance. At the same time, I think it’s important to stay relevant from a technical perspective. That’s why I also like being involved with implementing the solution. This way, I hear the technical struggles teams face and I can help them to find the right solution. Can you give us some insights into your day-to-day activities and what a typical day in your role looks like? Not a single day is the same, although there are some recurring activities. Specific parts of my day (or sprint) are dedicated to Scrum-related activities - whether it's participating in the daily scrum, having sprint reviews with stakeholders, planning the next sprint, or refining the backlog with the team or just aligning with the PO or stakeholders. I’m frequently involved in cross-organizational meetings focused on projects at scale. I contribute from the perspective of architecture, technical expertise, and integration strategy. In my role as a solution architect, I'm engaged in designing and implementing a critical integration platform for my client. This platform connects and exchanges data between many internal departments and external vendors - an effort that requires frequent alignment and collaboration. I’m always looking for opportunities to expand our Hybrid Integration Platform itself. Exploring how Azure resources may add value to our platform and working closely with the team to realize such improvements to the platform’s capabilities is something I enjoy. Outside of the regular meetings, I often focus on designing new integrations. Having working sessions with stakeholders to understand what they want. Based on these discussions, I assess the technical and architectural aspects of the solution. Every integration that lands on the platform is measured against both architectural and development principles and guidelines. I contribute to reviewing the solutions that have been developed. Ensuring that each integration is high-quality, consistent, easy to understand, and maintainable. I support the platform team with, and whenever possible. And if time permits, I develop parts of the solution myself – I see this as a great way to stay relevant from a technological perspective. All the spare time I have, I spend on writing technical articles that may help others. What motivates and inspires you to be an active member of the Aviators/Microsoft community? Because I enjoy helping others. Every day I work with a team of smart professionals on integration solutions and custom code within the Azure platform. Along the way, we regularly encounter challenges, limitations, or issues. In those moments, it's incredibly helpful to find solutions online or to have a community that can think along with you. Over the past few years, there have been many occasions where I just couldn’t find a solution online for a technical problem with Logic Apps. In these cases, we either came up with a creative solution ourselves or received support from Microsoft. When the integration community faces a similar challenge, it’s pretty much wasteful to tackle the same hurdles again. By documenting an approach or solution, others may be saving their invaluable time looking for a solution. Looking back, what advice do you wish you had been given earlier that you'd now share with those looking to get into STEM/technology? It is ok that you don’t know everything. Just start doing, experiment, stay curious, challenge yourself, don’t be afraid to ask questions, fail, learn and keep going! What has helped you grow professionally? I have spent a fair amount of my career at a big consulting firm. I started off as a software engineer all the way up to senior manager and architect. A long journey like that gives great and well-dosed opportunities and learning experiences to focus on your technical (in-depth) skillset first, continued by working on you soft skills like consulting, guiding and leading teams, solutioning and architecture. If I had not followed this path at that company, I would not be the person I am now professionally. Be ok with the fact that growth doesn’t happen overnight -no shortcuts, no magic pills. It's like a good red wine that needs time to mature. So do many challenging projects, become all-round and then choose a specialization, ask for constructive feedback, fail many times and take your time to reflect and learn. And don’t forget to have a strong work ethic and ongoing curiosity to learn new things. In the end I found that - from a technological perspective-, quality attributes (the “-illities”), enterprise application integration and scrum made my heart skip a beat. So my advice is to always pursue what brings you joy! If you had a magic wand that could create a feature in Logic Apps, what would it be and why? Overall, I must say that I’m happy with the current state of Logic Apps. Nevertheless, if I had a magic wand: I would like to see that the service plans for Logic App standard would be in line with Function Apps. The plans for Function apps have way better tiers from both memory, cores and pricing perspective. And being able to scale out and in based on specific metrics is more flexible than Logic App Standard currently offers. Having more CPU/memory available in the plans would also improve the overall performance of Logic Apps in general, even though performance optimizations of many actions would also be more than welcome. What I currently really miss in the HTTP connector (and possibly others) is the ability to have better control over the request timeouts. Even though the setting is there, it is capped to 4 minutes max. In practice, we need to deliver data to external APIs that work synchronously and take more time to complete. Giving better control on these timeouts would make the usability of workflows even better! Even though some nice additions to the initialization of variables have been made recently, I would like to see the ability to initialize variables at any point in the workflow. E.g. the foreach loop can be executed in parallel, and therefore the current global variables are not thread-safe, which leads to unexpected behavior. News from our product group Logic Apps Live June 2025 Missed Logic Apps Live in June? You can watch it here. We focused on the Logic Apps big announcements from Integrate 2025. There are a lot of great things to check! Feedback Opportunity: SRE Agent + Logic Apps Discover the new Applications feature in Azure API Management, enabling OAuth-based access to APIs and products. Streamline secure API access with built-in OAuth 2.0 application-based authorization. Configure SQL Storage for Standard Logic Apps Azure Logic Apps traditionally rely on Azure Storage to manage workflow states and runtime data. However, with the introduction of SQL as a storage provider (currently in preview), developers now have a compelling alternative that offers greater control, flexibility, and integration with existing SQL infrastructure. This post explores the benefits, configuration steps, and considerations for using SQL storage with Standard Logic Apps. Announcing General Availability: Azure Logic Apps Standard Automated Test Framework We’re excited to announce the General Availability (GA) of the Azure Logic Apps Standard Automated Test Framework—a major step forward in enabling developers to build, test, and maintain enterprise-grade workflows with confidence and agility. Announcing General Availability: Azure Logic Apps Standard Custom Code with .NET 8 We’re excited to announce the General Availability (GA) of Custom Code support in Azure Logic Apps Standard with .NET 8. This release marks a significant step forward in enabling developers to build more powerful, flexible, and maintainable integration workflows using familiar .NET tools and practices. With this capability, developers can now embed custom .NET 8 code directly within their Logic Apps Standard workflows. This unlocks advanced logic scenarios, promotes code reuse, and allows seamless integration with existing .NET libraries and services—making it easier than ever to build enterprise-grade solutions on Azure. Business Process Tracking Reaches General Availability Business Process Tracking provides key insights to business stakeholders from your Logic Apps (Standard) implementation in an efficient and timely manner. Today, we are pleased to announce the General Availability of this capability, allowing customers to leverage in their production workloads. Announcement: General Availability of Logic Apps Hybrid Deployment Model We’re excited to announce the Public Preview of two major integrations that bring the power of Azure Logic Apps to AI Agents in Foundry – Logic Apps as Tools and AI Agent Service Connector. Learn more on our announcement post! Announcing Public Preview: Organizational Templates in Azure Logic Apps We’re excited to announce the Public Preview of Organizational Templates in Azure Logic Apps— empowering teams to author, share, and reuse automation patterns across their organization. With this release, we’re also rolling out a brand-new UI experience to easily create templates directly from your workflows—no manual packaging required! OpenTelemetry in Azure Logic Apps (Standard and Hybrid) OpenTelemetry provides a unified, vendor-agnostic framework for collecting telemetry data—logs, metrics, and traces—across different services and infrastructure layers. It simplifies monitoring and makes it easier to integrate with a variety of observability backends such as Azure Monitor, Grafana Tempo, Jaeger, and others. For Logic Apps—especially when deployed in hybrid or on-premises scenarios—OpenTelemetry is a powerful addition that elevates diagnostic capabilities beyond the default Application Insights telemetry. Logic App Standard - When High Memory / CPU usage strikes and what to do Monitoring your applications is essential, as it ensures that you know what's happening and you are not caught by surprise when something happens. One possible event is the performance of your application starting to decrease and processing becomes slower than usual. This may happen due to various reasons, and in this blog post, we will be discussing the High Memory and CPU usage and why it affects your Logic App. We will also observe some possibilities that we've seen that have been deemed as the root cause for some customers. Introducing Agent in a Day Agent in a Day represents a fantastic opportunity for customers to participate in hackathon-style contests where attendees learn how to build agents and then can apply them to their unique business use cases. For Partners, Agent in a Day represents a great way to engage your customers by building agents with them and uncovering new use cases. Introducing Confluent Kafka Connector (Public Preview) We are pleased to announce the introduction of the Confluent Kafka Connector in Logic Apps (Standard) which allows you to both send and receive messages between Logic Apps and Confluent Kafka. Confluent Kafka is a distributed streaming platform for building real-time data pipelines and streaming applications. It is used across many industries including financial services, Omnichannel retail, autonomous cars, fraud detection services, microservices and IoT deployments. Our current connector offering supports both triggers (receive) and sending (publish) within Logic Apps. News from our community Logic App Standard: Throw exceptions like a pro! Post by Şahin Özdemir Learn how to throw exceptions in Logic App Standard using a simple Compose action—no code needed, just clever workflow design. Azure Logic Apps: are you handling large blobs? Keep memory usage under control. Post by Stefano Demiliani Struggling with large blob files in Logic Apps? Learn how to keep memory usage under control and avoid out-of-memory errors with smart workflow design and a few performance-boosting tricks De SOAPing Services SOAP to REST using Azure API Management Video by Stephen W Thomas Struggling with legacy SOAP integrations from BizTalk to Azure? Check out this video on simplifying SOAP-to-REST conversions using Azure API Management and learn how easily you can manage SOAP envelopes and streamline your Logic Apps integrations! Integrating Entra ID and AI Agent workflows in Azure Logic Apps Post by Brian Veldman Discover how to build AI-powered workflows in Azure Logic Apps that interact with Entra ID, automate tasks, and adapt dynamically using agentic tools and OpenAI models. Advanced KQL Queries for Logic Apps in Application Insights: A Practical Guide Post by Dieter Gobeyn Boost Logic App performance with advanced KQL queries in Application Insights—spot bottlenecks, analyze slow actions, and optimize workflows without upgrading your hosting plan. How to Build an AI Agent with Azure Logic Apps Post by Cameron McKay Learn how to build your first AI Agent in Azure Logic Apps using Agent Loop—connect to OpenAI, design smart prompts, and automate tasks like weather reporting with low-code workflows. You Can Now Initialize All Your Variables In One Single Action Post by Luis Rigueira You can now initialize multiple variables in Logic Apps with a single action—making your workflows cleaner, faster, and easier to manage. It is a Friday Fact, brought to you by Luis Rigueira! Integration Insights Podcast: The Future of Integration Video by Sagar Sharma and Jochen Toelen In this two-part episode of the Integration Insights podcast, Sagar, Joechen and Kent dive into how integration is evolving in a cloud-first world. From BizTalk migrations to hybrid deployments with Azure Arc, they share practical insights and best practices to future-proof your integration strategy. A must-listen! You can watch part 2 here. Event Grid vs Service Bus vs Event Hubs vs Storage Queues: Choosing the Right Messaging Backbone in Azure Post by Prashant Singh Confused by Azure’s messaging options? This guide breaks down Event Grid, Service Bus, Event Hubs, and Storage Queues—helping you choose the right tool for real-time events, telemetry, enterprise workflows, or lightweight tasks. IntelliSense in Logic Apps Just Got Smarter – Matching Brackets in the Expression Editor! Post by Sandro Pereira Logic Apps just got a lot friendlier—bracket matching in the expression editor now highlights pairs as you type, making it easier to write and debug complex expressions.A Friday Fact from Sandro Pereira. How to Build Resilient Integrations for Mission-Critical Systems Post by Lilan Sameera Learn how to build resilient integrations for mission-critical systems using Logic Apps, Service Bus, and Event Hub—ensuring reliable data delivery, smart retries, and clean outputs even under pressure.The Rising Significance of APIs - Azure API Management & API Center
As we venture deeper into the digital era, APIs (Application Programming Interfaces) have become the cornerstone of modern software development and digital communication. APIs continue to be pivotal, acting as the conduits through which different systems, applications, and devices interact and exchange data. This growing reliance on APIs is reflected in the investment trends, with a significant 92% of global respondents indicating that investments in APIs will either remain steady or increase over the next year (2023 State of the API Report, Postman, 2023). Recognizing the critical role that APIs play in modern software architecture, Microsoft has been consistently investing in and expanding its API suite to fulfill diverse needs. Managing APIs is not a one-size-fits-all solution with different API ecosystems requiring different API management approaches and tools. Azure API Center, a new API Azure service, was recently announced General Availability (GA). Azure API Center is engineered to function independently, yet it seamlessly integrates with Azure API Management, providing customers options to manage various aspects of their API ecosystem. In the following sections, we will dive into the specifics of Azure API Management and Azure API Center, highlighting their differences, use cases, and guiding you on when to use each product to best manage and leverage your API ecosystem. Azure API Management: Your Gateway to Digital Transformation Azure API Management (APIM) is a managed cloud service designed to streamline and secure the use of APIs. API Management acts as a secure front door to facilitate, manage, and analyze the interactions between an organization’s APIs and their users with some of their core functionalities listed below: API gateway - operational management: API Management acts as a gateway, managing API exposure, security, and analytics during runtime. Traffic routing: Acts as a facade to backend services by accepting API calls and routing them to appropriate backends. API access: Verifies API keys and other credentials such as JWT tokens and certificates presented with requests to access APIs published through an API Management instance. Operational stability: API Management allows you to enforce usage quotas and rate limits to manage the flow of requests to your APIs effectively to prevent API overuse. It also validates requests and responses in compliance with the specification - e.g., JSON and XML validation, validation of headers and query params. Request transformation: The rich policy engine of API Management allows you to modify incoming and outgoing requests to your needs with more than 60 built-in policies and the option to build your own custom policies. API logging: API Management provides the capability to emit logs, metrics, and traces, which are essential for monitoring, reporting, and troubleshooting your APIs. Self-hosted gateway: API Management also offers self-hosted gateway capabilities, a containerized version of the default managed gateway to place your gateways in the same environments where you host your APIs. Developer Portal: API Management features a developer portal, which can be generated automatically and is a fully customizable website with the documentation of your APIs. It facilitates API discovery, testing, and consumption by internal and external developers. Azure API Center: Your Inventory for API Lifecycle Management Azure API Center is the newest addition to the Azure API suite, focusing on the design-time aspects of API governance and centralizing your API inventory for tracking reasons. It acts as a repository and governance tool for all APIs within an organization, regardless of where they are in their lifecycle or where they are deployed. API inventory management: API Center allows you to register all your organization’s APIs in a centralized inventory, regardless of their type, lifecycle stage, or deployment location, for better tracking and accessibility. Tackling API sprawl: APIs' runtime might be managed in multiple different API Management services, multiple different API gateways from different vendors, or are unmanaged at all. Azure API Center allows you to develop and maintain a structured API inventory. Holistic API view: While API Management excels in runtime API mediation, its inventory management capabilities are limited to the types of APIs that are supported at runtime and to the versions that are actively managed in runtime. Azure API Center supports any kind of API types, such as AsyncAPIs, and you can easily track APIs across different deployment environments. Real-world API representation: You can add detailed information about each API, including versions, definitions, custom metadata, and associate them with deployment environments (e.g. Dev, Test, Production). API governance: Azure API Center provides tools to organize and filter APIs using metadata, set up linting and analysis to check API design consistency for better conformance on API style guidelines. Additionally, shift-left API compliance to API teams to ensure that developers can more productively and efficiently create compliant APIs. API discovery and reuse: It enables internal developers and API program managers to discover APIs through the Azure portal, an API Center portal, and developer tools, including a Visual Studio Code extension. Navigating Your API Ecosystem - Example Scenarios for Azure API Center and API Management While both services are integral to the API ecosystem, they serve distinct purposes: Azure API Management is geared towards runtime API governance and observability, focusing on the operational aspects of API management, such as securing, publishing, and analyzing APIs in use. Azure API Center, in contrast, is tailored for design-time API governance, helping organizations to maintain a structured inventory of all APIs for better discovery and governance. API Management and API Center are complementary services that, when used together, provide a comprehensive API management solution from design to deployment. API Mangement excels in the operational phase, while API Center, as your organizational API inventory, shines in the design and governance stages, ensuring that APIs are not only functional but also adhere to organizational standards and best practices. Note: The following scenarios are not mutually exclusive. They have been separated for better display and clarity. Scenario 1: Azure API Center serves as an API design governance tool for analyzing API definitions based on linting rules to check on API design consistency and quality: Scenario 2: Azure API Center serves as a centralized inventory solution for managing APIs across different API lifecycle stages (e.g. development, testing, production): Scenario 3: Azure API Center serves as a centralized inventory solution for managing APIs across different regional or organizational deployments (e.g. Asia, Europe, America): Scenario 4: Azure API Center serves as a centralized inventory solution for managing APIs across different cloud platforms (e.g. Azure, AWS, and Google Cloud): Azure API Center and API Management Workspaces Note: Azure API Management workspaces currently only apply to the Premium API Management tier (see Workspaces in Azure API Management for further details). API management workspaces are a feature within Azure API Management that allows decentralized API development teams to manage and productize their own APIs. Workspaces enable aggregation of multiple teams with proper isolation in a single APIM service. For Azure API Center, all previously mentioned scenarios still apply, regardless of whether APIM services use workspaces. Azure API Center will continue to improve the management of APIs across different API Managment services, as organizations... have APIM services across environments, for example, dev, test, and prod. have more than one production APIM service in their company. have APIm platforms from multiple vendors. Conclusion In conclusion, the launch of Azure API Center and the continued evolution of Azure API Management underscore Microsoft’s commitment to empowering organizations in their API first journey. By leveraging Azure API Management for runtime efficiency and Azure API Center for inventory and governance, organizations can navigate their API ecosystems with confidence, knowing they have the tools to foster innovation, efficiency, and growth. Share Your Thoughts! Your insights are invaluable to us. We're eager to hear what you think about Azure API Center and API Management, and to understand your needs. Is there something specific that would make you and your organization even more successful? Your feedback is the key to our continuous improvement. If you prefer a more personal touch, feel free to reach out via LinkedIn to Julia Kasper, Pierce Boggan and Mike Budzynski. Thank you for being a part of our journey!Logic Apps Newsletter - May 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month May 2026's Ace Aviator: Yahya Ajwad What's your role and title? What are your responsibilities? I work as Chief Architect and AI Lead at Epical. My role is centered around technical leadership, architecture, and advisory mostly within cloud adoption and transformation programs. I help customers design and implement integration platforms. I also support customers in navigating the AI landscape, with a focus on how integration platforms impact AI readiness and how AI can be used to create value in the platforms we build. Internally at Epical, I lead our Microsoft and Azure cloud integration offering, as well as our CoreAI team and AI initiatives. Can you give us some insights into your day-to-day activities? One moment it is about how we can utilize AI to deliver things cheaper and faster without compromising security, governance and quality. Next, a customer contacts us with an undocumented BizTalk environment asking us what to do next (that's where the fun begins). Usually followed up by the question about how much does their future integration platform in Azure will cost down to the last cent (good luck answering that 😜 hint: the right answer is always: "less than BizTalk"). And hey, public cloud might not be good enough for their security, so thank God for private connectivity. I also spend time helping customers identify the best cloud integration strategies and patterns and for their business needs, choosing the right platforms and components for specific use cases, and ensuring that the platforms we design are as secure, scalable, maintainable, and cost-efficient as possible. Increasingly, this also includes sprinkling AI so bosses are happy (joking I'm a true AI believer myself). Internally, I support Epical with technical business development and help ensure that we stay relevant. What motivates and inspires you to be an active member of the Aviators/Microsoft community? I honestly believe that IT in general would never have been the same without communities and the willingness to share knowledge and support one another. The Logic Apps and Azure Integration community is especially unique because it is both practical and open. People share real experiences which makes it incredibly valuable when trying to solve real-world challenges. What motivates me is the opportunity to learn by sharing, receive feedback, and be part of a community where everyone contributes to each other’s growth. Between us, I'm here for the stickers ;) Looking back, what advice do you wish you had been given earlier? Be kind, stay curious and be helpful. Share what you know, even if it feels small or irrelevant. Those small insights often help others more than you think and that will definitely help you grow. Also, focus on learning the fundamentals. Tools and platforms change quickly, and what is popular today might not matter in a few weeks. Strong basics will always stay relevant. Keep learning and try new things all the time. What has helped you grow professionally? Being around kind, skilled, and generous people both in the community and at work who are willing to teach, challenge my thinking, and share their knowledge. Also, finding mentors who are open to mentor me, listen to all my questions even the silly ones, and who are willing to guide me and correct me when I’m hallucinating. If you had a magic wand that could create a feature in Logic Apps, what would it be? I don’t need to wish for one, you guys (Shout-out to Harold, Dyvia and the team) have already created it: Logic Apps Migration Assistant Agents. That stuff is definitely magic. News from our product group Network Connectivity Check APIs for Logic App Standard This post introduces built-in network troubleshooting APIs for Logic App Standard when integrated with a virtual network. Three endpoints—connectivityCheck, dnsCheck, and tcpPingCheck—let you validate end‑to‑end connectivity to services such as Azure SQL, Key Vault, Storage, Service Bus, and Event Hubs, perform DNS resolution, and test TCP reachability from the actual worker hosting your workflows. It covers supported provider types, credential options including Managed Identity and app settings, example payloads, and known limitations (e.g., SMB port 445 cannot be tested). Step-by-step guidance shows how to call the APIs via Azure API Playground or CLI to quickly isolate network issues. Service Bus SBMP Retirement: What BizTalk Server 2020 Customers Need to Know Azure Service Bus will retire the Service Bus Messaging Protocol (SBMP) on September 30, 2026, impacting BizTalk Server 2020 customers using the SB‑Messaging adapter. Microsoft has released a hotfix that adds Advanced Message Queuing Protocol (AMQP) support to the adapter for CU6 and CU7. With the hotfix, AMQP becomes the default transport while SBMP remains an opt‑in fallback; an updated hotfix based on the new Service Bus SDK is expected in June. Guidance includes migrating configurations to AMQP, installing and validating the hotfix in non‑production, and testing large message/file scenarios. The hotfix can be requested via support (KB5091375). Migrate Data Ingestion from Data Collector to Log Ingestion With the HTTP Data Collector API for Log Analytics deprecated and heading out of support in September 2026, this guide shows Logic Apps users how to move to the Log Ingestion API. It explains impacts—such as 403 errors for new Data Collector connections and missing data in newly created custom log tables—and provides a migration path using the HTTP action. Steps include creating a Data Collection Endpoint (DCE) and Data Collection Rule (DCR), deriving the full ingestion URL, mapping sample data to define schema, assigning the Monitoring Metrics Publisher role to the Logic App’s managed identity, and verifying success (HTTP 204). Introducing AI Skill Assessment in Azure API Center Azure API Center now includes automated AI skill assessment, providing governance and quality scoring for skills at scale using an “LLM‑as‑a‑judge” approach. The system evaluates outputs against defined criteria and ships with four default dimensions—Documentation Clarity, Help Completeness, Discoverability, and Safe Usage—each scored 1–5 with configurable thresholds. Developers get detailed reports showing pass/fail, per‑dimension scores, structural checks, and schema validation, helping them decide which skills are production‑ready. Platform administrators can extend or customize criteria to match organizational standards. The feature centralizes oversight and reduces manual review effort, improving confidence when adopting AI skills across integration solutions. Introducing the plugin marketplace for Azure API Center Azure API Center adds a plugin marketplace endpoint (public preview) that exposes a version‑controlled catalog of organizational AI plugins—such as MCP servers and skills—directly from your API Center data plane. Developers can discover and install plugins from familiar tools like Claude Code and GitHub Copilot CLI using simple marketplace commands. The endpoint inherits the API Center portal’s authentication model, ensuring governance and security while platform teams control publication. The article explains the problem it addresses, the marketplace.git URL format, quick start commands, and documentation to enable the feature—streamlining how teams curate, manage, and consume AI plugins in enterprise environments. News from our community Control the Initial State of Logic Apps Standard Workflows Post by Sandro Pereira This tip explains how to prevent Logic Apps Standard workflows from auto-starting after deployment, a risky default in production. Unlike Consumption, Standard doesn’t expose a state property in ARM. Instead, each workflow’s initial state is controlled via App Service application settings using the pattern “Workflows.<WorkflowName>.FlowState=Disabled.” The post shows how to define these keys in local.settings.json (or pipelines/Bicep), deploy with workflows disabled, and enable them when ready. It also notes acceptable values (Disabled/disabled) and clarifies that omitting the keys leaves workflows enabled by default—reducing unwanted executions and noisy alerts. 10 Azure Function App Limitations for Enterprise Integration Post by Tarun Garg The post outlines ten reasons Azure Function Apps may be a poor fit for enterprise integration workloads. Issues include cold-start latency, limited orchestration and state management, operational complexity at scale, and the need to hand-roll observability. It also highlights security and network isolation challenges, cost variability under heavy throughput, strong dependence on custom code, risks around versioning and breaking changes, and insufficient governance controls for integration use cases. The takeaway: Function Apps excel at granular compute, but integration programs often benefit from managed orchestration layers and patterns better aligned to enterprise requirements. Logic Apps Standard: how accidentally blocking access from Edge results in CORS errors Post by Şahin Özdemir Şahin Özdemir explains a troubleshooting case where Logic Apps Standard action inputs/outputs stopped loading in the Azure portal, appearing like a CORS issue. The root cause was a blocked “Local Network Access” permission in Microsoft Edge, not misconfigured CORS. The article advises checking Edge’s site permissions and re-enabling local network access before diving into CORS diagnostics. By validating browser settings first, engineers can avoid unnecessary changes to integration apps and resolve portal rendering failures quickly—saving time and reducing confusion when workflow views suddenly fail to load. Logic apps – Handling AND OR conditions Post by Anitha Eswaran Anitha Eswaran explains how to correctly implement combined AND/OR logic in Azure Logic Apps when the designer view becomes confusing. Using a real example—validating item numbers—she shows how to check for empty values or specific suffixes (W/WN) and when to terminate processing. The article demonstrates building expressions to explicitly control evaluation order and outcomes, avoiding unintended behavior from default AND logic. Practical screenshots and expression snippets help readers structure conditions, handle arrays from trigger data, and create maintainable workflows that reflect real business rules. Why Enterprises Are Migrating from Logic Apps (Consumption) to Logic Apps (Standard): Practical Insights from the Field Post by Kunal Saha Kunal Saha outlines why organizations reach an inflection point where Logic Apps Standard becomes a better fit than Consumption. Drawing from field experience, he highlights drivers like consolidated app-level management, richer local development workflows, environment isolation, and cost predictability for sustained workloads. The piece discusses when per-execution billing ceases to be efficient, how Standard’s hosting model supports enterprise governance, and migration considerations around triggers, connectors, and stateful patterns. The article encourages teams to evaluate workload characteristics and operational needs to determine the right time to modernize to Standard. Event Debouncing with Logic Apps and Azure Table Storage Post by Daniel Jonathan This article presents an event debouncing pattern for webhook-heavy systems using three Logic Apps and a single Azure Table Storage table. Incoming events are buffered by upserting rows keyed by entity ID, ensuring only the latest state is retained. A timer-driven workflow processes pending rows after a cooldown window, fetches fresh state from the source, and calls downstream APIs, deleting entries on success or resetting on failure. Benefits include implicit deduplication, reduced downstream load, and operational transparency in Storage Explorer. The pattern suits moderate scale without Service Bus, with caveats for strict ordering or very high throughput scenarios. XML to JSON in Logic Apps: Fixing the “Object vs Array” Trap Post by Prashant Singh Prashant Singh explains a common pitfall when converting XML to JSON in Logic Apps: json(xml(...)) yields an array when multiple nodes exist, but a single object when only one node is present—breaking For each loops. He outlines three remedies: debatch directly with xpath() to always return a node set; wrap the target node with array() to normalize object/array differences; or use coalesce() with array() to safely handle missing nodes. With clear examples and expressions, the post helps engineers avoid brittle assumptions and build resilient workflows that handle single, multiple, or absent records cleanly. DevUP Talks 02 - 2026 Q1 Reflections with Ahmed Bayoumy, Sebastian Meyer and Andrew Wilson Video by Mattias Lögdberg This 12‑minute panel discussion surveys how AI and automation are changing day‑to‑day engineering work. Mattias Lögdberg hosts Ahmed Bayoumy, Sebastian Meyer, and Andrew Wilson to share early field perspectives: the shift from experimentation to production, emerging testing responsibilities around AI‑assisted code, and how integration teams are adapting operating models and skills. The conversation favors practical observations over hype, offering a snapshot of what practitioners are seeing at the start of 2026. It’s a compact watch for leaders tracking real impacts rather than theoretical roadmaps. How low can you code? From ‘drag-and-drop’ dreams to try–catch reality Post by Sonny Gillissen Sonny Gillissen argues that early low‑code promised simplicity but often obscured complexity with visual designers and limited tooling. He suggests AI can shift low‑code from diagramming boxes to describing intent—letting teams express business behavior in natural terms, with systems generating implementations. The piece calls for focusing on domain clarity, robust data/APIs, and guardrails over chasing more drag‑and‑drop. For integration engineers, it frames a path where Logic Apps and related platforms become orchestration shells around AI‑assisted specifications, improving maintainability without hiding the hard parts. Legacy Integration to Azure: 40% Cost Savings and Faster Delivery Post by Adaptiv (post by Simon Clendon) This piece outlines lessons from migrating legacy integration platforms to Microsoft Azure. It details the discovery work needed to untangle historical integrations, the diplomacy required with stakeholders, and the engineering patterns that de-risk cutovers. Highlights include modernizing HR workflows, establishing clear migration decision trees, and treating AI as a force multiplier rather than a silver bullet. The article emphasizes measurable outcomes—around 40% cost savings and faster delivery—while cautioning against underestimating analysis, testing, and organizational change, and recommending experienced partners to accelerate the journey. Using the Right Tool Is Not Over‑Engineering Post by Marcelo Gomes Marcelo Gomes argues that many integration failures stem from tool misalignment rather than flawed logic. Using a market‑stall analogy, he outlines when to rely on API Management for exposure and control, where Logic Apps should orchestrate rather than absorb all work, and why Azure Storage underpins durable, production‑ready designs. The piece encourages architects to map responsibilities explicitly—governance at the edge, orchestration in workflows, compute where it belongs—so systems scale cleanly without masking complexity under a single service. Choosing fit‑for‑purpose components, he suggests, is discipline—not over‑engineering. Using Event Grid to detect deleted files and trigger Logic App Post by Sandro Pereira (author: Luis Rigueira) This walkthrough shows how to capture Azure Storage blob deletion events with Event Grid and invoke a Logic App for downstream actions like audit, recovery, or notifications. It explains why native Blob triggers don’t fire on delete, then sets up a System Topic on the storage account, configures a Logic App with the “When a resource event occurs” trigger for Microsoft.Storage.BlobDeleted, and parses the event payload for container, file name, content‑type, and timestamp. The post provides expressions and screenshots to build the flow end‑to‑end, enabling reliable reactions to file deletions without custom functions.
