A Gateway to Lightweight Services: Enabling Mobile and Web Applications

Mobility is the latest buzzword in the Enterprise Applications space. As each day passes, we see organizations enabling the business application on their back end enterprise systems onto mobile devices. With HTML5, rich UI capabilities have also become the focus of many web applications that are being built across customer implementations. Yes, it is only natural that employees, vendors and customers of a business start demanding more of the data for their day today activities be made available on portable devices.

From a web services framework, we have seen a slow transition take us through SOAP messages to RESTful services. Now REST is considered lightweight web services (how lighter can they get eh?) and for those who are finding the terminology new, I will recommend reading this : Learn REST: A Tutorial

As one thought of taking a rest from REST, we were introduced to OData. Wondering what OData is? Read this.

PS: Crash course on OData? Then click here.

Eventually this transition meant that there was a huge amount of data within the backend enterprise systems that were waiting to be unlocked for the use of Mobile and Web applications. This is where integration enters the scene.

Today, SAP customers have two options to enable integration and expose the business logic as simple RESTful or OData services. SAP Process Integration and SAP Netweaver Gateway would look to facilitate these integration needs.

What is SAP Netweaver Gateway?

Project Gateway as it was known earlier, SAP NW G/W is:

a. The point of access into SAP Business Suite data and functionality

b. Uses a non-proprietary interface based on the Open Data Protocol (OData)

c. Service(s) can be consumed by any channel that can process XML received over an HTTP(s) connection

I am sure the first question that comes to the mind of many readers is going to be, “Why two toolsets? Isn’t this duplication of the Integration layer?”

Since this has been a topic debated for long, I will provide references for the readers to understand and arrive at their own judgement regarding this;

a. NetWeaver Gateway and PI – There’s a place for both!

b. Gateway or Process Integration – which is the Right Tool for the Job?

What is the truth?

The truth is that majority of our customers run their businesses on heterogeneous environments. This in very simple terms means that the backend business logic is locked within SAP and Non-SAP applications.

PS: The above reference to a MEAP is in the context of mobile applications. Many a time, the layer can also act as a reverse proxy.

Now in PI, at present there is no REST capability available as part of the standard installation. Almost every customer is dependent upon the REST adapter from Advantco which translates to additional costs for licences. NW Gateway is also procured via additional licences.

What usually one ends up with?

If you would have read the articles that I had referred earlier, you will understand that both the REST adapter and Gateway eventually find (are forced to?) a place for themselves. Gateway’s capability primarily lies in unlocking data on a SAP backend. It cannot, I repeat, it cannot integrate with non SAP backend and create services for you. Now on the other hand, a solution on PI would have the advantage of integrating with any backend since its characteristics of being an ESB. But a key difference that one will find between PI and Gateway is that Gateway exposes OData services while PI REST adapter does simple RESTful services with no OData capability.

This poses an architectural problem. So as of now, for a SAP customer to develop a mobile or web application on a heterogeneous landscape, it becomes inevitable that they;

1. Buy extra licences – Higher TCO

2. Find themselves using a combination of multiple standards i.e Simple REST and OData (so much for standardization)

3. Lose a holistic view of integration – Multiple layers of integration

What could be done?

Gateway only approach:

We could argue that a SAP customer usually has most of his business processes running on his SAP backend. Hence a majority of the service enablement will be for data on the SAP application. With this assumption, the remaining Non SAP data needed to be service enabled, could be fed into SAP, stored in custom tables (or wherever) and then again via Gateway expose them as OData.

Here the assumption that we make is that 70-80% of the backend data that is needed for the mobile and web application resides in a SAP backend. Yet, we need to factor in costs of having the non SAP data made accessible via Gateway i.e building additional interfaces (Non SAP to SAP), customization in SAP, data maintenance etc.

PI Only approach:

In this case, a big drawback would be that OData support is not available. The IDE plugins and other accelerators that come with Gateway will also be lost. But the advantage would be that integration would be seamless and consistent in a heterogeneous environment.

SAP does something:

Now this is an aspirational option where SAP consolidates the product and defines a single strategy. With heavy investments already on Gateway, enhancements could be made to support non SAP backends. This will clearly dictate a one tool approach. I am also aware that SAP is working on a standard REST adapter that would be an alternative to the 3rd party REST adapter now available. But until it settles, the waters are still muddy and I believe a combination of Gateway and PI will be what most customers will end up with.

Update [09-April-2014] – Integration gateway seems to be one of the first steps in enabling OData of non-SAP backend.

Afternote:

What are your experiences on this topic? What is your organization’s strategy for mobile and rich UI based applications?