EDI Updates

• Support for EDIFACT – The BizTalk Services Portal can now be used to configure and deploy EDIFACT agreements between two trading partners. For information on creating EDIFACT agreements, see Create an EDIFACT Agreement.
• EDIFACT support in TPM OM API – You can also use the TPM OM REST-based APIs to create EDIFACT agreements. For a list of new entities that were added to support EDIFACT, see TPM OM API: Exposed Entities and Properties.
• Support for SAS authentication while routing to Service Bus queues/topics from EDI bridges – While routing to queues/topics from an EDI bridge, you can now also use SAS authentication, if required. Earlier, you could only authenticate with the Service Bus entities using the issuer name/issuer key pair.

EAI Updates

• Using Service Bus queues as message sources – You can now use Service Bus queues as message sources for a bridge. For more information, see Configure a Service Bus Queue Source.
• Using Service Bus topic subscriptions as message sources – You can now use Service Bus queues as message sources for a bridge. For more information, see Configure a Service Bus Subscription Source.

Setup and Management Updates

• No dependency on a local SQL Server installation – Earlier, if you were using BizTalk Adapter Service, you had to provide details about a local SQL Server installation where the details for LOB relay and LOB targets were stored. Now, that dependency is done with. After the updates in February, the details about LOB relays and targets are stored in the repository associated with your Azure BizTalk Service subscription. Additionally, the BizTalk Services SDK setup enables you to migrate the LOB relay/target configuration information from the local SQL Server installation to the configuration repository on Azure. For more information, see Migrate the BizTalk Adapter Service Runtime Environment.
• Backup and Restore using the Azure Portal – In the previous version of BizTalk Services, you could only backup or restore the BizTalk Services environment using REST APIs (see here and here). You can now also use the Azure Management Portal to perform the same operation (see here). In fact, you can use the portal to do an Ad hoc Backup or a Scheduled Backup.  You can also restore from a backup using the portal. See here.
• Viewing BizTalk Services Operation Logs – Windows Azure already had the feature to provide operational logs for different services. BizTalk Services now ties into this feature to provide logs for management operations related to a BizTalk Services subscription. For more information, see here.

The sample touches upon the following:

• Configuring a bridge
• Configure multiple destinations for a bridge
• Routing to multiple destinations based on a filter
• Deploying a BizTalk Service project
• Sending message to a bridge

Do you want more samples for BizTalk Services? Leave a comment on this post with your requirements and I’ll ping you back.

• The tutorial is available at https://msdn.microsoft.com/en-us/library/windowsazure/dn617107.aspx.
• The entire solution is set up using a bunch of different samples. The location to download all the samples is provided at https://msdn.microsoft.com/en-us/library/windowsazure/dn617105.aspx.

Business scenario

Contoso, Ltd. is a car manufacturing company looking to build a system, Cloud Car, that provides rich experience to their customers by enabling connectivity to cloud and the rich set of services that are available via the cloud. To start with, Contoso, Ltd. envisions a modern application that enables customers to search for available services in the surrounding areas on the go (gas stations, restaurants, etc.), browse through the service catalogs they offer (fuel prices, restaurant menus, etc.), and then order the service they wish to use. As a first step, Contoso, Ltd. plans to start this service with a restaurant, Fourth Coffee. Contoso, Ltd. intends to build an end-to-end system that is scalable to easily onboard more and more partners, while also providing rich end-user experience to the customers that will be using the service. At a high-level, Contoso, Ltd. wants to enable the following end-to-end application experience for its customers:

• A customer of Contoso, Ltd. launches the Cloud Car application from the car, and chooses to look at the nearby dining options.
• The Cloud Car application determines the car location and suggests the nearest location of Fourth Coffee, a dine-in/drive-in restaurant.
• After selecting the Fourth Coffee restaurant, the customer is presented with the menu available at the restaurant. The customer selects the items of interest and puts in the order.
• The Fourth Coffee Restaurant is notified of the customer order, processes it, and sends the invoice back to Contoso, Ltd., which in turn sends it to the customer via e-mail.

Implementing the Business Scenario

To implement the business scenario, Contoso, Ltd. decides to use Microsoft integration offerings, especially, Windows Azure BizTalk Services. For the end-user application, one the customer can use from their cars, Contoso, Ltd. decides to use a Windows 8 modern app.

Before understanding the application flow, let us assume that one of the prerequisites for the application flow is already completed, which is Fourth Coffee must have already registered itself as a partner in the BizTalk Services portal. Fourth Coffee uses the Trading Partner Management OM REST API to onboard itself as a partner. It also uses the REST API to register the menu options it provides for dining.

After this one-time task is completed, this is how the application flows:

1. A customer of Contoso, Ltd. uses the Cloud Car application, which is a Windows 8 modern app. Using the app, the customer selects the nearest location of the Fourth Coffee restaurant, looks at the menu, selects the items of choice, and places the order.
   The order request, which is in the form of an XML message, is sent to a BizTalk Services bridge (purchase order bridge) that Contoso, Ltd. deploys as part of its BizTalk Services subscription.
2. The bridge processes the message (validates the message against the expected message schema, transforms it to an X12 purchase order (850), etc.), and then routes it to an Azure blob (purchase order blob). The bridge also inserts the purchase order message into an on-premise SQL Server database.
3. An Azure worker role continually polls the Azure blob and reads the 850 purchase order message from the blob.
4. The worker role routes the purchase order from the blob to an EDI Send bridge, also deployed under Contoso, Ltd.’s BizTalk Services subscription.
5. The EDI Send bridge processes the purchase order and routes it to another Azure blob for the supplier, Fourth Coffee.
6. Using an application, the Fourth Coffee restaurant reads the message from the blob, accepts or rejects the order, and generates an X12 810 invoice.
7. The Fourth Coffee restaurant application sends the EDI X12 invoice back to the EDI receive bridge deployed by Contoso, Ltd.
8. The EDI receive bridge, processes the incoming X12 810 invoice, and then routes the message to another EAI bridge (invoice bridge) deployed by Contoso, Ltd. to process the invoice messages.
9. The EAI invoice bridge does the following:
   • Processes the message and routes it to an Azure blob storage.
   • Inserts the invoice data into an on-premise SQL Server database.
   • Sends an e-mail to the customer with the order details.

The following illustration depicts the end-to-end scenario.

Business Scenario

Fabrikam and Contoso are two business partners. Fabrikam (the retailer) sends sales order messages to Contoso (the supplier). Contoso maintains all the sales order data in table called Orders, which is housed in a SQL Server database within Contoso’s premises. Fabrikam sends flat-file messages to Contoso using an FTP server. Hence, Contoso has to implement a solution on Windows Azure, which enables the following:

• Contoso must pull the flat file messages from the FTP server at which Fabrikam drops the sales order messages.
• Contoso must process the message received from Fabrikam and map it to the message for inserting the sales order in its SQL Server database.

To enable this scenario, Contoso does the following:

• Generates the schema of the flat-file message that it will receive from Fabrikam.
• Configures an XML One-Way Bridge as part of the BizTalk Service project to enable message validation and transformation. This bridge takes a flat-file message, validates it against the schema generated earlier, and then transforms it to the schema required to enter a message into the SQL Server database.
• Uses BizTalk Adapter Service to connect to the on-premise SQL Server database from the XML One-Way Bridge deployed under the BizTalk Services subscription

Links

• The tutorial is available at https://msdn.microsoft.com/en-us/library/windowsazure/hh949811.aspx
• The sample is available at https://code.msdn.microsoft.com/Use-BizTalk-to-insert-flat-cb4dc58d

The Trading Partner agreement migration tool does just that. You can download the tool (TPMMigration) from the Tools category at this download location. TPMMigration is a wizard-based tool that will ask you for your on-premises BizTalk Server environment, retrieve the trading partners and trading partner agreements in that BizTalk Server environment, and then let you select which partners and agreements you want to migrate to Azure BizTalk Services Portal. You can find more information about the tool usage, etc. from the Readme that is included with the tool.

As organizations look to move some part of their integration application workloads to Windows Azure using the recently GA’ed Windows Azure BizTalk Services, we are in need of tools that can help migrate the on-premises artifacts to Azure artifacts. To start with, there’s one such tool that can be used to migrate the BizTalk Server maps to BizTalk Services transforms.

The tool, called the BtmToTrfmConvertor, can be downloaded from the Tools category available at this download location. The syntax for using the tool is:

BtmToTrfmConvertor.exe <Full .BTM File Path> [optional]<output .trfm file path>

The tool comes with a well documented README.txt that provides more info, usage tips, and limitations for the tool. You can find more information for the tool at https://msdn.microsoft.com/en-us/library/windowsazure/hh949812.aspx.

• The tutorial is available at https://msdn.microsoft.com/en-us/library/windowsazure/hh859742(v=vs.103).aspx
• The sample is available at https://code.msdn.microsoft.com/Integrating-Windows-Azure-eaf7bb9d

Here’s a quick description of the scenario demonstrated in the tutorial/sample. You can read more about this, and how it is achieved using BizTalk Services, from the above links.

Business Scenario

Contoso sends a purchase order (PO) message to Fabrikam in an X12 Electronic Data Interchange (EDI) format using the PO (X12 850) schema. Fabrikam (that uses an SAP Server to manage partner data), accepts PO from its
partners using the ORDERS05 IDOCS. To enable Contoso to send a PO directly to Fabrikam’s on-premises SAP Server, Fabrikam decides to use Windows Azure’s integration offering, Windows Azure BizTalk Services, to set up a hybrid
integration scenario where the integration layer is hosted on Azure and the SAP Server is within the organization’s firewall. Fabrikam uses Azure BizTalk Services in the following ways to enable this hybrid integration scenario:

1. Fabrikam uses the BizTalk Adapter Service component available with Azure BizTalk Services to expose the Send operation on ORDERS05 IDOC as an operation using Service Bus relay endpoint. Contoso also creates the schema for Send operation using BizTalk Adapter Service.
2. Fabrikam uses the Transform component available with Azure BizTalk Service to create a map to transform the PO message in X12 format into the schema required by the SAP Server to invoke the Send operation on the ORDERS05 IDOC.
3. Fabrikam uses the BizTalk Services portal available with Azure BizTalk Services to create and deploy an EDI agreement Azure that processes the X12 850 PO message. As part of the message processing, the agreement also does the following - Receives an X12 850 PO message over FTP, Transforms the X12 PO message into the schema required by the SAP Server using the transform created earlier, and then routes the transformed message to another XML bridge that eventually routes the message to a relay endpoint created for sending a PO message to an SAP Server.

Once this is set up, Contoso drops an X12 850 PO message to the FTP location. The message is consumed by the EDI receive pipeline, which processes the message, transforms it to an ORDERS05 IDOC, and routes it to the intermediary XML bridge. The bridge then routes the message to the relay endpoint on Service Bus, which is then sent to the on-premises SAP Server. The following illustration represents the same scenario.

EAI Bridges are configured and deployed using Visual Studio and can be used for:

• Processing flat-file or XML messages against specified schemas
• Transforming messages from one scheme to another
• Routing messages to backend LOB applications like SQL Server, SAP, Oracle, and Siebel
• Routing messages to Service Bus relay endpoints, Queues, and topics
• Including custom-code as part of message processing
• Etc.

EDI Bridges are configured and deployed using the BizTalk Services Portal and can be used for:

• EDI message transfer between trading partners by using agreements
• Sending messages to partners in batches
• Routing messages to other endpoints deployed on Azure such as Service Bus Queues/Topics/relay endpoints, BizTalk Service Bridges, etc
• Receiving acknowledgements for trading partners for successfully delivered messages,
• Etc.

Needless to say that the capability to transfer messages from EDI Bridge to EAI bridge enables various enterprise scenarios for the end users. For example, you could have a scenario where an X12 message is transferred from the EDI bridge to EAI bridge, transformed into a format to insert that message into a SQL Server, and is then finally inserted in the SQL Server database. However, there’s one important consideration to make while setting up message transfer from EDI bridge to EAI bridge.

EDI To EAI Message Transfer

A single EAI bridge can be configured to process flat-file and/or XML messages. The bridge does this by using an “invisible” Decode stage in the bridge configuration. This Decode stage is enabled or disabled depending on the “content-type” header set on the incoming message. If the “content-type” of the incoming message is text/plain, the Decode stage kicks in, converts it to XML and the rest of the message processing happens on the XML message. However, if the “content-type” of the message is not text/plain, the Decode stage is skipped and the remaining processing happens.

Given that EDI bridges process X12 messages, which are flat-file messages, the content-type for the message is always set to text/plain, every time a message is routed to the EAI bridge, it has that header set, resulting in errors. So, if you are trying to send a message from EDI to EAI bridge, you must perform the following steps as part of the EDI agreement configuration that processes the message.

1. Under Receive Settings for the agreement, click the Route page.
2. Open the routing rule you have created under the Route Setting section. If you are creating the rule only now, skip this step.
3. Under Route action section, specify the values as shown in the screen capture and save your changes. Redeploy the agreement.

With this configuration, when the message is routed from the EDI bridge to the EAI bridge, the content-type header is set to application/xml and the message is processed accordingly by the EAI bridge.

References

• Business To Business Messaging
• Rich Messaging Endpoints
• Flat-file Support

• Tutorial - https://msdn.microsoft.com/en-us/library/windowsazure/jj158971.aspx
• Sample - https://code.msdn.microsoft.com/Use-BizTalk-Service-to-ac990346

Feedback on these is welcome. You can leave your comments as part of this blog post.

You can download the sample from the following links:

• Creating an X12 Agreement in BizTalk Services Using the TPM OM API
• Creating an AS2 Agreement in BizTalk Services Using the TPM OM API

More Resources for BizTalk Services TPM OM

• Trading Partner Management Object Model (TPM OM): API Reference
• Trading Partner Management Object Model: REST Endpoint
• TPM OM API: What to do Where?
• TPM OM API: Request and Response Headers
• TPM OM API: Exposed Entities and Properties