6. A Migration Strategy
AU Blob
Storage
AU Service Bus
each Customer Invoice has a
different property
AU Invoice Pre-
Processing
AU Customer 1 AU Customer 2 AU Customer 3 AU Customer 4
AU Customer 2
Invoice Post-
Processing
AU Customer 3
Invoice Post-
Processing
AU Customer 4
Invoice Post-
Processing
AU Customer 1
Invoice Post-
Processing
7. Key Design Assumptions
1. Using BizTalk Schemas, Maps and Trading Partner Agreements will
make migration quicker.
2. Azure Service Topics & Azure Storage to provide points of persistence.
• For retries in case of micro internet outages
• Publish subscribe model to replace the same in BizTalk Server.
3. Solutions can be migrated without touching any third –party
applications.
4. Transport protocols and message formats do not need to change.
7
10. Why I need an Integration Account
• Reuse BizTalk schemas and maps
• XML ->XML maps
• Flat file schemas
• AS2/EDIFACT message exchange
• Certificates
• Trading partners
• Trading partner agreements
10
11. Integration Accounts – XSLT Maps
The problem of XSLT extension objects.
• Custom functoids
• Microsoft Database lookup functoids
• Helper classes
I deconstructed into C# scripting functoids and separate database actions.
21. Azure Functions with Liquid Maps
https://github.com/olafloogman/functions-dotnet-
liquidtransform
9/1/2020
21
22. Conclusions
1. Using BizTalk Maps makes migration quicker.
2. Using Liquid Templates is hard for complex maps.
3. Integration Accounts are expensive.
4. Other custom solutions are not very well supported.
“We need a consistent tool to map messages in Azure.”
You can migrate BizTalk maps to Azure