Over the last couple of years that I have been evangelizing for Telerik, I have met a lot of customers and in particular enterprise customers. Most of the big enterprises have SAP deployed in their organization. This gives them the flexibility of having point to point information with respect to their projects or revenue or even an employee. In short SAP is one of the widely used system in enterprises. But it comes with its own environment and applications. The number one question from enterprise customers for us has always been “how does your offering work with SAP?” A fair question especially when it comes to engaging with a third party vendor. This question was more of a high priority question when it came to Mobile teams in the enterprises. How soon can you go to market with an application and expose the SAP data.

The questions from the enterprises led me to write this 2 part series on how to mobilize your SAP data. This blog post is the first in this series and below is how I have planned out the 3 part series blog post:

• Mobilizing Your SAP Data with Kendo UI Mobile – Get the Environment Ready – Part 1
• Mobilizing Your SAP Data – Mobile App Development – Part 2

If you are as excited as I am, then be with me in this journey of 2 blog posts. So let’s get started.

What is SAP ERP?

According to the dictionary of the web i.e. Wikipedia, SAP ERP is defined as follows:

SAP ERP is an Enterprise Resource Planning software which provides an integrated solution that incorporates key business functions of an organization.

I will not be delving too much in to SAP as a software as that is not the intention of the blog post. Now that we know what is SAP let’s see how to expose data from SAP so that applications outside of SAP can consume them.

SAP Netweaver Gateway:

In order for the SAP data to be exposed to outside world you use a technology called SAP Netweaver Gateway to develop REST based ODATA services. According to SAP, Netweaver Gateway is defined as:

Technology that provides a simple way to connect devices, environments and platforms to SAP software based on market standards.

SAP Netweaver Gateway offers connectivity to SAP applications using any programming language and you do not need to have SAP knowledge. SAP Netweaver Gateway leverages the REST Services and OData/ATOM protocols for data exchange.

SAP Netweaver Gateway System

Again I won’t be getting into too much details as to how you do this. SAP Community Network (SCN) has tutorials on how to do this.

SAP Netweaver Gateway Demo System:

If you are eager to try a SAP Netweaver Gateway Service, well we are in luck. SAP had released a set of Demo System for public usage. You can read more about the demo services here: http://scn.sap.com/docs/DOC-31221?rid=/webcontent/uuid/1051f6d9-e87a-2e10-d188-e2786c7878b1#section6. Following are the demo systems available for consumption:

• Flight Example
• Bank Example
• Sales Order Example
• GWDEMO/EPM Example
• New EPM Sample

To get access to the demo system, you will need to follow the instructions provided here: http://scn.sap.com/docs/DOC-40986

Sales Order Example:

For the sake of this exercise, I will be using the Sales Order Example service. This service is based on the common scenario of Sales Order. This service exposes Sales Orders which contain header and line item data from the SAP backend ERP system. The service document can be found at the following URL: https://sapes1.sapdevcenter.com/sap/opu/odata/sap/ZCD204_EPM_DEMO_SRV. The Metadata of the service can be found at: https://sapes1.sapdevcenter.com/sap/opu/odata/sap/ZCD204_EPM_DEMO_SRV/$metadata. The Sales Order service exposes four collections mainly. They are:

1. SalesOrders
   All the Sales Orders can be read using this collection
2. SalesOrderItems
   Items of a Sales Order can be read from this collection
3. Products
   Collection of products which can be purchased
4. BusinessPartners
   Collection of Partners with whom the company does transaction

Setting Up Reverse Proxy:

Services exposed by SAP Netweaver Gateway Demo system are all protected and need credentials to access them. In the previous section we talked about getting access to the demo system. During that process you would have used a username and password. You need the same credentials to authenticate against the demo system when querying for data.

In order for us to perform full CRUD on the demo system we will need to setup a reverse proxy in order to overcome the Same Origin policy restriction. A reverse proxy should be used for sending client HTTP requests designated to its domain to the correct server. Reverse proxy can be achieved in 2 ways. They are:

1. We can use IIS URL rewrite to create the reverse proxy. Here is an article on IIS rewrite: http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing.
2. We can also create a simple reverse proxy using ASP.NET Web API.

Reverse Proxy using ASP.NET Web API:

A simple reverse proxy can be easily created using ASP.NET Web API. Idea is to create a Web API and pass the SAP URI we need query data as a query string parameter. The Web API will read the query string value and use that as a URI to connect to the SAP Service. Response from SAP Service will be relayed back to the client as JSON. Following code snippet shows the Web API Controller and in particular the Get action method:

public class ProxyController : ApiController
{
        string username = "<username>";
        string password = "<password>";
        // GET: api/Proxy
        public async Task<JsonResult<string>> Get(string url)
        {
            var sapUri = new Uri(url);
            using (var client = new HttpClient())
            {
                var base64String = GetBase64String(username, password);
                client.DefaultRequestHeaders.Add("Accept", "application/json");
                client.DefaultRequestHeaders.Add("Authorization", "Basic " + base64String);
                var response = await client.GetAsync(sapUri);
                HttpContext.Current.Response.StatusCode = (int)response.StatusCode;
                return Json(await response.Content.ReadAsStringAsync());
            }
        }
}

Instead of querying the SAP service directly from the mobile application, we will querying the proxy we just created above and pass the SAP service URL as a query string. Here is the usage:

http://<proxy server>:<port>/api/proxy?url=https://sapes1.sapdevcenter.com/sap/opu/odata/sap/ZCD204_EPM_DEMO_SRV/BusinessPartners

Notice that we pass an Authorization header when making a request. SAP Services expect an authorization header and we pass the username:password string converted to base 64 and pass it as a request header. I have showed the example of a Read or Get. But on the similar grounds you can create the Create/Update/Delete actions also.

Summary:

With this blog post we start a journey to read data from SAP and use that data in a mobile application. As a first step we learnt that SAP data can be exposed to outside world using the SAP Netweaver Gateway system. We looked at various the demo services and picked the Sales Order system as a candidate to build the mobile app. In next post we will create a mobile application using Kendo UI Mobile framework and Telerik App Builder.