Azure Integration Services Blog articles

Introducing the plugin marketplace for Azure API Center

Sreekanth_Thirthala — Fri, 17 Apr 2026 00:50:01 GMT

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

Migrate Data Ingestion from Data Collector to Log Ingestion

mshboul — Mon, 13 Apr 2026 08:06:40 GMT

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.

Logic Apps Aviators Newsletter - April 2026

WSilveira — Tue, 07 Apr 2026 16:55:33 GMT

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

Marcelo Gomes - Integration Team Leader @ COFCO International

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.

How to revoke connection OAuth programmatically in Logic Apps

Omar_Abu_Arisheh — Wed, 01 Apr 2026 11:02:44 GMT

There are multiple ways to revoke the OAuth of an API Connection other than clicking on the Revoke button in the portal:

For using the "Invoke an HTTP request":

Get the connection name:

Create a Logic App (Consumption), use a trigger of your liking, then add the “Invoke an HTTP request” Action.
Create a connection on the same Tenant that has the connection, then add the below URL to the action, and test it:

https://management.azure.com/subscriptions/[SUBSCRIPTION_ID]/resourceGroups/[RESOURCE_GROUP]/providers/Microsoft.Web/connections/[NAME_OF_CONNECTION]/revokeConnectionKeys?api-version=2018-07-01-preview

Your test should be successful.

For using an App Registration to fetch the Token (which is how you can do this with Postman or similar as well):

App Registration should include this permission:

For your Logic App, or Postman, get the Bearer Token by calling this URL: https://login.microsoftonline.com/[TENANT_ID]/oauth2/v2.0/token

With this in the Body:

Client_Id=[CLIENT_ID_OF_THE_APP_REG]&Client_Secret=[CLIENT_SECRET_FROM_APP_REG]&grant_type=client_credentials&scope=https://management.azure.com/.default

For the Header use: Content-Type = application/x-www-form-urlencoded

If you’ll use a Logic App for this; Add a Parse JSON action, use the Body of the Get Bearer Token HTTP Action as an input to the Parse JSON Action, then use the below as the Schema:

{
"properties": {
"access_token": {
"type": "string"
},
"expires_in": {
"type": "integer"
},
"ext_expires_in": {
"type": "integer"
},
"token_type": {
"type": "string"
}
},
"type": "object"
}

Finally, add another HTTP Action (or call this in Postman or similar) to call the Revoke API. In the Header add “Authorization”key with a value of “Bearer” followed by a space then add the bearer token from the output of the Parse JSON Action.

If you want to use CURL:

Request the Token Use the OAuth 2.0 client credentials flow to get the token:

curl -X POST \

-H "Content-Type: application/x-www-form-urlencoded" \

-d "client_id=[CLIENT_ID_OF_APP_REG]" \

-d "scope= https://management.azure.com/.default" \

-d "client_secret=[CLIENT_SECRET_FROM_APP_REG]" \

-d "grant_type=client_credentials" \

https://login.microsoftonline.com/[TENANT_ID]/oauth2/v2.0/token

The access_token in the response is your Bearer token.

Call the Revoke API

curl -X POST "https://management.azure.com/subscriptions/[SUBSCRIPTION_ID]/resourceGroups/[RESOURCE_GROUP]/providers/Microsoft.Web/connections/[NAME_OF_CONNECTION]/revokeConnectionKeys?api-version=2018-07-01-preview" \

-H "Authorization: Bearer <ACCESS_TOKEN>" \

-H "Content-Type: application/json" \

-d '{"key":"value"}'

If you face the below error, you will need to grant Contributor Role to the App Registration on the Resource Group that contains the API Connection. (If you want “Least privilege” skip to below )

{ "error": {
"code": "AuthorizationFailed", "message": "The client '[App_reg_client_id]' with object id '[App_reg_object_id]' does not have authorization to perform action 'Microsoft.Web/connections/revokeConnectionKeys/action' over scope '/subscriptions/[subscription_id]/resourceGroups/[resource_group_id]/providers/Microsoft.Web/connections/[connection_name]' or the scope is invalid. If access was recently granted, please refresh your credentials."
} }

For “Least privilege” solution, create a Custom RBAC Role with the below Roles, and assign it to the App Registration Object ID same as above:

{
"actions": [
"Microsoft.Web/connections/read",
"Microsoft.Web/connections/write",
"Microsoft.Web/connections/delete",
"Microsoft.Web/connections/revokeConnectionKeys/action"
] }

Introducing Skills in Azure API Center

anishta — Thu, 26 Mar 2026 21:31:02 GMT

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

Reliable blob processing using Azure Logic Apps: Recommended architecture

SwathiK — Mon, 23 Mar 2026 10:53:35 GMT

Understanding the Limitations of In-App Blob Triggers

The Logic App Blob - In-App trigger https://learn.microsoft.com/en-us/azure/logic-apps/connectors/built-in/reference/azureblob/ is built upon the same architecture as the Azure Function App Blob trigger and therefore inherits similar features and limitations. Notably, the in-app blob trigger uses polling as its core mechanism to detect changes in blob containers Polling and latency.

Key behaviors and limitations include:

Polling-Based Detection: The trigger polls the associated container rather than subscribing to events. This hybrid mechanism combines periodic container scans with Azure Storage analytics log inspection.
Batch Scanning: Blobs are scanned in batches of up to 10,000 per interval, using a continuation token to track progress.
Best-Effort Logging: The system relies on Azure Storage logs, which are generated on a best-effort basis. These logs are not guaranteed to capture all blob events.
Event Loss Risk: Under specific conditions — such as high blob throughput, delayed log generation, or log retention settings — some blob creation events may be missed.
Latency and Missed Triggers: Due to the asynchronous and non-deterministic nature of polling and logging, there may be latency in triggering workflows, and in some cases, triggers may not fire at all.

Given these limitations, relying solely on the in-app blob trigger may not be suitable for mission-critical scenarios that require guaranteed blob processing.

Recommended Alternative Approach: Queue-Based Reliable Triggering

To ensure reliable and scalable blob processing without missing any events, we recommend an alternative architecture that introduces explicit event signaling via Azure Storage Queues. This approach provides greater reliability and control, especially in high-throughput or mission-critical scenarios. For more info on this pattern please refer Claim-Check pattern - Azure Architecture Center | Microsoft Learn

In this approach, the Logic App uses a Storage Queue trigger, and the source system must send a queue message whenever a blob is uploaded.

The source system should implement the following steps:
- File path or blob name
- Filename
- Additional context (for example, customer ID or upload timestamp)

Blob Upload
Upload the file to an Azure Blob Storage container as usual.
Queue Message Creation (Source responsibility)
Immediately after the blob upload completes, the source system constructs a queue message containing relevant blob metadata, such as:
Send Message to Azure Storage Queue
The source system sends the constructed metadata message to a pre‑configured Azure Storage Queue.
This queue message acts as the explicit trigger for downstream processing.

Trigger Logic App via Queue Message
The Logic App is configured with a Storage Queue trigger and is triggered only when a new message arrives in the queue.
Process Blob via Metadata
Upon receiving the queue message, the Logic App:

Parses the blob metadata (for example, file path and filename)
Uses the “Get blob content” action (or equivalent) to retrieve and process the actual blob content from Azure Blob Storage

Benefits of This Approach

Guaranteed Triggering: The Logic App is reliably triggered by a queue message, ensuring no blob is missed.
Decoupled Workflow: This architecture decouples blob creation from processing logic, enabling better scalability and fault isolation.
Resilience and Retry Support: Azure Storage Queues provide built-in retry capabilities, message visibility timeouts, and dead-lettering to handle transient failures gracefully.
Better Monitoring and Control: You can monitor the queue depth, message age, and processing status to track workflow health and throughput.

Alternative Approach: Event Grid Integration

Another reliable method for handling blob events is using Event Grid with Single Tenant Logic App workflow endpoints.

Using Single Tenant Logic App Workflow Endpoint as Event Grid Subscription method allows you to handle events from either system or custom Event Grid topics. However, Event Grid topics won't be able to deliver events on private endpoints. Hence, if you have Logic App enabled with Private Endpoint, you wouldn't be able to use the workflow endpoints as Event Grid subscriptions

In this approach, blob processing is triggered by events. Here, Azure Blob Storage acts as the event publisher, and Event Grid delivers blob lifecycle events to the Logic App endpoint, which then processes the blob.

Steps to Implement Event Grid Integration:

Create Event Grid Subscription
Configure an Event Grid subscription on the Azure Storage account or specific blob container to listen for blob events
Configure Logic App Endpoint
Configure the Logic App Standard workflow endpoint (HTTP or Event Grid trigger) as the event subscriber.
The endpoint must be publicly reachable, or an intermediate component must be used if private networking is required.
Handle Subscription Handshake (Logic App responsibility)
For Single‑Tenant Logic Apps, implement explicit Event Grid subscription validation (handshake) to confirm that the Logic App endpoint accepts events from Event Grid.
- When an Event Grid subscription is created, Event Grid sends a SubscriptionValidationEvent to the subscriber endpoint.
- The Logic App must:
  1. Detect the Microsoft.EventGrid.SubscriptionValidationEvent
  2. Extract the validation Code from the request payload
  3. Return an HTTP 200 OK response
    For detailed implementation guidance and example, see: Using Single‑Tenant Logic App Workflow Endpoint as Event Grid Subscription
Trigger Logic App via Events
Once the subscription is active, Event Grid automatically pushes blob events to the Logic App endpoint whenever a blob is created, updated.
Process Blob Based on Event Data
Upon receiving the event payload, the Logic App:
1. Parses event data (container name, blob name, blob URL, event type)
2. Retrieves the blob using actions such as “Read blob content”
3. Processes the blob according to business logic

Benefits of Event Grid Integration

Event-Driven Architecture: Provides real-time event handling, reducing latency compared to polling mechanisms.
Scalability: Event Grid can handle many events efficiently.
Flexibility: Supports various event sources and custom topics.

Note: If you have Logic App enabled with Private Endpoint, refer to how to trigger Azure Function from Event Grid over virtual network for alternative configurations

Implementing / Migrating the BizTalk Server Aggregator Pattern to Azure Logic Apps Standard

reynaldom — Tue, 03 Mar 2026 16:08:08 GMT

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.

Figure 1: BizTalk Server Aggregator Orchestration (Aggregate.odx) correlates messages by DestinationPartnerURI, loops to accumulate them, and sends the aggregated interchange.

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.

Figure 4: Detail of "When messages are available in a queue" for triggering the Logic App Workflow when messages are available in a queue.

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)

Figure 5: Detail of "Get CorrelationId" using coalesce for avoiding issues if correlationId message property is null or empty.
Decodes flat file content with zero refactoring using the XSD schema (equivalent to BizTalk's Flat File Disassembler pipeline component)

Figures 6 and 7: Detail of "Decode Flat File" action using the same Invoice.xsd schema from BizTalk Server SDK Sample. This action Decodes or encodes as needed.

Groups messages into a dictionary keyed by CorrelationId (equivalent to BizTalk's loop + message assignment pattern)

Figure 8: Detail of "Update CorrelationGroups" action where the correalation from messages are grouped.

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.

Figure 9: Detail of the "Build Result Object" action which composes the resulted aggregated message.

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.

Figure 10: Details of the "Response" action and its body.

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.
1. 1. 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
    1. In the templates gallery, use the search box and type “Aggregate” or “Aggregator”.
    2. Optionally, filter by:
      o Connectors: Select Azure Service Bus
      
      o Categories: All
    3. 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

Logic Apps Aviators Newsletter - March 2026

WSilveira — Mon, 02 Mar 2026 16:00:00 GMT

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

Lilan Sameera - Senior Consulltant @ Adaptiv

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.

New Azure API management service limits

Sreekanth_Thirthala — Wed, 04 Mar 2026 07:14:10 GMT

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¹

¹ 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

How to Access a Shared OneDrive Folder in Azure Logic Apps

Arpit_MSFT — Tue, 10 Mar 2026 06:39:31 GMT

What is the problem?

A common enterprise automation scenario involves copying files from a OneDrive folder shared by a colleague into another storage service such as SharePoint or Azure Blob Storage using Azure Logic Apps.

However, when you configure the OneDrive for Business – “List files in folder” action in a Logic App, you quickly run into a limitation:

The folder picker only shows:
- Root directory
- Subfolders of the authenticated user’s OneDrive
Shared folders do not appear at all, even though you can access them in the OneDrive UI

This makes it seem like Logic Apps cannot work with shared OneDrive folders—but that’s not entirely true.

Logic app's "List files in folder" action from OneDrive for business connector showing list of folders while when clicked on the file picker icon

Why this happens

The OneDrive for Business connector is user‑context scoped. It only enumerates folders that belong to the signed-in user’s drive and does not automatically surface folders that are shared with the user.

Even though shared folders are visible under “Shared with me” in the OneDrive UI, they:

Live in a different drive
Have a different driveId
Require explicit identification before Logic Apps can access them

How to access a shared OneDrive folder

There are two supported ways to access a shared OneDrive directory from Logic Apps.

Option 1: Use Microsoft Graph APIs (Delegated permissions)

You can invoke Microsoft Graph APIs directly using:

HTTP with Microsoft Entra ID (preauthorized)
Delegated permissions on behalf of the signed‑in user

This requires:

Admin consent or delegated consent workflows
Additional Entra ID configuration

📘 Reference: HTTP with Microsoft Entra ID (preauthorized) - Connectors | Microsoft Learn

While powerful, this approach adds setup complexity.

Option 2: Use Graph Explorer to configure the OneDrive connector

Instead of calling Graph from Logic Apps directly, you can:

Use Graph Explorer to discover the shared folder metadata
Manually configure the OneDrive action using that metadata

Step-by-step: Using Graph Explorer to access a shared folder

Scenario

A colleague has shared a OneDrive folder named “Test” with me, and I need to process files inside it using a Logic App.

Step 1: List shared folders using Microsoft Graph

In Graph Explorer, run the following request:

GET https://graph.microsoft.com/v1.0/users/{OneDrive shared folder owner username}/drive/root/children

📘Reference: List the contents of a folder - Microsoft Graph v1.0 | Microsoft Learn

✅This returns all root-level folders visible to the signed-in user, including folders shared with you.

From the response, locate the shared folder. You only need two values:

parentReference.driveId
id (folder ID)

Graph explorer snippet showing the request sent to the API to list the files & folders shared by a specific user on the root drive

Step 2: Configure Logic App “List files in folder” action

In your Logic App:

Add OneDrive for Business → List files in folder
Do not use the folder picker
Manually enter the folder value using this format: {driveId}.{folderId}

Once saved, the action successfully lists files from the shared OneDrive folder.

Step 3: Build the rest of your workflow

After the folder is resolved correctly:

You can loop through files
Copy them to SharePoint
Upload them to Azure Blob Storage
Apply filters, conditions, or transformations

All standard OneDrive actions now work as expected.

Troubleshooting: When Graph Explorer doesn’t help

If you’re unable to find the driveId or folderId via Graph Explorer, there’s a reliable fallback.

Use browser network tracing

Open the shared folder in OneDrive (web)
Open Browser Developer Tools → Network
Look for requests like:Browser network trace snippet on how to fetch the required driveID & folderId
In the response payload, extract:
- CurrentFolderUniqueId → folder ID
- drives/{driveId} from the CurrentFolderSpItemUrl

This method is very effective when Graph results are incomplete or filtered.

Stop Writing Plumbing! Use the New Logic Apps MCP Server Wizard

KentWeareMSFT — Wed, 25 Feb 2026 14:19:26 GMT

As part of our continued investment in making Logic Apps a first‑class platform for providing AI agents with connectivity, we’ve introduced the new Logic Apps MCP server configuration experience—a guided, in‑portal workflow that lets you turn any existing Standard logic app into a fully functional MCP server. With just a few clicks, you can configure authentication, generate API keys, create or manage MCP servers, and convert workflows into discoverable MCP tools that agents can call securely and reliably. This experience consolidates everything you need: setup, tooling, and management into one intuitive surface so developers can focus on building meaningful agentic capabilities instead of wiring up protocol plumbing.

This new experience builds upon our previous investments with API Center and the Microsoft Foundry tools catalog that introduced the ability to dynamically build MCP servers through a publishing wizard experience that leveraged Azure Logic Apps connectors. The investments made with API Center and Microsoft Foundry enabled the underlying platform components that make Logic Apps workflows accessible over the MCP protocol as MCP tools. What we have subsequently invested in is the ability to enable any existing Logic Apps Standard instance as an MCP server.

Core Capabilities

From an existing Logic Apps Standard instance, you will now discover a new section in our table of contents called Agents. Within this section, you will find an entry point called MCP servers. If you click on this link, our configuration experience will load. This experience will provide you with the option to create an MCP server using existing workflows or by creating new workflows.

Create new workflows

Using this option, allows us to dynamically build MCP tools using the Logic Apps managed connectors, much like we provide in API Center and Microsoft Foundry.

You will start by providing:

MCP Server Name
MCP Server Description

Once this information has been provided, we can select a connector that we would like to use in our MCP server like the Salesforce connector.

With our connector selected, we can choose one or more actions. For each action that is selected, a corresponding workflow will be created that enables that connector to be called. For our use case, we will select Create record, Update record and Get Opportunity records from Salesforce.

To connect to Salesforce, we need a connection so we will create that now

If we scroll down, we will discover that we have some actions that require configuration including Create record and Update record. The reason for this is due to the design of the Salesforce connector and its support for may different Salesforce object types. Salesforce has many object types and delegating this decision to a model will result in a lot of unpredictable behavior. We can increase the consistency of our MCP server by making it more specific.

To improve our predictability, we will target a specific object type of Contacts. With this selected, we will also be able to choose which fields we want our model to populate. For any fields that we want to hardcode, we can specify a provided by value to be set to User.

It is also a good practice to update the Description of our action to ensure we have something meaningful so that our model can achieve higher accuracy when trying to call it.

To complete our process, click the Register button. Once this is clicked, the related workflows will be automatically get created for us. These underlying workflows will have Request trigger schemas provided and configuration that will wire-up these inputs into our action.

Once the registration process is complete, we will see a notification in the upper fight corner indicating that our tools (workflows) have been saved.

We will now see our MCP Server created with the corresponding workflow tools. From this experience, there are multiple functions that we can access from this screen including:

Editing MCP Server Name and Description
Adding/removing workflows for this MCP server
Copy the MCP Server URL
Delete MCP Server

o The underlying workflows will remain, even if the MCP Server is deleted.

If we want to explore one of our workflow tools, we can click on the link and we will be navigated to the underlying workflow. If we want to make changes to this workflow, we are able to do so, including adding additional connectors (managed or built-in), business logic, custom code etc.

As we explore this workflow we will discover that we have a trigger schema that is included and we have our Salesforce action mapped. This was all completed by the wizard experience that we just went through. We can now secure and test our MCP server, as discussed later in this article.

Use existing workflows

You may already have workflows built that you want to expose as MCP tools. With this requirement in mind, we can support these use cases by selecting: Use existing workflows option.

Once again, we will provide an MCP server Name and Description. With these values provided, we can select one or more existing workflow(s) to be included in this MCP Server.

In order for a workflow to be eligible for selection it must satisfy the following conditions:

HTTP Trigger
HTTP Response Action

You have a lot of creative licensing for whatever actions you want to include between these actions. This can include calling APIs, custom code, built-in connectors and additional business logic.

Note: Using this approach also allows you to create a workflow with your own naming conventions in place and support for advanced scenarios.

I have built the following workflow which includes my trigger, ServiceNow action and a response. To optimize our model reliably calling my MCP Server, I have:

Added a relevant description for my trigger. This will communicate to the model what this workflow (tool) is able to provide.
Within my trigger, provided a JSON schema and included description fields that communicate to the model what these data properties provide.

Once we have provided a Name and Description, we can now select our workflow(s) and click Create button.

We now have two MCP servers that are hosted in this Logic App. Each MCP server will have a unique URL, but will share the same security scheme.

Authentication

There are two authentication schemes that are available for MCP servers:

API Key-based
OAuth

Note: It is important to know that these authentication schemes apply to the entire Logic App and not the individual MCP Servers/tools.

API key-based authentication

When we select Key-based from our method dropdown, we have the ability to generate keys by clicking on the Generate key button. From there, select a Duration and an Access Key, followed by clicking on the Generate button.

An API key will be presented for which you can copy this value.

Note: When you navigate away from this page, you will not be able to see this value again, so store it in a safe place. However, you can generate additional API keys. Prior API keys will continue to be valid until their expiration date is no longer valid or the access keys are regenerated. Regenerating access keys will be available in a future release, but are available via an API call.

OAuth Authentication

Here we are going to take advantage of EasyAuth authentication for Azure Logic Apps. We will start by clicking on the Manage authentication link.

From there we will click on the Add identity provider button.

Select Microsoft as the identity provider, followed by clicking the Add button.

We will now need an App Registration, so in a separate tab navigate to App registrations in the Azure Portal.

Start by providing a Name and select the desired account types.

Click on Expose an API

Add a Scope and provide relevant data

Navigate to the Overview page and then copy the values for:

Application (client) ID
Directory (tenant) ID
Application ID URI

Back in our Logic Apps, Add an identity provider and provide the following information from our App Registration:

Application (client) ID
Issuer URL https://login.microsoftonline.com/<Your_Tenant_ID>/v2.0
Allowed token audiences (Application ID URI) api://<your_value>/

In the Additional checks section, enable the following:

Allow requests from any application
Allow requests from any identity
Use default restrictions based on issuer

For the App Server authentication settings, enable unauthenticated access.

Note: These settings can be modified to address your organization’s specific needs.

Click Add to complete the configuration

Testing

You are now ready to test your MCP server from your favorite agent platform including VS Code, Copilot Studio, Microsoft Foundry or Azure Logic Apps. If you are using an API key, you will be asked to create an authentication header. In this case you will want to use: X-API-KEY and then provide your key value.

Known issue: We have seen some situations that when using OAuth, the Easy Auth settings need to be re-applied to address an authentication error from occurring. Issuing the following command from a Cloud shell should address the problem and allow you to authenticate using Easy Auth.

az webapp auth microsoft update --name "<LogicAppName>" --resource-group "<Your_ResourceGroup>" --client-id "<Your_Client_ID>" --issuer "https://login.microsoftonline.com/<tenant>/v2.0"

Video content

Want to see this content in video format? Check out the following video.

Logic Apps Agentic Workflows with SAP - Part 2: AI Agents

Emmanuel_Abram_Profeta — Mon, 23 Feb 2026 07:15:00 GMT

Part 2 focuses on the AI-shaped portion of the destination workflows: how the Logic Apps Agent is configured, how it pulls business rules from SharePoint, and how its outputs are converted into concrete workflow artifacts. In Destination workflow #1, the agent produces three structured outputs—an HTML validation summary, a CSV list of InvalidOrderIds, and an Invalid CSV payload—which drive (1) a verification email, (2) an optional RFC call to persist failed rows as IDocs, and (3) a filtered dataset used for the separate analysis step that returns only analysis (or errors) back to SAP. In Destination workflow #2, the same approach is applied to inbound IDocs: the workflow reconstructs CSV from the custom segment, runs AI validation against the same SharePoint rules, and safely appends results to an append blob using a lease-based write pattern for concurrency.

1. Introduction

In Part 1, the goal was to make the integration deterministic: stable payload shapes, stable response shapes, and predictable error propagation across SAP and Logic Apps. Concretely, Part 1 established:

how SAP reaches Logic Apps (Gateway/Program ID plumbing)
the RFC contracts (IT_CSV, response envelope, RETURN/MESSAGE, EXCEPTIONMSG)
how the source workflow interprets RFC responses (success vs error)
how invalid rows can be persisted into SAP as custom IDocs (Z_CREATE_ONLINEORDER_IDOC)
and how the second destination workflow receives those IDocs asynchronously

With that foundation in place, Part 2 narrows in on the part that is not just plumbing: the agent loop, the tool boundaries, and the output schemas that make AI results usable inside a workflow rather than “generated text you still need to interpret.”

The diagram below highlights the portion of the destination workflow where AI is doing real work. The red-circled section is the validation agent loop (rules in, structured validation outputs out), which then fans out into operational actions like email notification, optional IDoc persistence, and filtering for the analysis step.

Figure: AI boundary in the destination workflow.

What matters here is the shape of the agent outputs and how they are consumed by the rest of the workflow. The agent is not treated as a black box; it is forced to emit typed, workflow-friendly artifacts (summary + invalid IDs + filtered CSV). Those artifacts are then used deterministically: invalid rows are reported (and optionally persisted as IDocs), while valid rows flow into the analysis stage and ultimately back to SAP.

What this post covers

In this post, I focus on five practical topics:

Agent loop design in Logic Apps: tools, message design, and output schemas that make the agent’s results deterministic enough to automate.
External rule retrieval: pulling validation rules from SharePoint and applying them consistently to incoming payloads.
Structured validation outputs → workflow actions: producing InvalidOrderIds and a filtered CSV payload that directly drive notifications and SAP remediation.
Two-model pattern: a specialized model for validation (agent) and a separate model call for analysis, with a clean handoff between the two.
Output shaping for consumption: converting AI output into HTML for email and into the SAP response envelope (analysis/errors only).

(Everything else—SAP plumbing, RFC wiring, and response/exception patterns—was covered in Part 1 and is assumed here.)

Next, I’ll break down the agent loop itself—the tool sequence, the required output fields, and the exact points where the workflow turns AI output into variables, emails, and SAP actions.

Huge thanks to KentWeareMSFT for helping me understand agent loops and design the validation agent structure. And thanks to everyone in 🤖 Agent Loop Demos 🤖 | Microsoft Community Hub for making such great material available.

Note: For the full set of assets used here, see the companion GitHub repository (workflows, schemas, SAP ABAP code, and sample files).

2. Validation Agent Loop

In this solution, the Data Validation Agent runs inside the destination workflow after the inbound SAP payload has been normalized into a single CSV string. The agent is invoked as a single Logic Apps Agent action, configured with an Azure OpenAI deployment and a short set of instructions. Its inputs are deliberately simple at this stage:

the CSV payload (the dataset to validate), and
the ValidationRules reference (where the rule document lives), shown in the instructions as a parameter token (ValidationRules is a logic app parameter).

The figure below shows the validation agent configuration used in the destination workflow. The top half is the Agent action configuration (model + instructions), and the bottom half shows the toolset that the agent is allowed to use. The key design choice is that the agent is not “free-form chat”: it’s constrained by a small number of tools and a workflow-friendly output contract.

Figure: Data Validation Agent configuration in Logic Apps.

What matters most in this configuration is the separation between instructions and tools. The instructions tell the agent what to do (“follow business process steps 1–3”), while the tools define how the agent can interact with external systems and workflow state. This keeps the agent modular: you can change rules in SharePoint or refine summarization expectations without rewriting the overall SAP integration mechanics.

Purpose

This agent’s job is narrowly scoped: validate the CSV payload from SAP against externally stored business rules and produce outputs that the workflow can use deterministically. In other words, it turns “validation as reasoning” into workflow artifacts (summary + invalid IDs + invalid payload), instead of leaving validation as unstructured prose.

In Azure Logic Apps terms, this is an agent loop: an iterative process where an LLM follows instructions and selects from available tools to complete a multi-step task. Logic Apps agent workflows explicitly support this “agent chooses tools to complete tasks” model (see Agent Workflows Concepts).

Tools

In Logic Apps agent workflows, a tool is a named sequence that contains one or more actions the agent can invoke to accomplish part of its task (see Agent Workflows Concepts).

In the screenshot, the agent is configured with three tools, explicitly labeled Get validation rules, Get CSV payload, Summarize CSV payload review. These tool names match the business process in the “Instructions for agent” box (steps 1–3). The next sections of the post go deeper into what each tool does internally; at this level, the important point is simply that the agent is constrained to a small, explicit toolset.

Agent execution

The screenshot shows the agent configured with:

AI model: gpt-5-3 (gpt-5)
A connection line: “Connected to … (Azure OpenAI)”
Instructions for agent that define the agent’s role and a 3-step business process:
1. Get validation rules (via the ValidationRules reference)
2. Get CSV payload
3. Summarize the CSV payload review, using the validation document

This pattern is intentional:

The instructions provide the agent’s “operating procedure” in plain language.
The tools give the agent: controlled ways to fetch the rule document, access the CSV input, and return structured results.
Because the workflow consumes the agent’s outputs downstream, the instruction text is effectively part of your workflow contract (it must remain stable enough that later actions can trust the output shape).

Note: If a reader wants to recreate this pattern, the fastest path is:

Start with the official overview of agent workflows (Workflows with AI Agents and Models - Azure Logic Apps).
Follow a hands-on walkthrough for building an agent workflow and connecting it to an Azure OpenAI deployment (Logic Apps Labs is a good step-by-step reference). [azure.github.io]
Use the Azure OpenAI connector reference to understand authentication options and operations available in Logic Apps Standard (see Built-in OpenAI Connector)
If you’re using Foundry for resource management, review how Foundry connections are created and used, especially when multiple resources/tools are involved (see How to connect to AI foundry).

2.1 Tool 1: Get validation rules

The first tool in the validation agent loop is Get validation rules. Its job is to load the business validation rules that will be applied to the incoming CSV payload from SAP. I keep these rules outside the workflow (in a document) so they can be updated without redeploying the Logic App. In this example, the rules are stored in SharePoint, and the tool simply retrieves the document content at runtime.

Get validation rules is implemented as a single action called Get validation document. In the designer, you can see it:

uses a SharePoint Online connection (SharePoint icon and connector action)
calls GetFileContentByPath (shown by the “File Path” input)
reads the rule file from the configured Site Address
uses the workflow parameter token ValidationRules for the File Path (so the exact rule file location is configurable per environment)

The output of this tool is the raw rule document content, which the Data Validation Agent uses in the next steps to validate the CSV payload.

Figure: Tool #1 — Get validation rules retrieves the validation document from SharePoint

The bottom half of the figure shows an excerpt of the rules document. The format is simple and intentionally human-editable: each rule is expressed as FieldName: condition. For example, the visible rules include:

PaymentMethod: value must exist
PaymentMethod: value cannot be “Cash”
OrderStatus: value must be different from “Cancelled”
CouponCode: value must have at least 1 character
OrderID: value must be unique in the CSV array
A scope note: “Do not validate the Date field.”

These rules are the “source of truth” for validation. The workflow does not hardcode them into expressions; instead, it retrieves them from SharePoint and passes them into the agent loop so the validation logic remains configurable and auditable (you can always point to the exact rule document used for a given run).

A small but intentional rule in the document is “Do not validate the Date field.” That line is there for a practical reason: in an early version of the source workflow, the date column was being corrupted during CSV generation. The validation agent still tried to validate dates (even though date validation wasn’t part of the original intent), and the result was predictable: every row failed validation, leaving nothing to analyze. The upstream issue is fixed now, but I kept this rule in the demo to illustrate an important point: validation is only useful when it’s aligned with the data contract you can actually guarantee at that point in the pipeline.

Note: The rules shown here assume the CSV includes a header row (field names in the first line) so the agent can interpret each column by name. If you want the agent to be schema‑agnostic, you can extend the rules with an explicit column mapping, for example:

Column 1: Order ID
Column 2: Date
Column 3: Customer ID
…

This makes the contract explicit even when headers are missing or unreliable.

With the rules loaded, the next tool provides the second input the agent needs: the CSV payload that will be validated against this document.

2.2 Tool 2: Get CSV payload

The second tool in the validation agent loop is Get CSV payload. Its purpose is to make the dataset-to-validate explicit: it defines exactly what the agent should treat as “the CSV payload,” rather than relying on implicit workflow context. In this workflow, the CSV is already constructed earlier (as Create_CSV_payload), and this tool acts as the narrow bridge between that prepared string and the agent’s validation step.

Figure: Tool #2 (“Get CSV payload”) defines a single agent parameter and binds it to the workflow’s generated CSV.

The figure shows two important pieces:

- The tool parameter contract (“Agent Parameters”)
On the right, the tool defines an agent parameter named CSV Payload with type String, and the description (highlighted in yellow) makes the intent explicit: “The CSV payload received from SAP and that we validate based on the validation rules.”

This parameter is the tool’s interface: it documents what the agent is supposed to provide/consume when using this tool, and it anchors the rest of the validation process to a single, well-defined input. Tools in Logic Apps agent workflows exist specifically to constrain and structure what an agent can do and what data it operates on (see Agent Workflows Concepts).

- Why there is an explicit Compose action (“CSV payload”)
In the lower-right “Code view,” the tool’s internal action is shown as a standard Compose:

{ "type": "Compose", "inputs": "@outputs('Create_CSV_payload')" }

This is intentional. Even though the CSV already exists in the workflow, the tool still needs a concrete action that produces the value it returns to the agent. The Compose step:

- pins the tool output to a single source of truth (Create_CSV_payload), and
- creates a stable boundary: “this is the exact CSV string the agent validates,” independent of other workflow state.

Put simply: the Compose action isn’t there because Logic Apps can’t access the CSV—it’s there to make the agent/tool interface explicit, repeatable, and easy to troubleshoot.

What “tool parameters” are (in practical terms)

In Logic Apps agent workflows, a tool is a named sequence of one or more actions that the agent can invoke while executing its instructions.
A tool parameter is the tool’s input/output contract exposed to the agent. In this screenshot, that contract is defined under Agent Parameters, where you specify:

Name: CSV Payload
Type: String
Description: “The CSV payload received from SAP…”

This matters because it clarifies (for both the model and the human reader) what the tool represents and what data it is responsible for supplying.

With Tool #1 providing the rules document and Tool #2 providing the CSV dataset, Tool #3 is where the agent produces workflow-ready outputs (summary + invalid IDs + filtered payload) that the downstream steps can act on.

2.3 Tool 3: Summarize CSV payload review

The third tool, Summarize CSV payload review, is where the agent stops being “an evaluator” and becomes a producer of workflow-ready outputs. It does most of the heavy lifting so let's go into the details.

Instead of returning one blob of prose, the tool defines three explicit agent parameters—each with a specific format and purpose—so the workflow can reliably consume the results in downstream actions. In Logic Apps agent workflows, tools are explicitly defined tasks the agent can invoke, and each tool can be structured around actions and schemas that keep the loop predictable (see Agent Workflows Concepts).

Figure: Tool #3 (“Summarize CSV payload review”) defines three structured agent outputs

Description is not just documentation—it’s the contract the model is expected to satisfy, and it strongly shapes what the agent considers “relevant” when generating outputs. The parameters are:

Validation summary (String)

Goal: a human-readable summary that can be dropped straight into email.

In the screenshot, the description is very explicit about shape and content:

“expected format is an HTML table”
“create a list of all orderids that have failed”
“create a CSV document… only for the orderid values that failed… each row on a separate line”
“include title row only in the email body”

This parameter is designed for presentation: it’s the thing you want humans to read first.

InvalidOrderIds (String, CSV format)

Goal: a machine-friendly list of identifiers the workflow can use deterministically.

The key part of the description (highlighted in the image) is:

“The format is CSV.”

That single sentence is doing a lot of work: it tells the model to emit a comma-separated list, which you then convert into an array in the workflow using split(...).

Invalid CSV payload (String, one row per line)

Goal: the failed rows extracted from the original dataset, in a form that downstream steps can reuse.

The description constrains the output tightly:

“original CSV rows… for the orderid values that failed validation”
“each row must be on a separate line”
“keep the title row only for the email body and remove it otherwise”

This parameter is designed for automation: it becomes input to remediation steps (like transforming rows to XML and creating IDocs), not just a report.

What “agent parameters” do here (and why they matter)

A useful way to think about agent parameters is: they are the “typed return values” of a tool. Tools in agent workflows exist to structure work into bounded tasks the agent can perform, and a schema/parameter contract makes the results consumable by the rest of the workflow (see Agent Workflows Concepts).

In this tool, the parameters serve two purposes at once:

They guide the agent toward salient outputs.
The descriptions explicitly name what matters: “failed orderids,” “HTML table,” “CSV format,” “one row per line,” “header row rules.” That phrasing makes it much harder for the model to “wander” into irrelevant commentary.
They align with how the workflow will parse and use the results.
By stating “InvalidOrderIds is CSV,” you make it trivially parseable (split), and by stating “Invalid CSV payload is one row per line,” you make it easy to feed into later transformations.

Why the wording works (and what wording tends to work best)

What’s interesting about the parameter descriptions is that they combine three kinds of constraints:

Output format constraints (make parsing deterministic)

- “expected format is an HTML table”
- “The format is CSV.”
- “each row must be on a separate line”

These format cues help the agent decide what to emit and help you avoid brittle parsing later.

Output selection constraints (force relevance)

- “only for the orderid values that failed validation”
- “Create a list of all orderids that have failed”

This tells the agent what to keep and what to ignore.

Output operational constraints (tie outputs to downstream actions)

- “Include title row only in the email body”
- “remove it otherwise”

This explicitly anticipates downstream usage (email vs remediation), which is exactly the kind of detail models often miss unless you state it.

Rule of thumb: wording works best when it describes

what to produce,
in what format,
with what filtering rules, and
why the workflow needs it.

How these parameters tie directly to the downstream actions

The next picture makes the design intent very clear: each parameter is immediately “bound” to a normal workflow value via Compose actions and then used by later steps. This is the pattern we want: agent output → Compose → (optional) normalization → reused by deterministic workflow actions. It’s the opposite of “read the model output and hope.”

Figure: Tying up parameters to downstream actions.

This is the reusable pattern:

Decide the minimal set of outputs the workflow needs.
Specify formats that are easy to parse.
Write parameter descriptions that encode both selection and formatting constraints.
Immediately bind outputs to workflow variables via Compose/SetVariable actions.

The main takeaway from this tool is that the agent is being forced into a structured contract: three outputs with explicit formats and clear intent. That contract is what makes the rest of the workflow deterministic—Compose actions can safely read @agentParameters(...), the workflow can safely split(...) the invalid IDs, and downstream actions can treat the “invalid payload” as real data rather than narrative.

I'll show later how this same “parameter-first” design scales to other agent tools.

2.4 Turning agent outputs into a verification email

Once the agent has produced structured outputs (Validation summary, InvalidOrderIds, and Invalid CSV payload), the next goal is to make those outputs operational: humans need a quick summary of what failed, and the workflow needs machine‑friendly values it can reuse downstream.

The design here is intentionally straightforward: the workflow converts each agent parameter into a first‑class workflow output (via Compose actions and one variable assignment), then binds those values directly into the Office 365 email body. The result is an email that is both readable and actionable—without anyone needing to open run history.

The figure below shows how the outputs of Summarize CSV payload review are mapped into the verification email. On the left, the tool produces three values via subsequent actions (Summary, Invalid order ids, and Invalid CSV payload), and the workflow also normalizes the invalid IDs into an array (Save invalid order ids). On the right, the Send verification summary action composes the email body using those same values as dynamic content tokens.

Figure: Mapping agent outputs to the verification email

The important point is that the email is not constructed by “re-prompting” or “re-summarizing.” It is assembled from already-structured outputs. This mapping is intentionally direct: each piece of the email corresponds to one explicit output from the agent tool. The workflow doesn’t interpret or transform the summary beyond basic formatting—its job is to preserve the agent’s structured outputs and present them consistently. The only normalization step happens for InvalidOrderIds, where the workflow also converts the CSV string into an array (ArrayOfInvalidOrderIDs) for later filtering and analysis steps.

The next figure shows a sample verification email produced by this pipeline. It illustrates the three-part structure: an HTML validation summary table, the raw invalid order ID list, and the extracted invalid CSV rows:

Figure: Sample verification email — validation summary table + invalid order IDs + invalid CSV rows.

The extracted artifacts InvalidOrderIds and Invalid CSV payload are used in the downstream actions that persist failed rows as IDocs for later processing, which were presented in Part 1. I will get back to this later to talk about reusing the validation agent. Next however I will go over the data analysis part of the AI integration.

3. Analysis Phase: from validated dataset to HTML output

After the validation agent loop finishes, the workflow enters a second AI phase: analysis. The validation phase is deliberately about correctness (what to exclude and why). The analysis phase is about insight, and it runs on the remaining dataset after invalid rows are filtered out.

At a high level, this phase has three steps:

Call Azure OpenAI to analyze the CSV dataset while explicitly excluding invalid OrderIDs.
Extract the model’s text output from the OpenAI response object.
Convert the model’s markdown output into HTML so it renders cleanly in email (and in the SAP response envelope).

3.1 OpenAI component: the “Analyze data” call

The figure below shows the Analyze data action that drives the analysis phase. This action is executed after the Data Validation Agent completes, and it uses three messages: a system instruction that defines the task, the CSV dataset as input, and a second user message that enumerates the OrderIDs to exclude (the invalid IDs produced by validation).

Figure: Azure OpenAI analysis call.

The analysis call is structured as:

system: define the task and constraints
user: provide the dataset
user: provide exclusions derived from validation

system: Analyze dataset; provide trends/predictions; exclude specified orderids. user: <csv payload=""> user: Excluded orderids: <comma-separated ids="" invalid=""></comma-separated></csv>

Two design choices are doing most of the work here:

The model is given the dataset and the exclusions separately. This avoids ambiguity: the dataset is one message, and the “do not include these OrderIDs” constraint is another.
The exclusion list is derived from validation output, not re-discovered during analysis. The analysis step doesn’t re-validate; it consumes the validation phase’s results and focuses purely on trends/predictions.

3.2 Processing the response

The next figure shows how the workflow turns the Azure OpenAI response into a single string that can be reused for email and for the SAP response. The workflow does three things in sequence: it parses the response JSON, extracts the model’s text content, and then passes that text into an HTML formatter.

Figure: Processing the OpenAI response.

This is the only part of the OpenAI response you need to understand for this workflow:

Analyze_data response └─ choices[] (array) └─ [0] (object) └─ message (object) └─ content (string) <-- analysis text

Everything else in the OpenAI response (filters, indexes, metadata) is useful for auditing but not required to build the final user-facing output.

3.3 Crafting the output to HTML

The model’s output is plain text and often includes lightweight markdown structures (headings, lists, separators). To make the analysis readable in email (and safe to embed in the SAP response envelope), the workflow converts the markdown into HTML. The script was generated with copilot. Source code snippet may be found in Part 1. The next figure shows what the formatted analysis looks like when rendered. Not the explicit reference to the excluded OrderIDs and summary of the remaining dataset before listing trend observations.

Figure: Example analysis output after formatting.

4. Closing the loop: persisting invalid rows as IDocs

In Part 1, I introduced an optional remediation branch: when validation finds bad rows, the workflow can persist them into SAP as custom IDocs for later handling. In Part 2, after unpacking the agent loop, I want to reconnect those pieces and show the “end of the story”: the destination workflow creates IDocs for invalid data, and a second destination workflow receives those IDocs and produces a consolidated audit trail in Blob Storage.

This final section is intentionally pragmatic. It shows:

where the IDoc creation call happens,
how the created IDocs arrive downstream,
and how to safely handle many concurrent workflow instances writing to the same storage artifact (one instance per IDoc).

4.1 From “verification summary” to “Create all IDocs”

The figure below shows the tail end of the verification summary flow. Once the agent produces the structured validation outputs, the workflow first emails the human-readable summary, then converts the invalid CSV rows into an SAP-friendly XML shape, and finally calls the RFC that creates IDocs from those rows.

Figure: End of the validation/remediation branch.

This is deliberately a “handoff point.” After this step, the invalid rows are no longer just text in an email—they become durable SAP artifacts (IDocs) that can be routed, retried, and processed independently of the original workflow run.

`4.2 Z_CREATE_ONLINEORDER_IDOC` and the downstream receiver

The next figure is the same overview from Part 1. I’m reusing it here because it captures the full loop: the workflow calls Z_CREATE_ONLINEORDER_IDOC, SAP converts the invalid rows into custom IDocs, and Destination workflow #2 receives those IDocs asynchronously (one workflow run per IDoc).

Figure 2: Invalid rows persisted as custom IDocs.

This pattern is intentionally modular:

Destination workflow #1 decides which rows are invalid and optionally persists them.
SAP encapsulates the IDoc creation mechanics behind a stable RFC (Z_CREATE_ONLINEORDER_IDOC).
Destination workflow #2 processes each incoming IDoc independently, which matches how IDoc-driven integrations typically behave in production.

4.3 Two phases in Destination workflow #2: AI agent + Blob Storage logging

In the receiver workflow, there are two distinct phases:

AI agent phase (per-IDoc): reconstruct a CSV view from the incoming IDoc payload and (optionally) run the same validation logic.
Blob storage phase (shared output): append a normalized “verification line” into a shared blob in a concurrency-safe way.

It’s worth calling out: in this demo, the IDocs being received were created from already-validated outputs upstream, so you could argue the second validation is redundant. I keep it anyway for two reasons:

it demonstrates that the agent tooling is reusable with minimal changes, and
in a general integration, Destination workflow #2 may receive IDocs from multiple sources, not only from this pipeline—so “validate on receipt” can still be valuable.

4.3.1 AI agent phase

The figure below shows the validation agent used in Destination workflow #2. The key difference from the earlier agent loop is the output format: instead of producing an HTML summary + invalid lists, this agent writes a single “audit line” that includes the IDoc correlation key (DOCNUM) along with the order ID and the failed rules.

Figure: Destination workflow #2 agent configuration.

The reusable part here is the tooling structure: rules still come from the same validation document, the dataset is still supplied as CSV, and the summarization tool outputs a structured value the workflow can consume deterministically. The only meaningful change is “what shape do I want the output to take,” which is exactly what the agent parameter descriptions control.

The next figure zooms in on the summarization tool parameter in Destination workflow #2. Instead of three outputs, this tool uses a single parameter (VerificationInfo) whose description forces a consistent line format anchored on DOCNUM.

Figure 4: VerificationInfo parameter.

This is the same design principle as Tool #3 in the first destination workflow: describe the output as a contract, not as a vague request. The parameter description tells the agent exactly what must be present (DOCNUM + OrderId + failed rules) and therefore makes it straightforward to append the output to a shared log without additional parsing.

Interesting snippets

Extracting DOCNUM from the IDoc control record and carry it through the run:

xpath(xml(triggerBody()?['content']), 'string(/*[local-name()="Receive"] /*[local-name()="idocData"] /*[local-name()="EDI_DC40"] /*[local-name()="DOCNUM"])')

4.3.2 Blob Storage phase

Destination workflow #2 runs one instance per inbound IDoc. That means multiple runs can execute at the same time, all trying to write to the same “ValidationErrorsYYYYMMDD.txt” artifact. The figure below shows the resulting appended output: one line per IDoc, each line beginning with DOCNUM, which becomes the stable correlation key.

Destination workflow #2 runs one instance per inbound IDoc, so multiple instances can attempt to write to the same daily “validation errors” append blob at the same time. The figure below shows the concurrency control pattern I used to make those writes safe: a short lease acquisition loop that retries until it owns the blob lease, then appends the verification line(s), and finally releases the lease.

Figure: Concurrency-safe append pattern.

Reading the diagram top‑to‑bottom, the workflow uses a simple lease → append → release pattern to make concurrent writes safe. Each instance waits briefly (Delay), attempts to acquire a blob lease (Acquire validation errors blob lease), and loops until it succeeds (Set status code → Until lease is acquired). Once a lease is obtained, the workflow stores the lease ID (Save lease id), appends its verification output under that lease (Append verification results), and then releases the lease (Release the lease) so the next workflow instance can write.

Implementation note: the complete configuration for this concurrency pattern (including the HTTP actions, headers, retries, and loop conditions) is included in the attached artifacts, in the workflow JSON for Destination workflow #2.

5. Concluding remarks

Part 2 zoomed in on the AI boundary inside the destination workflows and made it concrete: what the agent sees, what it is allowed to do, what it must return, and how those outputs drive deterministic workflow actions.

The practical outcomes of Part 2 are:

A tool-driven validation agent that produces workflow artifacts, not prose.
The validation loop is constrained by tools and parameter schemas so its outputs are immediately consumable: an email-friendly validation summary, a machine-friendly InvalidOrderIds list, and an invalid-row payload that can be remediated.
A clean separation between validation and analysis.
Validation decides what not to trust (invalid IDs / rows) and analysis focuses on what is interesting in the remaining dataset. The analysis prompt makes the exclusion rule explicit by passing the dataset and excluded IDs as separate messages.
A repeatable response-processing pipeline.
You extract the model’s text from a stable response path (choices[0].message.content), then shape it into HTML once (markdown → HTML) so the same formatted output can be reused for email and the SAP response envelope.
A “reuse with minimal changes” pattern across workflows.
Destination workflow #2 shows the same agent principles applied to IDoc reception, but with a different output contract optimized for logging: DOCNUM + OrderId + FailedRules. This demonstrates that the real reusable asset is the tool + parameter contract design.

Putting It All Together

We have a full integration story where SAP, Logic Apps, AI, and IDocs are connected with explicit contracts and predictable behavior:

Part 1 established the deterministic integration foundation.
- SAP ↔ Logic Apps connectivity (gateway/program wiring)
- RFC payload/response contracts (IT_CSV, response envelope, error semantics)
- predictable exception propagation back into SAP
- an optional remediation branch that persists invalid rows as IDocs via a custom RFC (Z_CREATE_ONLINEORDER_IDOC)
- and the end-to-end response handling pattern in the caller workflow.
Part 2 layered AI on top without destabilizing the contracts.
- Agent loop + tools for rule retrieval and validation
- output schemas that convert “reasoning” into workflow artifacts
- a separate analysis step that consumes validated data and produces formatted results
- and an asynchronous IDoc receiver that logs outcomes safely under concurrency.

The reason it works as a two-part series is that the two layers evolve at different speeds:

The integration layer (Part 1) should change slowly. It defines interoperability: payload shapes, RFC names, error contracts, and IDoc interfaces.
The AI layer (Part 2) is expected to iterate. Prompts, rule documents, output formatting, and agent tool design will evolve as you tune behavior and edge cases.

References

Logic Apps Agentic Workflows with SAP - Part 1: Infrastructure

🤖 Agent Loop Demos 🤖 | Microsoft Community Hub

Agent Workflows Concepts

Workflows with AI Agents and Models - Azure Logic Apps

Built-in OpenAI Connector

How to connect to AI foundry

Create Autonomous AI Agent Workflows - Azure Logic Apps

Handling Errors in SAP BAPI Transactions

Access SAP from workflows

Create common SAP workflows

Generate Schemas for SAP Artifacts via Workflows

Exception Handling | ABAP Keyword Documentation

Handling and Propagating Exceptions - ABAP Keyword Documentation

SAP .NET Connector 3.1 Overview

SAP .NET Connector 3.1 Programming Guide

Connect to Azure AI services from Workflows

All supporting content for this post may be found in the companion GitHub repository.

Logic Apps Agentic Workflows with SAP - Part 1: Infrastructure

Emmanuel_Abram_Profeta — Mon, 23 Feb 2026 07:12:09 GMT

When you integrate Azure Logic Apps with SAP, the “hello world” part is usually easy. The part that bites you later is data quality. In SAP-heavy flows, validation isn’t a nice-to-have — it’s what makes the downstream results meaningful. If invalid data slips through, it can get expensive fast: you may create incorrect business documents, trigger follow-up processes, and end up in a cleanup path that’s harder (and more manual) than building validation upfront. And in “all-or-nothing” transactional patterns, things get even more interesting: one bad record can force a rollback strategy, compensating actions, or a whole replay/reconciliation story you didn’t want to own. See for instance Handling Errors in SAP BAPI Transactions | Microsoft Community Hub to get an idea of the complexity in a BizTalk context.

That’s the motivation for this post: a practical starter pattern that you can adapt to many data shapes and domains for validating data in a Logic Apps + SAP integration.

Note: For the full set of assets used here, see the companion GitHub repository (workflows, schemas, SAP ABAP code, and sample files).

1. Introduction

Scenario overview

The scenario is intentionally simple, but it mirrors what shows up in real systems:

A Logic App workflow sends CSV documents to an SAP endpoint.
SAP forwards the payload to a second Logic App workflow that performs:
- rule-based validation (based on pre-defined rules)
- analysis/enrichment (market trends, predictions, recommendations)
The workflow either:
- returns validated results (or validation errors) to the initiating workflow, or
- persists outputs for later use

For illustration, I’m using fictitious retail data. The content is made up, but the mechanics are generic: the same approach works for orders, inventory, pricing, master data feeds, or any “file in → decision out” integration. You’ll see sample inputs and outputs below to keep the transformations concrete.

Figure: Input CSV data and corresponding rules

Figure: Outputs - Analysis of trends and predictions, validation summary and IDoc information.

What this post covers

This walkthrough focuses on the integration building blocks that tend to matter in production:

Calling SAP RFCs from Logic App workflows, and invoking Logic App workflows from SAP function modules
Using the Logic Apps SAP built-in trigger
Receiving and processing IDocs
Returning responses and exceptions back to SAP in a structured, actionable way
Data manipulation patterns in Logic Apps, including:
- parsing and formatting
- inline scripts
- XPath (where it fits, and where it becomes painful).

Overall Implementation

A high-level view of the implementation is shown below. The source workflow handles end-to-end ingestion—file intake, transformation, SAP integration, error handling, and notifications—using Azure Logic Apps. The destination workflows focus on validation and downstream processing, including AI-assisted analysis and reporting, with robust exception handling across multiple technologies. I’ll cover the AI portion in a follow-up post.

Figure: Overall implementation.

Note on AI-assisted development

Most of the workflow “glue” in this post—XPath, JavaScript snippets, and Logic Apps expressions—was built with help from Copilot and the AI assistant in the designer (see Get AI-assisted help for Standard workflows - Azure Logic Apps | Microsoft Learn). In my experience, this is exactly where AI assistance pays off: generating correct scaffolding quickly, then iterating based on runtime behavior.

I’ve also included SAP ABAP snippets for the SAP-side counterpart. You don’t need advanced ABAP knowledge to follow along; the snippets are deliberately narrow and integration-focused. I include them because it’s hard to design robust integrations if you only understand one side of the contract. When you understand how SAP expects to receive data, how it signals errors, and where transactional boundaries actually are, you end up with cleaner workflows and fewer surprises.

2. Source Workflow

This workflow is a small, end‑to‑end “sender” pipeline: it reads a CSV file from Azure Blob Storage, converts the rows into the SAP table‑of‑lines XML shape expected by an RFC, calls Z_GET_ORDERS_ANALYSIS via the SAP connector, then extracts analysis or error details from the RFC response and emails a single consolidated result. The name of the data file is a parameter of the logic app.

At a high level:

Input: an HTTP request (used to kick off the run) + a blob name.
Processing: CSV → array of rows → XML (…) → RFC call
Output: one email containing either:
- the analysis (success path), or
- a composed error summary (failure path).

The diagram below summarizes the sender pipeline: HTTP trigger → Blob CSV (header included) → rows → SAP RFC → parse response → email.

Figure: End‑to‑end sender pipeline

Two design choices are doing most of the work here. First, the workflow keeps the CSV transport contract stable by sending the file as a verbatim list of lines—including the header—wrapped into … elements under IT_CSV. Second, it treats the RFC response as the source of truth: EXCEPTIONMSG and RETURN/MESSAGE drive a single Has errors gate, which determines whether the email contains the analysis or a consolidated failure summary.

Step-by-step description

Phase 0 — Trigger

Trigger — When_an_HTTP_request_is_received
The workflow is invoked via an HTTP request trigger (stateful workflow).

Phase 1 — Load and split the CSV

Read file — Read_CSV_orders_from_blob
Reads the CSV from container onlinestoreorders using the blob name from @parameters('DataFileName'). The name of the data file is a parameter of the logic app.
Split into rows — Extract_rows
Splits the blob content on \r\n, producing an array of CSV lines.

Design note: Keeping the header row is useful when downstream validation or analysis wants column names, and it avoids implicit assumptions in the sender workflow.

Phase 2 — Shape the RFC payload

Convert CSV rows to SAP XML — Transform_CSV_to_XML
Uses JavaScript to wrap each CSV row (including the header line) into the SAP line structure and XML‑escape special characters. The output is an XML fragment representing a table of ZTY_CSV_LINE rows.

Phase 3 — Call SAP and extract response fields

Call the RFC — [RFC]_Z_GET_ORDERS_ANALYSIS
Invokes Z_GET_ORDERS_ANALYSIS with an XML body containing … built from the transformed rows. Note that a <DEST>...</DEST> element can also be provided to override the default value in the function module definition.
Extract error/status — Save_EXCEPTION_message and Save_RETURN_message
Uses XPath to pull:
- EXCEPTIONMSG from the RFC response, and
- the structured RETURN/MESSAGE field.

Phase 4 — Decide success vs failure and notify

Initialize output buffer — Initialize_email_body
Creates the EmailBody variable used by both success and failure cases.
Gate — Has_errors
Determines whether to treat the run as failed based on:
- EXCEPTIONMSG being different from "ok", or
- RETURN/MESSAGE being non‑empty.
Send result — Send_an_email_(V2)
Emails either:
- the extracted ANALYSIS (success), or
- a concatenated error summary including RETURN/MESSAGE plus message details (MESSAGE_V1…MESSAGE_V4) and EXCEPTIONMSG.

Note: Because the header row is included in IT_CSV, the SAP-side parsing/validation treats the first line as column titles (or simply ignores it). The sender workflow stays “schema-agnostic” by design.

Useful snippets

Snippet 1 — Split the CSV into rows

split(string(body('Read_CSV_orders_from_blob')?['content']), '\r\n') Tip: If your CSV has a header row you don’t want to send to SAP, switch back to: @skip(split(string(body('Read_CSV_orders_from_blob')?['content']), '\r\n'), 1)

Snippet 2 — JavaScript transform: “rows → SAP table‑of‑lines XML”

Snippet 3 — XPath extraction of response fields (namespace-robust)

EXCEPTIONMSG: @xpath(body('[RFC]_Call_Z_GET_ORDERS_ANALYSIS')?['content'], 'string( /*[local-name()="Z_GET_ORDERS_ANALYSISResponse"] /*[local-name()="EXCEPTIONMSG"])') RETURN/MESSAGE: @xpath(body('[RFC]_Call_Z_GET_ORDERS_ANALYSIS')?['content'], 'string( /*[local-name()="Z_GET_ORDERS_ANALYSISResponse"] /*[local-name()="RETURN"] /*[local-name()="MESSAGE"])')

Snippet 4 — Failure email body composition

concat( 'Error message: ', outputs('Save_RETURN_message'), ', details: ', xpath(body('[RFC]_Call_Z_GET_ORDERS_ANALYSIS')?['content'], 'string(//*[local-name()=\"MESSAGE_V1\"])'), xpath(body('[RFC]_Call_Z_GET_ORDERS_ANALYSIS')?['content'], 'string(//*[local-name()=\"MESSAGE_V2\"])'), xpath(body('[RFC]_Call_Z_GET_ORDERS_ANALYSIS')?['content'], 'string(//*[local-name()=\"MESSAGE_V3\"])'), xpath(body('[RFC]_Call_Z_GET_ORDERS_ANALYSIS')?['content'], 'string(//*[local-name()=\"MESSAGE_V4\"])'), '; ', 'Exception message: ', outputs('Save_EXCEPTION_message'), '.')

3. SAP Support

To make the SAP/Logic Apps boundary simple, I model the incoming CSV as a table of “raw lines” on the SAP side. The function module Z_GET_ORDERS_ANALYSIS exposes a single table parameter, IT_CSV, typed using a custom line structure.

Figure: IT_CSV is a table of CSV lines (ZTY_CSV_LINE), with a single LINE field (CHAR2048).

IT_CSV uses the custom structure ZTY_CSV_LINE, which contains a single component LINE (CHAR2048). This keeps the SAP interface stable: the workflow can send CSV lines without SAP having to know the schema up front, and the parsing/validation logic can evolve independently.

The diagram below shows the plumbing that connects SAP to Azure Logic Apps in two common patterns: SAP sending IDocs to a workflow and SAP calling a remote-enabled endpoint via an RFC destination. I’m showing all three pieces together—the ABAP call site, the SM59 RFC destination, and the Logic Apps SAP built-in trigger—because most “it doesn’t work” problems come down to a small set of mismatched configuration values rather than workflow logic.

Figure: SAP-to-Logic Apps wiring for inbound IDocs and RFC callbacks

The key takeaway is that both patterns hinge on the same contract: Program ID plus the SAP Gateway host/service. In SAP, those live in SM59 (TCP/IP destination, registered server program). In Logic Apps, the SAP built-in trigger listens using the same Program ID and gateway settings, while the trigger configuration (for example, IDoc format and degree of parallelism) controls how messages are interpreted and processed. Once these values line up, the rest of the implementation becomes “normal workflow engineering”: validation, predictable error propagation, and response shaping.

Before diving into workflow internals, I make the SAP-side contract explicit. The function module interface below shows the integration boundary: CSV lines come in as IT_CSV, results come back as ANALYSIS, and status/error information is surfaced both as a human-readable EXCEPTIONMSG and as a structured RETURN (BAPIRET2). I also use a dedicated exception (SENDEXCEPTIONTOSAPSERVER) to signal workflow-raised failures cleanly.

Contract (what goes over RFC):

Input: IT_CSV (CSV lines)
Outputs: ANALYSIS (analysis payload), EXCEPTIONMSG (human-readable status)
Return structure: RETURN (BAPIRET2) for structured SAP-style success/error
Custom exception: SENDEXCEPTIONTOSAPSERVER for workflow-raised failures

Here is the ABAP wrapper that calls the remote implementation and normalizes the result.

FUNCTION z_get_orders_analysis. *"---------------------------------------------------------------------- *" This module acts as a caller wrapper. *" Important: the remote execution is determined by DESTINATION. *" Even though the function name is the same, this is not recursion: *" the call runs in the remote RFC server registered under DESTINATION "DEST". *"---------------------------------------------------------------------- *" Contract: *" TABLES it_csv "CSV lines *" IMPORTING analysis "Result payload *" EXPORTING exceptionmsg "Human-readable status / error *" CHANGING return "BAPIRET2 return structure *" EXCEPTIONS sendexceptiontosapserver *"---------------------------------------------------------------------- CALL FUNCTION 'Z_GET_ORDERS_ANALYSIS' DESTINATION dest IMPORTING analysis = analysis TABLES it_csv = it_csv CHANGING return = return EXCEPTIONS sendexceptiontosapserver = 1 system_failure = 2 MESSAGE exceptionmsg communication_failure = 3 MESSAGE exceptionmsg OTHERS = 4. CASE sy-subrc. WHEN 0. exceptionmsg = 'ok'. "Optional: normalize success into RETURN for callers that ignore EXCEPTIONMSG IF return-type IS INITIAL. return-type = 'S'. return-message = 'OK'. ENDIF. WHEN 1. exceptionmsg = |Exception from workflow: SENDEXCEPTIONTOSAPSERVER { sy-msgv1 }{ sy-msgv2 }{ sy-msgv3 }{ sy-msgv4 }|. return-type = 'E'. return-message = exceptionmsg. WHEN 2 OR 3. "system_failure / communication_failure usually already populate exceptionmsg IF exceptionmsg IS INITIAL. exceptionmsg = |RFC system/communication failure.|. ENDIF. return-type = 'E'. return-message = exceptionmsg. WHEN OTHERS. exceptionmsg = |Error in workflow: { sy-msgv1 }{ sy-msgv2 }{ sy-msgv3 }{ sy-msgv4 }|. return-type = 'E'. return-message = exceptionmsg. ENDCASE. ENDFUNCTION.

The wrapper is intentionally small: it forwards the payload to the remote implementation via the RFC destination and then normalizes the outcome into a predictable shape. The point isn’t fancy ABAP — it’s reliability. With a stable contract (IT_CSV, ANALYSIS, RETURN, EXCEPTIONMSG) the Logic Apps side can evolve independently while SAP callers still get consistent success/error semantics.

Important: in 'CALL FUNCTION 'Z_GET_ORDERS_ANALYSIS' DESTINATION dest' the name of the called function should be the same as the name of the ABAP wrapper function module, the reason being that the SAP built-in trigger in the logic app uses the function module signature as the contract (i.e. metadata).

Also note that in the provided companion artifacts, a default value was assigned to 'dest' in the function module definition. But it can also be specified in the request (DEST element).

Figure: ABAP interface and error propagation for Z_GET_ORDERS_ANALYSIS.

To sum up, the integration is intentionally shaped around three outputs: the raw input table (IT_CSV), a standardized SAP return structure (RETURN / BAPIRET2), and a readable status string (EXCEPTIONMSG). The custom exception (SENDEXCEPTIONTOSAPSERVER) gives me a clean way to surface workflow failures back into SAP without burying them inside connector-specific error payloads. This is depicted in the figure below.

4. Destination Workflow

The diagram below shows the destination workflow at a high level. I designed it as a staged pipeline: guard early, normalize input, validate, and then split the workload into two paths—operational handling of invalid records (notifications and optional IDoc remediation) and analysis of the validated dataset. Importantly, the SAP response is intentionally narrow: SAP receives only the final analysis (or a structured error), while validation details are delivered out-of-band via email.

How to read this diagram

Guardrail: Validate requested action ensures the workflow only handles the expected request.
Normalize: Create CSV payload converts the inbound content into a consistent CSV representation.
Validate: Data Validation Agent identifies invalid records (and produces a summary).
Operational handling (invalid data): invalid rows are reported by email and may optionally be turned into IDocs (right-hand block).
Analyze (valid data): Analyze data runs only on the validated dataset (invalid IDs excluded).
Outputs: users receive Email analysis, while SAP receives only the analysis (or a structured error) via Respond to SAP server.

Figure: Destination workflow with staged validation, optional IDoc remediation, and an SAP response .

Reading the workflow top-to-bottom, the main design choice is separation of concerns. Validation is used to filter and operationalize bad records (notify humans, optionally create IDocs), while the SAP-facing response stays clean and predictable: SAP receives the final analysis for the validated dataset, or an error if the run can’t complete. This keeps the SAP contract stable even as validation rules and reporting details evolve.

Step‑by‑step walkthrough

Phase 0 — Entry and routing

Trigger — When a message is received
The workflow starts when an inbound SAP message is delivered to the Logic Apps SAP built‑in trigger.
Guardrail — Validate requested action (2 cases)
The workflow immediately checks whether the inbound request is the operation it expects (for example, the function/action name equals Z_GET_ORDERS_ANALYSIS).
- If the action does not match: the workflow sends an exception back to SAP describing the unexpected action and terminates early (fail fast).
- If the action matches: processing continues.

Phase 1 — Normalize input into a workflow‑friendly payload

Prepare input — Create CSV payload
The workflow extracts CSV lines from the inbound (XML) SAP payload and normalizes them into a consistent CSV text payload that downstream steps can process reliably.
Initialize validation state — Initialize array of invalid order ids
The workflow creates an empty array variable to capture order IDs that fail validation. This becomes the “validation output channel” used later for reporting, filtering, and optional remediation.

Phase 2 — Validate the dataset (AI agent loop)

Validate — Data Validation Agent (3 cases)
This stage performs rule‑based validation using an agent pattern (backed by Azure OpenAI). Conceptually, it does three things (as shown in the diagram’s expanded block):
- Get validation rules: retrieves business rules from a SharePoint‑hosted validation document.
  The location of the validation rules file is a parameter of the logic app.
- Get CSV payload: loads the normalized CSV created earlier.
- Summarize CSV payload review: evaluates the CSV against the rules and produces structured validation outputs.
Outputs produced by validation:
- A list of invalid order IDs
- The corresponding invalid CSV rows
- A human‑readable validation summary

Note: The detailed AI prompt/agent mechanics are covered in Part 2. In Part 1, the focus is on the integration flow and how data moves.

Phase 3 — Operational handling of invalid records (email + optional SAP remediation)

After validation, the workflow treats invalid records as an operational concern: they are reported to humans and can optionally be routed into an SAP remediation path. This is shown in the right‑hand “Create IDocs” block.

Notify — Send verification summary
The workflow sends an email report (Office 365) to configured recipients containing:
- the validation summary
- the invalid order IDs
- the invalid CSV payload (or the subset of invalid rows)
Transform — Transform CSV to XML
The workflow converts the invalid CSV lines into an XML format that is suitable for SAP processing.
Optional remediation — [RFC] Create all IDocs (conditional)
If the workflow parameter (for example, CreateIDocs) is enabled, the workflow calls an SAP RFC (e.g., Z_CREATE_ONLINEORDER_IDOC) to create IDocs from the transformed invalid data.

Why this matters: Validation results are made visible (email) and optionally actionable (IDocs), without polluting the primary analysis response that SAP receives.

Phase 4 — Analyze only the validated dataset (AI analysis)

The workflow runs AI analysis on the validated dataset, explicitly excluding invalid order IDs discovered during the validation phase. The analysis prompt instructs the model to produce outputs such as trends, predictions, and recommendations.

Note: The AI analysis prompt design and output shaping are covered in Part 2.

Phase 5 — Post‑process the AI response and publish outputs

Package results — Process analysis results (Scope)
The workflow converts the AI response into a format suitable for email and for SAP consumption:
- Parse the OpenAI JSON response
- Extract the analysis content
- Convert markdown → HTML using custom JavaScript formatting
Outputs
- Email analysis: sends the formatted analysis to recipients.
- Respond to SAP server: returns only the analysis (and errors) to SAP.

Key design choice: SAP receives a clean, stable contract—analysis on success, structured error on failure. Validation details are handled out‑of‑band via email (and optionally via IDoc creation).

Note: the analysis email sent by the destination workflow is there for testing purposes, to verify that the html content remains the same as it is sent back to the source workflow.

Useful snippets

Snippet 1 - Join each CSV line in the XML to make a CSV table:

join( xpath( xml(triggerBody()?['content']), '/*[local-name()=\"Z_GET_ORDERS_ANALYSIS\"] /*[local-name()=\"IT_CSV\"] /*[local-name()=\"ZTY_CSV_LINE\"] /*[local-name()=\"LINE\"]/text()' ), '\r\n')

Note: For the sake of simplicity, XPath is used here and throughout all places where XML is parsed. In the general case however, the Parse XML with schema action is the better and recommended way to strictly enforce the data contract between senders and receivers. More information about Parse XML with schema is provided in Appendix 1.

Snippet 2 - Format markdown to html (simplified):

5. Exception Handling

To illustrate exception handling, we supposed that multiple workflows may listen to the same program id (by design or unexpectedly) and could therefore receive messages that were meant for others. So the first thing that happens is validate that the function name is as expected. It is shown below.

In this section I show three practical ways to surface workflow failures back to SAP using the Logic Apps action “Send exception to SAP server”, and the corresponding ABAP patterns used to handle them. The core idea is the same in all three: Logic Apps raises an exception on the SAP side, SAP receives it as an RFC exception, and your ABAP wrapper converts that into something predictable (for example, a readable EXCEPTIONMSG, a populated RETURN, or both). The differences are in how much control you want over the exception identity and whether you want to leverage SAP message classes for consistent, localized messages.

5.1 Default exception

This first example shows the default behavior of Send exception to SAP server. When the action runs without a custom exception name configuration, the connector raises a pre-defined exception that can be handled explicitly in ABAP.

On the Logic Apps side, the action card “Send exception to SAP server” sends an Exception Error Message (for example, “Unexpected action in request: …”). On the ABAP side, the RFC call lists SENDEXCEPTIONTOSAPSERVER = 1 under EXCEPTIONS, and the code uses CASE sy-subrc to map that exception to a readable message.

Figure: Default exception

The key takeaway is that you get a reliable “out-of-the-box” exception path: ABAP can treat sy-subrc = 1 as the workflow‑raised failure and generate a consistent EXCEPTIONMSG. This is the simplest option and works well when you don’t need multiple exception names—just one clear “workflow failed” signal.

5.2 Message exception

If you want more control than the default, you can configure the action to raise a named exception declared in your ABAP function module interface. This makes it easier to route different failure types without parsing free-form text.

The picture shows Advanced parameters under the Logic Apps action, including “Exception Name” with helper text indicating it must match an exception declared in the ABAP function module definition.

Figure: Message exception

This option is useful when you want to distinguish workflow error categories (e.g., validation vs. routing vs. downstream failures) using exception identity, not just message text. The contract stays explicit: Logic Apps raises a named exception, and ABAP can branch on that name (or on sy-subrc mapping) with minimal ambiguity.

5.3 Message class exception

The third approach uses SAP’s built-in message class mechanism so that the exception raised by the workflow can map cleanly into SAP’s message catalog (T100). This is helpful when you want consistent formatting and localization aligned with standard SAP patterns.

On the Logic Apps side, the action shows advanced fields including Message Class, Message Number, and an Is ABAP Message toggle, with helper text stating the message class can come from message maintenance (SE91) or be custom. On the ABAP side, the code highlights an error-handling block that calls using sy-msgid, sy-msgno, and variables sy-msgv1…sy-msgv4, then stores the resulting text in EXCEPTIONMSG.

Figure: Message class exception

This pattern is ideal when you want workflow exceptions to look and behave like “native” SAP messages. Instead of hard-coding strings, you rely on the message catalog and let ABAP produce a consistent final message via FORMAT_MESSAGE. The result is easier to standardize across teams and environments—especially if you already manage message classes as part of your SAP development process.

Refer to Appendix 2 for further information on FORMAT_MESSAGE.

5.4 Choosing an exception strategy that SAP can act on

Across these examples, the goal is consistent: treat workflow failures as first‑class outcomes in SAP, not as connector noise buried in run history. The Logic Apps action Send exception to SAP server gives you three increasingly structured ways to do that, and the “right” choice depends on how much semantics you want SAP to understand.

Default exception (lowest ceremony): Use this when you just need a reliable “workflow failed” signal. The connector raises a pre-defined exception name (for example, SENDEXCEPTIONTOSAPSERVER), and ABAP can handle it with a simple EXCEPTIONS … = 1 mapping and a sy-subrc check. This is the fastest way to make failures visible and deterministic.
Named exception(s) (more routing control): Use this when you want SAP to distinguish failure types without parsing message text. By raising an exception name declared in the ABAP function module interface, you can branch cleanly in ABAP (or map to different return handling) and keep the contract explicit and maintainable.
Message class + number (most SAP-native): Use this when you want errors to look and behave like standard SAP messages—consistent wording, centralized maintenance, and better alignment with SAP operational practices. In this mode, ABAP can render the final localized string using FORMAT_MESSAGE and return it as EXCEPTIONMSG (and optionally BAPIRET2-MESSAGE), which makes the failure both human-friendly and SAP-friendly.

A practical rule of thumb: start with the default exception while you stabilize the integration, move to named exceptions when you need clearer routing semantics, and adopt message classes when you want SAP-native error governance (standardization, maintainability, and localization). Regardless of the option, the key is to end with a predictable SAP-side contract: a clear success path, and a failure path that produces a structured return and a readable message.

6. Response Handling

This section shows how the destination workflow returns either a successful analysis response or a workflow exception back to SAP, and how the source (caller) workflow interprets the RFC response structure to produce a single, human‑readable outcome (an email body). The key idea is to keep the SAP-facing contract stable: SAP always returns a Z_GET_ORDERS_ANALYSISResponse envelope, and the caller workflow decides between success and error using just two fields: EXCEPTIONMSG and RETURN/MESSAGE. To summarize the steps:

Destination workflow either:
- sends a normal response via Respond to SAP server, or
- raises an exception via Send exception to SAP server (with an error message).
SAP server exposes those outcomes through the RFC wrapper:
- sy-subrc = 0 → success (EXCEPTIONMSG = 'ok')
- sy-subrc = 1 → workflow exception (SENDEXCEPTIONTOSAPSERVER)
- sy-subrc = 2/3 → system/communication failures
Source workflow calls the RFC, extracts:
- EXCEPTIONMSG
- RETURN/MESSAGE and uses an Has errors gate to choose between a success email body (analysis) or a failure email body (error summary).

The figure below shows the full return path for results and failures. On the right, the destination workflow either responds normally (Respond to SAP server) or raises a workflow exception (Send exception to SAP server). SAP then maps that into the RFC outcome (sy-subrc and message fields). On the left, the source workflow parses the RFC response structure and populates a single EmailBody variable using two cases: failure (error details) or success (analysis text).

Figure: Response/exception flow

Two things make this pattern easy to operationalize. First, the caller workflow does not need to understand every SAP field—only EXCEPTIONMSG and RETURN/MESSAGE are required to decide success vs failure. Second, the failure path intentionally aggregates details (MESSAGE_V1…MESSAGE_V4 plus the exception text) into a single readable string so errors don’t get trapped in run history.

Callout: The caller workflow deliberately treats EXCEPTIONMSG != "ok" or RETURN/MESSAGE present as the single source of truth for failure, which keeps the decision logic stable even if the response schema grows.

Detailed description

Phase 1 — Destination workflow: choose “response” vs “exception”

Respond to SAP server returns the normal response payload back to SAP.
Send exception to SAP server raises a workflow failure with an Exception Error Message (the screenshot shows an example beginning with “Unexpected action in request:” and a token for Function Name).

Outcome: SAP receives either a normal response or a raised exception for the RFC call.

Phase 2 — SAP server: map workflow outcomes to RFC results

The SAP-side wrapper code shown in the figure calls:

CALL FUNCTION 'Z_GET_ORDERS_ANALYSIS' DESTINATION DEST ...
It declares exception mappings including:
- SENDEXCEPTIONTOSAPSERVER = 1
- system_failure = 2 MESSAGE EXCEPTIONMSG
- communication_failure = 3 MESSAGE EXCEPTIONMSG
- OTHERS = 4

Then it uses CASE sy-subrc. to normalize outcomes (the figure shows WHEN 0. setting EXCEPTIONMSG = 'ok'., and WHEN 1. building a readable message for the workflow exception).

Outcome: regardless of why it failed, SAP can provide a consistent set of fields back to the caller: a return structure and an exception/status message.

Phase 3 — Source workflow: parse response and build one “email body”

After the RFC action ([RFC] Call Z GET ORDERS ANALYSIS) the source workflow performs:

Save EXCEPTION message
Extracts EXCEPTIONMSG from the response XML using XPath.
Save RETURN message
Extracts RETURN/MESSAGE from the response XML using XPath.
Initialize email body
Creates EmailBody once, then sets it in exactly one of two cases.
Has errors (two cases)
The condition treats the run as “error” if either:
- EXCEPTIONMSG is not equal to "ok", or
- RETURN/MESSAGE is not empty.
Set email body (failure) / Set email body (success)
- Failure: builds a consolidated string containing RETURN/MESSAGE, message details (MESSAGE_V1..V4), and EXCEPTIONMSG.
- Success: sets EmailBody to the ANALYSIS field extracted from the response.

Outcome: the caller produces a single artifact (EmailBody) that is readable and actionable, without requiring anyone to inspect the raw RFC response.

Note: the email recipient is set as a logic app parameter.

7. Destination Workflow #2: Persisting failed rows as custom IDocs

In this section I zoom in on the optional “IDoc persistence” branch at the end of the destination workflow. After the workflow identifies invalid rows (via the Data Validation Agent) and emails a verification summary, it can optionally call a second SAP RFC to save the failed rows as IDocs for later processing.

This is mainly included to showcase another common SAP integration scenario—creating/handling IDocs—and to highlight that you can combine “AI-driven validation” with traditional enterprise workflows. The deeper motivation for invoking this as part of the agent tooling is covered in Part 2; here, the goal is to show the connector pattern and the custom RFC used to create IDocs from CSV input.

The figure below shows the destination workflow at two levels: a high-level overview at the top, and a zoomed view of the post-validation remediation steps at the bottom. The zoom starts from Data Validation Agent → Summarize CSV payload review and then expands the sequence that runs after Send verification summary: Transform CSV to XML followed by an SAP RFC call that creates IDocs from the failed data.

Figure: Zoomed remediation branch

The key point is that this branch is not the main “analysis response” path. It’s a practical remediation option: once invalid rows are identified and reported, the workflow can persist them into SAP using a dedicated RFC (Z_CREATE_ONLINEORDER_IDOC) and a simple IT_CSV payload. This keeps the end-to-end flow modular: analysis can remain focused on validated data, while failed records can be routed to SAP for follow-up processing on their own timeline.

Callout: This branch exists to showcase an IDoc-oriented connector scenario. The “why this is invoked from the agent tooling” context is covered in Part 2; here the focus is the mechanics of calling Z_CREATE_ONLINEORDER_IDOC with IT_CSV and receiving ET_RETURN / ET_DOCNUMS.

The screenshot shows an XML body with the RFC root element and an SAP namespace:

<z_create_onlineorder_idoc xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/"> <iv_direction>...</iv_direction> <iv_sndptr>...</iv_sndptr> <iv_sndprn>...</iv_sndprn> <iv_rcvptr>...</iv_rcvptr> <iv_rcvprn>...</iv_rcvprn> <it_csv> @{ ...Outputs... } </it_csv> <et_return></et_return> <et_docnums></et_docnums> </z_create_onlineorder_idoc>

What to notice:

the workflow passes invalid CSV rows in IT_CSV, and SAP returns a status table (ET_RETURN) and created document numbers (ET_DOCNUMS) for traceability.
The payload includes standard-looking control fields (IV_DIRECTION, IV_SNDPTR, IV_SNDPRN, IV_RCVPTR, IV_RCVPRN) and the actual failed-row payload as IT_CSV.
IT_CSV is populated via a Logic Apps expression (shown as @{ ...Outputs... } in the screenshot), which is the bridge between the prior transform step and the RFC call.
The response side indicates table-like outputs: ET_RETURN and ET_DOCNUMS.

7.1 From CSV to IDocs

I’ll cover the details of Destination workflow #2 in Part 2. In this post (Part 1), I focus on the contract and the end-to-end mechanics: what the RFC expects, what it returns, and how the created IDocs show up in the receiving workflow.

Before looking at the RFC itself, it helps to understand the payload we’re building inside the IDoc. The screenshot below shows the custom segment definition used by the custom IDoc type. This segment is intentionally shaped to mirror the columns of the CSV input so the mapping stays direct and easy to reason about.

Figure: Custom segment ZONLINEORDER000 (segment type ZONLINEORDER)

This segment definition is the contract anchor: it makes the CSV-to-IDoc mapping explicit and stable. Each CSV record becomes one segment instance with the same 14 business fields. That keeps the integration “boringly predictable,” which is exactly what you want when you’re persisting rejected records for later processing.

The figure below shows the full loop for persisting failed rows as IDocs. The source workflow calls the custom RFC and sends the invalid CSV rows as XML. SAP converts each row into the custom segment and creates outbound IDocs. Those outbound IDocs are then received by Destination workflow #2, which processes them asynchronously (one workflow instance per IDoc) and appends results into shared storage for reporting.

Figure: Persisting rejected rows as IDocs

This pattern deliberately separates concerns:

the first destination workflow identifies invalid rows and decides whether to persist them,
SAP encapsulates the mechanics of IDoc creation behind a stable RFC interface, and
a second destination workflow processes those IDocs asynchronously (one per IDoc), which is closer to how IDoc-driven integrations typically operate in production.

Destination workflow #2 is included here to show the end-to-end contract and the “receipt” side of the connector scenario:

Triggered by the SAP built-in trigger and checks FunctionName = IDOC_INBOUND_ASYNCHRONOUS
extracts DOCNUM from the IDoc control record (EDI_DC40/DOCNUM)
reconstructs a CSV payload from the IDoc data segment (the fields shown match the segment definition)
appends a “verification info” line to shared storage for reporting

The implementation details of that workflow (including why it is invoked from the agent tooling) are covered in Part 2.

`7.2 Z_CREATE_ONLINEORDER_IDOC` - Contract overview

The full source code for Z_CREATE_ONLINEORDER_IDOC is included in the supporting material. It’s too long to reproduce inline, so this post focuses on the contract—the part you need to call the RFC correctly and interpret its results.

A quick note on authorship: most of the implementation was generated with Copilot, with manual review and fixes to resolve build errors and align the behavior with the intended integration pattern. The contract is deliberately generic because the goal was to produce an RFC that’s reusable across more than one scenario, rather than tightly coupled to a single workflow.

At a high level, the RFC is designed to support:

Both inbound and outbound IDoc creation
It can either write IDocs to the SAP database (inbound-style persistence) or create/distribute IDocs outbound.
Multiple IDoc/message/segment combinations
IDoc type (IDOCTYP), message type (MESTYP), and segment type (SEGTP) are configurable so the same RFC can be reused.
Explicit partner/port routing control
Optional sender/receiver partner/port fields can be supplied when routing matters.
Traceability of created artifacts
The RFC returns created IDoc numbers so the caller can correlate “these failed rows” to “these IDocs.”

Contract:

Inputs (import parameters)

IV_DIRECTION (default: 'O') — 'I' for inbound write-to-db, 'O' for outbound distribute/dispatch
IV_IDOCTYP (default: ZONLINEORDERIDOC)
IV_MESTYP (default: ZONLINEORDER)
IV_SEGTP (default: ZONLINEORDER)
Optional partner/port routing fields: IV_SNDPRT, IV_SNDPRN, IV_RCVPRT, IV_RCVPRN, IV_RCVPOR

Tables

IT_CSV (structure ZTY_CSV_LINE) — each row is one CSV line (the “table-of-lines” pattern)
ET_RETURN (structure BAPIRET2) — success/warning/error messages (per-row and/or aggregate)
ET_DOCNUMS (type ZTY_DOCNUM_TT) — list of created IDoc numbers for correlation/traceability

Outputs

EV_DOCNUM — a convenience “primary / last created” DOCNUM value returned by the RFC

8. Concluding Remarks

Part 1 established a stable SAP ↔ Logic Apps integration baseline: CSV moves end‑to‑end using explicit contracts, and failures are surfaced predictably. The source workflow reads CSV from Blob, wraps rows into the IT_CSV table‑of‑lines payload, calls Z_GET_ORDERS_ANALYSIS, and builds one outcome using two fields from the RFC response: EXCEPTIONMSG and RETURN/MESSAGE. The destination workflow gates requests, validates input, and returns only analysis (or errors) back to SAP while handling invalid rows operationally (notification + optional persistence).

On the error path, we covered three concrete patterns to raise workflow failures back into SAP: the default connector exception (SENDEXCEPTIONTOSAPSERVER), named exceptions (explicit ABAP contract), and message‑class‑based errors (SAP‑native formatting via FORMAT_MESSAGE). On the remediation side, we added a realistic enterprise pattern: persist rejected rows as custom IDocs via Z_CREATE_ONLINEORDER_IDOC (IT_CSV in, ET_RETURN + ET_DOCNUMS out), using the custom segment ZONLINEORDER000 as the schema anchor and enabling downstream receipt in Destination workflow #2 (one run per IDoc, correlated via DOCNUM).

Part 2 is separate because it tackles a different problem: the AI layer. With contracts and error semantics now fixed, Part 2 can focus on the agent/tooling details that tend to iterate—rule retrieval, structured validation outputs, prompt constraints, token/history controls, and how the analysis output is generated and shaped—without muddying the transport story.

Appendix 1: Parse XML with schema

In this section I consider the CSV payload creation as an example, but parsing XML with schema applies in every place where we get an XML input to process, such as when receiving SAP responses, exceptions, or request/responses from other RFCs.

Strong contract

The Create_CSV_payload step in the shown implementation uses an xpath() + join() expression to extract LINE values from the incoming XML:

join( xpath( xml(triggerBody()?['content']), '/*[local-name()="Z_GET_ORDERS_ANALYSIS"] /*[local-name()="IT_CSV"] /*[local-name()="ZTY_CSV_LINE"] /*[local-name()="LINE"]/text()' ), '\r\n' )

That approach works, but it’s essentially a “weak contract”: it assumes the message shape stays stable and that your XPath continues to match. By contrast, the Parse XML with schema action turns the XML payload into structured data based on an XSD, which gives you a “strong contract” and enables downstream steps to bind to known fields instead of re-parsing XML strings.

The figure below compares two equivalent ways to build the CSV payload from the RFC input. On the left is the direct xpath() compose (labeled “weak contract”). On the right is the schema-based approach (labeled “strong contract”), where the workflow parses the request first and then builds the CSV payload by iterating over typed rows.

Figure: comparison Compose/XPath vs. Parse XML with schema.

What’s visible in the diagram is the key tradeoff:

XPath compose path (left): the workflow creates the CSV payload directly using join(xpath(...), '\r\n'), with the XPath written using local-name() selectors. This is fast to prototype, but the contract is implicit—your workflow “trusts” the XML shape and your XPath accuracy.
Parse XML with schema path (right): the workflow inserts a Parse XML with schema step (“Parse Z GET ORDERS ANALYSIS request”), initializes variables, loops For each CSV row, and Appends to CSV payload, then performs join(variables('CSVPayload'), '\r\n'). Here, the contract is explicit—your XSD defines what IT_CSV and LINE mean, and downstream steps bind to those fields rather than re-parsing XML.

A good rule of thumb is: XPath is great for lightweight extraction, while Parse XML with schema is better when you want contract enforcement and long-term maintainability, especially in enterprise integration / BizTalk migration scenarios where schemas are already part of the integration culture.

Implementation details

The next figure shows the concrete configuration for Parse XML with schema and how its outputs flow into the “For each CSV row” loop. This is the “strong contract” version of the earlier XPath compose.

Figure: Parse XML with schema - details.

This screenshot highlights three practical implementation details:

The Parse action is schema-backed.
In the Parameters pane, the action uses:
- Content: the incoming XML Response
- Schema source: LogicApp
- Schema name: Z_GET_ORDERS_ANALYSIS
  The code view snippet shows the same idea: type: "XmlParse" with content: "@triggerBody()?['content']" and schema: { source: "LogicApp", name: "Z_GET_ORDERS_ANALYSIS.xsd" }.
The parsed output becomes typed “dynamic content.”
The loop input is shown as “JSON Schema for element 'Z_GET_ORDERS_ANALYSIS: IT_CSV'”. This is the key benefit: you are no longer scraping strings—you are iterating over a structured collection that was produced by schema-based parsing.
The LINE extraction becomes trivial and readable.
The “Append to CSV payload” step appends @item()?['LINE'] to the CSVpayload variable (as shown in the code snippet). Then the final Create CSV payload becomes a simple join(variables('CSVPayload'), '\r\n'). This is exactly the kind of “workflow readability” benefit you get once XML parsing is schema-backed.

Schema generation

The Parse action requires XSD schemas, which can be stored in the Logic App (or via a linked Integration Account). The final figure shows a few practical ways to obtain and manage those XSDs:

Generate Schema (SAP connector): a “Generate Schema” action with Operation Type = RFC and an RFC Name field, which is a practical way to bootstrap schema artifacts when you already know the RFC you’re calling.
Run Diagnostics / Fetch RFC Metadata: a “Run Diagnostics” action showing Operation type = Fetch RFC Metadata and RFC Name, which is useful to confirm the shape of the RFC interface and reconcile it with your XSD/contract.

Figure: schema generation.

If you don’t want to rely solely on connector-side schema generation, there are also classic “developer tools” approaches:

Infer XSD from a sample XML using .NET’s XmlSchemaInference (good for quick starting points).
Generate XSD from an XML instance using xsd.exe (handy when you already have representative sample payloads) or by asking your favorite AI prompt.

When to choose XPath vs Parse XML with schema (practical guidance)

Generally speaking, choose XPath when…

You need a quick extraction and you’re comfortable maintaining a single XPath.
You don’t want to manage schema artifacts yet (early prototypes).

Choose Parse XML with schema when…

You want a stronger, explicit contract (XSD defines what the payload is).
You want the designer to expose structured outputs (“JSON Schema for element …”) so downstream steps are readable and less brittle.
You expect the message shape to evolve over time and prefer schema-driven changes over XPath surgery.

Appendix 2: Using FORMAT_MESSAGE to produce SAP‑native error text

When propagating failures from Logic Apps back into SAP (for example via Send exception to SAP server), I want the SAP side to produce a predictable, human‑readable message without forcing callers to parse connector‑specific payloads. ABAP’s FORMAT_MESSAGE is ideal for this because it converts SAP’s message context—message class, message number, and up to four variables—into the final message text that SAP would normally display, but without raising a UI message.

What FORMAT_MESSAGE does

FORMAT_MESSAGE formats a message defined in SAP’s message catalog (T100 / maintained via SE91) using the values in sy-msgid, sy-msgno, and sy-msgv1…sy-msgv4. Conceptually, it answers the question:

“Given message class + number + variables, what is the rendered message string?”

This is particularly useful after an RFC call fails, where ABAP may have message context available even if the exception itself is not a clean string.

Why this matters in an RFC wrapper

In the message class–based exception configuration, the workflow can provide message metadata (class/number/type) so that SAP can behave “natively”: ABAP receives a failure (sy-subrc <> 0), formats the message using FORMAT_MESSAGE, and returns the final text in a field like EXCEPTIONMSG (and/or in BAPIRET2-MESSAGE). The result is:

consistent wording across systems and environments
easier localization (SAP selects language-dependent text)
separation of concerns: code supplies variables; message content lives in message maintenance

A robust pattern

After the RFC call, I use this order of precedence:

Use any explicit text already provided (for example via system_failure … MESSAGE exceptionmsg), because it’s already formatted.
If that’s empty but SAP message context exists (sy-msgid / sy-msgno), call FORMAT_MESSAGE to produce the final string.
If neither is available, fall back to a generic message that includes sy-subrc.

Here is a compact version of that pattern:

DATA: lv_text TYPE string. CALL FUNCTION 'Z_GET_ORDERS_ANALYSIS' DESTINATION dest IMPORTING analysis = analysis TABLES it_csv = it_csv CHANGING return = return EXCEPTIONS sendexceptiontosapserver = 1 system_failure = 2 MESSAGE exceptionmsg communication_failure = 3 MESSAGE exceptionmsg OTHERS = 4. IF sy-subrc <> 0. "Prefer explicit message text if it already exists IF exceptionmsg IS INITIAL. "Otherwise format SAP message context into a string IF sy-msgid IS NOT INITIAL AND sy-msgno IS NOT INITIAL. CALL FUNCTION 'FORMAT_MESSAGE' EXPORTING id = sy-msgid no = sy-msgno v1 = sy-msgv1 v2 = sy-msgv2 v3 = sy-msgv3 v4 = sy-msgv4 IMPORTING msg = lv_text. exceptionmsg = lv_text. ELSE. exceptionmsg = |RFC failed (sy-subrc={ sy-subrc }).|. ENDIF. ENDIF. "Optionally normalize into BAPIRET2 for structured consumption return-type = 'E'. return-message = exceptionmsg. ENDIF.

Common gotchas

FORMAT_MESSAGE only helps if sy-msgid and sy-msgno are set. If the failure did not originate from an SAP message (or message mapping is disabled), these fields may be empty—so keep a fallback.
Message numbers are typically 3-digit strings (e.g., 001, 012), matching how messages are stored in the catalog.
FORMAT_MESSAGE formats text; it does not raise or display a message. That makes it safe to use in RFC wrappers and background processing.

Bottom line: FORMAT_MESSAGE is a simple tool that helps workflow‑originated failures “land” in SAP as clean, SAP‑native messages—especially when using message classes to standardize and localize error text.

References

Logic Apps Agentic Workflows with SAP - Part 2: AI Agents

Handling Errors in SAP BAPI Transactions | Microsoft Community Hub

Access SAP from workflows | Microsoft Learn

Create common SAP workflows | Microsoft Learn

Generate Schemas for SAP Artifacts via Workflows | Microsoft Learn

Parse XML using Schemas in Standard workflows - Azure Logic Apps | Microsoft Learn

Announcing XML Parse and Compose for Azure Logic Apps GA

Exception Handling | ABAP Keyword Documentation

Handling and Propagating Exceptions - ABAP Keyword Documentation

SAP .NET Connector 3.1 Overview

SAP .NET Connector 3.1 Programming Guide

All supporting content for this post may be found in the companion GitHub repository.

Azure API Management - Unified AI Gateway Design Pattern

nicolehaugen — Tue, 17 Feb 2026 16:21:27 GMT

Scaling AI adoption requires a unified control plane

As organizations scale generative AI adoption, they face growing complexity managing multiple AI providers, models, API formats, and rapid release cycles. Without a unified control plane, enterprises risk fragmented governance, inconsistent developer experiences, and uncontrolled AI consumption costs.

As an AI Gateway, Azure API Management enables organizations to implement centralized AI mediation, governance, and developer access control across AI services. This blog post introduces the Unified AI Gateway design pattern, a customer developed architecture pattern designed by Uniper, that builds on API Management’s policy extensibility to create a flexible and maintainable solution for managing AI services across providers, models, and environments. Uniper runs this pattern in production today to optimize AI governance and operational efficiency, enhance the developer experience, and manage AI costs.

Note: The Unified AI Gateway described in this post is a customer-implemented design pattern built using Azure API Management policy extensibility.

Customer spotlight: Uniper

Uniper is a leading European energy company with a global footprint, generating, trading, and delivering electricity and natural gas through a diverse portfolio spanning hydro, wind, solar, nuclear, and flexible thermal assets. With a strategy centered on accelerating the energy transition, Uniper provides reliable and innovative energy solutions that power industries, strengthen grids, and support communities across its core markets.

Committed to becoming one of Europe’s first AI-driven utilities, Uniper views artificial intelligence as a strategic cornerstone for future competitiveness, efficiency, and operational transformation. Building on a strong foundation of AI and machine-learning solutions—from plant optimization and predictive maintenance to advanced energy trading—Uniper is now scaling the adoption of generative AI (GenAI) across all business functions.

At Uniper, AI is not just a technology enhancer—it is a business imperative. The momentum for AI-driven transformation starts within Uniper’s business areas, with the technology organization enabling and empowering this evolution through responsible, value-focused AI deployment.

Enterprise challenges when scaling AI services

As Uniper expanded AI adoption, they encountered challenges common across enterprises implementing multi-model and multi-provider AI architectures:

API growth and management overhead – Using a conventional REST/SOAP API definition approach, each combination of AI provider, model, API type, and version typically results in a separate API schema definition in API Management. As AI services evolve, the number of API definitions can grow significantly, increasing management overhead.
Limited routing flexibility – Each API schema definition is typically linked to a static backend, which prevents dynamic routing decisions based on factors like model cost, capacity, or performance (e.g., routing to gpt-4.1-mini instead of gpt-4.1).

Because AI services evolve rapidly, this approach creates exponential growth in API definitions and ongoing management overhead:

Separate APIs are typically needed for each of the following:

o AI service provider (e.g. Microsoft Foundry, Google Gemini)

o API type (e.g., OpenAI, Inference, Responses)

o Model (e.g., gpt-4.1, gpt-4.1-mini, phi-4)

Each AI service also supports multiple versions. For instance, OpenAI might include:

o 2025-01-01-preview (latest features)

o 2024-10-21 (stable release)

o 2024-02-01 (legacy support)

Different request patterns may be required. For example, Microsoft Foundry's OpenAI supports chat completion using both:

o OpenAI v1 format (/v1/chat/completions)

o Azure OpenAI format (/openai/deployments/{model}/chat/completions)

Each API definition may be replicated across environments. For example, Development, Test, and Production API Management environments.

The Unified AI Gateway design pattern

To address these challenges, Uniper implemented a policy-driven enterprise AI mediation layer using Azure API Management.

At a high level, the pattern creates a single enterprise AI access layer that:

Normalizes requests across providers and models
Enforces consistent authentication and governance
Dynamically routes traffic across AI services
Provides centralized observability and cost controls

The design emphasizes modular policy components that provide centralized, auditable control over security, routing, quotas, and monitoring.

Core architecture components

The following components are involved in the Unified AI Gateway pattern:

Single wildcard API definition with wildcard operations (/*) that minimizes API management overhead. No API definition changes are required when introducing new AI providers, models, or APIs.
Unified authentication that enforces consistent authentication for every request, supporting both API key and JWT validation for inbound requests, with managed identity used for backend authentication to AI services.
Optimized path construction that automatically transforms requests to simplify consuming AI services, such as automatic API version selection (for example, transforming /deployments/gpt-4.1-mini/chat/completions to /openai/deployments/gpt-4.1-mini/chat/completions?api-version=2025-01-01-preview).
Model and API aware backend selection that dynamically routes requests to backend AI services and load balancing pools based on capacity, cost, performance, and other operational factors.
Circuit breaker and load balancing that leverages API Management’s built-in circuit breaker functionality with load balancing pools to provide resiliency across backend AI services deployed in different regions. When endpoints reach failure thresholds, traffic automatically rebalances to healthy regional instances.
Tiered token limiting that enforces token consumption using API Management’s llm-token-limit policy with quota thresholds.
Comprehensive trace logging and monitoring using Application Insights to provide robust usage tracking and operational insights, including token tracking through API Management’s llm‑emit‑token‑metric policy.

Unified AI Gateway pattern designed by Uniper

"The collaboration between the Uniper and Microsoft’s AI and API Management teams on delivering the unified AI gateway has been exceptional. Together, we've built a robust solution that provides the flexibility to rapidly adapt to fast-paced advancements in the AI sphere, while maintaining the highest standards of security, resilience, and governance. This partnership has enabled us to deliver enterprise-grade AI solutions that our customers can trust and scale with confidence."

~ Ian Beeson – Uniper, API Centre of Excellence Lead

Uniper’s results: Business and operational impact

For Uniper, shifting to use the Unified AI Gateway pattern has proven to be a strategic enabler for scaling their AI adoption with API Management. Uniper reports significant improvements across governance, efficiency, developer experience, and cost management:

Centralized AI security and governance

o Real-time content filtering – Uniper can detect, log, and alert on content filter violations.

o Centralized audit and traceability – All AI requests and responses are centrally logged, enabling unified auditing and tracing.

Operational efficiency

o Reduction in API definitions – Uniper estimates an 85% API definition reduction, moving from managing seven API definitions per environment (Development, Test, and Production) to a single universal wildcard API definition per environment.

o Feature deployment speed – Uniper delivers AI capabilities 60–180 days faster, enabled by immediate feature availability and the elimination of reliance on API schema updates and migrations.

o AI service availability – Uniper achieves 99.99% availability for AI services, enabled through circuit breakers and multi‑regional backend routing.

o Centralized ownership and maintenance – API management responsibilities are now consolidated under a single team.

Improved developer experience

o Immediate feature availability – New AI capabilities are available immediately without requiring API definition updates, eliminating the previous 2–6-month delay before new features could be shared with Uniper’s developers.

o Automatic API schema compatibility – Both Microsoft and third-party provider API updates no longer require migrations to new or updated API definitions. Previously, Uniper’s developers had to migrate for each update.

o Consistent API interface with equivalent SDK support – A unified API surface across all AI services simplifies development and integration for Uniper’s developers.

o Equivalent request performance – Uniper validated that request performance through the Unified AI Gateway pattern is equivalent to the conventional API definition approach, based on comparing the time a request is received by the gateway to the time it is sent to the backend.

AI cost management

o Token consumption visibility – Uniper uses detailed usage and token level metrics to enable a charge‑back model.

o Automated cost controls – Uniper enforces costs through configurable quotas and limits at both the AI gateway and backend AI service levels.

o Optimized model routing – Uniper dynamically routes requests to the most cost-effective models based on their policy.

Uniper's results

“The Unified AI Gateway pattern has fundamentally changed how we scale and govern AI across the enterprise. By consolidating AI access behind a single, policy-driven Azure API Management layer, we’ve reduced operational complexity while improving security, resilience, and developer experience. Most importantly, this approach allows us to adopt new models and capabilities at the pace the AI ecosystem demands—without compromising performance, availability, or governance.”

~ Hinesh Pankhania – Uniper, Head of Cloud Engineering & CCoE

When to use this pattern

The Unified AI Gateway pattern is most beneficial when organizations experience growing AI service complexity. Consider using the Unified AI Gateway pattern when:

Multiple AI service providers: Your organization integrates with various AI service providers (Microsoft Foundry, Google Gemini, etc.)
Frequent model/API changes: New models/APIs need to be regularly added or existing ones updated
Dynamic routing needs: Your organization requires dynamic backend selection based on capacity, cost, or performance

When not to use this pattern: If you expect a limited number of models/API definitions with minimal ongoing changes, following the conventional approach may be simpler to implement and maintain. The additional implementation and maintenance effort required by the Unified AI Gateway pattern should be weighed against the management overhead it is intended to reduce. Refer to the next section for details on implementing the Unified AI Gateway pattern, including how the request and response pipeline is built using API Management policy fragments.

Get started

Get started by exploring a simplified sample that demonstrates the Unified AI Gateway pattern: Azure-Samples/APIM-Unified-AI-Gateway-Sample. The sample shows how to route requests to multiple AI models through a single API Management endpoint, including Phi‑4, GPT‑4.1, and GPT‑4.1‑mini from Microsoft Foundry, as well as Google Gemini 2.5 Flash‑Lite. It uses a universal wildcard API definition (/*) across GET, POST, PUT, and DELETE operations, routing all requests through a unified, policy-driven pipeline built with policy fragments to ensure consistent security, dynamic routing, load balancing, rate limiting, and comprehensive logging and monitoring.

The Unified AI Gateway pattern is designed to be extensible, allowing organizations to add support for additional API types, models, versions, etc. to meet their unique requirements through minimal updates to policy fragments. Each policy fragment is designed as a modular component with a single, well-defined responsibility. This modular design enables targeted customization, such as adding customized token tracking, without impacting the rest of the pipeline.

Unified AI Gateway sample component diagram

Acknowledgments

We would like to recognize the following Uniper contributors for their design of the Unified AI Gateway pattern and their contributions to this blog post:

~ Hinesh Pankhania, Uniper – Head of Cloud Engineering and CCoE

~ Ian Beeson, Uniper - API Centre of Excellence Lead

~ Steve Atkinson – Freelance AI Architect and AI Engineering Lead (Contract)

A BizTalk Migration Tool: From Orchestrations to Logic Apps Workflows

hcamposu — Fri, 13 Feb 2026 19:03:08 GMT

As organizations move toward cloud-native architecture, this project addresses one of the most challenging aspects of modernization: converting existing BizTalk artifacts into their Azure Logic Apps equivalents while preserving business logic and integration patterns.

Architecture and Components

The BizTalk Migration Starter is available here: haroldcampos/BizTalkMigrationStarter and consists of four main projects and a test project, each targeting a specific aspect of BizTalk migration:

BTMtoLMLMigrator - BizTalk Map Converter

The BTMtoLMLMigrator is a tool that converts BizTalk Maps (.btm files) to the Logic Apps Mapping Language (.lml files). BizTalk maps define data transformations between different message formats, using XSLT and functoids to implement complex mapping logic.

Input:

Output:

Key Capabilities:

Parses BizTalk map XML structure to extract transformation logic.
Translates BizTalk functoids (string manipulation, mathematical operations, logical operations, date/time functions, etc.) to equivalent LML syntax
Preserves source and target schema references
Generates Logic Apps-compatible Liquid maps that can be directly deployed to Azure Integration Accounts

Core Components:

BtmParser.cs: Extracts map structure, functoid definitions, and link connections from BTM files
FunctoidTranslator.cs: Converts BizTalk functoid operations to Logic Apps Maps template equivalents
LmlGenerator.cs: Generates the final LML output
BtmMigrator.cs: Orchestrates the entire conversion process
Models.cs: Defines data structures for representing maps, functoids, and links

To convert a single map:

BTMtoLMLMigrator.exe -btm "C:\BizTalkMaps\OrderToInvoice.btm" -source "C:\Schemas\Order.xsd" -target "C:\Schemas\Invoice.xsd" -output "C:\Output\OrderToInvoice.lml"

To Convert all maps in a directory:

Be mindful of having the right naming for schemas in the BizTalk maps to avoid the tool picking up the wrong schemas:

BTMtoLMLMigrator.exe -batchDir "C:\BizTalkMaps" -schemasDir "C:\Schemas" -outputDir "C:\Output\LMLMaps"

Recommendations and Troubleshooting:

Make sure to use the real schemas, source and destination, and the corresponding map.
Most BizTalk functoids are supported, however for those who don’t, like scripting, it will add the code into the lml file, expecting you to conduct a re-design of the scenario. Currently the Data Mapper does not have a direct function that replaces scripting functoids. We are exploring alternatives for this.
Use GHCP agent to troubleshoot the tool if you run into issues.

ODXtoWFMigrator - Orchestration to Workflow Converter

The ODXtoWFMigrator tackles one of the most complex aspects of BizTalk migration: converting BizTalk Orchestrations (.odx files) to Azure Logic Apps workflow definitions. Orchestrations represent business processes with sequential, parallel, and conditional logic flows. It requires the orchestration and bindings file, exported from the BizTalk Application. If you don't have orchestration, for Content Routing Based scenarios, it uses the bindings file only.

Go to BizTalk Central Admin. Select your BizTalk Application:

Export all bindings. You can have multiple orchestrations in one binding file, so is important to export all the information available.

Input:

Output:

Key Capabilities:

Parses BizTalk orchestration XML to extract process flows, shapes, and connections
Maps BizTalk orchestration shapes (Receive, Send, Decide, Parallel, Loop, etc.) to Logic Apps actions and control structures
Generates connector configurations for common integration patterns
Creates comprehensive migration reports documenting the conversion process and any limitations
Produces standard Logic Apps JSON workflow definitions ready for deployment

Core Components:

BizTalkOrchestrationParser.cs: Analyzes orchestration structure and extracts workflow patterns
LogicAppsMapper.cs: Maps BizTalk orchestration shapes to Logic Apps equivalents
LogicAppJSONGenerator.cs: Generates the final Logic Apps workflow JSON
OrchestrationReportGenerator.cs: Creates detailed migration reports.
Schemas/Connectors/connector-registry.json: Registry of connector mappings and configurations

Recommendations and Troubleshooting:

Most BizTalk shapes are supported, however for those who don’t, it will default to compose actions and inject the code or a comment. It supports most BizTalk adapters.
If you need to add support to a new Logic Apps connector/service provider, you can update the connector-registry.json file by adding the trigger or action following the pattern for the other entries.
This tool has been tested with multiple patterns and orchestrations. Use GHCP agent to troubleshoot the tool if you run into issues.

The following are some of the supported commands. Please run the command line and review the README files to see all supported commands.

Command	Sample Usage
MIGRATE / CONVERT
With output file	ODXtoWFMigrator.exe convert "C:\BizTalk\InventorySync.odx" "C:\BizTalk\BindingInfo.xml" "C:\Output\InventorySync.workflow.json"
With refactored generator	ODXtoWFMigrator.exe migrate "C:\BizTalk\MessageRouter.odx" "C:\BizTalk\BindingInfo.xml" --refactor
BINDINGS-ONLY
Basic bindings-only	ODXtoWFMigrator.exe bindings-only "C:\BizTalk\ProductionBindings.xml"
With output directory	ODXtoWFMigrator.exe bindings-only "C:\BizTalk\BindingInfo.xml" "C:\LogicApps\BindingsWorkflows"
With refactored generator	ODXtoWFMigrator.exe bindings-only "C:\BizTalk\BindingInfo.xml" --refactor
REPORT / ANALYZE
Basic HTML report	ODXtoWFMigrator.exe report "C:\BizTalk\OrderProcessing.odx"
With output file	ODXtoWFMigrator.exe report "C:\BizTalk\OrderProcessing.odx" --output "C:\Reports\OrderProcessing_Analysis.html"
BATCH REPORT
Process directory	ODXtoWFMigrator.exe batch report --directory "C:\BizTalk\Orchestrations"
Short directory flag	ODXtoWFMigrator.exe batch report -d "C:\BizTalk\ContosoProject\Orchestrations"
BATCH CONVERT
Basic batch convert	ODXtoWFMigrator.exe batch convert --directory "C:\BizTalk\Orchestrations" --bindings "C:\BizTalk\BindingInfo.xml"
Alternative migrate syntax	ODXtoWFMigrator.exe batch migrate -d "C:\BizTalk\AllOrchestrations" -b "C:\BizTalk\BindingInfo.xml"
Specific files	ODXtoWFMigrator.exe batch convert --files "C:\BizTalk\Order.odx,C:\BizTalk\Invoice.odx" --bindings "C:\BizTalk\BindingInfo.xml"
With output directory	ODXtoWFMigrator.exe batch convert -d "C:\BizTalk\Orchestrations" -b "C:\BizTalk\BindingInfo.xml" -o "C:\LogicApps\Workflows"
With refactored generator	ODXtoWFMigrator.exe batch convert -d "C:\BizTalk\Orchestrations" -b "C:\BizTalk\BindingInfo.xml" --refactor
GENERATE-PACKAGE
Basic package generation	ODXtoWFMigrator.exe generate-package "C:\BizTalk\OrderProcessing.odx" "C:\BizTalk\BindingInfo.xml"
With output directory	ODXtoWFMigrator.exe generate-package "C:\BizTalk\OrderProcessing.odx" "C:\BizTalk\BindingInfo.xml" "C:\Deploy\OrderProcessing"
With refactored generator	ODXtoWFMigrator.exe package "C:\BizTalk\CloudIntegration.odx" "C:\BizTalk\BindingInfo.xml" --refactor
ANALYZE-ODX / GAP-ANALYSIS
Analyze directory	ODXtoWFMigrator.exe analyze-odx "C:\BizTalk\LegacyOrchestrations"
With output report	ODXtoWFMigrator.exe analyze-odx "C:\BizTalk\Orchestrations" --output "C:\Reports\gap_analysis.json"
LEGACY MODE
Legacy basic	ODXtoWFMigrator.exe "C:\BizTalk\OrderProcessing.odx" "C:\BizTalk\BindingInfo.xml" "C:\Output\OrderProcessing.json"

BTPtoLA - Pipeline to Logic Apps Converter

BTPtoLA handles the conversion of BizTalk pipelines to Logic Apps components. BizTalk pipelines process messages as they enter or leave the messaging engine, performing operations like validation, decoding, and transformation.

Key Capabilities:

Converts BizTalk receive and send pipelines to Logic Apps processing patterns
Maps pipeline components (decoders, validators, disassemblers, etc.) to Logic Apps actions
Preserves pipeline stage configurations and component properties
Generates appropriate connector configurations for pipeline operations

Input:

Output:

Core Components:

Pipeline parsing and analysis logic
Connector registry (Schemas/Connectors/pipeline-connector-registry.json) for mapping pipeline components
Logic Apps workflow generation for pipeline equivalents

To convert a receive pipeline:

BTPtoLA.exe -pipeline "C:\Pipelines\ReceiveOrderPipeline.btp" -type receive -output "C:\Output\ReceiveOrderPipeline.json"

To Convert a send pipeline:

BTPtoLA.exe -pipeline "C:\Pipelines\SendInvoicePipeline.btp" -type send -output "C:\Output\SendInvoicePipeline.json"

BizTalktoLogicApps.MCP - Model Context Protocol Server

The MCP (Model Context Protocol) server provides a standardized interface for AI-assisted migration workflows. This component enables integration with AI tools and assistants to provide intelligent migration suggestions and automation.

Key Capabilities:

Exposes migration tools through a standardized MCP interface
Enables AI-driven migration assistance and recommendations
Provides tool handlers for map conversion and other migration operations
Facilitates interactive migration workflows with AI assistance

Core Components:

McpServer.cs: Main MCP server implementation
Server/ToolHandlers/MapConversionToolHandler.cs: Handler for map conversion operations
test-requests.json: Test request definitions for validating MCP functionality

BizTalktoLogicApps.Tests - Test Project

A complete test project ensuring the reliability and accuracy of all migration tools, with integration tests that validate end-to-end conversion scenarios.

Key Capabilities:

Integration tests for BTM to LML conversion across multiple map files
Schema validation and error handling tests
Batch processing tests for converting multiple artifacts
Output verification and quality assurance

Where to upload your data:

Upload your BizTalk artifacts in the Data directory, and run your tests using the Test explorer.

For a complete demonstration, watch the video below:

Azure Arc Jumpstart Template for Hybrid Logic Apps Deployment

Shree_Divya_M_V — Tue, 10 Feb 2026 03:43:20 GMT

Today I’m sharing a new Azure Arc Jumpstart template (Jumpstart Drop) that implements a hybrid deployment for Azure Logic Apps (Standard) on Azure Arc-enabled AKS cluster which enables deployment with a single command that sets up a complete, working environment for testing your scenarios.

Jumpstart Drop link: Azure Arc Jumpstart

Hybrid deployment model allows you to run Logic Apps workloads on your own infrastructure, providing you with the option to host your integration solutions on premises, in a private cloud, or even in a third-party public cloud. You can find more information in this article:Set up your own infrastructure for Standard logic app workflows - Azure Logic Apps | Microsoft Learn

Demo video:

Given that Hybrid Logic Apps is designed to support mission-critical, enterprise-level integration scenarios, with provision to configure on custom infrastructure across both Azure and Kubernetes environments—the setup can naturally be complex. This Jumpstart template addresses these intricacies by simplifying onboarding and providing an all-in-one script for comprehensive testing and validation.

This Jumpstart template deploys the following components and verifies each deployment stage. You can customize each step as per your requirements by modifying the script.

An AKS cluster as the Kubernetes substrate for the scenario.

Azure Arc enablement for Kubernetes to onboard the cluster into Azure for centralized governance and operations.

ACA extension, Custom location and Connected Environment.

Azure SQL Server for runtime storage.

Azure storage account for SMB artifacts storage.

A hybrid logic Apps resource.

Getting started :

Visit the Jumpstart URL Azure Arc Jumpstart and follow the steps below.

Check prerequisites and permissions (see Prerequisites tab).

Download the GitHub repo and run the deployment command (see Quick Start tab).

After deployment, run test commands to confirm everything works (see Testing tab).

Feedback and contributions

Jumpstart templates are built for the community and improved with community input. If you try this drop and have suggestions (documentation clarity, additional validation, new scenarios, or fixes), please share feedback through the https://github.com/ShreeDivyaMV/LogicApps_Jumpstart_Templates repository associated with the drop.

References:

Announcement: General Availability of Logic Apps Hybrid Deployment Model | Microsoft Community Hub

Create Standard logic app workflows for hybrid deployment - Azure Logic Apps | Microsoft Learn

https://github.com/ShreeDivyaMV/LogicApps_Jumpstart_Templates

Azure Arc Jumpstart

Logic Apps Aviators Newsletter - February 2026

WSilveira — Mon, 02 Feb 2026 20:44:05 GMT

In this issue:

Ace Aviator of the Month
News from our product group
News from our community

Ace Aviator of the Month

February 2026’s Ace Aviator: Camilla Bielk

Camilla Bielk - Solutions Architect @ XLENT

What's your role and title? What are your responsibilities?

I’m a developer and solution architect, working as a consultant (at XLENT) in teams involved across the integration lifecycle—from understanding business needs and building new solutions to operations. Previously I worked a lot with BizTalk and with customers using both Azure and BizTalk. In my current role, I work exclusively with Azure.

Can you give us some insights into your day-to-day activities and what a typical day in your role looks like?

A typical day starts by syncing operational status with the team to ensure everything is running as expected (Logic Apps, Service Bus, Functions, API Management, etc.) and discussing any findings from the previous day. Then I continue with ongoing work, ranging from stakeholder meetings and designing new integration flows to C# development, operations, and maintenance of the existing landscape.

I enjoy being involved across the entire chain. Working closely with operational issues provides valuable input into design decisions, and vice versa, which strengthens me as a designer and architect.

What motivates and inspires you to be an active member of the Aviators/Microsoft community?

The openness to feedback and knowledge sharing from both community developers and the product team motivates me to stay active, continuously learn, and become the best consultant I can be. Passing knowledge to new team members is rewarding and completes the circle. Integration conferences are inspiring - networking with amazing people and discussing the technology we use every day. That’s also why we started the Nordic Integration Summit: to give more people the chance to take part in such an inspiring event.

Looking back, what advice do you wish you had been given earlier that you'd now share with those looking to get into STEM/technology?

Your social skills are more valuable than you might think. Teamwork is everything, and understanding business needs—even from non-technical colleagues—is just as important as technology. Listen to your heart and find environments where you can thrive.

Programming languages change over time; the real takeaway is mastering common concepts and patterns and developing the ability to learn continuously. Stay curious and embrace new things as they come!

What has helped you grow professionally?

100% of my professional growth comes from working with kind, humble, and collaborative people—teams where knowledge is shared freely in all directions, mistakes are allowed, and learning from them is encouraged.

If you had a magic wand that could create a feature in Logic Apps, what would it be and why?

Better cost transparency—clearly showing which actions drive costs (executions, retries, data volume, logging) with visibility before production deployment. Design-time guidance that warns about expensive operations, anti-patterns, and inefficient configurations.

News from our product group

Introducing Unit Test Agent Profiles for Logic Apps & Data Maps

Focused unit test agent profiles help Logic Apps Standard teams discover workflows and data maps, write reusable specifications, generate typed mocks/test data, and implement MSTest suites against the Automated Test SDK. The approach promotes spec-first testing, consistent artifacts, and reliable validations across scenarios (happy path, error handling, boundaries). The project demonstrates how GitHub Copilot custom agents and prompts can accelerate unit test authoring while enforcing constraints for maintainability in enterprise integrations.

Automated Test Framework - Missing Tests in Test Explorer

If Logic Apps Standard tests disappear from VS Code’s Test Explorer, the cause is typically a MSTest version mismatch introduced by a recent C# DevKit update. The fix is to update package references in the project (MSTest, Test SDK, and related dependencies) to supported versions. After adjusting packages and restarting VS Code, tests reappear and run as expected. The extension is being updated, but existing projects should apply the manual changes to restore a stable testing experience.

Upcoming Agentic Azure Logic Apps Workshops

Free workshops introduce Agentic Business Processes in Azure Logic Apps, including MCP Server integrations and agent loop patterns. Sessions cover connecting the enterprise with MCP Servers from Copilot Studio and building agentic workflows in a day using Logic Apps (Standard). Registration links are provided, with dates set in January. These events help practitioners explore agent tools, orchestration patterns, and practical scenarios for intelligent automation in modern integration landscapes.

News from our community

Enterprise AI ≠ Copilot

Post by Al Ghoniem, MBA

Deploying Copilot is not the same as building an enterprise AI strategy. This article distinguishes between adopting a product versus developing a core organizational capability. It explores why many AI rollouts stall when treated as point solutions and outlines what it takes to embed AI as a strategic, scalable function across the enterprise. For leaders evaluating their AI roadmaps, this piece offers a framework for thinking beyond tools toward sustainable transformation.

BizTalk Server and WinSCP Error

Post by Sandro Pereira

A common SFTP adapter issue resurfaces when BizTalk Server cumulative updates are applied. This troubleshooting guide explains why the WinSCPnet assembly fails to load after upgrading from CU5 to CU6 and provides a version compatibility matrix for BizTalk Server 2020. It includes step-by-step instructions to resolve the error by copying the correct WinSCP binaries to the BizTalk installation folder, along with an automated PowerShell script for streamlined remediation.

More on finding application registrations used by Logic Apps

Post by Mikael Sand

Building on earlier work around API connection discovery, this post extends KQL queries to find Logic Apps that authenticate via Client ID and secret in HTTP actions. Using Azure Resource Graph Explorer, the technique scans workflow parameters to identify application registration references. While the approach assumes parameters are used for credentials, it provides a practical method for auditing which Logic Apps depend on a given app registration across subscriptions.

MCP Servers in Azure Logic Apps Agent Loops (Step-by-Step)

Video by Stephen W. Thomas

This walkthrough demonstrates how to move tool logic out of Logic App Agent loops and into reusable Model Context Protocol servers. The video covers setting up an MCP server, registering tools, and invoking them from within an agent workflow. By decoupling tool definitions from orchestration logic, developers can build modular, maintainable agentic systems that scale across multiple workflows and scenarios.

From Rigid Choreography to Intelligent Collaboration: Agentic Orchestration as the Evolution of SOA

Post by Steef-Jan Wiggers

Integration has evolved from rigid, deterministic workflows to adaptive, goal-driven orchestrations powered by intelligent agents. This article traces the journey from BizTalk-era SOA composites to modern agentic patterns, explaining how AI-enabled orchestrators dynamically plan, self-correct, and communicate intent rather than follow fixed sequences. With examples from Azure Logic Apps Agent Loop, it shows how integration professionals can leverage existing connectors and APIs as tools within reasoning-based architectures.

Azure Integrations That Actually Work in Production

Post by Devarajan Gurusamy

Architecture diagrams often look perfect in presentations but fail under real-world conditions. This article examines what it takes to build Azure integrations that survive production workloads, covering resilience patterns, error handling strategies, and operational considerations that separate proof-of-concepts from enterprise-grade solutions. It offers practical guidance for teams moving beyond demos toward reliable, maintainable integration implementations.

Configuring BizTalk Server Backup Jobs for Azure Blob Storage

Post by Sandro Pereira

Modernizing BizTalk infrastructure can start with small, targeted improvements. This guide shows how to redirect native BizTalk backup jobs to Azure Blob Storage using SQL Server’s BACKUP TO URL feature. It covers generating SAS tokens, creating SQL credentials, updating job steps, and validating backups. The approach improves disaster recovery posture with geo-redundant cloud storage while keeping the BizTalk environment unchanged—no new components or custom code required.

Building an AI Agent with Logic Apps Consumption and Agent Loop

Post by Stephen W. Thomas

Logic Apps Consumption with AgentLoop offers a fast path to practical AI agents, particularly for experimentation and low-volume workloads. This post walks through building a stateful poker-playing agent, demonstrating tool orchestration, agent instructions, and execution tracing. It compares Consumption and Standard tiers, explores cost efficiency, and shows how to offload reasoning to external models. At roughly a dollar for 25 runs, it’s an accessible entry point for agentic development.

Microsoft Agent Framework

Post by Al Ghoniem, MBA

Microsoft’s open-source Agent Framework provides a comprehensive toolkit for building, orchestrating, and deploying AI agents in Python and .NET. It features graph-based workflows with streaming and checkpointing, multi-agent patterns, built-in observability via OpenTelemetry, and support for multiple LLM providers. The repository includes quickstart samples, migration guides from Semantic Kernel and AutoGen, and experimental labs for benchmarking and reinforcement learning.

Storage Account: You do not have permissions to list the data using your user account with Entra ID

Post by Sandro Pereira

Being an Owner of an Azure Storage Account does not automatically grant access to its data. This common confusion trips up many developers working with Logic Apps and blob storage. The article explains the distinction between management roles and data-plane permissions, then walks through assigning Storage Blob Data roles via Access Control (IAM) to resolve the “You do not have permissions” error when authenticating with Microsoft Entra ID.

Using Office 365 Outlook Connector in Logic Apps Standard

Post by Srikanth Gunnala

When configuring Office 365 Outlook (V2) with Managed Identity in Logic Apps Standard, the workflow designer may fail to auto-bind existing API connections—even when runtime works correctly. This post details the issue, explaining how a null referenceName in the workflow JSON causes the trigger to appear unbound. The fix involves manually setting the connection reference name in the workflow definition, after which the designer immediately recognizes the connection.

Inside Logic Apps Standard: Understanding Compute Units (CU) for Storage Scaling

Post by Daniel Jonathan

High-volume Logic Apps can hit Azure Storage throttling limits. This deep-dive explains how Compute Units enable horizontal storage scaling by distributing workflow execution data across up to 32 storage accounts. It covers CU routing via Run ID suffixes, table distribution patterns, and configuration via host.json. Understanding this architecture is essential for building monitoring tools, querying run histories programmatically, or troubleshooting performance at scale.

E59 - Roles & Personas

Video by Sebastian Meyer

This episode recaps highlights from SAP TechEd and Microsoft Ignite, with a focus on the SAP Innovation Guide and Logic Apps announcements. It explores roles and personas in the integration space, discussing how different team members contribute to enterprise integration projects. The conversation provides context for practitioners following both SAP and Microsoft ecosystems and offers insights into recent platform developments relevant to hybrid integration scenarios.

Architecting Trust: Leveraging Microsoft Foundry to Solve AI Governance Challenges

Post by Kent Weare

As organizations scale AI deployments, governance becomes critical. This article explores how Microsoft Foundry addresses common AI governance challenges including model management, access controls, auditability, and compliance. It outlines architectural patterns for building trust into AI systems from the ground up and provides guidance for teams navigating the balance between innovation velocity and responsible AI practices in enterprise environments.

Introducing Unit Test Agent Profiles for Logic Apps & Data Maps

WSilveira — Wed, 28 Jan 2026 23:33:34 GMT

I did some experimentation this week with GitHub Copilot custom agents and custom prompts. The result was a couple of agents to help with creation of unit tests for Logic Apps Standard workflows and data maps.

These agent profiles are designed to keep test artifacts consistent and maintainable by separating discovery, specification, data generation, and implementation. Specifications serve as the single source of truth; generated code and data follow from the specs.

Discover: Enumerate workflows/maps, triggers/actions, dependencies, and control flow to build a testability inventory.
Spec (Speckit): Write reusable test specifications (intent, inputs/mocks, expected outcomes) stored in a predictable location.
Cases: Design scenario catalogs with categories (Happy Path, Error Handling, Boundary Conditions, etc.).
Test Data: Generate typed mocks (Logic Apps) or input/expected data files (Data Maps) per scenario.
Implement: Produce MSTest code against the Automated Test SDK on net8.0, enforcing strict constraints for reliability.
Project Batch: Run operations across all workflows/maps with pre-checks, scaffolding verification, and summary reporting.

ℹ️ You can find this project on GitHub: https://github.com/wsilveiranz/logicapps-unittest-custom-agent. This is an example of how those agents can be created using what is available in GitHub Copilot, so feel free to fork it and adjust it to your own requirements.

Agent Profiles Available

Logic Apps Workflow Unit Test Author

Specialist agent for authoring Logic Apps Standard workflow unit tests using MSTest (net8.0) and the Automated Test SDK. Produces spec-first test cases, typed mocks, and runnable MSTest implementations.

How It Works

Discover workflows: Locate workflow.json, summarize triggers/actions, and identify external dependencies to mock.
Spec-first: Write reusable specs capturing intent, mock plan, inputs, and expected outcomes.
Create cases: Build scenario catalogs (Happy Path, Error Handling, Boundary Conditions, etc.).
Generate test data: Produce typed MockOutput and ActionMock classes instances mapped to action names. This step is optional, as implementation will create test data if not available.
Implement tests: Generate MSTest code enforcing SDK constraints and required annotations.
Validate: Build and run tests; refine specs and data as needed.
Batch (optional): Apply the flow across all workflows once scaffolding is verified.

Skill	Description	Prompt File
Discover Workflows	Discover workflow definitions, summarize triggers/actions, and produce a mock inventory.	.github/prompts/la-unit-tests-discover.prompt.md
Create Test Cases	Create unit test cases from a workflow definition; define intent, inputs, mock plan, and expected outcomes.	.github/prompts/la-unit-tests-create-cases.prompt.md
Write Speckit Specs	Write and maintain Speckit-style specification documents for reusable scenarios.	.github/prompts/la-unit-tests-speckit-specs.prompt.md
Implement Tests	Implement MSTest unit tests using the Automated Test SDK with enforced constraints.	.github/prompts/la-unit-tests-implement.prompt.md
Generate Test Data	Generate trigger/action mock payloads and typed outputs for success and failure variants.	.github/prompts/la-unit-tests-generate-test-data.prompt.md
Project Batch	Execute project-wide operations with scaffolding verification and roll-up reporting.	.github/prompts/la-unit-tests-project-batch.prompt.md

Logic Apps Data Map Unit Test Author

Specialist agent for authoring Data Map unit tests from LML or XSLT using MSTest (net8.0). Produces spec-first test cases, sample input/expected data, and MSTest implementations.

How It Works

Discover data maps: Locate Artifacts/MapDefinitions/*.lml and Artifacts/Maps/*.xslt; summarize transformations and schema requirements.
Spec-first: Write reusable specs capturing intent, input data, expected output, and validation criteria.
Create cases: Build scenario catalogs (Happy Path, Empty/Missing, Boundary Values, Special Characters, Large Data, etc.).
Generate test data: Produce representative input files and expected output files aligned to schemas and mapping rules. This step is optional, as implementation will create test data if not available.
Implement tests: Generate MSTest classes using DataMapTestExecutor.
Validate: Build and run tests; refine specs and data as needed.
Batch (optional): Apply the flow across all maps; verify project scaffolding first.

Skill	Description	Prompt File
Discover Data Maps	Discover LML/XSLT maps and schemas; summarize transformation structure and complexity.	.github/prompts/dm-unit-tests-discover.prompt.md
Create Test Cases	Design scenarios covering happy path, edge cases, and error handling.	.github/prompts/dm-unit-tests-create-cases.prompt.md
Write Speckit Specs	Write and maintain Speckit-style specs with mapping rules and validations.	.github/prompts/dm-unit-tests-speckit-specs.prompt.md
Implement Tests	Implement MSTest suites using DataMapTestExecutor with required defaults.	.github/prompts/dm-unit-tests-implement.prompt.md
Generate Test Data	Generate input and expected output files matched to map rules and schemas.	.github/prompts/dm-unit-tests-generate-test-data.prompt.md
Project Batch	Execute project-wide operations with scaffolding and summary reporting.	.github/prompts/dm-unit-tests-project-batch.prompt.md

FAQ

Why Speckit-style specs?

Specs are human-readable contracts that drive consistent test implementation across teams and time. They decouple scenario design from code generation, improving reuse.

Can I run batch operations?

Yes. Use the project-batch profiles to orchestrate discovery and implementation across all workflows/maps once scaffolding is verified.

What if scaffolding is missing?

The Implement and Project Batch agents will stop and report the exact folders/files you need to create (via the Logic Apps Designer’s Create Unit Test command or manual steps).

Automated Test Framework - Missing Tests in Test Explorer

WSilveira — Thu, 05 Feb 2026 01:49:49 GMT

Have your tests created using the Logic Apps Standard Automated Test Framework disappeared from the Test Explorer in VS Code all of a sudden? The answer is a mismatch between the MSTest versions used.

A recent update in the C# DevKit extension changed the minimum requirements for the MSTest library - it now requires the minimum of 3.7.*. The project scaffolding created byt the Logic Apps Standard extension uses 3.0.2.

The good news is that you can fix this by just changing package versions on your project. Follow the instructions below to have this fixed:

Open the .csproj that the extension created (e.g. LogicApps.csproj).
Find the ItemGroup containing your package references. It should look like this:

Replace the package references with this new version:

Once you make this change, restart VSCode window and rebuild your project - Test Explorer will start showing your tests again. Notice that this package reference is simplified as some of the previous references are already in the dependency chain, so don't need to be explicitly added.

ℹ️ We are updating our extension to make sure that new projects are being generated with the new values, but you should make those changes manually on existing projects.

Upcoming Agentic Azure Logic Apps Workshops

KentWeareMSFT — Fri, 09 Jan 2026 21:52:15 GMT

Join me for a couple of upcoming workshops where you can learn about Logic Apps MCP Servers and building Agentic Business Processes

Topic: Connecting the enterprise, using MCP Servers from Copilot Studio

When: Tuesday, January 13th at 2PM CET/6 AM Mountain

Registration link

Topic: Building Agentic Business Processes in a Day, using Azure Logic Apps Agent Loop
When: Friday, January 16th at 2pm CET/6 AM Mountain

Registration Link

Azure Integration Services Blog articles

Introducing the plugin marketplace for Azure API Center

The problem we're solving

What's new

Get up and running in seconds

Enterprise-ready from day one

Documentation

Migrate Data Ingestion from Data Collector to Log Ingestion

Logic Apps Aviators Newsletter - April 2026

Ace Aviator of the Month

What’s your role and title? What are your responsibilities?

Can you give us some insights into your day‑to‑day activities and what a typical day looks like?

What motivates and inspires you to be an active member of the Aviators / Microsoft community?

Looking back, what advice would you give to people getting into STEM or technology?

What has helped you grow professionally?

If you had a magic wand to create a new feature in Logic Apps, what would it be and why?

News from our product group

News from our community

How to revoke connection OAuth programmatically in Logic Apps

Introducing Skills in Azure API Center

The problem

What is a Skill?

How Skills work in API Center

Option 1: Register a Skill manually

Option 2: Sync Skills from a Git repository

Discovering Skills in your catalog

Why this matters for AI development teams

Available now

Reliable blob processing using Azure Logic Apps: Recommended architecture

Implementing / Migrating the BizTalk Server Aggregator Pattern to Azure Logic Apps Standard

Why is it important?

The migration at a glance: BizTalk orchestration vs. Logic Apps workflow

The Azure Logic Apps Standard implementation

Side-by-side comparison: BizTalk Server vs. Azure Logic Apps

Key architectural differences

How the workflow works

Azure Service Bus: The cloud-native replacement for BizTalk’s MessageBox

Decode Flat File Invoice: Reuse your BizTalk schemas with zero refactoring

The message with correlation Id

Step-by-step guide: Deploy the template from the Azure portal

Prerequisites

Step 1: Open the templates gallery

Step 2: Find the Aggregator template

Step 3: Review the template details

Step 4: Provide workflow information

Step 5: Create connections

Step 6: Configure parameters

Step 7: Review and create

Step 8: Upload the flat file schema

Step 9: Verify and test

Conclusion

Resources

Logic Apps Aviators Newsletter - March 2026

Ace Aviator of the Month

What's your role and title? What are your responsibilities?

Can you give us some insights into your day-to-day activities?

What motivates and inspires you to be an active member of the Aviators/Microsoft community?

Looking back, what advice do you wish you had been given earlier?

What has helped you grow professionally?

If you had a magic wand that could create a feature in Logic Apps, what would it be?

News from our product group

News from our community

New Azure API management service limits

Changes to service limits - 2026 update

What's changing

Rollout process

Limits policy for existing classic tier customers

Guidelines for limit increases

Requesting a limit increase

Documentation

How to Access a Shared OneDrive Folder in Azure Logic Apps

What is the problem?

Why this happens

How to access a shared OneDrive folder

Option 1: Use Microsoft Graph APIs (Delegated permissions)

Option 2: Use Graph Explorer to configure the OneDrive connector

Step-by-step: Using Graph Explorer to access a shared folder

Scenario

Step 1: List shared folders using Microsoft Graph

Step 2: Configure Logic App “List files in folder” action