Add Aggregator pattern template for BizTalk migration

[ocag305]

Template Description

Azure Logic Apps Standard template implementing the Aggregator enterprise integration pattern for BizTalk Server migration. Aggregates messages from Azure Service Bus by CorrelationId with flat file decoding support.

Author

Reynaldo Montes de Oca
Email: reynaldom@microsoft.com

Harold Campos
Email: hcampos@microsoft.com

Key Features

• ✅ Aggregates messages by CorrelationId (BizTalk correlation sets equivalent)
• ✅ Flat file decoding with XSD schemas (BizTalk-compatible)
• ✅ Sequential convoy processing (BizTalk pattern replication)
• ✅ Built-in Service Bus operations (optimal performance)
• ✅ 8 configurable parameters
• ✅ Comprehensive error handling with scopes
• ✅ HTTP Response action for downstream integration

Template Components

• workflow.json (21 KB) - Complete workflow definition
• manifest.json (6 KB) - Metadata with 8 parameters
• parameters.json (0.9 KB) - ARM deployment parameters
• README.md (21.6 KB) - Documentation with BizTalk migration guide
• workflow-light.png - Light theme screenshot
• workflow-dark.png - Dark theme screenshot

Compliance Checklist

• All naming conventions followed (lowercase, hyphens)
• manifest.json complete (8 parameters with _#workflowname# suffix)
• parameters.json with ARM schema
• README.md with Microsoft Style Guide compliance
• Screenshots included (light + dark themes)
• No sensitive data
• BizTalk migration documentation
• Second person voice ("you/your")
• Sentence case for headings

Target Audience

Organizations migrating BizTalk Server Aggregator patterns to Azure Logic Apps Standard requiring CorrelationId-based message grouping with XSD schema support.

BizTalk Migration Context

This template replicates BizTalk Server functionality:

• Correlation Sets → CorrelationId property
• Sequential Convoy → Sequential processing mode
• Flat File Disassembler → Flat File Decoding action
• Aggregator Orchestration → ForEach + variables
• Exception Handlers → Scope-based error handling

Performance Guidance

The batch size recommendations in README.md are based on unit testing with various message sizes. No memory or processing issues were observed during testing. Recommendations serve as starting points; adjust based on your specific workload and monitoring.

Testing Completed

• ✅ Azure Service Bus queues (non-session)
• ✅ XSD schemas (BizTalk-exported)
• ✅ Batch sizes: 1-100 messages
• ✅ Sequential and parallel processing modes
• ✅ Error handling scenarios (malformed messages)
• ✅ Cross-platform deployment (ARM templates)

Documentation Highlights

Complete migration guide including:

• BizTalk component mapping table
• Pattern hierarchy explanation (Aggregator + Sequential Convoy)
• Code equivalents (C# orchestration vs JSON workflow)
• Migration steps and key differences
• Performance optimization guidelines
• Troubleshooting section

Version

• Version: 1.0.0
• Release Date: November 2025
• Logic Apps: Standard (stateful workflows)

[ocag305]

@microsoft-github-policy-service agree company="Microsoft"

[ocag305]

@wsilveiranz this is it

[wsilveiranz]

@ocag305 - I've looked at the workflow and found two things that might need updates:

1. You are not using peek-lock - so you are assuming customers would be ok with a fire and forget approach not processing messages in order?
2. You are adding a decode flat file as part of the process steps. This assumes a very specific message type - shouldn't this be another compose, with a generic name like (process message - and give examples on that shape on different processing type - decode, transform, xpath, etc) - if this will use the flat file, we should rename it to make it more specific.
3. Your process have a response action as the final result - but who would it be returning to, since there is no request open to receive that response? it might be better to have this calling a second workflow that processes or using a batch action?

[ocag305]

• You are not using peek-lock - so you are assuming customers would be ok with a fire and forget approach not processing messages in order?
• You are adding a decode flat file as part of the process steps. This assumes a very specific message type - shouldn't this be another compose, with a generic name like (process message - and give examples on that shape on different processing type - decode, transform, xpath, etc) - if this will use the flat file, we should rename it to make it more specific.
• Your process have a response action as the final result - but who would it be returning to, since there is no request open to receive that response? it might be better to have this calling a second workflow that processes or using a batch action?

@wsilveiranz

1. Yes, actually I am currently working on a peek-lock version.
   2 . Yes, it was thought as SDK BizTalk Aggregator Patten example which implements decode flat file shape in orchestrations.. I am thinking on "Decode_Flat_File_Invoice" or more generic "Process_Message_Content"
2. Absolutely, HTTP POST call to another workflow will be more generic and adaptable for Customers.

What do you think?