Azure API Center Introduces a Data Plane MCP Server for Enterprise-Wide API and AI Asset Discovery
As organizations scale their adoption of MCP-based tooling and AI agents, one challenge keeps surfacing: developers spend too much time figuring out what APIs, tools, and AI assets exist — and then manually wiring up connections to each one. Today, we're excited to announce general availability of a new capability that changes that. What's new Azure API Center now provides a data plane MCP server — a unified enterprise discovery endpoint that gives agents and developer tools a single connection point to your organization's full catalog of registered MCP servers, tools, APIs, and AI assets. Instead of hunting across systems or hand-configuring integrations one by one, developers and agents can now connect once and immediately access everything that's been registered in your API Center. Why this matters The MCP ecosystem is growing fast. So is the number of enterprise APIs and AI assets that teams need to manage and consume. Without a central discovery mechanism, that growth creates friction — more manual configuration, more drift between what's available and what's actually reachable, and more integration complexity for every new agentic application. The Azure API Center data plane MCP server addresses this directly. With it, teams can: Give agents centralized access to enterprise APIs and AI assets without custom routing logic Eliminate manual configuration of connections to individual MCP servers Automatically surface newly registered MCP servers and tools without reconfiguration Simplify discovery and consumption across a rapidly growing enterprise catalog Built for how organizations actually operate Agentic applications don't just need APIs — they need to find the right APIs, trust that the catalog is current, and connect reliably at scale. By acting as a unified discovery endpoint, Azure API Center helps teams operationalize AI ecosystems with stronger discoverability, governance, and developer productivity, while meaningfully reducing integration complexity. This is especially valuable as enterprises move from experimenting with AI agents to deploying them in production workflows, where manual integration approaches don't scale. How to enable the data plane MCP server Turning on the MCP server takes just a few clicks in the Azure portal. Navigate to your API Center instance and open Data API settings under the Consumption section in the left-hand menu. From there, under MCP endpoint, toggle Enable API Center MCP endpoint to on. Once enabled, your MCP endpoint URL (in the form https://<your-instance>.data.<region>.azure-apicenter.ms/mcp) will appear and can be copied directly for use in agent configurations or developer tools. Note: When enabled, the MCP endpoint is also surfaced on the developer portal homepage, so developers can connect via CLI without needing to look up the URL separately. You can also enable the Plugin marketplace endpoint from the same settings page to let developers browse and install approved plugins and skills from your organization's marketplace. The Visibility section lets you control which APIs are exposed through the data plane — use Add condition to filter the catalog based on your governance requirements. Get started Learn more about Azure API Center and how organizations are building unified catalogs for APIs, MCP tools, agents, and AI assets.GA: Azure API Center Now Supports Plugin Registration
As organizations scale their AI and integration ecosystems, one challenge keeps surfacing: developers don't have a reliable, governed way to discover and reuse the plugins their teams have already built. Plugins end up siloed in individual repos, shared over Slack, or duplicated across teams — slowing down development and creating governance blind spots. What's new With this update, developers can register plugins directly into Azure API Center's enterprise catalog. Once registered, plugins are discoverable, governable, and consumable alongside the rest of an organization's API and AI portfolio — no more hunting across repositories or relying on word-of-mouth to find what's already been built. Why it matters Plugins are increasingly central to how AI-powered applications are built. Agents depend on them. Integrations are built on top of them. But without a governed home, even well-built plugins go undiscovered and get rebuilt from scratch. Plugin registration in Azure API Center helps organizations: Centralize plugin discovery within a governed catalog, so developers always know where to look Surface vetted plugins that teams can confidently find and reuse — reducing duplication and accelerating development Align plugins with source-controlled workflows, keeping development practices consistent across the catalog Reduce friction between building a plugin and enabling it for real-world integration One catalog for your entire AI ecosystem This update reflects a broader vision for Azure API Center: a single, unified catalog for everything an organization builds and consumes — APIs, plugins, agents, and AI assets. By bringing plugins into this experience, teams can operationalize reusable integration and AI capabilities at scale, with the governance and discoverability that enterprise development requires. Whether your teams are building copilot extensions, orchestration layers, or custom integrations, Azure API Center gives them a governed foundation to build on — and a shared place to discover what's already there. Learn more about Azure API Center and how organizations are building centralized catalogs for APIs, plugins, agents, and AI assets.🎉Announcing the HL7 connector for Azure Logic Apps Standard and Hybrid (Public Preview)
We’re excited to announce the Public Preview of the HL7 connector for Azure Logic Apps, empowering healthcare organizations to seamlessly integrate clinical applications and automate data exchange using industry-standard HL7 protocols. Why HL7 Integration Matters Healthcare organizations are complex ecosystems, with departments such as admissions, laboratories, nursing stations, and billing all generating and consuming critical patient data. Efficient, secure, and standardized data exchange is essential for delivering quality care and streamlining operations. HL7 Connector: Key Capabilities Simplified healthcare application integration with HL7-specific adapters and schemas. Standardized clinical data interchange between diverse medical applications. Automated communication processes to minimize manual intervention. End-to-end business process support for scenarios like admissions, discharge, and transfer, using publisher/subscriber patterns. Typical Scenarios End-to-End Integration: Publishers (e.g., Admissions Discharge and Transfer systems) send HL7 messages to subscribers (Hospital Information System, Pharmacy System). Azure Logic Apps processes, validates, reformats, and routes these messages, with acknowledgments sent back to publishers. Interrogative (Query/Response): Line-of-business applications can query other systems (e.g., requesting lab results from the Hospital Information System), with Azure Logic Apps managing routing and responses. HL7 Encode/Decode actions The HL7 connector provides native parsing and serialization of HL7 messages. It provides a Decode action that receives an HL7 message to decode in flat file format to produce an XML file, and an Encode action that receives a message to encode, with a header to encode to produce a Flat file. Decode Input: Flat file HL7 message. Output: Decoded XML message content and XML header content. Encode Input: XML message and header content. Output: Encoded HL7 flat file message. Important Considerations HL7 Message Schemas: Supports HL7 v2.X flat-file and XML schemas. Schema Management: Upload BizTalk schemas directly into integration accounts for seamless migration. Hybrid Deployment: Integration accounts connect to Azure. Message Processing: Logic Apps currently supports single message processing, with batching planned for future updates. Multipart Handling: Logic Apps exposes header, body, and custom segments as first-class outputs, simplifying orchestration compared to BizTalk’s multipart pipelines. Connector Availability: HL7 is available for both hybrid and Logic App Standard. Integration accounts: Currently we only support uploading schemas in Integration accounts. Announcing MLLP Private Preview We’re pleased to announce that MLLP support is now available as a private preview. MLLP Adapter: Enables HL7 messaging over the Minimal Lower Layer Protocol (MLLP). MLLP is available only in hybrid due to port restrictions in app services. Customers interested in early access and providing feedback can sign up via this survey: Private bundle for MLLP request Get Started To learn more about the HL7 connector and how it can transform your healthcare integration workflows, visit our documentation at Integrate Healthcare Systems with HL7 in Standard Workflows | Microsoft Learn. Video explaining the features of the new HL7 connectorLogic Apps Aviators Newsletter - May 2025
In this issue: Ace Aviator of the Month News from our product group Community Playbook News from our community Ace Aviator of the Month May’s Ace Aviator: Calle Andersson & Cloud at Contica What's your role and title? What are your responsibilities? I’m an IT Security Expert, integration security enthusiast, and full-time breaker of bad security defaults. I'm spending my days at Contica where I serve as Head of Security – Integration & Cloud. My day job involves helping customers secure their Azure environments, focusing on Logic Apps, Function Apps, API Management, and the rest of the Azure Integration Services family. I’m also working on building managed services focused on security posture and threat detection making secure delivery of integration platforms the default, not the exception. I’m trying to make “secure by design” feel less like a personal hobby for the one paranoid person on the team, and more like something the entire delivery process just quietly gets right. Can you give us some insights into your day-to-day activities and what a typical day in your role looks like? A big part of my day revolves around helping customers design secure patterns and infrastructure in Azure. That includes everything from shaping network boundaries and authentication flows, to figuring out how to make security practical and scalable. I spend a lot of time reviewing architecture, reading documentation, and testing different configurations, always looking for ways to improve how security is built into the platform itself, not just added on top. It’s part deep technical work, part strategy, and part translating complex security concepts into something teams can actually use. I also work closely with our developers, supporting them in security related questions and helping them navigate things like identity, permissions, and secure machine-to-machine communication. There is also many meetings with different stakeholders to raise awareness, guide decisions, and provide better insight into the actual security posture of their integration platforms. What motivates and inspires you to be an active member of the Aviators/Microsoft community? I genuinely enjoy learning and mastering new skills, and writing technical blog posts or sharing insights is a great way for me to reflect on what I’ve learned, while hopefully making someone else’s day a bit easier. I’ve also met a lot of brilliant people through the community, and it’s incredibly motivating to be surrounded by others who are just as nerdy passionate about secure design in Azure as I am. 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? You don’t need to know everything, just be curious, ask thoughtful questions, and don’t be afraid to break things in a lab environment. The best learning often happens when something goes wrong, and you dig your way out. Also, just ask that stupid question you've been thinking about. What has helped you grow professionally? If I had to mention one thing, it’s consistently challenging my comfort zone and putting myself in situations that push me in the right direction, even when it feels uncomfortable or a bit scary. Growth rarely happens when things are easy and cozy. I also believe that prioritizing your health has an amazing ROI. Getting enough sleep, eating well, and staying active might not sound groundbreaking, but if you want to do extraordinary things, you need the energy and persistence to match. If you had a magic wand that could create a feature in Logic Apps, what would it be and why? This one is really hard. I have three features that i really would love to see. So if i had a magic wand, id wish for a genie that could grant me three wishes! - Private Endpoint support for Consumption: This would enable private invocations HTTP triggers and prevent unnecessary exposure. Some workflows might fit better in Consumption, but security requirements force customers to Standard. - VNET Integration support for Consumption: Same benefits as above but applies when the Logic App needs to communicate with other internal resources over the VNET. - Managed Identity support for WEBSITE_ CONTENTAZUREFILECONNECTIONSTRING in Logic App Standard: Right now, this is in many cases the only access key left that is preventing customers from fully transitioning to Managed Identity and disabling the possibility to use access keys to their Storage Accounts. I really want that magic wand! 🙂 News from our product group Logic Apps Live April 2025 Missed Logic Apps Live in April? You can watch it here. We focused on the Public Preview of Logic Apps Standrad Automated Testing Framework and on the new Logic Apps Lab initiative! You will not regret checking those out! Announcement: Azure Logic Apps (Standard) Automated Testing Public Preview We are excited to announce the public preview of the Azure Logic Apps (Standard) Automated Testing Framework! This new framework is designed to simplify and enhance the testing process for your Logic Apps workflows, ensuring that your integrations are robust, reliable, and ready for production. Hybrid deployment model for Logic Apps - Performance Analysis and Optimization recommendations This document offers an in-depth performance evaluation of Azure Logic Apps within a hybrid deployment framework. It examines, several key factors such as CPU and memory allocation and scaling mechanisms, providing valuable insights aimed at maximizing the application’s efficiency and performance. Summing it up: Aggregating repeating nodes in Logic Apps Data Mapper Logic Apps Data Mapper makes it easy to define visual, code-free transformations across structured JSON data. One pattern that's both powerful and clean: using built-in collection functions to compute summary values from arrays. This post walks through an end-to-end example: calculating a total from a list of items using just two functions — `Multiply` and `Sum`. driving efficiency, agility, and fueling business growth in the AI-powered era. Use Index + Direct Access to pull data across loops in Data Mapper When working with repeating structures in Logic Apps Data Mapper, you may run into situations where two sibling loops exist under the same parent. What if you need to access data from one loop while you’re inside the other? This is where the Direct Access function, used in combination with Index, can save the day. Beyond the Basics: Using Minimum, Maximum, and Average Functions in Logic Apps Data Mapper In this blog, we walk through real-world scenarios and provide downloadable samples so you can try it yourself and accelerate your integration workflows. Demystifying Logic App Standard workflow deployments As Logic App Standard is built on the App Services runtime, it requires a different approach to automation than the consumption tier. AI Procurement assistant using prompt templates in Standard Logic Apps Answering procurement-related questions doesn't have to be a manual process. With the new Chat Completions using Prompt Template action in Logic Apps (Standard), you can build an AI-powered assistant that understands context, reads structured data, and responds like a knowledgeable teammate. Q1’2025: Azure Integration Services Quarterly Highlights and Insights From reinventing hybrid integration to unlocking AI-powered productivity and simplifying API management across ecosystems, the first quarter of 2025 was all about making integration smarter, faster, and more accessible for everyone. Whether you're a developer modernizing legacy workflows, an IT pro securing mission-critical APIs, or a business technologist building intelligent automations, Azure Integration Services and Azure API Management are moving at the speed of innovation. Here’s what stood out this quarter and how these updates can help accelerate your next move. Unleash Innovation with a Modern Integration Platform and an API-First Strategy Join us for a two-day global virtual event where you’ll discover how to unlock the full potential of your data and APIs to drive intelligent, agile growth with Azure Integration Services and an API-first strategy (this event happened in the past, but you should have access to the on-demand videos after registering) How to get JWT token of certificate-based SPN in logic app HTTP action When working with Azure Logic Apps and needing to call an API secured with Azure AD, you might use a Service Principal Name (SPN) with certificate-based authentication to obtain a JSON Web Token (JWT). This article shows a brief guide on how to set this up and use it in an HTTP action within a Logic App Standard How to send Excel file via HTTP in Logic App Due to logic app content transfer mechanism, sending an Excel file (XLSX) in HTTP will corrupt original content format by default. This article will help you to workaround this issue by sending binary data in HTTP body instead. Using Graph API to assign roles to logic app managed identity In this article, we will use the Graph API to assign roles to logic app managed identity. Previous document are mostly use powershell, here is a simply guide with Graph API AI Gateway Enhancements: LLM policies, Real-Time API support, Content Safety, and more As AI becomes more deeply integrated into applications, managing and governing Large Language Models (LLMs) is more important than ever. Today, we’re excited to announce several major updates to AI Gateway in Azure API Management, including the general availability of LLM policies, expanded real-time API support, new integrations for semantic caching and content safety, and a streamlined UI experience to make it even easier to get started. Plus, you can now opt in to early access for the latest AI Gateway features. Let’s dive into what’s new! Enhancing AI Integrations with MCP and Azure API Management As AI Agents and assistants become increasingly central to modern applications and experiences, the need for seamless, secure integration with external tools and data sources is more critical than ever. The Model Context Protocol (MCP) is emerging as a key open standard enabling these integrations - allowing AI models to interact with APIs, Databases and other services in a consistent, scalable way. Azure API Management Your Auth Gateway For MCP Servers Azure API Management is at the forefront, ready to support the open-source Model Context Protocol (MCP). APIM provides an enterprise-ready solution that helps you securely expose your MCP servers while evolving with the latest technology. Announcing "Service updates" for Azure API management Configure service update settings to manage when you receive updates and select maintenance window Announcing open public preview of inbound private endpoint for Standard v2 tier of API Management Today, we are excited to announce the open public preview of inbound private endpoint for Azure API management Standard v2 tier. Announcing General Availability of Authoring API Management Policies with Microsoft Copilot in Azure Microsoft announced the general availability of Microsoft Copilot in Azure. The API Management team is excited to share that authoring Azure API Management policies with Microsoft Copilot in Azure is also generally available, featuring localization, responsible AI, and enhancements to availability, performance, and capabilities. Announcing the Microsoft Azure API Management + Apiboost Partnership To help organizations build scalable, tailored API portals, we are thrilled to announce our partnership with Apiboost. A leader in SaaS and On-prem API portals, Apiboost, paired with Microsoft Azure API Management, enables businesses to create powerful, fully integrated API portals. This partnership allows customers to leverage Azure's secure, scalable platform, simplifying API consumption and enhancing business value. Available on Azure Marketplace. Announcing the Microsoft Azure API Management + Pronovix Partnership We are excited to announce our partnership with Pronovix, a leader in developer portals and API documentation. Pronovix has spent nearly a decade helping enterprises worldwide build business-aligned developer portals, and together, we’re making it faster and easier for Azure API Management customers to launch and scale their own API portals. Logic Apps Aviators Community Playbook We are excited to announce the latest articles from the Logic Apps Aviators Community Playbook. Interested in contributing? We have made it easy for you to get involved. Simply fill out our call for content sign-up link with the required details and wait for our team to review your proposal. And we will contact you with more details on how to contribute. Secure Standard workflows in Azure Logic Apps with Azure API Management Author: Andrew Wilson Everything that we build requires security as a fundamental requirement. Through every stage in the software development lifecycle, starting with requirements and design to how our solutions evolve over time, we should keep a "security first" mindset so we can focus and deliberate on security's importance. In this article, Andrew outlines methods to secure Azure Logic Apps workflows using Azure API Management, focusing on Shared Access Signature (SAS) keys and Easy Auth for authentication and authorization, emphasizing best practices for security and integration. News from our community Building a Complete RAG Application in Azure with No Code Post by Dan Toomey Learn to build Retrieval-Augmented Generation (RAG), a pattern a useful pattern for building LLM-based chat applications against an easily updateable knowledge store, without the expense of re-training the LLM. The pattern provides a base for AI generated responses that are as reliable, context-bounded, and current as the data in the knowledge store (which can be as simple as a collection of documents). Debatching in Logic Apps with Performance in Mind Post by Prashant Singh When working with Azure Logic Apps, handling large arrays efficiently is critical for performance and cost control. It is almost a routine need, but many implementations either slow down over time or rack up unnecessary costs. The solution isn’t just debatching, it’s smart debatching. Let’s break it down using a realistic use case and explore different techniques to handle it effectively. Unlocking the Power of Azure Logic Apps Standard with Azure App Service Environment v3 Post by Kritika Singh In today’s fast-paced digital landscape, businesses are constantly seeking ways to streamline operations, automate workflows, and enhance productivity. Azure Logic Apps Standard, especially when deployed in an Azure App Service Environment v3 (ASEv3), offers a powerful solution for building and orchestrating workflows in a secure and scalable manner. In this blog, we will explore what Azure Logic Apps Standard is, the benefits of using it in ASEv3, and how to get started. Setting Up Azure API Management (APIM) for Logic Apps Standard Video by Stephen W Thomas Learn how to set up Azure API Management (APIM) with Logic Apps Standard to manage, secure, and expose your HTTP-based workflows as APIs. You can use Flat File Schemas in Logic Apps to parse CSV Post by Sandro Pereira There’s a clean and native way to handle csv files: Flat File Schemas. We can use them with an Integration Account inside Logic App Consumption, or they are available inside Logic App Standard by default. Learn more on this Friday Fact from Sandro! Logic App Parameters naming size limits and restrictions Post by Sandro Pereira Learn about parameter naming conventions and best practices when creating Azure Logic Apps parameters, in this Friday Fact from Sandro Pereira. Logic App Variables naming size limits and restrictions Post by Sandro Pereira And since we are talking about naming conventions and best practices – how about learn about those details when creating Azure Logic Apps variables! Another Friday Fact from Sandro Pereira. The Ultimate Azure Logic Apps Handbook: 50 Expert Tips & Best Practices [Free] released Post by Sandro Pereira That Sandro Pereira is one of most prolific authors of our community, that is no news – you just need to look a this month’s community session… But did you know that he put together and Azure Logic Apps Handbook as e-book that can be downloaded for free? Take a look at his announcement on this blog post.
Reliable B2B Tracking Database Schema
The Azure Data Explorer (ADX) cluster database used for Reliable B2B Tracking stores transaction data in a structured format. AS2 transactions are stored in a table named AS2TrackRecords. X12 and EDIFACT transactions are stored in a table named EdiTrackRecords. These tables enable efficient querying and retrieval of B2B tracking data, providing structured insights into message flow, processing status, and troubleshooting details. Since B2B tracking data is stored in an Azure Data Explorer database, users can leverage Azure Workbook to create visually rich custom dashboards for analyzing their B2B transactions. If users choose to use rest API to create tracking store in integration account, then these two tables need to be created manually in the ADX database and integration account needs to have 'Ingester' permission to the database. AS2 Tracking Table – AS2TrackRecords All AS2 tracking data are stored on the AS2TrackRecords table. Below is the table creation query: .create table AS2TrackRecords ( IntegrationAccountSubscriptionId: string, /Subscription ID for the integration account. IntegrationAccountResourceGroup: string, // Resource group for the integration account. IntegrationAccountName: string, // Integration Account name. IntegrationAccountId: string, // Integration Account id. WorkflowRunOperationInfo: dynamic, // Workflow run operation information. ClientRequestId: string, // Client request id. EventTime: datetime, // Time of event. Error: dynamic, // Error if any. RecordType: string, // Tracking record type. Direction: string, // Direction of the message flow, which is either receive or send. IsMessageFailed: bool, // Whether the message is failed. MessageProperties: dynamic, // Message properties. AdditionalProperties: dynamic, // Additional properties. TrackingId: string, // Any custom tracking id. AgreementName: string, // Name of the agreement to which the messages are resolved. As2From: string, //AS2 message receiver’s name. As2To: string, //AS2 message sender’s name. ReceiverPartnerName: string, //AS2 message receiver's partner name. SenderPartnerName: string, // AS2 message sender's partner name. MessageId: string, // AS2 message ID. OriginalMessageId: string, // AS2 Original message ID. CorrelationMessageId: string, // AS2 message ID, to correlate messages with MDNs. IsMdnExpected: bool // whether the MDN is expected. ) X12/EDIFACT Tracking Table – EdiTrackRecords X12 and EDIFACT tracking data are stored in the EdiTrackRecords table. Below is the table creation query: .create table EdiTrackRecords ( IntegrationAccountSubscriptionId: string, // Subscription id of the Integration Account. IntegrationAccountResourceGroup: string, // Resource group for the integration account. IntegrationAccountName: string, // Integration Account name. IntegrationAccountId: string, // Integration Account id. WorkflowRunOperationInfo: dynamic, // Workflow run operation information. ClientRequestId: string, // Client request id. EventTime: datetime, // Time of event. Error: dynamic, // Error if any. RecordType: string, // Tracking record type. Direction: string, // Direction of the message flow, either receive or send. IsMessageFailed: bool, // Whether the message is failed. MessageProperties: dynamic, // Message properties. AdditionalProperties: dynamic, // Additional properties. TrackingId: string, // Any custom tracking id. AgreementName: string, // Name of the agreement to which the messages are resolved. SenderPartnerName: string, // Message sender's partner name. ReceiverPartnerName: string, // Message receiver's partner name. SenderQualifier: string, // Send partner qualifier. SenderIdentifier: string, // Send partner identifier. ReceiverQualifier: string, // Receive partner qualifier. ReceiverIdentifier: string, // Receive partner identifier. TransactionSetControlNumber: string, // Transaction set control number. FunctionalGroupControlNumber: string, // Functional group control number. InterchangeControlNumber: string, // Interchange control number. MessageType: string, // Transaction set or document type. RespondingTransactionSetControlNumber: string, //The responding transaction set control number in case of acknowledgement message. RespondingFunctionalGroupControlNumber: string, // The responding interchange control number in case of acknowledgement. RespondingInterchangeControlNumber: string, // The responding interchange control number in case of acknowledgement. ProcessingStatus: string // Processing status of the acknowledgment with these permitted values: Received, Generated, and Sent } Message Properties JSON schema Both As2TrackRecords and EdiTrackRecords table has a MessageProperties column which is of dynamic type having different JSON schema for different types of track records. AS2 Message Track Record Message Properties schema { "direction": "", "messageId": "", "dispositionType": "", "fileName": "", "isMessageFailed": "", "isMessageSigned": "", "isMessageEncrypted": "", "isMessageCompressed": "", "correlationMessageId": "", "incomingHeaders": {}, "outgoingHeaders": {}, "isNrrEnabled": "", "isMdnExpected": "", "mdnType": "" } The following table describes the properties in the JSON schema for message properties in an AS2 message track record. Property Type Description direction String Direction of the message flow, which is either receive or send messageId String AS2 message ID. dispositionType String Message Disposition Notification (MDN) disposition type value fileName String File name from the header of the AS2 message isMessageFailed Boolean Whether the AS2 message failed isMessageSigned Boolean Whether the AS2 message was signed isMessageEncrypted Boolean Whether the AS2 message was encrypted isMessageCompressed Boolean Whether the AS2 message was compressed correlationMessageId String AS2 message ID, to correlate messages with MDNs incomingHeaders Dictionary of JToken Incoming AS2 message header details outgoingHeaders Dictionary of JToken Outgoing AS2 message header details isNrrEnabled Boolean Whether to use default value if the value isn't known isMdnExpected Boolean Whether the MDN is expected. mdnType Enum Allowed values: NotConfigured, Sync, and Async As2 MDN Track Record Message Properties schema { "direction": "", "messageId": "", "originalMessageId": "", "dispositionType": "", "isMessageFailed": "", "isMessageSigned": "", "isNrrEnabled": "", "statusCode": "", "micVerificationStatus": "", "correlationMessageId": "", "incomingHeaders": { }, "outgoingHeaders": { } } The following table describes the properties in the JSON schema for message properties in an AS2 MDN track record. Property Type Description direction String Direction of the message flow, which is either receive or send messageId String AS2 message ID originalMessageId String AS2 original message ID dispositionType String MDN disposition type value isMessageFailed Boolean Whether the AS2 message failed isMessageSigned Boolean Whether the AS2 message was signed isNrrEnabled Boolean Whether to use the default value if the value isn't known statusCode Enum Allowed values: Accepted, Rejected, and AcceptedWithErrors micVerificationStatus Enum Allowed values: NotApplicable, Succeeded, and Failed correlationMessageId String Correlation ID, which is the ID for the original message that has the MDN configured incomingHeaders Dictionary of JToken Incoming message header details outgoingHeaders Dictionary of JToken Outgoing message header details X12 transaction set Track Record Message Properties schema { "direction": "", "interchangeControlNumber": "", "functionalGroupControlNumber": "", "transactionSetControlNumber": "", "CorrelationMessageId": "", "messageType": "", "isMessageFailed": "", "isTechnicalAcknowledgmentExpected": "", "isFunctionalAcknowledgmentExpected": "", "needAk2LoopForValidMessages": "", "segmentsCount": "" } The following table describes the properties in the JSON schema for message properties in a X12 transaction set track record. Property Type Description direction Enum Direction of the message flow, which is either receive or send interchangeControlNumber String Interchange control number functionalGroupControlNumber String Functional control number transactionSetControlNumber String Transaction set control number CorrelationMessageId String Correlation message ID, which is a combination of {AgreementName}{GroupControlNumber}{TransactionSetControlNumber} messageType String Transaction set or document type isMessageFailed Boolean Whether the X12 message failed isTechnicalAcknowledgmentExpected Boolean Whether the technical acknowledgment is needed isFunctionalAcknowledgmentExpected Boolean Whether the functional acknowledgment is needed needAk2LoopForValidMessages Boolean Whether the AK2 loop is required for a valid message segmentsCount Integer Number of segments in the X12 transaction set X12 transaction set acknowledgment Track Record Message Properties schema { "direction": "", "interchangeControlNumber": "", "functionalGroupControlNumber": "", "respondingfunctionalGroupControlNumber": "", "respondingFunctionalGroupId": "", "respondingtransactionSetControlNumber": "", "respondingTransactionSetId": "", "statusCode": "", "processingStatus": "", "CorrelationMessageId": "", "isMessageFailed": "", } The following table describes the properties in the JSON schema for message properties in a X12 transaction set acknowledgement track record. Property Type Description direction Enum Direction of the message flow, which is either receive or send interchangeControlNumber String Interchange control number of the functional acknowledgment. The value populates only for the send side where functional acknowledgment is received for the messages sent to partner. functionalGroupControlNumber String Functional group control number of the functional acknowledgment. The value populates only for the send side where functional acknowledgment is received for the messages sent to partner. respondingfunctionalGroupControlNumber String The responding interchange control number respondingFunctionalGroupId String The responding functional group ID, which maps to AK101 in the acknowledgment respondingtransactionSetControlNumber String The responding transaction set control number respondingTransactionSetId String The responding transaction set ID, which maps to AK201 in the acknowledgment statusCode Boolean Transaction set acknowledgment status code segmentsCount Enum Acknowledgment status code with these permitted values: Accepted, Rejected, and AcceptedWithErrors processingStatus Enum Processing status of the acknowledgment with these permitted values: Received, Generated, and Sent CorrelationMessageId String Correlation message ID, which is a combination of {AgreementName}{GroupControlNumber}{TransactionSetControlNumber} isMessageFailed Boolean Whether the X12 message failed X12 interchange Track Record Message Properties schema { "direction": "", "interchangeControlNumber": "", "isTechnicalAcknowledgmentExpected": "", "isMessageFailed": "", "isa09": "", "isa10": "", "isa11": "", "isa12": "", "isa14": "", "isa15": "", "isa16": "" } The following table describes the properties in the JSON schema for message properties in a X12 interchange track record. Property Type Description direction Enum Direction of the message flow, which is either receive or send interchangeControlNumber String Interchange control number isTechnicalAcknowledgmentExpected Boolean Whether the technical acknowledgment is configured in the X12 agreement isMessageFailed Boolean Whether the X12 message failed isa09 String X12 document interchange date isa10 String X12 document interchange time isa11 String X12 interchange control standards identifier isa12 String X12 interchange control version number isa14 String X12 acknowledgment is requested isa15 String Indicator for test or production isa16 String Element separator X12 interchange acknowledgment Track Record Message Properties schema { "direction": "", "interchangeControlNumber": "", "respondingInterchangeControlNumber": "", "isMessageFailed": "", "statusCode": "", "processingStatus": "", "ta102": "", "ta103": "", "ta105": "" } The following table describes the properties in the JSON schema for message properties in a X12 interchange acknowledgement track record. Property Type Description direction Enum Direction of the message flow, which is either receive or send interchangeControlNumber String Interchange control number of the technical acknowledgment that's received from partners respondingInterchangeControlNumber String Interchange control number for the technical acknowledgment that's received from partners isMessageFailed Boolean Whether the X12 message failed statusCode Enum Interchange acknowledgment status code with these permitted values: Accepted, Rejected, and AcceptedWithErrors processingStatus Enum Acknowledgment status with these permitted values: Received, Generated, and Sent ta102 String Interchange date ta103 String Interchange time ta105 String Interchange note code X12 functional group Message Properties schema { "direction": "", "interchangeControlNumber": "", "functionalGroupControlNumber": "", "isTechnicalAcknowledgmentExpected": "", "isFunctionalAcknowledgmentExpected": "", "isMessageFailed": "", "gs01": "", "gs02": "", "gs03": "", "gs04": "", "gs05": "", "gs07": "", "gs08": "" } The following table describes the properties in the JSON schema for message properties in a X12 functional group track record. Property Type Description direction Enum Direction of the message flow, either receive or send interchangeControlNumber String Interchange control number functionalGroupControlNumber String Functional control number isTechnicalAcknowledgmentExpected Boolean Whether the technical acknowledgment is configured in the X12 agreement isFunctionalAcknowledgmentExpected Boolean Whether the functional acknowledgment is configured in the X12 agreement isMessageFailed Boolean Whether the X12 message failed gs01 String Functional identifier code gs02 String Application sender's code gs03 String Application receiver's code gs04 String Functional group date gs05 String Functional group time gs07 String Responsible agency code gs08 String Identifier code for the version, release, or industry X12 functional group acknowledgment Message Properties schema { "direction": "", "interchangeControlNumber": "", "functionalGroupControlNumber": "", "respondingfunctionalGroupControlNumber": "", "respondingFunctionalGroupId": "", "isMessageFailed": "", "statusCode": "", "processingStatus": "", "ak903": "", "ak904": "", "ak9Segment": "" } The following table describes the properties in the JSON schema for message properties in a X12 functional group acknowledgement track record. Property Type Description direction Enum Direction of the message flow, which is either receive or send interchangeControlNumber String Interchange control number, which populates for the send side when a technical acknowledgment is received from partners functionalGroupControlNumber String Functional group control number of the technical acknowledgment, which populates for the send side when a technical acknowledgment is received from partners respondingfunctionalGroupControlNumber String Control number of the original functional group respondingFunctionalGroupId String Maps to AK101 in the acknowledgment functional group ID isMessageFailed Boolean Whether the X12 message failed statusCode Enum Acknowledgment status code with these permitted values: Accepted, Rejected, and AcceptedWithErrors processingStatus Enum Processing status of the acknowledgment with these permitted values: Received, Generated, and Sent ak903 String Number of transaction sets received ak904 String Number of transaction sets accepted in the identified functional group ak9Segment String Whether the functional group identified in the AK1 segment is accepted or rejected, and why WorkflowRunOperationInfo Column JSON schema WorkflowRunOperationInfo column of both AS2TrackRecords and EdiTrackRecords table captures details about the standard logic apps action. Please find JSON schema for Workflow run operation information. { "title": "WorkflowRunOperationInfo", "type": "object", "properties": { "Workflow": { "type": "object", "properties": { "SystemId": { "type": "string", "description": "The workflow system id." }, "SubscriptionId": { "type": "string", "description": "The subscription id of the workflow." }, "ResourceGroup": { "type": "string", "description": "The resource group name of the workflow." }, "LogicAppName": { "type": "string", "description": "The logic app name of the workflow." }, "Name": { "type": "string", "description": "The name of the workflow." }, "Version": { "type": "string", "description": "The version of the workflow." } } }, "RunInstance": { "type": "object", "properties": { "RunId": { "type": "string", "description": "The logic app run id." }, "TrackingId": { "type": "string", "description": "The tracking id of the run." }, "ClientTrackingId": { "type": "string", "description": "The client tracking id of the run." } } }, "Operation": { "type": "object", "properties": { "OperationName": { "type": "string", "description": "The logic app operation name." }, "RepeatItemScopeName": { "type": "string", "description": "The repeat item scope name." }, "RepeatItemIndex": { "type": "integer", "description": "The repeat item index." }, "RepeatItemBatchIndex": { "type": "integer", "description": "The index of the repeat item batch." }, "TrackingId": { "type": "string", "description": "The tracking id of the logic app operation." }, "CorrelationId": { "type": "string", "description": "The correlation id of the logic app operation." }, "ClientRequestId": { "type": "string", "description": "The client request id of the logic app operation." }, "OperationTrackingId": { "type": "string", "description": "The operation tracking id of the logic app operation." } } } } }🎉Built for Enterprise: Integration Account Premium SKU Hits General Availability
We are thrilled to announce the General Availability (GA) of the Premium SKU for Integration Account! Since the Preview release, we’ve incorporated enhancements to deliver greater reliability and enable Integration Accounts to seamlessly operate within VNETs—a critical requirement for enterprise workloads. These updates provide a secure, scalable foundation tailored for your B2B and EDI integrations. What’s New in GA? Availability Zone Support Integration Accounts now support Availability Zones by default, ensuring enhanced reliability and resilience. Customers can enable AZ support for the underlying storage to achieve a fully AZ-enabled architecture. VNET Support Integration Accounts can now operate within a VNET, enabling you to: Host both the Integration Account and its underlying storage in a secure VNET environment. Strengthen the security and isolation of your enterprise workflows. These features, combined with unlimited artifacts, ensure that Integration Account provides a secure, reliable, and scalable platform for running mission-critical B2B and EDI workloads. There are no changes to the pricing. The Premium SKU pricing will be like Standard Account Pricing and will be billed at the rate of $1.37 per hour. Don’t Miss: EDI Actions in Logic Apps Standard Complementing the Integration Account, EDI actions for different EDI standards (AS2, X12, EDIFACT) are available as built-in actions in Logic Apps Standard. These actions empower you to: Process messages individually or in batches. Handle payloads up to 100MB by default, with support for even larger sizes using higher compute tiers. Achieve secure and scalable message processing for your enterprise workflows. Do you have business requirements for handling even larger payloads? We’d love to hear from you! Use Cases Here are just a few examples of how businesses can leverage these new capabilities: Retail and Supply Chain: Automate purchase orders, shipping notices, and invoices using X12. Healthcare: Process claims and remittances securely with HIPAA-compliant EDIFACT transactions. Manufacturing: Optimize production schedules with automated order exchanges using AS2. Try It Today Start leveraging the Integration Account Premium SKU and EDI actions for your enterprise integrations either through Azure Portal or VS Code. For detailed documentation and best practices, check out our documentation page.📢 Announcement !! Premium Integration Account and Enhanced EDI Connectors
In today's fast-paced business landscape, the ability to seamlessly manage B2B and EDI workloads within a secure and scalable environment is super important. We're thrilled to launch the first round of capabilities that would help how you handle these critical tasks. Let's dive into the details...
