enterprise integration

107 Topics

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.
WSilveira
May 04, 2026 Place Azure Integration Services Blog
358Views
1like
0Comments
Introducing AI Skill Assessment in Azure API Center
As AI skills become central to enterprise automation and intelligent workflows, ensuring their quality, safety, and discoverability at scale is a growing challenge. Today, we're excited to announce skills assessment in Azure API Center — a built-in, automated quality scoring system powered by the LLM-as-a-judge technique. This capability enables organizations to continuously evaluate AI skills against defined quality standards, giving platform administrators governance controls and giving developers the confidence to adopt skills that are ready for production. What is LLM-as-a-Judge? AI skill assessments using the LLM-as-a-judge technique leverage a large language model to evaluate AI outputs against defined quality criteria — scoring responses across dimensions like accuracy, coherence, and helpfulness. The judge model can be prompted with rubrics, reference answers, or pairwise comparisons, enabling scalable feedback at a fraction of the cost of human annotation. By embedding this technique directly into Azure API Center, teams can now benefit from continuous, automated quality evaluation — without manual review overhead. Default Assessment Criteria: Four Dimensions of Quality API Center comes with default skill assessment criteria out of the box, evaluating skills across four key dimensions — each scored on a 1–5 scale with a default threshold of 3: Documentation Clarity — Evaluates how clearly a skill's purpose and behavior are communicated. Help Completeness — Assesses whether the output serves as a comprehensive standalone reference. Discoverability — Measures how easily functionality can be navigated and found. Safe Usage — Evaluates whether sufficient guidance is provided for safe operation. Enterprise platform administrators can further extend these defaults by defining custom assessment criteria tailored to their organization's specific standards, compliance requirements, and governance policies. Figure 1: Platform administrators configure skill assessment criteria and thresholds in the Azure API Center portal Detailed Quality Reports for Developers Once skills assessment is enabled, developers can view a detailed AI Quality Score report for each skill directly within the API Center portal. This report provides an at-a-glance Pass or Fail status along with per-dimension scores and actionable feedback. Alongside the LLM-based scores, the report includes: Structural Checks — Verifying foundational elements like valid frontmatter, skill name, and body content. Schema Validation — Flags missing sections such as examples or error handling Figure 2: Developers see per-dimension quality scores, structural checks, and schema validation results for each skill in the API Center portal. What This Means for Developers As a developer, this means you can quickly understand the quality and reliability of a skill before adopting it — making informed decisions about which skills are ready to use and which may need further refinement. No more guessing whether a skill is production ready. With skills assessment, every skill in your catalog comes with a transparent quality score, clear actionable feedback, and the confidence that comes from automated, consistent evaluation. Get Started Skills assessment is available now in Azure API Center. Platform administrators can enable assessment, configure criteria, and start evaluating skills from the API Center portal today. To learn more, visit the skills assessment in Azure API Center documentation or try it out in the Azure Portal.
Sreekanth_Thirthala
Apr 27, 2026 Place Azure Integration Services Blog
529Views
0likes
0Comments
Introducing native Service Bus message publishing from Azure API Management (Preview)
We’re excited to announce a preview capability in Azure API Management (APIM) — you can now send messages directly to Azure Service Bus from your APIs using a built-in policy. This enhancement, currently in public preview, simplifies how you connect your API layer with event-driven and asynchronous systems, helping you build more scalable, resilient, and loosely coupled architectures across your enterprise. Why this matters? Modern applications increasingly rely on asynchronous communication and event-driven designs. With this new integration: Any API hosted in API Management can publish to Service Bus — no SDKs, custom code, or middleware required. Partners, clients, and IoT devices can send data through standard HTTP calls, even if they don’t support AMQP natively. You stay in full control with authentication, throttling, and logging managed centrally in API Management. Your systems scale more smoothly by decoupling front-end requests from backend processing. How it works The new send-service-bus-message policy allows API Management to forward payloads from API calls directly into Service Bus queues or topics. High-level flow A client sends a standard HTTP request to your API endpoint in API Management. The policy executes and sends the payload as a message to Service Bus. Downstream consumers such as Logic Apps, Azure Functions, or microservices process those messages asynchronously. All configurations happen in API Management — no code changes or new infrastructure are required. Getting started You can try it out in minutes: Set up a Service Bus namespace and create a queue or topic. Enable a managed identity (system-assigned or user-assigned) on your API Management instance. Grant the identity the “Service Bus data sender” role in Azure RBAC, scoped to your queue/ topic. Add the policy to your API operation: <send-service-bus-message queue-name="orders"> <payload>@(context.Request.Body.As<string>())</payload> </send-service-bus-message> Once saved, each API call publishes its payload to the Service Bus queue or topic. 📖 Learn more. Common use cases This capability makes it easy to integrate your APIs into event-driven workflows: Order processing – Queue incoming orders for fulfillment or billing. Event notifications – Trigger internal workflows across multiple applications. Telemetry ingestion – Forward IoT or mobile app data to Service Bus for analytics. Partner integrations – Offer REST-based endpoints for external systems while maintaining policy-based control. Each of these scenarios benefits from simplified integration, centralized governance, and improved reliability. Secure and governed by design The integration uses managed identities for secure communication between API Management and Service Bus — no secrets required. You can further apply enterprise-grade controls: Enforce rate limits, quotas, and authorization through APIM policies. Gain API-level logging and tracing for each message sent. Use Service Bus metrics to monitor downstream processing. Together, these tools help you maintain a consistent security posture across your APIs and messaging layer. Build modern, event-driven architectures With this feature, API Management can serve as a bridge to your event-driven backbone. Start small by queuing a single API’s workload, or extend to enterprise-wide event distribution using topics and subscriptions. You’ll reduce architectural complexity while enabling more flexible, scalable, and decoupled application patterns. Learn more: Get the full walkthrough and examples in the documentation 👉 here
anishta
Apr 21, 2026 Place Azure Integration Services Blog
4.5KViews
4likes
7Comments
Introducing the plugin marketplace for Azure API Center
Today, we're excited to announce the public preview of the plugin marketplace endpoint for Azure API Center. This new capability makes it easier than ever for developers to discover and install AI plugins — including MCP servers and skills — directly from the tools they already use, like Claude Code and GitHub Copilot CLI. The problem we're solving As AI plugins and MCP servers become core parts of the developer workflow, teams have struggled with a fundamental challenge: there's no central, governed place to find and manage them. Developers hunt through documentation, Teams messages, and wikis — and platform teams have no reliable way to ensure the right plugins are being used. Azure API Center has built the plugin marketplace to fix this issue What's new When you register plugins in your API Center inventory and enable the API Center portal, we now automatically provision a marketplace.git endpoint at your data plane URL: Your marketplace endpoint is https://<service>.data.<region>.azure-apicenter.ms/workspaces/default/plugins/marketplace.git This endpoint serves as a live, version-controlled catalog of every plugin in your API Center — with metadata, configuration, and install instructions ready for developer tools to consume. Get up and running in seconds We've designed the experience to be as frictionless as possible. Developers can add your organization's marketplace and start installing plugins with just two commands: In Claude Code /plugin marketplace add <url> /plugin install plugin-name@myapicenter In GitHub Copilot CLI /plugin marketplace add <url> /plugin marketplace browse myapicenter Enterprise-ready from day one The plugin marketplace isn't just convenient — it's governed. Access to the marketplace endpoint inherits the same authentication model you configured for your API Center portal, so your security and compliance posture stays intact. Platform teams remain in full control of what gets published; developers get a seamless, trusted source of truth. Documentation To learn more click here
Sreekanth_Thirthala
Apr 16, 2026 Place Azure Integration Services Blog
490Views
0likes
0Comments
Migrate Data Ingestion from Data Collector to Log Ingestion
HTTP Data Collector API in Log Analytics workspaces is being deprecated, and will be totally out of support in September 2026. Data Collector actions in logic app using already created API connections (which uses workspace Id & Key) would still work against old custom log tables, however, newly created table will not be able to ingest data, although the connector would still succeed in logic app, but no data will be populated in newly created custom logs. In case new API connection is created for Data Collector action (using workspace Id & Key); these will fail with 403 - Forbidden action. Users should start using the Log Ingestion API to send data to custom tables, and this document will guide users on how to use Log Ingestion API in logic apps. Note: Azure portal currently is update so it doesn't show the Workspace keys in Log Analytics workspace page, however, Az CLI will still get the keys, but as stated, actions will fail with 403 when using them in Data Collector Action. Creating DCE & DCRs: To utilize the Log Ingestion API, Data Collection Endpoint & Data Collection Rule should be created first. DCE Creation is simple, from azure portal search for DCE, and then create a new one: For DCR creation, it can be either created from the DCR page in Azure Portal, or upon creating the custom log in Log Analytics workspace. DCR Popup You need to upload sample data file, so the custom log table has a schema, it needs to be JSON array. In case the sample log doesn't have a TimeGenerated field, you can easily add it using the mapping function as below: Add the below code in the Transformation box, then click run. Once you complete the DCR creation, we need to get the DCE full endpoint. Getting DCE Log Ingestion Full URL To get the full endpoint URL, please follow the below: 1. Get the DCE Log Ingestion URL from the DCE overview page: 2. On the DCR Page, get the immutable id for the DCR., then click on the JSON view of the DCR resource: 3. From the JSON view, get the stream name from the streamDeclarations field Now the full Log Ingestion URL is: DCE_URL/dataCollectionRules/{immutable_id}/streams/{streamName}?api-version=2023-01-01 It would be similar to: https://mshbou****.westeurope-1.ingest.monitor.azure.com/dataCollectionRules/dcr-7*****4e988bef2995cd52ae/streams/Custom-mshboulLogAPI_CL?api-version=2023-01-01 Granting Logic App MI needed IAM Roles: To call the ingestion endpoint using Logic Apps MI, we need to grant logic apps MI the role "Monitoring Metrics Publisher" over the DCR resource. To do this, open the DCR, from the blade choose Access Control (IAM), and then grant the logic app MI the role "Monitoring Metrics Publisher" Calling Log Ingestion Endpoint from logic apps: To call the ingestion endpoint from logic apps, we need to use the HTTP action, as below, the URI is the full DCE Endpoint we created before. Add the content-type headers, and the json body that contains the log data you want to send. For the authentication, it will be as below: Once executed, it should succeed, with status code 204. For more details on the Log Ingestion API, and the migration, please see our documentation: Migrate from the HTTP Data Collector API to the Log Ingestion API - Azure Monitor | Microsoft Learn Logs Ingestion API in Azure Monitor - Azure Monitor | Microsoft Learn Thanks.
mshboul
Apr 13, 2026 Place Azure Integration Services Blog
485Views
0likes
0Comments
Logic Apps Aviators Newsletter - April 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month April 2026's Ace Aviator: Marcelo Gomes What’s your role and title? What are your responsibilities? I’m an Integration Team Leader (Azure Integrations) at COFCO International, working within the Enterprise Integration Platform. My core responsibility is to design, architect, and operate integration solutions that connect multiple enterprise systems in a scalable, secure, and resilient way. I sit at the intersection of business, architecture, and engineering, ensuring that business requirements are correctly translated into technical workflows and integration patterns. From a practical standpoint, my responsibilities include: - Defining integration architecture standards and patterns across the organization - Designing end‑to‑end integration solutions using Azure Integration Services - Owning and evolving the API landscape (via Azure API Management) - Leading, mentoring, and supporting the integration team - Driving PoCs, experiments, and technical explorations to validate new approaches - Acting as a bridge between systems, teams, and business domains, ensuring alignment and clarity In short, my role is to make sure integrations are not just working — but are well‑designed, maintainable, and aligned with business goals. Can you give us some insights into your day‑to‑day activities and what a typical day looks like? My day‑to‑day work is a balance between technical leadership, architecture, and execution. A typical day usually involves: - Working closely with Business Analysts and Product Owners to understand integration requirements, constraints, and expected outcomes - Translating those requirements into integration flows, APIs, and orchestration logic - Defining or validating the architecture of integrations, including patterns, error handling, resiliency, and observability - Guiding developers during implementation, reviewing approaches, and helping them make architectural or design decisions - Managing and governing APIs through Azure API Management, ensuring consistency, security, and reusability - Unblocking team members by resolving technical issues, dependencies, or architectural doubts - Performing estimations, supporting planning, and aligning delivery expectations I’m also hands‑on. I actively build integrations myself — not just to help deliver, but to stay close to the platform, understand real challenges, and continuously improve our standards and practices. I strongly believe technical leadership requires staying connected to the actual implementation. What motivates and inspires you to be an active member of the Aviators / Microsoft community? What motivates me is knowledge sharing. A big part of what I know today comes from content shared by others — blog posts, samples, talks, community discussions, and real‑world experiences. Most of my learning followed a simple loop: someone shared → I tried it → I broke it → I fixed it → I learned. For me, learning only really completes its cycle when we share back. Explaining what worked (and what didn’t) helps others avoid the same mistakes and accelerates collective growth. Communities like Aviators and the Microsoft ecosystem create a space where learning is practical, honest, and experience‑driven — and that’s exactly the type of environment I want to contribute to. Looking back, what advice would you give to people getting into STEM or technology? My main advice is: start by doing. Don’t wait until you feel ready or confident — you won’t. When you start doing, you will fail. And that failure is not a problem; it’s part of the learning process. Each failure builds experience, confidence, and technical maturity. Another important point: ask questions. There is no such thing as a stupid question. Asking questions opens perspectives, challenges assumptions, and often triggers better solutions. Sometimes, a simple question from a fresh point of view can completely change how a problem is solved. Progress in technology comes from curiosity, iteration, and collaboration — not perfection. What has helped you grow professionally? Curiosity has been the biggest driver of my professional growth. I like to understand how things work under the hood, not just how to use them. When I’m curious about something, I try it myself, test different approaches, and build my own experience around it. That hands‑on curiosity helps me: - Develop stronger technical intuition - Understand trade‑offs instead of just following patterns blindly - Make better architectural decisions - Communicate more clearly with both technical and non‑technical stakeholders Having personal experience with successes and failures gives me clarity about what I’m really looking for in a solution — and that has been key to my growth. If you had a magic wand to create a new feature in Logic Apps, what would it be and why? I’d add real‑time debugging with execution control. Specifically, the ability to: - Pause a running Logic App execution - Inspect intermediate states, variables, and payloads in real time - Step through actions one by one, similar to a traditional debugger This would dramatically improve troubleshooting, learning, and optimization, especially in complex orchestrations. Today, we rely heavily on post‑execution inspection, which works — but real‑time visibility would be a huge leap forward in productivity and understanding. For integration engineers, that kind of feature would be a true game‑changer. News from our product group How to revoke connection OAuth programmatically in Logic Apps The post shows how to revoke an API connection’s OAuth tokens programmatically in Logic Apps, without using the portal. It covers two approaches: invoking the Revoke Connection Keys REST API directly from a Logic App using the 'Invoke an HTTP request' action, and using an Azure AD app registration to acquire a bearer token that authorizes the revoke call from Logic Apps or tools like Postman. Step-by-step guidance includes building the request URL, obtaining tokens with client credentials, parsing the token response, and setting the Authorization header. It also documents required permissions and a least-privilege custom RBAC role. Introducing Skills in Azure API Center This article introduces Skills in Azure API Center—registered, reusable capabilities that AI agents can discover and use alongside APIs, models, agents, and MCP servers. A skill describes what it does, its source repository, ownership, and which tools it is allowed to access, providing explicit governance. Teams can register skills manually in the Azure portal or automatically sync them from a Git repository, supporting GitOps workflows at scale. The portal offers discovery, filtering, and lifecycle visibility. Benefits include a single inventory for AI assets, better reuse, and controlled access via Allowed tools. Skills are available in preview with documentation links. Reliable blob processing using Azure Logic Apps: Recommended architecture The post explains limitations of the in‑app Azure Blob trigger in Logic Apps, which relies on polling and best‑effort storage logs that can miss events under load. For mission‑critical scenarios, it recommends a queue‑based pattern: have the source system emit a message to Azure Storage Queues after each blob upload, then trigger the Logic App from the queue and fetch the blob by metadata. Benefits include guaranteed triggering, decoupling, retries, and observability. As an alternative, it outlines using Event Grid with single‑tenant Logic App endpoints, plus caveats for private endpoints and subscription validation requirements. Implementing / Migrating the BizTalk Server Aggregator Pattern to Azure Logic Apps Standard This article shows how to implement or migrate the classic BizTalk Server Aggregator pattern to Azure Logic Apps Standard using a production-ready template available in the Azure portal. It maps BizTalk orchestration concepts (correlation sets, pipelines, MessageBox) to cloud-native equivalents: a stateful workflow, Azure Service Bus as the messaging backbone, CorrelationId-based grouping, and FlatFileDecoding for reusing existing BizTalk XSD schemas with zero refactoring. Step-by-step guidance covers triggering with the Service Bus connector, grouping messages by CorrelationId, decoding flat files, composing aggregated results, and delivering them via HTTP. A side‑by‑side comparison highlights architectural differences and migration considerations, aligned with BizTalk Server end‑of‑life timelines. News from our community Resilience for Azure IPaaS services Post by Stéphane Eyskens Stéphane Eyskens examines resilience patterns for Azure iPaaS workloads and how to design multi‑region architectures spanning stateless and stateful services. The article maps strategies across Service Bus, Event Hubs, Event Grid, Durable Functions, Logic Apps, and API Management, highlighting failover models, idempotency, partitioning, and retry considerations. It discusses trade‑offs between active‑active and active‑passive, the role of a governed API front door, and the importance of consistent telemetry for recovery and diagnostics. The piece offers pragmatic guidance for integration teams building high‑availability, fault‑tolerant solutions on Azure. From APIs to Agents: Rethinking Integration in the Agentic Era Post by Al Ghoniem, MBA This article frames AI agents as a new layer in enterprise integration rather than a replacement for existing platforms. It contrasts deterministic orchestration with agent‑mediated behavior, then proposes an Azure‑aligned architecture: Azure AI Agent Service as runtime, API Management as the governed tool gateway, Service Bus/Event Grid for events, Logic Apps for deterministic workflows, API Center as registry, and Entra for identity and control. It also outlines patterns—tool‑mediated access, hybrid orchestration, event+agent systems, and policy‑enforced interaction—plus anti‑patterns to avoid. DevUP Talks 01 - 2026 Q1 trends with Kent Weare Video by Mattias Lögdberg Mattias Lögdberg hosts Kent Weare for a concise discussion on early‑2026 trends affecting integration and cloud development. The conversation explores how AI is reshaping solution design, where new opportunities are emerging, and how teams can adapt practices for reliability, scalability, and speed. It emphasizes practical implications for developers and architects working with Azure services and modern integration stacks. The episode serves as a quick way to track directional changes and focus on skills that matter as agentic automation and platform capabilities evolve. Azure Logic Apps as MCP Servers: A Step-by-Step Guide Post by Stephen W Thomas Stephen W Thomas shows how to expose Azure Logic Apps (Standard) as MCP servers so AI agents can safely reuse existing enterprise workflows. The guide explains why this matters—reusing logic, tapping 1,400+ connectors, and applying key-based auth—and walks through creating an HTTP workflow, defining JSON schemas, connecting to SQL Server, and generating API keys from the MCP Servers blade. It closes with testing in VS Code, demonstrating how agents invoke Logic Apps tools to query live data with governance intact, without rewriting integration code. BizTalk to Azure Migration Roadmap: Integration Journey Post by Sandro Pereira This roadmap-style article distills lessons from BizTalk-to-Azure migrations into a structured journey. It outlines motivations for moving, capability mapping from BizTalk to Azure Integration Services, and phased strategies that reduce risk while modernizing. Readers get guidance on assessing dependencies, choosing target Azure services, designing hybrid or cloud‑native architectures, and sequencing workloads. The post emphasises that migration is not a lift‑and‑shift but a program of work aligned to business priorities, platform governance, and operational readiness. BizTalk Adapters to Azure Logic Apps Connectors Post by Michael Stephenson Michael Stephenson discusses how organizations migrating from BizTalk must rethink integration patterns when moving to Azure Logic Apps connectors. The post considers what maps well, where gaps and edge cases appear, and how real-world implementations often require re‑architecting around AIS capabilities rather than a one‑to‑one adapter swap. It highlights community perspectives and practical considerations for planning, governance, and operationalizing new designs beyond pure connector parity. Pro-Code Enterprise AI-Agents using MCP for Low-Code Integration Video by Sebastian Meyer This short video demonstrates bridging pro‑code and low‑code by using the Model Context Protocol (MCP) to let autonomous AI agents interact with enterprise systems via Logic Apps. It walks through the high‑level setup—agent, MCP server, and Logic Apps workflows—and shows how to connect to platforms like ServiceNow and SAP. The focus is on practical tool choice and architecture so teams can extend existing integration assets to agent‑driven use cases without rebuilding from scratch. Friday Fact: The Hidden Retry Behavior That Makes Logic Apps Feel Stuck Post by João Ferreira This Friday Fact explains why a Logic App can appear “stuck” when calling unstable APIs: hidden retry policies, exponential backoff, and looped actions can accumulate retries and slow runs dramatically. It lists default behaviors many miss, common causes like throttling, and mitigation steps such as setting explicit retry policies, using Configure run after for failure paths, and introducing circuit breakers for flaky backends. The takeaway: the workflow may not be broken—just retrying too aggressively—so design explicit limits and recovery paths. Your Logic App Is NOT Your Business Process (Here’s Why) Video by Al Ghoniem, MBA This short explainer argues that mapping Logic Apps directly to a business process produces brittle workflows. Real systems require retries, enrichment, and exception paths, so the design quickly diverges from a clean process diagram. The video proposes separating technical orchestration from business visibility using Business Process Tracking. That split yields clearer stakeholder views and more maintainable solutions, while keeping deterministic execution inside Logic Apps. It’s a practical reminder to design for operational reality rather than mirroring a whiteboard flow. BizTalk Server Migration to Azure Integration Services Architecture Guidance Post by Sandro Pereira A brief overview of Microsoft’s architecture guidance for migrating BizTalk Server to Azure Integration Services. The post explains the intent of the guidance, links to sections on reasons to migrate, AIS capabilities, BizTalk vs. AIS comparisons, and service selection. It highlights planning topics such as migration approaches, best practices, and a roadmap, helping teams frame decisions for hybrid or cloud‑native architectures as they modernize BizTalk workloads. Logic Apps & Power Automate Action Name to Code Translator Post by Sandro Pereira This post introduces a lightweight utility that converts Logic Apps and Power Automate action names into their code identifiers—useful when writing expressions or searching in Code View. It explains the difference between designer-friendly labels and underlying names (spaces become underscores and certain symbols are disallowed), why this causes friction, and how the tool streamlines the translation. It includes screenshots, usage notes, and the download link to the open-source project, making it a practical time-saver for developers moving between designer and code-based workflows. Logic Apps Consumption CI/CD from Zero to Hero Whitepaper Post by Sandro Pereira This whitepaper provides an end‑to‑end path to automate CI/CD for Logic Apps Consumption using Azure DevOps. It covers solution structure, parameterization, and environment promotion, then shows how to build reliable pipelines for packaging, deploying, and validating Logic Apps. The guidance targets teams standardizing delivery with repeatable patterns and governance. With templates and practical advice, it helps reduce manual steps, improve quality, and accelerate releases for Logic Apps workloads. Logic App Best practices, Tips and Tricks: #2 Actions Naming Convention Post by Sandro Pereira This best‑practices post focuses on action naming in Logic Apps. It explains why consistent, descriptive names improve readability, collaboration, and long‑term maintainability, then outlines rules and constraints on allowed characters. It shows common pitfalls—default names, uneditable trigger/branch labels—and practical tips for renaming while avoiding broken references. The guidance helps teams treat names as living documentation so workflows remain understandable without drilling into each action’s configuration. How to Expose and Protect Logic App Using Azure API Management (Whitepaper) Post by Sandro Pereira This whitepaper explains how to front Logic Apps with Azure API Management for governance and security. It covers publishing Logic Apps as APIs, restricting access, enforcing IP filtering, preventing direct calls to Logic Apps, and documenting operations. It also discusses combining multiple Logic Apps under a single API, naming conventions, and how to remove exposed operations safely. The paper provides step‑by‑step guidance and a download link to help teams standardize exposure and protection patterns. Logic apps – Check the empty result in SQL connector Post by Anitha Eswaran This post shows a practical pattern for handling empty SQL results in Logic Apps. Using the SQL connector’s output, it adds a Parse JSON step to normalize the result and then evaluates length() to short‑circuit execution when no rows are returned. Screenshots illustrate building the schema, wiring the content, and introducing a conditional branch that terminates the run when the array is empty. The approach avoids unnecessary downstream actions and reduces failures, providing a reusable, lightweight guard for query‑driven workflows. Azure Logic Apps Is Basically Power Automate on Steroids (And You Shouldn’t Be Afraid of It) Post by Kim Brian Kim Brian explains why Logic Apps feels familiar to Power Automate builders while removing ceilings that appear at scale. The article contrasts common limits in cloud flows with Standard/Consumption capabilities, highlights the designer vs. code‑view model, and calls out built‑in Azure management features such as versioning, monitoring, and CI/CD. It positions Logic Apps as the “bigger sibling” for enterprise‑grade integrations and data throughput, offering more control without abandoning the visual authoring experience. Logic Apps CSV Alphabetic Sorting Explained Post by Sandro Pereira Sandro Pereira describes why CSV headers and columns can appear in alphabetical order after deploying Logic Apps via ARM templates. He explains how JSON serialization and array ordering influence CSV generation, what triggers the sorting behavior, and practical workarounds to preserve intended column order. The article helps teams avoid subtle defects in data exports by aligning workflow design and deployment practices with how Logic Apps materializes CSV content at runtime. Azure Logic Apps Translation vs Transformation – Actions, Examples, and Schema Mapping Explained Post by Maheshkumar Tiwari Maheshkumar Tiwari clarifies the difference between translation (format change) and transformation (business logic) in Logic Apps, then maps each to concrete Azure capabilities. Using a purchase‑order scenario, he shows how to decode/encode flat files and EDI, convert XML↔JSON, and apply Liquid/XSLT, Select, Compose, and Filter Array for schema mapping and enrichment. A quick reference table ties common tasks to the right action, helping architects separate concerns so format changes don’t break business rules and workflow design remains maintainable.
WSilveira
Apr 07, 2026 Place Azure Integration Services Blog
466Views
0likes
0Comments
Introducing Skills in Azure API Center
The problem Modern applications depend on more than APIs. A single AI workflow might call an LLM, invoke an MCP tool, integrate a third-party service, and reference a business capability spanning dozens of endpoints. Without a central inventory, these assets become impossible to discover, easy to duplicate, and painful to govern. Azure API Center — part of the Azure API Management platform — already catalogs models, agents, and MCP servers alongside traditional APIs. Skills extend that foundation to cover reusable AI capabilities. What is a Skill? As AI agents become more capable, organizations need a way to define and govern what those agents can actually do. Skills are the answer. A Skill in Azure API Center is a reusable, registered capability that AI agents can discover and consume to extend their functionality. Each skill is backed by source code — typically hosted in a Git repository — and describes what it does, what APIs or MCP servers it can access, and who owns it. Think of skills as the building blocks of AI agent behavior, promoted into a governed inventory alongside your APIs, MCP servers, models, and agents. Example: A "Code Review Skill" performs automated code reviews using static analysis. It is registered in API Center with a Source URL pointing to its GitHub repo, allowed to access your code analysis API, and discoverable by any AI agent in your organization. How Skills work in API Center Skills can be added to your inventory in two ways: registered manually through the Azure portal, or synchronized automatically from a connected Git repository. Both approaches end up in the same governed catalog, discoverable through the API Center portal. Option 1: Register a Skill manually Use the Azure portal to register a skill directly. Navigate to Inventory > Assets in your API center, select + Register an asset > Skill, and fill in the registration form. Figure 2: Register a skill form in the Azure portal. The form captures everything needed to make a skill discoverable and governable: Field Description Title Display name for the skill (e.g. Code Review Skill). Identification Auto-generated URL slug based on the title. Editable. Summary One-line description of what the skill does. Description Full detail on capabilities, use cases, and expected behavior. Lifecycle stage Current state: Design, Preview, Production, or Deprecated. Source URL Git repository URL for the skill source code. Allowed tools The APIs or MCP servers from your inventory this skill is permitted to access. Enforces governance at the capability level. License Licensing terms: MIT, Apache 2.0, Proprietary, etc. Contact information Owner or support contact for the skill. Governance note: The Allowed tools field is key for AI governance. It explicitly defines which APIs and MCP servers a skill can invoke — preventing uncontrolled access and making security review straightforward. Option 2: Sync Skills from a Git repository For teams managing skills in source control, API Center can integrate directly with a Git repository and synchronize skill information automatically. This is the recommended approach for teams practicing GitOps or managing many skills at scale. Figure 3: Integrating a Git repository to sync skills automatically into API Center. When you configure a Git integration, API Center: Creates an Environment representing the repository as a source of skills Scans for files matching the configured pattern (default: **/skill.md) Syncs matching skills into your inventory and keeps them current as the repo changes For private repositories, a Personal Access Token (PAT) stored in Azure Key Vault is used for authentication. API Center's managed identity retrieves the PAT securely — no credentials are stored in the service itself. Tip: Use the Automatically configure managed identity and assign permissions option when setting up the integration if you haven't pre-configured a managed identity. API Center handles the Key Vault permissions automatically. Discovering Skills in your catalog Once registered — manually or via Git — skills appear in the Inventory > Assets page alongside all other asset types. Linked skills (synced from Git) are visually identified with a link icon, so teams can see at a glance which skills are source-controlled. From the API Center portal, developers and other stakeholders can browse the full skill catalog, filter by lifecycle stage or type, and view detailed information about each skill — including its source URL, allowed tools, and contact information. Figure 4: Skills catalog in API Center portal, showing registered skills and the details related to the skill. Developer experience: The API Center portal gives teams a self-service way to discover approved skills without needing to ask around or search GitHub. The catalog becomes the authoritative source of what's available and what's allowed. Why this matters for AI development teams Skills close a critical gap in AI governance. As organizations deploy AI agents, they need to know — and control — what those agents can do. Without a governed skill registry, capability discovery is ad hoc, reuse is low, and security review is difficult. By bringing skills into Azure API Center alongside APIs, MCP servers, models, and agents, teams get: A single inventory for all the assets AI agents depend on Explicit governance over which resources each skill can access via Allowed tools Automated, source-controlled skill registration via Git integration Discoverability for developers and AI systems through the API Center portal Consistent lifecycle management — Design through Production to Deprecated API Center, as part of the Azure API Management platform and the broader AI Gateway vision, is evolving into the system of record for AI-ready development. Skills are the latest step in that direction. Available now Skills are available today in Azure API Center (preview). To register your first skill: Sign in to the Azure portal and navigate to your API Center instance In the sidebar, select Inventory > Assets Select + Register an asset > Skill Fill in the registration form and select Create → Register and discover skills in Azure API Center (docs) → Set up your API Center portal → Explore the Azure API Management platform
anishta
Mar 31, 2026 Place Azure Integration Services Blog
2KViews
0likes
2Comments
New Azure API management service limits
Azure API Management operates on finite physical infrastructure. To ensure reliable performance for all customers, the service enforces limits calibrated based on: Azure platform capacity and performance characteristics Service tier capabilities Typical customer usage patterns Resource limits are interrelated and tuned to prevent any single aspect from disrupting overall service performance. Changes to service limits - 2026 update Starting March 2026 and over the following several months, Azure API Management is introducing updated resource limits for instances across all tiers. The limits are shown in the following table. Entity/Resource Consumption Developer Basic/ Basic v2 Standard/ Standard v2 Premium/ Premium v2 API operations 3,000 3,000 10,000 50,000 75,000 API tags 1,500 1,500 1,500 2,500 15,000 Named values 5,000 5,000 5,000 10,000 18,000 Loggers 100 100 100 200 400 Products 100 100 200 500 2,000 Subscriptions N/A 10,000 15,000 25,000 75,000 Users N/A 20,000 20,000 50,000 75,000 Workspaces per workspace gateway N/A N/A N/A N/A 30 Self-hosted gateways N/A 5 N/A N/A 100 1 1 Applies to Premium tier only. What's changing Limits in the classic tiers now align with those set in the v2 tiers. Limits are enforced for a smaller set of resource types that are directly related to service capacity and performance, such as API operations, tags, products, and subscriptions. Rollout process New limits roll out in a phased approach by tier as follows: Tier Expected rollout date Consumption Developer Basic Basic v2 March 15, 2026 Standard Standard v2 April 15, 2026 Premium Premium v2 May 15, 2026 Limits policy for existing classic tier customers After the new limits take effect, you can continue using your preexisting API Management resources without interruption. Existing classic tier services, where current usage exceeds the new limits, are "grandfathered" when the new limits are introduced. (Instances in the v2 tiers are already subject to the new limits.) Limits in grandfathered services will be set 10% higher than the customer's observed usage at the time new limits take effect. Grandfathering applies per service and service tier. Other existing services and new services are subject to the new limits when they take effect. Guidelines for limit increases In some cases, you might want to increase a service limit. Before requesting a limit increase, note the following guidelines: Explore strategies to address the issue proactively before requesting a limit increase. See the article here Manage resources within limits. Consider potential impacts of the limit increase on overall service performance and stability. Increasing a limit might affect your service's capacity or increase latency in some service operations. Requesting a limit increase The product team considers requests for limit increases only for customers using services in the following tiers that are designed for medium to large production workloads: Standard and Standard v2 Premium and Premium v2 Requests for limit increases are evaluated on a case-by-case basis and aren't guaranteed. The product team prioritizes Premium and Premium v2 tier customers for limit increases. To request a limit increase, create a support request from the Azure portal. For more information, see Azure support plans. Documentation For more information, please see documentation here
Sreekanth_Thirthala
Mar 03, 2026 Place Azure Integration Services Blog
2.2KViews
0likes
2Comments
Implementing / Migrating the BizTalk Server Aggregator Pattern to Azure Logic Apps Standard
While the article focuses on the migration path from BizTalk Server, the template is equally suited for new (greenfield) implementations any team looking to implement the Aggregator pattern natively in Azure Logic Apps can deploy it directly from the Azure portal without prior BizTalk experience. The template source code is open source and available in the Azure LogicAppsTemplates GitHub repository. For full details on the original BizTalk implementation, see the BizTalk Server Aggregator SDK sample. Why is it important? BizTalk Server End of life has been confirmed and if you have not started your migration to Logic Apps, you should start soon. This is one of many articles in BizTalk Migration. More information can be found here: https://aka.ms/biztalkeolblog. The migration at a glance: BizTalk orchestration vs. Logic Apps workflow The BizTalk SDK implements the pattern through an orchestration (Aggregate.odx) that uses correlation sets, receive shapes, loop constructs, and send pipelines. The Logic Apps Standard template replicates the same logic using a stateful workflow with Azure Service Bus and CorrelationId-based grouping. The BizTalk solution includes: Component Purpose Aggregate.odx Main orchestration that collects correlated messages and executes the send pipeline FFReceivePipeline.btp Receive pipeline with flat file disassembler Invoice.xsd Document schema for invoice messages InvoiceEnvelope.xsd Envelope schema for output interchange PropertySchema.xsd Property schema with promoted properties for correlation XMLAggregatingPipeline.btp Send pipeline to assemble collected messages into XML interchange The Azure Logic Apps Standard implementation The Logic Apps Standard workflow replicates the same Aggregator pattern using a stateful workflow with Azure Service Bus as the message source and CorrelationId-based grouping. The template is publicly available in the Azure portal templates gallery. Figure 2: The “Aggregate messages from Azure Service Bus by CorrelationId” template in the Azure portal templates gallery, published by Microsoft. Receives messages from Service Bus in batches, groups them by CorrelationId, decodes flat files, and responses with the aggregated result via HTTP. Side-by-side comparison: BizTalk Server vs. Azure Logic Apps Understanding how each component maps between platforms is essential for a smooth migration: Concept BizTalk Server (Aggregate.odx) Azure Logic Apps Standard Messaging infrastructure MessageBox database (SQL Server) Azure Service Bus (cloud-native PaaS) Message source Receive Port / Receive Location Service Bus trigger (peekLockQueueMessagesV2) Message decoding Receive Pipeline (Flat File Disassembler) Decode_Flat_File_Invoice action (FlatFileDecoding) Correlation mechanism Correlation Sets on promoted properties (DestinationPartnerURI) CorrelationId from Service Bus message properties Message accumulation Loop shape + Message Assignment shapes ForEach loop + CorrelationGroups dictionary variable Completion condition Loop exit (10 messages or 1-minute timeout) Batch-based: processes all messages in current batch Aggregated message construction Construct Message shape + XMLAggregatingPipeline Build_Aggregated_Messages ForEach + Compose actions Result delivery Send Port (file, HTTP, or other adapter) HTTP Response or any other regarding business need Error handling Exception Handler shapes + SuspendMessage.odx Scope + error handler actions Schema support BizTalk Flat File Schemas (XSD) Same XSD schemas in Artifacts/Schemas folder State management Orchestration dehydration/rehydration Stateful workflow with run history Key architectural differences Aspect BizTalk Server Azure Logic Apps Standard Processing model Convoy pattern (long-running, event-driven) Batch-based (processes N messages per trigger) Scalability BizTalk Host instances (manual scaling) Elastic scale (Azure App Service Plan) Retry logic Adapter-level retries Built-in HTTP retry policy (3 attempts, 10s interval) Architecture Monolithic orchestration Decoupled: aggregation + downstream processing Monitoring BizTalk Admin Console / HAT Azure portal run history + Azure Monitor Schema reuse BizTalk project schemas Direct XSD reuse in Artifacts/Schemas Deployment MSI / BizTalk deployment ARM templates, Azure DevOps, GitHub Actions How the workflow works 1. Trigger: Receive messages from Service Bus The workflow uses the built-in Service Bus trigger to retrieve messages in batches from a non-session queue. This is analogous to BizTalk's Receive Location polling the message source. 2. Process and correlate: Group messages by CorrelationId Each message is processed sequentially (like BizTalk's ordered delivery). The workflow: Extracts the CorrelationId from Service Bus message properties (equivalent to BizTalk's promoted property used in the Correlation Set) Decodes flat file content with zero refactoring using the XSD schema (equivalent to BizTalk's Flat File Disassembler pipeline component) Groups messages into a dictionary keyed by CorrelationId (equivalent to BizTalk's loop + message assignment pattern) 3. Build aggregated output Once all messages in the batch are processed, the workflow constructs a result object for each correlation group containing the CorrelationId, message count and the array of decoded messages. 4. Deliver results The aggregated output is sent to a target workflow via HTTP POST, following a decoupled architecture pattern. This is analogous to BizTalk's Send Port delivering the result to the destination system. You can substitute this action for another endpoint as needed. This, will depend on your business case. Azure Service Bus: The cloud-native replacement for BizTalk’s MessageBox In BizTalk Server, the MessageBox database is the central hub for all message routing, subscription-based delivery, and correlation. It’s the engine that enables patterns like the Aggregator — messages are published to the MessageBox, and the orchestration subscribes to them based on promoted properties and correlation sets. In Azure Logic Apps Standard, there is no MessaeBox equivalent. Instead, Azure Service Bus serves as the cloud-native messaging backbone. Service Bus provides the same publish/subscribe semantics, message correlation (via the built-in CorrelationId property), peek-lock delivery, and reliable queuing — but as a fully managed, elastically scalable PaaS service with no infrastructure to maintain. This is a fundamental shift in architecture: you move from a centralized SQL Server-based message broker (MessageBox) to a distributed, cloud-native messaging service (Service Bus) that scales independently and integrates natively with Logic Apps through the built-in Service Bus connector. Important: Service Bus is not available on-premises. However, RabbitMQ is available to cover these needs, on-premises. RabbitMQ offers a fantastic alternative for customers looking to replicate BizTalk message routing, subscription-based delivery, and correlation. Decode Flat File Invoice: Reuse your BizTalk schemas with zero refactoring One of the biggest concerns during any BizTalk migration is: “What happens to our flat file schemas and message formats?” The workflow template includes a Decode Flat File action (type FlatFileDecoding) that converts positional or delimited flat file content into XML — exactly like BizTalk’s Flat File Disassembler pipeline component. The key advantage: your original BizTalk XSD flat file schemas work as-is. Upload them to the Logic Apps Artifacts/Schemas folder and reference them by name in the workflow — no modifications, no refactoring. This means: Your existing message formats don’t change — upstream and downstream systems continue sending and receiving the same flat file messages Your BizTalk schemas are directly reusable — the same Invoice.xsd from your BizTalk project works seamlessly with the FlatFileDecoding action Migration effort is significantly reduced — no need to redesign schemas, re-validate message structures, or update trading partner agreements Time-to-production is faster — focus on workflow logic and connectivity instead of rewriting message definitions Notice that, if you need to process XML data, as your data might arrive in XML format, use the XML Operations: Validate, Transform, Parse, and Compose XML with schema. You can find more information at Compose XML using Schemas in Standard Workflows - Azure Logic Apps | Microsoft Learn. The message with correlation Id Each message in the Service Bus queue is a flat file invoice the same positional/delimited text format used in the BizTalk SDK sample. Here's an example: INVOICE12345 DestinationPartnerURI:http://www.contoso.com?ID=1E1B9646-48CF-41dd-A0C0-1014B1CE5064 BILLTO,US,John Connor,123 Cedar Street,Mill Valley,CA,90952 101-TT Plastic flowers 10 4.99 Fragile handle with care 202-RR Fertilizer 1 10.99 Lawn fertilizer 453-XS Weed killer 1 5.99 Lawn weed killer The message structure combines positional and delimited fields: Line 1: Invoice identifier (fixed-length record) Line 2: Destination partner URI — in BizTalk, this value is promoted as a context property and used in the Correlation Set to group related messages Line 3: Bill-to header (comma-delimited: country, name, address, city, state, ZIP) Line 4: Line items (positional fields: item code, description, quantity, unit price, notes) Why CorrelationId is essential In BizTalk Server, the orchestration promotes `DestinationPartnerURI` from the message body into a context property and uses it as the Correlation Set to match related messages. This requires a Property Schema, promoted properties, and pipeline configuration. In Azure Logic Apps Standard, correlation is decoupled from the message body. The `CorrelationId` is a native Azure Service Bus message property with a first-class header set by the message producer when sending to the queue. This means: No schema changes needed: the flat file content stays exactly the same No property promotion: Service Bus provides the correlation identifier out of the box Simpler architecture: the workflow reads `CorrelationId` directly from the message metadata, not from the payload Producer flexibility any system sending to Service Bus can set the `CorrelationId` header using standard SDK methods, without modifying the message body This is why the Aggregator pattern maps so naturally to Service Bus: the correlation mechanism that BizTalk implements through promoted properties and correlation sets is already built into the messaging infrastructure. Step-by-step guide: Deploy the template from the Azure portal The “Aggregate messages from Azure Service Bus by CorrelationId” template is publicly available in the Azure Logic Apps Standard templates gallery. Follow these steps to deploy it: Prerequisites Before you begin, make sure you have: An Azure subscription. If you don’t have one, sign up for a free Azure account . An Azure Logic Apps Standard resource deployed in your subscription. If you need to create one, see Create an example Standard logic app workflow . An Azure Service Bus namespace with a non-session queue configured. A flat file XSD schema (for example, Invoice.xsd) ready to upload to the logic app’s Artifacts/Schemas folder. A target workflow with an HTTP trigger to receive the aggregated results (optional, can be created after deployment). Step 1: Open the templates gallery Sign in to the Azure portal. Navigate to your Standard logic app resource. On the logic app sidebar menu, select Workflows. On the logic app sidebar menu, select Workflows. On the Workflows page, select + Create to create a new workflow. In the “Create a new workflow” pane, select Use Template to open the templates gallery and select Create button. Step 2: Find the Aggregator template In the templates gallery, use the search box and type “Aggregate” or “Aggregator”. Optionally, filter by: o Connectors: Select Azure Service Bus o Categories: All Locate the template named “Aggregate messages from Azure Service Bus by CorrelationId”. o The template card shows the labels Workflow and Event as the solution type and trigger type. o The template is published by Microsoft. Step 3: Review the template details Select the template card to open the template overview pane. On the Summary tab, review: o Connections included in this template: Azure Service Bus (in-app connector) o Prerequisites: Requirements for Azure Service Bus, flat file schema, and connection configuration o Details: Description of the Aggregator enterprise integration pattern implementation Source code: Link to the GitHub repository Select the Workflow tab to preview the workflow design that the template creates and when you are ready select Use this template. Step 4: Provide workflow information In the Create a new workflow from template pane, on the Basics tab: o Workflow name: Enter a name for your workflow, for example, wf-aggregator-invoices o State type: Select Stateful (recommended for aggregation scenarios that require run history and reliable processing) Select Next. Step 5: Create connections On the Connections tab, create the Azure Service Bus connection: o Select Connect next to the Service Bus connection. o Provide your Service Bus connection string or select the managed identity authentication option. For managed identity (recommended), make sure your logic app’s managed identity has the Azure Service Bus Data Receiver role on the Service Bus namespace. 2. Select Next. Step 6: Configure parameters On the Parameters tab, provide values for the workflow parameters: Parameter Description Example value Azure Service Bus queue name The queue to monitor for incoming messages invoice-queue Maximum batch size Number of messages per batch (1-100) 10 Flat file schema name XSD schema name in Artifacts/Schemas Invoice.xsd Default CorrelationId Fallback value for messages without CorrelationId NO_CORRELATION_ID Target workflow URL HTTP endpoint of the downstream workflow https://your-logicapp.azurewebsites.net/... Target workflow timeout HTTP call timeout in seconds 60 Enable sequential processing Maintain message order true 2. Select Next. Step 7: Review and create On the Review + create tab, review all the provided information. Select Create. When the deployment completes, select Go to my workflow. Step 8: Upload the flat file schema Navigate to your logic app resource in the Azure portal. On the sidebar menu, under Artifacts, select Schemas. Select + Add and upload your Invoice.xsd. Confirm the schema appears in the list. Notice that: for this scenario we are using the Invoice.xsd schema, you can/must use the schema your scenario needs. Step 9: Verify and test On the workflow sidebar, select Designer to review the created workflow. Verify all actions are configured correctly. Send test messages to your Service Bus queue with different CorrelationId values. Monitor the Run history to verify successful execution and aggregation. For more information on creating workflows from templates, see Create workflows from prebuilt templates in Azure Logic Apps. Conclusion The Aggregator pattern is a cornerstone of enterprise integration, and migrating it from BizTalk Server to Azure Logic Apps Standard doesn’t mean starting from scratch. By using this template, you can: Reuse your existing XSD flat file schemas directly from your BizTalk projects Replace BizTalk Correlation Sets with CorrelationId-based message grouping via Azure Service Bus Deploy in minutes from the Azure portal templates gallery Scale elastically with Azure App Service Plan Monitor with Azure-native tools instead of the BizTalk Admin Console The template is open source and available at: GitHub PR: Azure/LogicAppsTemplates#108 Template name in Azure portal: “Aggregate messages from Azure Service Bus by CorrelationId” Source code: GitHub repository Whether you’re migrating from BizTalk Server or building a new integration solution from scratch, this template gives you a solid, production-ready starting point. I encourage you to try it, customize it for your scenarios, and contribute back to the community. Resources BizTalk Server Aggregator SDK sample Create workflows from prebuilt templates in Azure Logic Apps Create and publish workflow templates for Azure Logic Apps Flat file encoding and decoding in Logic Apps Azure Service Bus connector overview BizTalk to Azure migration guide BizTalk Migration Starter tool
reynaldom
Mar 03, 2026 Place Azure Integration Services Blog
617Views
0likes
0Comments
Logic Apps Aviators Newsletter - March 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month March 2026's Ace Aviator: Lilan Sameera What's your role and title? What are your responsibilities? I’m a Senior Consultant at Adaptiv, where I design, build, and support integration solutions across cloud and enterprise systems, translating business requirements into reliable, scalable, and maintainable solutions. I work with Azure Logic Apps, Azure Functions, Azure Service Bus, Azure API Management, Azure Storage, Azure Key Vault, and Azure SQL. Can you give us some insights into your day-to-day activities? Most of my work focuses on designing and delivering reliable, maintainable integration solutions. I spend my time shaping workflows in Logic Apps, deciding how systems should connect, handling errors, and making sure solutions are safe and effective. On a typical day, I might be: - Designing or reviewing integration workflows and message flows - Investigating tricky issues - Working with teams to simplify complex processes - Making decisions about patterns, performance, and long-term maintainability A big part of what I do is thinking ahead, anticipating where things could go wrong, and building solutions that are easy to support and extend. The culture at Adaptiv encourages this approach and makes knowledge sharing across teams easy. What motivates and inspires you to be an active member of the Aviators/Microsoft community? The Microsoft and Logic Apps communities are incredibly generous with knowledge. I’ve learned so much from blogs, GitHub repos, and forum posts. Being part of the Aviators community is my way of giving back, sharing real-world experiences, lessons learned, and practical solutions. Adaptiv encourages people to engage with the community, which makes it easier to contribute and stay involved. Looking back, what advice do you wish you had been given earlier? Don’t wait until you feel like you “know everything” to start building or sharing. You learn the most by doing, breaking things, fixing them, and asking questions. Focus on understanding concepts, not simply tools. Technologies change, fundamentals don’t. Communication matters as well. Being able to explain why something works is just as important as making it work. What has helped you grow professionally? Working on real-world, high-impact projects has been key. Being exposed to different systems, integration patterns, and production challenges has taught me more than any textbook. Supportive teammates, constructive feedback, and a culture that encourages learning and ownership have also been key in my growth. If you had a magic wand that could create a feature in Logic Apps, what would it be? I would love a first-class, visual way to version and diff Logic Apps workflows, like how code changes are tracked in Git. It would make reviews, troubleshooting, and collaboration much easier, notably in complex enterprise integrations, and help teams work more confidently. News from our product group New Azure API management service limits Azure API Management announced updated service limits across classic and v2 tiers to ensure predictable performance on shared infrastructure. The post details new limits for key resources such as API operations, tags, products, subscriptions, and users, along with a rollout schedule: Consumption/Developer/Basic (including v2) from March 15, Standard/Standard v2 from April 15, and Premium/Premium v2 from May 15, 2026. Existing classic services are grandfathered at 10% above observed usage at the time limits take effect. Guidance is provided on managing within limits, evaluating impact, and requesting increases (priority for Standard/Standard v2 and Premium/Premium v2). How to Access a Shared OneDrive Folder in Azure Logic Apps Logic Apps can work with files in a OneDrive folder shared by a colleague, but the OneDrive for Business “List files in folder” action doesn’t show shared folders because it enumerates only the signed‑in user’s drive. The article explains two supported approaches: (1) call Microsoft Graph using HTTP with Microsoft Entra ID (delegated permissions), or (2) use Graph Explorer to discover the shared folder’s driveId and folderId, then manually configure the action with {driveId}:{folderId}. A troubleshooting section shows how to extract these identifiers from browser network traces when Graph Explorer results are incomplete. Stop Writing Plumbing! Use the New Logic Apps MCP Server Wizard A new configuration experience in Logic Apps Standard (Preview) turns an existing logic app into an MCP server with a guided, in‑portal workflow. The wizard centralizes setup for authentication, API keys, server creation, and tool exposure, letting teams convert connectors and workflows into discoverable MCP tools that agents can call. You can generate tools from new connectors or register existing HTTP‑based workflows, choose API key or OAuth (EasyAuth) authentication, and test from agent platforms such as VS Code, Copilot Studio, and Foundry. The post also notes prerequisites and a known OAuth issue mitigated by reapplying EasyAuth settings. Logic Apps Agentic Workflows with SAP - Part 2: AI Agents Part 2 focuses on the AI portion of an SAP–Logic Apps integration. A Logic Apps validation agent retrieves business rules from SharePoint and produces structured outputs—an HTML summary, a CSV of invalid order IDs, and an “invalid rows” CSV—that directly drive downstream actions: email notifications, optional persistence of failed rows as custom IDocs, and filtering before a separate analysis step returns results to SAP. The post explains the agent loop design, tool boundaries (“Get validation rules,” “Get CSV payload,” “Summarize review”), and a two‑model pattern (validation vs. analysis) to keep AI outputs deterministic and workflow‑friendly. Logic Apps Agentic Workflows with SAP - Part 1: Infrastructure Part 1 establishes the infrastructure and contracts for a Logic Apps + SAP pattern that keeps integrations deterministic. A source workflow sends CSV data to SAP, while destination workflows handle validation and downstream processing. The post covers SAP connectivity (RFC/IDoc), the SAP‑side wrapper function, and the core contract elements—IT_CSV for input lines, ANALYSIS for results, EXCEPTIONMSG for human‑readable status, and RETURN (BAPIRET2) for structured success/error. It also details data shaping, error propagation, and email notification paths, with code snippets and diagrams to clarify gateway settings, namespace‑robust XPath extraction, and end‑to‑end flow control. Azure API Management - Unified AI Gateway Design Pattern This customer‑implemented pattern from Uniper uses Azure API Management as a unified AI gateway to normalize requests, enforce authentication and governance, and dynamically route traffic across multiple AI providers and models. Key elements include a single wildcard API, unified auth (API keys/JWT plus managed identity to backends), policy‑based path construction and model‑aware routing, circuit breakers with regional load balancing, token limits and metrics, and centralized logging. Reported outcomes include an 85% reduction in API definitions, faster feature availability, and 99.99% service availability. A GitHub sample shows how to implement the policy‑driven pipeline with modular policy fragments. A BizTalk Migration Tool: From Orchestrations to Logic Apps Workflows The BizTalk Migration Starter is an open‑source toolkit for modernizing BizTalk Server solutions to Azure Logic Apps. It includes tools to convert BizTalk maps (.btm) to Logic Apps Mapping Language (.lml), transform orchestrations (.odx) into Logic Apps workflow JSON, map pipelines to Logic Apps processing patterns, and expose migration tools via an MCP server for AI‑assisted workflows. The post outlines capabilities, core components, and command‑line usage, plus caveats (e.g., scripting functoids may require redesign). A demo video and GitHub repo links are provided for getting started, testing, and extending connector mappings and migration reports. Azure Arc Jumpstart Template for Hybrid Logic Apps Deployment A new Azure Arc Jumpstart “drop” provisions a complete hybrid environment for Logic Apps Standard on an Arc‑enabled AKS cluster with a single command. The deployment script sets up AKS, Arc for Kubernetes, the ACA extension, a custom location and Connected Environment, Azure SQL for runtime storage, an Azure Storage account for SMB artifacts, and a hybrid Logic Apps resource. After deployment, test commands verify each stage. The post links to prerequisites, quick‑start steps, a demo video, and references on hybrid deployment requirements. It invites community feedback and contributions via the associated GitHub repository. News from our community Pro-Code Enterprise AI-Agents using MCP for Low-Code Integration Video by Sebastian Meyer This video demonstrates how Model Context Protocol (MCP) can bridge pro-code and low-code integration by combining Microsoft Agent Framework with Azure Logic Apps. It shows how an autonomous AI agent can be wired into enterprise workflows, using MCP as the glue to connect to systems and trigger actions through Logic Apps. Viewers see how this approach reduces friction between traditional development and low-code automation while enabling consistent orchestration across services. The result is a practical pattern for extending enterprise automation with agent capabilities, improving flexibility without sacrificing control. Logic Apps: Autonomous agent loops - a practical solution for application registration secrets expiration (part 1) Post by Şahin Özdemir Şahin Özdemir describes how a single expired client secret disrupted an integration platform and how Logic Apps autonomous agent loops can prevent recurrence. The solution uses an AI-backed agent loop to call Microsoft Graph, list app registrations, detect secrets expiring within three weeks, and notify stakeholders via email using the Office 365 connector. Prerequisites include a Logic App with a managed identity and an AI model (e.g., via Microsoft Foundry). Clear agent instructions and tool context are emphasized to ensure consistent behavior. The result is a low-effort operational guardrail that replaces complex control-flow logic. From Low-Code to Full Power: When Power Platform Needs Azure with Sofia Platas Video by Ahmed Bayoumy & Robin Wilde Robin Wilde hosts Sofia Platas to explore when Power Platform solutions should extend into Azure. The conversation focuses on adopting an engineering mindset beyond low-code constraints—recognizing when workloads need Azure capabilities for scale, integration, or specialized services. It highlights moving from CRM and Power Platform into Azure and AI, and how pushing boundaries accelerates growth. The episode emphasizes practical decision-making over rigid labels, encouraging builders to reach for Azure when required while retaining the speed of low-code. It’s an insightful discussion about balancing agility with the robustness of cloud-native architecture. Cut Logic Apps Standard Costs by 70% in Dev & POC Azure Environments Post by Daniel Jonathan This article explains a practical cost-saving pattern for Logic Apps Standard in non‑production environments. Because Standard runs on an App Service Plan billed continuously, the author recommends deploying compute only during working hours and tearing it down afterward while retaining the Storage Account. Run history persists in storage, so redeployments reconnect seamlessly. Scripts automate deploy/teardown, with guidance on caveats: avoid removing compute during active runs, recurrence triggers won’t “catch up,” and production should stay always‑on. The post compares Standard versus Consumption and shows how this approach typically yields around 70% savings. Friday Fact: You can reference App Settings inside your Logic Apps Workflows Post by Sandro Pereira Sandro Pereira highlights a simple technique to externalize configuration in Logic Apps Standard by using the appsetting('Key') expression directly in workflow actions. The approach allows storing connection details, flags, and endpoints in App Settings or local.settings.json rather than hardcoding values, improving maintainability and environment portability. He notes the expression may not appear in the editor’s suggestion list but still works when added manually. The post includes a concise “one‑minute brief” and reminders to ensure the keys exist in the chosen configuration source, plus a short video for those who prefer a quick walkthrough. LogicAppWorkbook: Azure Monitor Workbook for Logic Apps Standard (App Insights v1) Post by sujith reddy komma This open-source Azure Monitor workbook provides a focused dashboard for Logic Apps Standard using Application Insights v1 telemetry. It organizes monitoring into Overview and Failures tabs, surfacing KPIs, status distribution, execution trends, and detailed failure grids. The repository includes KQL queries (Queries.md), screenshots, and clear import steps for Azure Workbooks. Notably, it targets the v1 telemetry schema (traces table, FlowRunLastJob) and isn’t compatible with newer v2 telemetry without query adjustments. It’s a useful starting point for teams wanting quick visibility into run health and trends without building dashboards from scratch. Azure Logic Apps - Choosing Between Consumption and Standard Models Post by Manish K. This post shares a primer that compares Logic Apps Consumption and Standard models to help teams choose the right hosting approach. It outlines Standard’s single‑tenant isolation, VNET integration, and better fit for long‑running or high‑throughput workloads, versus Consumption’s multi‑tenant, pay‑per‑action model ideal for short, variable workloads. It highlights migration considerations, limitations, and when each model is cost‑effective. The takeaway: align architecture, networking, and workload patterns to the model’s strengths to avoid surprises in performance, security, and pricing as solutions scale. Logic Apps standard monitoring dashboard – Fix ‘Runs’ tab Post by Integration.team Integration.team describes a fix for Logic Apps Standard where the Application Insights “Runs” tab shows a misconfiguration error and no history. The solution has two parts: ensure host.json sets ApplicationInsights telemetry to v2, and add a hidden tag on the Logic App that links it to the App Insights resource. They provide Bicep snippets for automated deployments and a portal-based alternative during initial creation. After applying both steps, run history populates correctly, restoring visibility in the monitoring dashboard and making troubleshooting more reliable. Using MCP Servers with Azure Logic App Agent Loops Post by Stephen W Thomas Stephen W Thomas explains how exposing Logic Apps as MCP servers simplifies agent loop designs. By moving inline tool logic out of the agent and into MCP-exposed endpoints, tools become reusable, easier to debug, and scoped to only what an agent needs. He discusses limiting accessible tools to control cost and execution time, and outlines a structure for organizing Logic Apps as discrete capabilities. The approach reduces agent complexity while improving maintainability and governance for AI-enabled workflows on Azure. Logic App Best Practices, Tips, and Tricks: #49 The Hidden 32-Character Naming Trap in Logic Apps Standard Post by Sandro Pereira Sandro Pereira explains a subtle but impactful pitfall in Logic Apps Standard tied to the Azure Functions runtime: the host ID is derived from only the first 32 characters of the Logic App name. When multiple Logic App Standard instances share a storage account and have identical leading characters, collisions can cause intermittent deployment and runtime failures. He recommends ensuring uniqueness within the first 32 characters or, in advanced cases, explicitly setting the host ID via AzureFunctionsWebHost__hostid. The article includes naming patterns and practical guidance to avoid hours of troubleshooting.
WSilveira
Mar 02, 2026 Place Azure Integration Services Blog
678Views
0likes
0Comments