Let's follow up this discussion at the Neptune Community

(this forum will be kept in read-only mode)

OData Support ... + fill out the survey ;-)

Hi Everyone, 

One feedback coming in from the Neptune Community Survey [it is still open and you should fill it out too] is a request to support OData.

Now Njål Stabell has posted about this on SCN: Three Major Misconceptions of SAP Enterprise Mobility

Here is the passage: 

"3 – Base your Enterprise Mobility implementations on an API first approach.

The API first approach is gaining momentum. Theorists (I’ll pay for this  ) claim that it boosts development productivity and helps create multi-platform applications more easily. A few years ago, we had the same hype around the ESR (Enterprise Service Repository) and SOAP was the solution for all integration and external exposing of backend data (I returned to good old custom IDOC’s after a short time). Well it was not. Our PI systems crashed and debug was hell. Why? The services were created for certain scenarios and often complex and not optimized for large volumes. Today we look at oData through GW services, often with nested structures demanding complex client-side logic and low performance. Performance is vital in a mobile scenario.

Therefore, it is better in my experience, to create your backend access in parallel with client functionality – Consumer first approach. This will ensure that you only fetch and send the data you need in each request. This (And superior offline capabilities) has been the main reason we use native JSON bound to element attributes in the Neptune Application Designer and not taken the GW path, even though external pressure has been big."

Hope that clarifies things, Mark. 

Dear Mark, 

thanks for clarification again.
But customers have to support oData on their way to HANA and in this context Neptune becomes a growing disadvantage during presales and projects with this strong denial of oData.for this point of view Neptune isnt big enough to resist against SAP (my personal opinion).
On mobile scenarios i am always with you. but we build webapps for online scenarios too an if customers have to build a given odata structure with integration by their own into Neptune app customer gets more and more annoyed about this topic.

customers have to support Fiori and Neptune in parallel - but i may not lead into a divided app world: one with and one without oData - then Neptune will loose.

but if Neptune supports oData, we could build apps which can be easily transferred later on HANA without adapting any dataretrieval - this would be avery great argument to build apps with Neptune today.

best regards Ralf

2 people like this

Hi Ralf,

First of all, thank you for the feedback. Our hope is to make this forum and our community in general more active so replies like this is great.

Let me clarify a couple of points regarding Neptune and oData and HANA. 

Neptune does support oData. Since we started this company in 2011 we have always kept development open. That means that whatever JavaScript, HTML or CSS coding you wish to add to your application is completely open.Regarding oData specifically you can see a live example in this app . That being said there are lots of reasons why we have chosen a different path regarding our communication framework. First of all, it is WAY faster and increases the application performance drastically. JSONH removes 60-70% of the data load being sent from the server to the client. Also, when it comes to changing data we have full support of passive locking on the back-end even when running stateless apps... this is vital for all applications changing data. Our customers simply can't live with optimistic locking and this is a main reason why many chose Neptune to compliment their S/4 implementation for those transactions .

Offline Support. Our framework allows offline capable apps with your a couple of clicks and pre made JavaScript helpers. Offline capable apps are not necessary just for situations without coverage or with dead spots it is also vital that you can handle data transmition between client and server in any way you want... read reduction of server-side memory being consumed and more snappy apps. 

HANA you do not need oData for accessing a HANA DB. CDS views and even accessing data from SAP Cloud Platform's HANA DB (Formerly HCP) is performed by loads of our customers and partners.Remember that Gateway also is an ABAP solution and uses ICF for communication, so everything you can do with GW you can do with Neptune ;-)

Finally, we at Neptune are strong believers in simplifying the development process and we see that modern agile development methodologies are more easy to use with our low-code single developer approach with consumer-first instead of API first which in many cases forces you into waterfall like methodology and increases development time drastically.

Anyhow that was my 2 cents   



4 people like this

Hi everyone,

Just wanted to add my 2 cents :)

In the following demo Neptune App (links below) you will be able to compare:

  • OData retrieval from an OData service.
  • JSONH retrieval from an ABAP Class using UI5 models.
  • JSONH retrieval using Neptune's sap.n.database, also known as AppSync framework.

Variables measured:
  • Time to get full response (milliseconds - in blue color)
  • Size of the data transfer (kilobytes - in red color).


  • Same SELECT statement, same table, same amount of records, same server, same network.
  • 20K records, all table fields from table DD02L (SELECT *). 

  • OData Service implementation:


  • Neptune Class Implementation:


Statements needed to consume an OData service in Neptune Application Designer:   3 (three).


Preliminary results (from my slow home connection):

  • JSONH consumed 59% less data transfer (kb) and took 20% less time than OData. 
  • AppSync (also known as sap.n.database) consumed 57 % less data transfer and took  67 % less time than OData.


Additional notes:

  • Records transferred using AppSync (aka sap.n.database) are immediately available offline (SQLite) once the data transfer is complete, giving an additional functional benefit over JSONH and OData.
  • The app has extra JS to perform the time/size measurements on the fly and show them in the chart.

Please feel free to test and play with the app and share your conclusions. 


Kind regards,


5 people like this

Wow, looks like AppSync is a factor of 2 times faster with less transfer to boot. 

Well done Julian :-) 

Sorry guys, but what are we talking about: a mobile app or an interface?

I think we are talking about a mobile app and that's why we shouldn't use unrealistic amount of data for the measurement. 

20k rows of database lines? Let us break it down to 200 rows (else the design of the system is wrong), so a factor of 100. And now we have an answer (or better transfer) time of 61ms with OData, 48ms with JSONH and 20ms with AppSync. As a user it is more than irelevant if he's waiting 60ms or 20ms.

Concentrate on the usability / design and use as backend what ever the system provides. CDS views -> OData ftw ;). 

Cheers, Uwe

1 person likes this

Hi Uwe

Nice to see you here. 

The 20k size is for our offline apps. And this is even small amount of data in a typically Neptune offline app. 

I don't think we need to discuss what protocol is the best oData/Neptune JSONH. In the upcoming release we will add full support for oData. Then it's up to the developer to use oData source(s) or/and the Application Class. I do see the benefit using all the strengths of oData with Annotations and CDS Views !

Disclaimer: this is under development :-) 




Ole Andre 

4 people like this

Hi everyone,

Just wanted to clarify 2 important things:

A- Last Thursday and Friday, the Odata service was fetching only 200 (instead of 20 K ) records.  If anyone has been playing with the comparison tool, they would have gotten extraordinary good results for Odata performance.

B- Besides this really interesting discussion about performance and data usage, an important thing is that Neptune UX Platform SP03 is introducing support for OData services :)




1 person likes this

Hi Julian, 

Do I understand this right: 

>the Odata service was fetching only 200 (instead of 20 K ) records

The results of your speed test above are based on just 200 records, not 20K records? 

That would be marvelous. 

If yes, please update your original post, if possible. 

Love that you guys have listened to the community feedback and

If anyone reading this has experience with OData and a has vision on how to ideally support it within the Neptune platform, now is the time to step up and help make it the best it can be. Let us know, Mark. 

Hi Mark,

No, what I mean is that the results of the test posted on this forum topic are 100% accurate.

I was just saying that "in case someone ran their own tests last Thursday and Friday", the results they got were not accurate since the oData service on our end was only retrieving 200 records at that time.  This happened only last Thurday and Friday.

All kind of suggestions for making the best oData support are extremely welcome !!    Thanks !!


Login or Signup to post a comment