Condividi tramite


Tutorial and Sample on Integrating BizTalk Services with SAP

One of the key value propositions of BizTalk Services is to expose operation on on-premises LOB applications as endpoints on the cloud. This tutorial demonstrates how this can be done for an on-premises SAP Server.

 

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.

 

image