Skip to Content

Expose a BAPI using JSON and REST



These are the technologies you need when writing modern web applications. And that is what makes it so hard to use SAP together with modern web applications: Currently you only get REST from SAP with Gateway, but not JSON. OData comes from Microsoft and support is not as wide spread as someone expects. How OData does looks like? You can try it out by downloading the Gateway Trial from SCN or use the online demo system. To experiment with Gateway the usual flight example from SAP can be used.

To get the details of a specific flight:

http://gateway trial server:port/sap/opu/sdata/iwfnd/RMTSAMPLEFLIGHT/FlightCollection(carrid=’AA’,connid=’0017′,fldate=’20110601′)

Data returned from Gateway:


Instead of being able to use the data exposed by Gateway by the widely used Javascript frameworks like jQuery you need to find a OData plugin. Of course you can use SAP UI5, but what when you are forced to use jQuery, Sencha, Dojo or something else?

That’s a problem with SAP and ABAP in general: you have to wait until SAP implements missing functionality or someone posts it on Code Exchange or some other platform, and because of the limit resources available in the ABAP ecosystem this can take a while, costs some (serious amount of) money or will never happen. That’s where we can be happy that SAP also embraces the use of Java. As Java was made for the internet there is a huge Java community out there that most probably already developed a tool that fits your needs.

For exposing data as JSON in a REST-full way the tool available is: Jersey

After Jersey transformed the data, the response looks like:


Jersey needs Java 6 and runs in a servlet container. As NetWeaver CE >= 7.2 fulfills these requirements, Jersey can be used to transform Java objects into JSON and expose them using REST. NW CE comes with a framework for creating composite applications (CAF) that can consume BAPIs. CAF uses standard J2EE technology like JCA and Beans. This bean can be used by Jersey to automatically extract the data, transform it into JSON and make it accessible using REST.

Consuming a BAPI using CAF can be done with no coding involved at all as CAF comes with some nice wizards. Just map the input and output parameters and the code will be generated including the bean that can be used to interact with the BAPI. In the Jersey web application the URL and protocol get defined:


The CAF bean gets called using the parameters retrieved from the URL:

out = e.bapiFLIGHTGETDETAIL(null, null, null, carrid, connid, flightDate);

  That’s it. Jersey will do the rest:


How the URL gets constructed is up to you, the parameters can be part of the URL as above or a query. You can also define if it is GET, POST, PUT, etc. If you want to do some coding you can adjust the output, or combine the result of several BAPIs into one Java object that JSON will expose.

Now that the BAPI can be accessed in a RESTful way and the data retrieved is in the JSON format, it’s easy to use the data in a Javascript framework like jQuery with Datatables:


The actual coding for making the CAF bean accessible to Jersey and expose the data is less than 10 lines of code. From CAF to Jersey to a running HTML application it does not even take 30 minutes.

The framework I used for interacting with the ABAP system is CAF, a framework available for NetWeaver Java since a while (7.0): well documented enterprise ready and supported. If you want or need to expose your BAPI by REST and JSON or XML and you have a NetWeaver CE >= 7.2 (like Portal 7.3) available, you can start today. As your NW CE system is a separate one, upgrades won’t affect your backend system and as Jersey is also a separate application; changes to Jersey don’t affect your other CE server and applications. Of course you don’t need NW CE for using Jersey and CAF for interacting with BAPI. Every platform that Jersey supports and where you can use JCo from SAP to call a BAPI can be used like tomcat. It just means that some extra configuration and coding will be necessary. This also implies that your backend ABAP system can be used as long as a JCo connection to it is possible.

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


    These are the technologies you need when writing modern web applications"

    Why is that, Thobias? Could you supply us with some facts and figures here please? What were the previous technologies, where were they uses, where and why did they lack, and how do these two make up for that? Much appreciated

    While on that, can you also please explain me how this is REST-ful? It isn't at all, from where I'm standing

    • Marijn,

      a modern web application comes down to: HTML, CSS and Javascript with AJAX. As these kind of applications use HTTP for sending / receiving data, they already use REST, even when the underlying application was not designed for being RESTful: it still is client / server, uses HTTP and in most cases: GET <resource>. That's basic REST.

      About JSON: every Javascrpt framework support XML and JSON, and JSON is preferred as the data transferred is smaller: no XML overhead. Are you aware of HTML5 apps (to not call it modern web application again) that uses a binary or other format to send / receive data used to display (flash does not count)?

      Jersey allows to make Java resources accessible in a RESTful way. Why do you think that the exposed resource (here: flight) is not RESTful? GET, PUT, POST, DELETE, HEADER, etc is supported by Jersey. As all of these operations can be mapped to an underlying BAPI of the resource exposed, it is RESTful. If the operation isn't possible - like: create a flight - Jersey can respond with an HTTP error code for PUT and POST. So: it's RESTful.

  • I think you're missing the boat a little with OData... it's a new protocol and will take some time to adapt, but look at some of the OData services being exposed by companies by like eBay, Netflix, and others and you can see the power of's more than just exposing data. It's be able to easily relate objects and collections of objects to other objects and collections, filtering, aggregating, sorting and more.

    You seem very concerned about JSON (just a format, not a protocol) not being available with Gateway, but my guess is it will be out on the next couple of service packs. Gateway is a newer product, you're not going to get everything right away. Regardless, having the ability to consume the service in an XML format is not always bad.

    For Microsoft developers as well, being able to consume OData services and use things like LINQ make interacting with these services extremely straightforward and simplifies code greatly.

    • OData is not really new, as is Gateway. Both are around for quite a while. And that Netflix or other sites that depend on being accessible from Microsoft SW/HW is no surprise (btw: Netflix also offers JSON). OData comes from Microsoft, and even when they are saying that it is open and they won't process anyone, it's still not a RFC-standard.

      That OData still has a long way to go can be seen when you attend a SAP session about Gateway: half the time is about what OData is why SAP thinks you should use it. Talks about JSON support are shorter: "Hey, we also support JSON".

      Gateway allows consumption of SAP data of the internet. As long as you don't develop a native app or servlet application you get into trouble using OData as the Javascript frameworks currently used are made for XML/JSON. Not for OData. If you develop a web application with Sencha or jQuery Gateway does offer little value. Looking at the history of Gateway it's no surprise that OData came first, but that there is still no JSON support? And when it comes you'll have to update your Gateway server, and you'll depend on further SPS releases by SAP.

      The mobile and web application world is turning faster than the release cycles of SAP.

      • Again I think you're missing something...OData is a data protocol while JSON is just a data format, they are not the same thing. JSON is just a way of formatting data, it has nothing to do with the underlying data protocol. Saying that Javascript frameworks are not made for OData is NOT correct.

        Just because Gateway doesn't support JSON yet doesn't mean that the OData protocol doesn't support JSON. The OData protocol has two supported formats: Atom (XML) & JSON in fact ( SAP chose to only roll with the Atom at first and I'm sure JSON will be here soon.

        If you have an OData service which supports JSON, you can consume it very easily with Javascript.

        • I'm aware what OData is, and Javascript frameworks are not made to work with OData. They are made to work with what a server returns: XML / JSON. For instance, the .ajax() call in jQuery has a Data Type parameter that takes XML, HTML, JSON/P, script or text. That the answer comes from a server that encapsulates it into OData is of no interest. jQuery needs the data, not the OData protool overhead. It does not even understand what OData is.

          The overhead you get with OData can be very high when you transmit little (actual) information. It gets less when the format is JSON, but still you transmit unnecessary information. For that Gateway is not really an optimal solution when you have to exchange data to a mobile device.

  • Hi Tobias,

    Any chance you can upload the DC for people to take a look? - I kinda liked the approach you used to avoid Gateway and extra development using ICF to consume RFCs.

    Also, have you ever tried using hibersap? - I found out that using it with JCA is quite fast, and this would remove any 'dependency' related to SAP itself (which would make the solution deployable on any J2EE container having a compatible adapter).


    • I'm thinking of putting the code of the Jersey part into a wiki page. The same for the CAF part isn't really necessary as I just imported a standard RFC without coding anything.

      Replacing CAF: as I wrote in the blog, you can use whatever you want. In a twitter conversation a had with Jan Penninkhof he also raised that question. I'm only using here CAF and not something else that runs on tomcat to simplify the example. While with another framework I'd had to write how to consume a BAPI, with CAF this is standard and well documented by SAP. Short: it was easier for me 🙂

  • I think it's a big advantage being able to expose/consume data in JSON format, since it's far more flexible, readable and lighter than the bloated XML(AtomPub) that's being provided by Gateway. It's easier and faster to parse JSON using a browser (since it's pure javascript, you might not even use a library), while it's easy to use it with desktop apps thanks to the object-oriented model (you can take a look at Google's Gson).

    Plus, most developer communities and services have chosen JSON as their default protocol for exchanging data, meaning it's easier to integrate with other applications and systems as well.

    Releasing a product that is meant to provide SAP Data to the outside world that doesn't come with the ability to serve JSON output, IMO, is releasing a product that is far from finished, at best. Again, SAP has missed the point in looking at what is happening in the outside world. There's a lot of benefits in using open and market standards that SAP refuses to see.

    • Absolutely, I agree Gateway should have had JSON support when it was released, SAP missed that boat on that one, but that's not my point. My point is that OData can be used with Javascript and JQuery or other frameworks because it does support JSON.

      And for what it's worth, GW SP4 was just released and supposed to have JSON support...i'm waiting to hear from our basis team for them to get it installed and I will try it out.

  • Hi Tobias, great blog.

    Do you have any information on how to use the ODATA-CXF-EXT ( software component? To expose bean with REST?

    How do you configure dependency in NWDS "Development Infrastructure perspective" and then what is needed in J2EE perspective to make it work?