Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
marc_augustin2
Active Participant

Content of this series:

     The power of OData - Part 1 - Introduction (this part)

The power of OData - Part 2 - Setting up the Environment

The power of OData - Part 3 - Creating a data Model

The power of OData - Part 4 - Creating an OData service

The power of OData - Part 5 - Consuming the service with SAPUI5

Over the weekend, I started looking at OData in more detail as I wanted to get a better understanding about this new “standard”. The first time I stumbled upon OData was when I read about SAPUI5 and the new Netweaver Gateway features.

Reading more about this topic, I realized that the protocol initially was defined by Microsoft and used within their products. Well, Microsoft won’t create a standard that is only for their own products, so there has to be more about it. OData in general is a protocol that is designed to provide standard CRUD access to data via websites, so that it can be compared to the common REST apis that exist.

Following the standard around and looking at the website, there are more producers than only Microsoft. The before mentioned Gateway for example acts as an OData producer, providing access to SAP systems. Microsoft’s Sharepoint, their SQL Server 2012, Windows Azure or the Team Foundation Server can also act as OData producers. Having those options and the possibility to access OData services from UI5 applications, a real new world opens up for us.

Just imagine we have some customer specific data lying in tables in a SQL Server or some data stored in a Sharepoint that we want to link with data coming from a SAP system. Well, call a few OData services and link the results within an UI5 application together, nothing “easier” then that. We could also build master/detail applications using data from 2 systems at each step. Getting the master data out of a SAP system and fetching the details from a Sharepoint directory. Many ideas and options are possible here.

What I really wanted to find out was: what if our data isn’t stored in Sharepoint or MS SQL Server? What if our developers prefer MySQL? What if we have an Apache running and use PHP, if we use some PHP-based web applications that access MySQL databases and process data?

The answer is: There are SDKs, OData producers that can be implemented and used, enabling us to create even more use cases and scenarios. By using those SDKs, we are able to access almost any data store through various languages (.NET based ones, Java, PHP) and create services that deliver the data we need. This data can then be mixed and enriched with the data stored in SAP to increase the user experience and the usability of applications. The times when we had to manually mix up data from different sources are over.

I’d like to start a short series here that begins with setting up the environment for developing PHP-based OData services. This would include setting up Eclipse and MySql as well as installing a web server. Next, I would create a sample database to fetch the data from. By using tools and SDKs provided by Microsoft, I will then create a sample service, add some more logic and finally create a simple UI5 application that will show the data in a web browser.

Adding data derived from a SAP system through SAP Netweaver Gateway would be the next step, which won’t be covered in this series.

Continue to read the next part: The power of OData - Part 2 - Setting up the Environment

4 Comments
Labels in this area