Skip to Content


Like many others I am eagerly awaiting the release of SAP Netweaver Gateway, a technology which promises to simplify SAP integration. By exposing SAP Business Suite functionality as REST based OData services Gateway will enable SAP applications to share data with a wide range devices, technologies and platforms in an easy to understand and consume manner.

The intention of this blog is to give a high level overview to the Open Data Protocol (OData), showing by example how to access and consume the services.  For a more concise definition I recommend the following recently released article – Introducing OData – Data Access for the Web, the cloud, mobile devices, and more

What is OData?

“OData is to REST what MS Access is to databases..”  a complimentary tweet I read, because MS Access is an entry level technology which is easy to learn, it allows users to focus on the data and empowers them to build simple and effective data centric applications.

“OData can be considered as the ODBC API for the Web/Cloud” Open Database Connectivity (ODBC) is a standard API independent of programming language for doing Create, Read, Update and Delete (CRUD) methods on most of the popular relational databases.

“OData is a data silo buster” 



Essentially OData is an easy to understand extensible Web Protocol for sharing data. Based on the REST design pattern and AtomPub standard, it provides consumers with a predictable interface for querying a variety of datasources not only limited to traditional databases.

OData Services provides a sample of the Northwind Database exposed as OData formatted services, this is a great resource for exploring the protocol.

**If you are using IE you may want to disable the feed reading view.

The link below is to the Northwind service document, it lists all of the service operations, each operation represents a collection query-able data.


To access the Customers collection we append the link provided above to the base url as follows

We can accesses specific Customers via the links provided in the feed‘ALFKI’)

With the query string operations we can start to control the data provided, for example paging Customers 20 at a time.$top=20$top=20$skip=20&$top=20

Using filters we can search for Customers in a particular city or Products in our price range$filter=City eq ‘London’$filter=UnitPrice le 200 and UnitPrice gt 100

Once we have found the data we wanted we can use the links to navigate to the related data.

Finally we can format the response as JSON$format=json


Consuming OData

To illustrate how easy it is to consume OData, I am sharing simple JQuery Mobile application, it uses the following tables and relationships.


OData Sample Application – hopefully the 100 lines of HTML code, JavaScript and annotations are easy to follow, copy the source to a html file, save it locally and run in a browser. Best viewed in the latest versions of Firefox, Chrome and IE.

image image image

Opening up more than data

A couple of months ago I set off on a exercise to learn all I could about OData, along the way I started investigating some of the available opensource libraries like datajs and odata4j, rediscovering a passion for JavaScript and Java.  Through the many examples and resources available it was surprising how easy it was to take my limited skills into the world of Cloud and Mobile application development.


Similar in many ways to ODBC and SOAP, OData is an initiative started by Microsoft as means for providing a standard for platform agnostic interoperability. For it to become successful it needs to be widely adopted and managed.

From a high level the strengths of OData are that it can be used with a multitude of data sources, it is easy to understand and consume. From what I have seen it will be great for simple scenarios and prototyping. Early to tell what its real weaknesses are, however to be simple and easy to use there has to be either a lot of pipes and plumbing or constraints and limitations when used on top of technologies like BAPI’s and BDC’s, things like managing concurrency, transactions and state come to mind. Conversely the threats of not being adopted and competing standards and initiatives like RDF and GData represent some big opportunities for an extensible protocol.

To report this post you need to login first.


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

  1. Matthew Harding
    Hi John,
    I just wanted to say nice work on this.  Very clear, good links, easy to follow; with a great easy to test html example (with some nice jquery mobile thrown in for good measure). Works for my learning style!
    Thanks for sharing,
    1. Richard Hirsch
      I agree with Matt. Good blog with lots of useful examples. Can’t wait to use your code for future OData work. I’m hoping that future blogs from you will build on this one and examine the use of SAP Annotations on top of OData in equal detail.


    2. Glen Simpson
      Hi John

      I’ll add my voice to chorus. 🙂
      I think this blog is a fantastic resource (maybe even “the” resource?) for anyone wanting to learn what OData actually is and what it does… there’s nothing like good examples to help do that. Nice one!


  2. Alisdair Templeton
    Hi John.

    Great blog. Really impressed with the mobile app – I must find some time to learn some more JavaScript 🙂

    I think what’s going to be important is understanding what can be done well with OData and what shouldn’t be done. I think your second quote nailed it for me – OData IS data centric, and it’s really only appropriate for data centric applications where the focus is CRUD operations. When we want to build applications based on a Domain Application Protocol and use a RESTful style to explicitly expose the protocol to the client through hypermedia – guiding the client through valid state transitions – i’m yet to be convinced that OData will allow this easily. Of course, Atompub is a hypermedia aware mediatype, and allows link relations, but i’m yet to see a good example where the link relation is anything other than another collection of data. A good example of OData being used to guide a client through ordering and payment would help change my mind 🙂

    So, Gateway, as a data enabler through OData, will offer a quick and easy way to build Data Centric applications. There is nothing wrong with this, aslong as we don’t try to twist it into something it’s not.

    Of course, there is the old chestnut of the tight coupling that OData introduces through its query model, as well as the fact that the client can’t self discover the $metadata – requiring out-of-band information – but I think this is a conversation for another time…

    I’m hoping that some of these issues can be overcome by building “custom” Gateway objects – hopefully it will all become clear round Tech Ed!!


    1. John Patterson Post author
      The example provided was a cut down version of a mobile application I wrote with datajs, built on my own Azure based Northwind OData services, it included local storage and result caching, as well as merge and batch operation, all very easy to code, a little too easy. 

      I have concerns, not just about OData, seeing something like a Restbucks implementation in ABAP on top of RFC’s is a great idea.


      1. Alisdair Templeton
        Hi John.

        I’d be interested in your opinion on how coupled the client and server are. It appears that operations such as batch require the client to know alot about the OData protocol that cannot be determined directly from the representation you currently have.

        I’m not sure I follow your second sentence – why would I implement Restbucks with RFC’s? Surely the ICF would be the way to go?

        Rather than build a reference implementation of Restbucks in ABAP, a more interesting challenge would be to build it using OData/Gateway to get a feel for how RESTful they can be…

        Look forward to discussing thus further with you next time our paths cross 🙂

        1. John Patterson Post author
          lol – I meant a working hypermedia example on top of existing SAP functionality.

          My $batch operation was too simple, 2 queries of related products by category and price.

          Let me know next time your in Wollongong.

  3. Chris Paine
    Hi John, agree with all the comments below – great blog and nicely put together.

    I just couldn’t help though pick up on:
    “OData is to REST what MS Access is to databases”.
    I think this is actually quite telling – in a non-complimentary manner as well as the way in which the quote referred to it.

    OData (a quasi-open Microsoft protocol – we have to hope that there is never a need to file against MS for any patent infringements that they might against SAP ) by it’s very definition is not RESTful as it allows for stateful constructs (BATCH, etc). In the same way, to run more than 5 users through an Access DB will cause issues. As per AT’s comments below I think we should be very careful about spreading the SAP marketing lines about OData providing a RESTful interface to SAP. An HTTP based CRUD interface does not REST make.

    Btw – nice JS!

    More please!



    1. Chris Paine
      PS – liked the use of Google code to share the JS code – much nicer than embedding it in the blog in a scrollable frame (which is what I’ve typically done to share code sections). Will shamelessly copy you in this for my next blog. 🙂 Thanks!
      1. John Patterson Post author
        Hi Chris,
        A lot of thought went into the comments after the MS Access comparison.

        Next time your writing a blog, try inserting javascript, you’ll see why I used Google code.


        1. Chris Paine
          Hi John, I didn’t mean to imply that thought did not go into the comments you made about MS Access comparison. As I mentioned, I really enjoyed and appreciated your insightful blog. I think SAP’s adoption of OData as a means of building HTTP interfaces in a easy way is good. I just think we ought to be mindful of repeating SAP’s sales pitch of Gateway+OData = RESTful interfaces. Hopefully we’ll find out more about Gateway’s ability to behave in a more RESTful manner soon, but current indications are that this is not the full solution that many of us have been looking/hoping for.
          Another nice point about your excellent idea of using Google code for the JS section of the blog is the ability to mark out a licence for the code (GPL or otherwise) something that I worry a little bit about with just embedding code directly in a blog. I have to admit I have never tried embedding JS but I can imagine with the SCN blog editor as it is, that you’d have fun. I remember spending a frustrating few nights just trying to get strikethrough to work (unsuccessfully). Thanks again for a great blog.
          1. John Patterson Post author
            Hi Chris
            I totally agree with both yours and Als comments. I tried hard not to make the MS Access comparison sound like a back handed compliment, it is what it is, its fit for the purpose of simple integration.

            Maybe a better analogy would be comparing blog editors based on tinyMCE.



Leave a Reply