Guidance on Migrating BizTalk Server 2010 EDI Solutions to Windows Azure
Author: Tim Wieman
Written using: Windows Azure BizTalk Services – December 2011 release.
Electronic Data Interchange (EDI) is one of the most prevalent means by which businesses and business entities exchange data electronically. BizTalk Server has had EDI support for over a decade, since the initial BizTalk Sever 2000 release (see http://go.microsoft.com/fwlink/?LinkID=237312. With Azure BizTalk Services, Microsoft continues the support for EDI solutions on the Windows Azure Platform.
While some customers will look at Azure BizTalk Services as a "greenfield" platform for new EDI solutions, many customers have current BizTalk Server EDI solutions that they may want to migrate to Windows Azure. Because Azure BizTalk Services is architected based on the same concepts as BizTalk Server 2010 EDI architecture, it is possible to migrate BizTalk Server EDI solutions to Azure BizTalk Services.
This document discusses some of the differences and issues involved with migrating a BizTalk Server 2010 EDI solution to Azure BizTalk Services. This document assumes a working knowledge of BizTalk Server 2010 EDI processing and Trading Partner Agreements.
As with BizTalk Server 2010, EDI processing in Azure BizTalk Services is built around a Trading Partner Management (TPM) solution and Trading Partner Agreements. Simple EDI processing scenarios are very easy to implement in Azure BizTalk Services. In fact, you can implement sending and receiving EDI messages to trading partners without configuring any Windows Azure Compute instances (Web or Worker roles), any Windows Azure SQL Databases, or any Windows Azure storage accounts. More complex scenarios will require tying in workflows or other service processing "around the edges" of a Trading Partner agreement, that is, before or after Trading Partner Agreement EDI Bridge processing.
The following is an example of an EDI message flow in Azure BizTalk Services:
The following sequences of events occur during an EDI message flow in Azure BizTalk Services.
An EDI message is received from trading partner, Fabrikam. For receiving EDI messages from trading partners, Azure BizTalk Services supports transport protocols such as FTP, AS2, and HTTP/S.
The trading partner agreement receive-side processing disassembles the EDI message to XML format. You can route the disassembled EDI message (in XML format) to Service Bus endpoints such as a Service Bus Relay endpoint, Service Bus Topic, Service Bus Queue, or Service Bus Bridge.
The disassembled XML messages could then be received from the endpoint for further custom processing. These Service Bus endpoints could be processed by an on-premises process or a Windows Azure Compute instance to further process the message in a Windows Workflow (WF) or Windows Communication Foundation (WCF) service, for example.
The "send-side processing" of the trading partner agreement then assembles the XML message into EDI format and sends it to trading partner, Contoso. For sending EDI messages to trading partners, Azure BizTalk Services supports the same protocols as those used for receiving EDI messages.
This document further discusses migrating some of the different BizTalk Server artifacts used in an EDI solution to Azure BizTalk Services.
Send/Receive Ports to Trading Partners
In BizTalk Server you would set up Receive Locations and Receive Ports to receive EDI/XML messages from trading partner companies, and you would set up Send Ports to send EDI/XML messages to partner trading companies. You would then tie up these ports to a trading partner agreement using the BizTalk Server Administration console. In Azure BizTalk Services, the locations where you receive messages from trading partners and where you send messages to trading partners are configured as part of the trading partner agreement in the BizTalk Services Portal. So you do not really have the concept of "send ports" and "receive locations", per se, in Azure BizTalk Services.
In addition, the supported protocols for sending and receiving EDI messages in Azure BizTalk Services are more limited than what is available in BizTalk Server.
For the first release of Azure BizTalk Services, the EDI bridges (“pipelines” in BizTalk Server parlance) are "closed". That is, you cannot add your own custom activities ("pipeline components" in BizTalk Server parlance) to a bridge. Any custom work must be done outside of the EDI bridge in your application, either before or after the bridge processing in the Trading Partner agreement.
You can insert a publish/subscribe flow with custom code and/or using Service Bus Messaging Queues and Topics before the trading partner agreement receives the message, or after the agreement processes the message and routes it to a Service Bus endpoint.
See Scenarios/Message Flow for the message flow pattern.
If you are familiar with the BizTalk Server 2010 Trading Partner Agreements used for EDI processing, then Azure BizTalk Services trading partner agreements will look very familiar. Most of the agreement settings are the same and use the same terminology. In some cases, the agreement settings are much simpler compared to the same settings in BizTalk Server 2010.
The Windows Azure BizTalk Services supports X12 EDI and AS2 transport. EDIFACT support is being evaluated for a future release. The ability to import or migrate BizTalk Server trading partner agreements to Azure BizTalk Services in a future release is also being evaluated.
Azure BizTalk Services includes EDI schemas which can be used in Azure BizTalk Services solutions. In addition, BizTalk Server 2010 EDI schemas can also be used with Azure BizTalk Services. Thus, you will be able to directly take your BizTalk Server EDI schemas and use them in the EDI portion of your Azure BizTalk Services solution.
Migrating maps from BizTalk Server EDI solutions to Azure BizTalk Services could be one of the more complex artifacts to migrate (depending on map complexity). The mapping tool used for Azure BizTalk Services is different than the BizTalk mapper. Even though the mapper looks mostly the same, the underlying map format is different. The functoids (called map operations in Azure BizTalk Services) available to the users are different as well. In effect, one cannot directly use a BizTalk map in Azure BizTalk Services.
One very important difference is that not all the functoids available in BizTalk Server 2010 are available as map operations in Azure BizTalk Services. A notable difference is the lack of a "Scripting" map operation in Azure BizTalk Services Transforms.
New Transform Operations
While the list of Transform map operations available may seem quite different from the BizTalk mapper, Azure BizTalk Services Transforms will have new ways of accomplishing tasks, compared to the BizTalk mapper.
For example, Azure BizTalk Services Transforms have List Operations available. This was not available in the BizTalk mapper. The List Operations enable you to create and operate on a "List", where a list is a set of items (also known as "rows") and where each item can have multiple members (also known as "columns"). You can sort the list, select items based on a condition, etc.
Another example of new functionality in Azure BizTalk Services Transforms are the Loop Operations. It is difficult to create nested loops in the BizTalk Server mapper. Thus, the Loop map operations are added for the Azure BizTalk Services Transforms.
Yet another example is the If-Then-Else Expression operation. Doing an if-then-else operation was possible in the BizTalk mapper, but it required multiple functoids to accomplish a seemingly simple task.
Migrating BizTalk Server Maps
We are currently exploring the possibility of providing a migration tool that would at least partially convert BizTalk maps to Azure BizTalk Services Transforms. The tool would not convert areas in the map that use BizTalk functoids for which there is not an analogous Azure BizTalk Services map operation (such as some of the Scripting functoids).
However, for BizTalk mapper functoids that cannot be converted, the migrated Azure BizTalk Services Transform could have "placeholder" shapes with a note that describes the original operation. For example, for a Scripting functoid migration, a placeholder shape could be inserted in the migrated transform, with a note that includes the original script. This would allow you to try to manually implement the same functionality in a different way, possibly using new map operations available in Azure BizTalk Services Transforms. At least a partial conversion is feasible, with the likelihood of full conversion increasing as map complexity decreases.
If you need to migrate BizTalk Server orchestration processing to Windows Azure, the orchestrations would need to be rewritten because Windows Azure does not support running BizTalk Server orchestrations. You could rewrite the orchestration functionality in a Windows Workflow Foundation 4.0 (WF4) service. This would be a complete rewrite as there is currently no migration from BizTalk orchestrations to WF4. Here are some resources for Windows Workflow:
How to integrate a WCF Workflow Service with Service Bus Queues and Topics by Paolo Salvatori. See here (http://go.microsoft.com/fwlink/?LinkId=237313).
Building apps with Windows Workflow Foundation and Windows Azure session from the Build 2011 conference. See here (http://go.microsoft.com/fwlink/?LinkId=237314).
Windows Workflow Foundation Developer Center on MSDN. See here (http://go.microsoft.com/fwlink/?LinkId=237315).
Windows Workflow Foundation 4 (WF4) documentation on MSDN. See here (http://go.microsoft.com/fwlink/?LinkId=237316).
Following are a few complexities with the Azure BizTalk Services December 2011 Release.
Flat File Processing
Other than ASC X12 EDI, there is no flat file processing support in the December release of Azure BizTalk Services. Thus, if you have the need to send or receive flat files (other than EDI) in your Azure BizTalk Services solution, then you will need to implement your own flat file assembler and/or disassembler either in a Windows Azure Compute instance that runs before or after the Azure BizTalk Services processing or in a hybrid scenario that does the flat file assembly/disassembly on-premises.
Support for flat file assembly / disassembly for a later release of Azure BizTalk Services is being evaluated.
BizTalk Server EDI processing has the concept of "Fallback Agreements". Azure BizTalk Services does not have a Fallback Agreement concept, at least not in the first production release. See BizTalk documentation topics The Role of Agreements in EDI Processing and Configuring Global or Fallback Agreement Properties for information on how Fallback Agreements are used in BizTalk Server.
In the first release of Azure BizTalk Services, de-batching is supported for inbound EDI messages. Batching is not supported in the December 2011 Labs release, but will be supported in a later release.
As Azure BizTalk Services functionality progresses to its first public CTP release and on to future releases, the available functionality will change. As the releases progress, we look forward to supporting increased functionality to facility business to business (B2B) communication and processes.
Other ResourcesDeveloping Enterprise Applications with Windows Azure