Skip to Content

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

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. nabheet madan

    Thanks for the blog Marc.. Nice view point… Actually i did not think from this point of view..i can see now tons of possibilties..We have UI5 the front end with us and the customer has n number of systems including SAP which can provide ODATA or JSON stuff UI5 can show all of them at one platform otherwise the effort would have been too much.

    Looking forward to your next part

    Nabheet

    (0) 
  2. John Pawski

    I need some advice on this…

    if your OData Producer supports delta query protocol to track changes, the provided delta links are automatically used to track changes and you need not configure delta tracking. When possible, use an OData Producer that supports delta query protocol. help with this;

    A few questions on SAP ODATA provider

    1. What producers are available?

    2. How to find out if they support ‘track changes’

    (0) 

Leave a Reply