Over the past 7 years I have spent a lot of time integrating BizTalk and SAP systems. I probably built more interfaces for SAP than any other system. When new technology such as Windows Azure BizTalk Services surfaces I am always interested to understand what the experience looks like.
If you read my prior post in this series, you are probably wondering how it is possible to use Windows Azure BizTalk Services in the Windows Azure Cloud and connect to your On-Premise LOB Systems like SAP? Enter BizTalk Adapter Services.
BizTalk Adapter Services allows us to use the BizTalk Adapter Pack in order to connect to LOB systems. The BizTalk Adapter Services are hosted in IIS and leverage the Service Bus Relay (under the hood) in order to traverse Firewalls and NATs. Using the BizTalk Adapter Service is just another tool in our toolbox when achieving Hybrid integration.
Adapter Services Installation
I am now going to quickly install the BizTalk Adapter Services and then provide a walkthrough of how we can integrate with SAP. The scenario that we are going to walk through is part of a larger process that I won’t get into much detail within this blog but we have an SAP process were we need to feed sub-systems within the organization with Equipment data from SAP. We will get this equipment by calling a custom SAP RFC(BAPI).
The BizTalk Adapter Service is a component that we want to install on a Server within our Network. This machine does not require BizTalk Server to be present.
This is an important step as the account that we specify here will require access to SQL Server where configuration will be stored about our Relay Endpoints.
In this case I am using a local SQL Server instance. You can use SQL Express if you so desire but I have leveraged SQL 2008 R2 (SQL Server 2012 is also supported).
This step kinda reminds me of the BizTalk SSO Service password but they are not related or linked.
The BizTalk Adapter Service installation will be installing a Management Web Service. Since I am just using this for demo purposes I did not enable SSL.
Once we have finished installing the BizTalk Adapter Service we will discover a new database called BAService.
We will also discover a new entry in Server Explorer within Visual Studio called BizTalk Adapter Services.
If we right mouse click on BizTalk Adapter Services we have the ability to add a BizTalk Adapter Service by specifying the URL of the Management Service that was created as part of the installation process.
Once this Adapter Service has been added we can expand it and discover our LOB Targets.
We can add a new SAP target by right mouse clicking on SAP and selecting Add SAP Target.
We now need to specify our SAP connection information much like we would if we were adding Generated Items within a BizTalk Server 2013 solution. We need to specify the Application Server, the System Number, Client and Language. I recently blogged about connecting to SAP Messaging Servers. Not to worry these more advanced scenarios are supported by clicking on the Advanced button.
Next we need to provide our SAP credentials if we are not using Windows Credentials.
Much like the BizTalk Server experience we can search operations including IDOCs, BAPIs and RFCs. Do note that at this point we are only able to push messages to SAP. This means we can send an IDOC and call a BAPI/RFC and get the response back. SAP cannot push IDOCs or call an RFC that is hosted by the BizTalk Adapter Service.
Once we have found the artifact that we are looking for we can add it to the Selected operations list and then click the Next button.
Once again need to provide credentials that the BizTalk Adapter Service will use to connect to SAP.
This gets a little interesting. Much like in my previous blog post where we connected to a Service Bus Topic, we will use the production Service Bus connectivity information. So in this case I am going to leverage an existing Service Bus Namespace and credentials to enable Service Bus Relay capabilities.
We also have the ability to specify a Target sub-path that just allows us to organize our endpoints.
We now have a confirmation page that we can just click the Create button in order to finish the wizard.
With our SAP LOB Target created we can now drag that Target onto our canvas:
At this point we have just created an SAP target and added it to our canvas. but we have not actually generated our schemas that will be used within our solution. In order to generate these schemas we need to right mouse click on our SAP LOB Target and specify Add Schemas to Project.
We will once again be prompted for SAP credentials.
Within our solution, we will now find two schemas have been added. One is the core schema and the other is a schema for data types leveraged by the core schema.
A Web Request Schema, that we will expose externally to calling applications, is also needed. This schema is very simple with only two fields: Plant and EquipmentName.
Next we need to add a Map that will allow us to transform our Web Request message into our SAP Request message.
The map is pretty straight forward as we only need to map a couple fields.
A Map that will allow us to transform our SAP Response into our Web Response is also required.
Next, we need to add an Xml Request-Reply Bridge to our canvas by dragging it onto our canvas.
We now want to modify the Property page for this artifact as it will become part of our overall URI.
By double clicking on our Bridge, we have the ability to configure it. Within this configuration we will want to specify the Message Type for the message that we will be receiving from the calling application and the Message Type for the type of message we will be sending back to the calling application.
We also want to specify our two Transformations. The first one will take our Web Request and map it to our SAP Request. The second Transformation will take our SAP Response and map it to our Web Response.
Once our Bridge has been configured, we need to connect our Request Response Bridge to our SAP LOB Target. We can do so by dragging a Connector from our Toolbox and connecting our Bridge to our SAP LOB Target.
Routing messages is a core functionality within BizTalk Services. In order to route messages, we need to provide a filter condition that will allow us to specify messages to flow between the Bridge and the SAP LOB Target. In order to set this filter we need to click on the line that connects these two artifacts and then click on the Filter Condition.
Since we want all messages to flow to this LOB system we will choose Match All and click the OK button.
We also need to specify a SOAP Action much like we need to do with BizTalk Server. In order to do this we need to highlight the connection between the Bridge and LOB target and then click on Route Action.
In this case we want to specify a SOAP Action and then specify the action from our Request Schema. Much like the EAI/EDI Labs solutions we want to wrap our Expression around single quotes( ‘ ‘)
We are now almost ready to deploy our solution but before we can do that we need to specify our Deployment Endpoint. We can do so by clicking on any blank space on our canvas and then specifying our Deployment Endpoint address in the Property page.
Deploying our solution is as simple as right mouse clicking on our Visual Studio Solution file and selecting Deploy Solution.
In order to deploy our solution we will need to provide the Deployment Endpoint, ACS Namespace(for BizTalk Service environment), Issuer Name and Issuer Shared Secret.
Within a few seconds our solution will be deployed and will be ready for testing. Once again I can use the MessageSender application that is part of the BizTalk Services SDK. But, since looking at a black screen with white xml text isn’t very appealing, I created an ASP.Net Web application and borrowed the MessageSender class from the SDK project. In this case I have my Web Application running on a laptop that isn’t on the same network as the machine that is hosting the BizTalk Adapter Service.
Within the web application, we have the ability to provide a Plant and a wild card string representing a piece of equipment in order to get more details about where that piece of equipment has been deployed, the Manufacturer and Model Number.
Hopefully this walkthrough has provided you with some valuable insight on what it takes to integrate a Line of Business system like SAP with Windows Azure BizTalk Services. I can certainly envision scenarios where an organization uses an LOB system like SAP but may not have a dedicated integration platform to perform some of this integration. Windows Azure BizTalk Services may fill this void and enable some business scenarios that just may not have been possible for that organization. Consider another situation where you may have a SalesForce system that requires SAP data (maybe Equipment data ) and this type of functionality in BizTalk Services really becomes a business catalyst.
I also think that the BizTalk Adapter Service may provide some interesting Mobile use cases as well as we can now expose SAP data through the cloud in a secure manner.
While the scenario is a bit dated, I also wrote a similar article on how to submit IDOCs to SAP using the Windows Azure EAI/EDI Labs CTP which has now been superseded by Windows Azure BizTalk Services.