Note: 1^st published on SCN at 22.5.2012

REST.

JSON.

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: sap/opu/sdata/iwfnd/RMTSAMPLEFLIGHT/FlightCollection(carrid=’AA’,connid=’0017′,fldate=’20110601′)

Data returned from Gateway looks like this:

Instead of being able to use the data exposed by Gateway by the widely used Javascript frameworks like jQuery you need to find an OData plugin. Of course you can still 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 or developer implements functionality, 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:

{“EXTENSION_IN”:{“item”:[]},”EXTENSION_OUT”:{“item”:[]},”RETURN”:{“item”:[{“TYPE”:”S”,”ID”:”BC_IBF”,”NUMBER”:”000″,”MESSAGE”:”Method was executed successfully”,”LOG_NO”:””,”LOG_MSG_NO”:”000000″,”MESSAGE_V1″:””,”MESSAGE_V2″:””,”MESSAGE_V3″:””,”MESSAGE_V4″:””,”PARAMETER”:””,”ROW”:0,”FIELD”:””,”SYSTEM”:”NPLCLNT001″}]},”ADDITIONAL_INFO”:{“FLIGHTTIME”:361,”DISTANCE”:2572.0000,”UNIT”:”MI”,”UNIT_ISO”:”SMI”,”PLANETYPE”:”747-400″,”FLIGHTTYPE”:””},”AVAILIBILITY”:{“ECONOMAX”:385,”ECONOFREE”:20,”BUSINMAX”:31,”BUSINFREE”:1,”FIRSTMAX”:21,”FIRSTFREE”:3},”FLIGHT_DATA”:{“AIRLINEID”:”AA”,”AIRLINE”:”American Airlines”,”CONNECTID”:”0017″,”FLIGHTDATE”:1306897200000,”AIRPORTFR”:”JFK”,”CITYFROM”:”NEW YORK”,”AIRPORTTO”:”SFO”,”CITYTO”:”SAN FRANCISCO”,”DEPTIME”:50400000,”ARRTIME”:61260000,”ARRDATE”:1306897200000,”PRICE”:422.9400,”CURR”:”USD”,”CURR_ISO”:”USD”}}

Jersey needs Java 6 and runs in a servlet container. As NetWeaver CE >= 7.2 fulfills these requirements, Jersey can be used to transform POJOs 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:

@GET

@Path(“getFlight/carrid/{carrid}/connid/{connid}/fldate/{fldate}”)

@Produces(“application/json”)

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.