Using Service Bus EAI and EDI Labs to Integrate with an On-Premises SAP Server
Author: Nitin Mehrotra
Windows Azure BizTalk Services provides a rich set of integration capabilities enabling organizations to create hybrid solutions such that their customer or partner facing applications are hosted on Azure, while the data related to customers or partners is stored on-premises using LOB applications. In this article, we talk about how to set up a similar hybrid scenario using Azure BizTalk Services. To demonstrate how to integrate Azure applications with an on-premises LOB application using Azure BizTalk Services, let us consider a scenario involving two business partners, Fabrikam and Contoso.
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, 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:
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.
Note A Send operation on an IDOC is an operation that is exposed by the BizTalk Adapter Pack on any IDOC to send the IDOC to the SAP Server. BizTalk Adapter Service uses BizTalk Adapter Pack to connect to an SAP Server.
Fabrikam uses the Transform component available with Azure BizTalk Services 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.
Fabrikam uses the Windows Azure BizTalk Services Portal (TPM) portal available with Azure BizTalk Services to create and deploy an EDI agreement on Service Bus 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.
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. Fabrikam earlier exposed (as explained in bullet 1 above) the Send operation on ORDERS05 IDOC to enable partners to send PO messages using BizTalk Adapter Service.
Note For the Azure BizTalk Services December 2011 release, the EDI bridge deployed using the TPM portal does not support setting route actions, which are mandatory for setting SOAP action headers on the messages being sent to an LOB relay endpoint. So, as an intermediate step, Fabrikam configures the EDI agreement to route the transformed message to an XML bridge, which then routes the message to the relay endpoint at which the Send operation for ORDERS05 IDOC is exposed. As part of this intermediary routing, the XML bridge sets the required SOAP action headers on the message.
- Receives an X12 850 PO message over FTP.
Once this is set up, Contoso drops an X12 850 PO message to the FTP location and 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.
How to Use This Article
This tutorial is written around a sample, SAPIntegration, which is available as part of the download (SAPIntegration.zip) from the MSDN Code Gallery. You could either use the SAPIntegration sample and go through this tutorial to understand how the sample was built or just use this tutorial to create your own application. This tutorial is targeted towards the second approach so that you get to understand how this application was built. Also, to be consistent with the sample, the names of artifacts (e.g. schemas, transforms, etc.) used in this tutorial are same as that in the sample.
The sample available from the MSDN code gallery contains only half the solution, which can be developed at design-time on your computer. The sample cannot include the configuration that you must do on the EDI Portal on Azure. For that, you must follow the steps in this tutorial to set up your EDI pipeline. Even though Microsoft recommends that you follow the tutorial to best understand the concepts and procedures, if you really wish to use the sample, this is what you should do:
Download the SAPIntegration.zip package, extract the SAPIntegration sample and make relevant changes like providing your service namespace, issuer name, issuer key, etc. After changing the sample, deploy the application to get the endpoint URL at which the XML bridge is deployed.
Go to the EDI Portal, and configure the EDI Receive pipeline as described at Create and Deploy the EDI Receive Pipeline and follow the procedures to hook the EDI Receive pipeline to the XML bridge you already deployed.
Drop a test message at the FTP location configured as part of the agreement and verify that the application works as expected.
If the message is successfully processed, it will be routed to the SAP Server and you can verify the ORDERS IDOC using the SAP GUI.
If the EDI agreement fails to process the message, the failure/error messages are routed to a relay endpoint on Service Bus. To receive such messages, you must set up a relay receiver service that receives any message that comes to that specific relay endpoint. As part of the EDI agreement, you will specify this endpoint to receive notifications for messages that fail to be processed by the agreement. A receiver service (RelayReceiverService) is also provided as part of the SAPIntegration.zip package. You can use this service to receive the error messages explaining why the EDI agreement failed to process a PO message. More details on why you need this service and how to use it are available at Test the Solution.
- If the message is successfully processed, it will be routed to the SAP Server and you can verify the ORDERS IDOC using the SAP GUI.
In This Section