Skip to Content

Hi,

It’s me again.

This time I want to tell you about a new Mobile Service feature I’m very excited about: the Mobile Service OData Generator tooling. It may be an odd name, but I’m sure you will like it anyhow.

This year was a very busy one in mobility. Let me quickly recap:

  • SAP Cloud Platform SDK for Android Global Availability (see blog here) – our contribution to the Google SAP partnership
  • SAP Fiori for Android design language – coming form our colleagues from Global Design (link)
  • SAP Cloud Platform Mobile Service for Cloud Foundry (released in some AWS data centers already and more to come)
  • Mobile Development Kit announced to be available on Android as well (See our roadmap here)
  • SAP Cloud Platform SDK for iOS 3.0 with awesome enhancements (read Andreas blog here)

This is already a lot of new stuff. Hope there’s something in for you as well.

Anyhow, I want to draw your attention to something else today. We have already mentioned it in our Mobile Services roadmap, but you may have missed this little detail. So let me quote our the Mobile Services roadmap:

Full-stack mobile app development
Support for end-to-end mobile app development, including cloud data storage using cloud tooling

Well, we are intentionally a bit vague here, but today I want to tell you what this is good for.

OK then, what is it good for?

We created the Mobile OData Service Generator to enable you to quickly build an mobile enabled OData service that constitutes your mobile back-end service for mobile applications.

So if, for instance, you want to quickly create a mobile solution that displays the daily canteen menu on your mobile app and you don’t know where to store the data for this – the Mobile OData Service Generator will do the trick.

This is the development flow in a nutshell:

  1. Design your services by either providing a CSDL file or create it in our visual editor
  2. Generate a Java service from the CSDL definition
  3. Build the Java service
  4. Deploy the Java service
  5. Start mobile app development

All these steps can be performed in SAP Web IDE, but obviously you can also choose to use build a mobile app with our SAP Cloud Platform SDK for iOS, SAP Cloud Platform SDK for Android, SAP Mobile Cards or with the Mobile Development Kit (in the MDK case, you can stay in SAP Web IDE) it’s up to you.

The Generated Service Characteristics

The Java service you are building will either use SAP HANA, SAP ASE or Postgress as a persistence layer and it will support all OData characteristics you would expect, e.g. $filter, $select and even OData v2 and V4 in parallel. Especially, the ones that are needed for a proper offline application – delta tokens. Yes, the generated service will support OData Delta Tokens for efficient offline applications. The service can be generated either for deployment on NEO landscapes or for Cloud Foundry. For Cloud Foundry you can even deploy the service directly from within the WebIDE.

This is how it looks like from above:

This feature can be found in the Mobile Development Kit feature in the SAP WebIDE Full-Stack version – currently in your SAP Cloud Platform trial as of today. If you want to know how to enable the MDK in the SAP Web IDE, you can watch this introduction video here.

Hope you find this as interesting as I do and want to get your hands dirty, read my other blog about it.

Have fun,

Martin

To report this post you need to login first.

1 Comment

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

  1. Mike Doyle

    Hi Martin, this looks interesting.  I attended a session at Tech Ed by Rui Nogueira about the Cloud Platform Application Programming Model (or CAP).  I’m to work out how your announcement relates to that.  One difference might be that, as you say, your tool has support for delta requests built in.  There is also the question of function imports, for example, which can’t be used for offline OData.  Are there any plans to unify these two services?  Couldn’t an offline- or mobile-friendly option be built into the CAP?

    Another difference is that the CAP is using CDS whereas you are requesting a CSDL file.

     

    (0) 

Leave a Reply