🧩 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. 🧪 Scenario In this pattern, we’re focusing on the schema nodes shown below: 📸 Source & Destination Schemas (with loops highlighted) In the source schema: Under the parent node VehicleTrips, we have two sibling arrays: Vehicle → contains VehicleRegistration Trips → contains trip-specific values like VehicleID, Distance, and Duration In the destination schema: We're mapping into the repeating node Looping/Trips/Trip It expects each trip’s data along with a flattened VehicleRegistration value that combines both: The current trip’s VehicleID The corresponding vehicle’s VehicleRegistration The challenge? These two pieces of data live in two separate sibling arrays. 🧰 Try it yourself 📎 Download the sample files from GitHub Place them into the following folders in your Logic Apps Standard project: Artifacts → Source, destination and dependency schemas (.xsd) Map Definitions → .lml map file Maps → The .xslt file generated when you save the map Then right-click the .lml file and select “Open with Data Mapper” in VS Code. 🛠️ Step-by-step Breakdown ✅ Step 1: Set up the loop over Trips Start by mapping the repeating Trips array from the source to the destination's Trip node. Within the loop, we map: Distance Duration These are passed through To String functions before mapping, as the destination schema expects them as string values. As you map the child nodes, you will notice a loop automatically added on parent nodes (Trips->Trip) 📸 Mapping Distance and Duration nodes (context: we’re inside Trips loop) 🔍 Step 2: Use Index and Direct Access to bring in sibling loop values Now we want to map the VehicleRegistration node at the destination by combining two values: VehicleID (from the current trip) VehicleRegistration (from the corresponding vehicle) ➡️ Note: Before we add the Index function, delete the auto-generated loop from Trips to Trip To fetch the matching VehicleRegistration: Use the Index function to capture the current position within the Trips loop 📸 Index setup for loop tracking Use the Direct Access function to retrieve VehicleRegistration from the Vehicle array. 📘 Direct Access input breakdown The Direct Access function takes three inputs: Index – from the Index function, tells which item to access Scope – set to Vehicle, the array you're pulling from Target Node – VehicleRegistration, the value you want This setup means: “From the Vehicle array, get the VehicleRegistration at the same index as the current trip.” 📸 Direct Access setup 🔧 Step 3: Concatenate and map the result Use the Concat function to combine: VehicleID (from Trips) VehicleRegistration (from Vehicle, via Direct Access) Map the result to VehicleRegistration in the destination. 📸 Concat result to VehicleRegistration ➡️ Note: Before testing, delete the auto-generated loop from Vehicle to Trip 📸 Final map connections view ✅ Step 4: Test the output Once your map is saved, open the Test panel and paste a sample payload. You should see each Trip in the output contain: The original Distance and Duration values (as strings) A VehicleRegistration field combining the correct VehicleID and VehicleRegistration from the sibling array 📸 Sample Trip showing the combined nodes 💬 Feedback or ideas? Have feedback or want to share a mapping challenge? Open an issue on GitHubSumming it up: Aggregating repeating nodes in Logic Apps Data Mapper 🧮
Logic Apps Data Mapper makes it easy to define visual, code-free transformations across structured JSON data. One pattern that's both powerful and clean: using built-in collection functions to compute summary values from arrays. This post walks through an end-to-end example: calculating a total from a list of items using just two functions — `Multiply` and `Sum`. 🧾 Scenario: Line Item Totals + Order Summary You’re working with a list of order items. For each item, you want to: Compute Total = Quantity × Price Then, compute the overall OrderTotal by summing all the individual totals 📥 Input { "orders" : [ { "Quantity" : 10, "Price" : 100 }, { "Quantity" : 20, "Price" : 200 }, { "Quantity" : 30, "Price" : 300 } ] } 📤 Output { "orders" : [ { "Quantity" : 10, "Price" : 100, "Total" : 1000 }, { "Quantity" : 20, "Price" : 200, "Total" : 4000 }, { "Quantity" : 30, "Price" : 300, "Total" : 9000 } ], "Summary": { "OrderTotal": 14000 } } 🔧 Step-by-step walkthrough 🗂️ 1. Load schemas in Data Mapper Start in the Azure Data Mapper interface and load: Source schema: contains the orders array with Quantity and Price Target schema: includes a repeating orders node and a Summary → OrderTotal field 📸 Docked schemas in the mapper 🔁 2. Recognize the repeating node The orders array shows a 🔁 icon on <ArrayItem>, marking it as a repeating node. 📸 Repeating node detection 💡 When you connect child fields like Quantity or Price, the mapper auto-applies a loop for you. No manual loop configuration needed. ➗ 3. Multiply Quantity × Price (per item) Drag in a Multiply function and connect: Input 1: Quantity Input 2: Price Now connect the output of Multiply directly to the Total node under Orders node in the destination. This runs once per order item and produces individual totals: [1000, 4000, 9000] 📸 Multiply setup ➕ 4. Aggregate All Totals Using Sum Use the same Multiply function output and pass it into a Sum function. This will combine all the individual totals into one value. Drag and connect: Input 1: multiply(Quantity, Price) Input 2: <ArrayItem> Connect the output of Sum to the destination node Summary → OrderTotal 1000 + 4000 + 9000 = 14000 📸 Sum function ✅ 5. Test the Output Run a test with your sample input by clicking on the Open test panel. Copy/paste the sample data and hit Test. The result should look like this: { "orders": [ { "Quantity": 10, "Price": 100, "Total": 1000 }, { "Quantity": 20, "Price": 200, "Total": 4000 }, { "Quantity": 30, "Price": 300, "Total": 9000 } ], "Summary": { "OrderTotal": 14000 } } 🧠 Why this pattern works 🔁 Repeating to repeating: You’re calculating Total per order 🔂 Repeating to non-repeating: You’re aggregating with Sum into a single node 🧩 No expressions needed — it’s all declarative This structure is perfect for invoices, order summaries, or reporting payloads where both detail and summary values are needed. 📘 What's coming We’re working on official docs to cover: All functions including collection (Join, Direct Access, Filter, etc.) that work on repeating nodes Behavior of functions inside loops Real-world examples like this one 💬 What should we cover next? We’re always looking to surface patterns that matter most to how you build. If there’s a transformation technique, edge case, or integration scenario you’d like to see explored next — drop a comment below and let us know. We’re listening. 🧡 Special thanks to Dave Phelps for collaborating on this scenario and helping shape the walkthrough.🔁 Public Preview Refresh: More Power to Data Mapper in Azure Logic Apps
We’re back with a Public Preview refresh for the Data Mapper in Azure Logic Apps (Standard) — bringing forward some long-standing capabilities that are now fully supported in the new UX. In our initial announcement, we introduced a redesigned experience focused on usability, error handling, and improved mapping for complex schemas. As we continue evolving the tool, we’re working to bring feature parity with the classic experience, while layering in modern enhancements along the way. With this update, several existing capabilities from the legacy Data Mapper are now available in the new preview version — so you can bring your advanced scenarios forward with confidence. 🛠️ Run XSLT Inside Your Data Map The ability to apply XSLT has long been a powerful feature in Logic Apps, and we’re excited to bring Run XSLT support into the new UX. You can now invoke reusable transformation logic from your map, including: Enterprise-grade XSLT Predefined templates or logic from your BizTalk workflows How to try it out: Create a new data map. Right-click on the MapDefintions or Maps folder and click Create new data map Store the XSLT file under Artifacts -> DataMapper/Extension -> InlineXslt. Open the data map and search for Run XSLT in the functions panel. Select the function and simply select the function you want to run from the dropdown Connect to desired destination node. In my case, the function simply adds a "Placeholder" value for the Name node at destination, alongside an "EmployeeType" node. Note that you do not need to connect any source node to the XSLT function given this is custom XSLT logic that will be applied directly at destination node. Upon testing the map, right value is generated in the destination schema 🔍 Execute XPath to Extract Targeted Values Execute XPath is now supported in the new experience, giving you control to extract specific values from nested XML structures. This function is particularly useful for: Accessing attributes and nested elements Applying logic based on the structure or content of incoming data How to try it out: Search for Execute XPath in the functions panel. Select the function and add the expression you want to extract Map it to destination node. Here is what the map will look like: The test payload correctly creates multiple Address nodes at destination based on the Address node at source. 🧩 Use Custom XML Functions Custom XML functions allow you to define and reuse logic across your map. This helps reduce duplication and supports schema-specific transformations. Now that support is available in the new UX, you can: Wrap complex logic into manageable components Handle schema-specific edge cases with ease How to try it out: Add the .xml function file under Artifacts -> DataMapper/Extension -> Functions Open the data map and under Utility category of functions, select the new function. In our case, the xml function is called Age Connect function input to Date_of_Birth node at source and output to Age node at destination. The map will look something like this Test the map and notice that the age is calculated correctly at the destination node 🌒 Dark Mode Support in VS Code The new UX now respects Dark Mode in VS Code, giving you a visually cohesive and low-contrast authoring experience — perfect for long mapping sessions. No extra steps needed — Dark Mode works automatically based on your VS Code theme settings. ⚙️ How to Enable the New Experience If you haven’t yet tried the new UX: Open your Logic Apps (Standard) project in VS Code Go to Logic Apps (Standard) extension → Settings → Data Mapper Select Version ~2 You’ll find detailed walkthroughs in the initial preview announcement blog. 💬 We’d Love Your Feedback We’re continuously evolving the Data Mapper, and your feedback is key to getting it right — especially as we bring more advanced transformation scenarios into the new experience. 👉 Submit your feedback here 🐛 Found an issue or have a specific feature request? Let us know on GitHub Issues Thanks again for being part of the journey — more updates coming soon! 🚀
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...
