This time we decided to focus on the middleware layer of your SAPUI5 application (“Frontend”) and your SAP instance (“Backend”) – ODATA services implementation, based on SAP NetWeaver Gateway.

So what is ODATA?

ODATA (Open Data Protocol) is a protocol initially developed by Microsoft, and it defines the interaction layer of HTML5 web applications with back end systems.  In SAP world, the protocol allows performing queries and updating information back in your SAP instance, providing a native connection to RFC functions, search helps, filtering and sorting data and working with large data sets.

Why ODATA?

ODATA defines rules and standards that acceptable in HTML5 frameworks. This protocol uses URL-based methodology to access entities and perform operations according to CRUD methods, also known as REST.

SAP has chosen ODATA as their main protocol for all use cases of Fiori apps and SAPUI5 developments, in order to align with international standards accepted in the field of WEB development. This would prevent developers from making up their tailor-made solutions and align to technology and platform paradigms accepted in the market.

Basic ODATA principles

The basis principle embedded in ODATA paradigm is entities. The entities can implement different methods, such as create / read / update / delete, AKA CRUD .

Entity is something similar to ABAP structures, if you know what I mean. This is a set of fields that are included in single object called entity. Entity set, in this case, would be an array of entities of the same type.

Another important principle of ODATA protocol is the ability to define relations of any kinds between different entities.

The actions that can be implemented are:

• CREATE – create a new entity
• READ – read an entity by it’s key
• UPDATE – update an entity by it’s key
• DELETE – update an entity by it’s key
• QUERY – fetch an array of entities

Additional terms you might run into while researching the subject of ODATA:

• Deep insert – a method that receives a complex data structure and usually creates a complex entity that contains of multiple sub-entities
• Function import – a method that is our of CRUD scope

How can I build ODATA?

Modeling an ODATA service is done in SEGW transaction in your Business Suite back end system, usually by importing structures from existing RFC functions or search helps, and then exposing the entities through SAP NetWeaver Gateway, which also logs all requests and provides tools to analyze errors and failures.

The result of building an ODATA service would be an addressable URL with metadata, which implements standard REST-like calls.

For example, fetching a list of orders would look like this:
https://{ODataServerAddress}/Orders

Getting info of a specific order by order number:
https://{ODataServerAddress}/Orders(‘123456789′)

Reading a row ’10’ of this order would be:
https://{ODataServerAddress}/Orders(‘123456789′)/OrderLines(’10’)

Summary

Following said above you can understand that proper modeling of ODATA services is an integral part of SAPUI5 application development. Proper definition of data schema and entities at an early stage of your project will build a great base for understanding how your app will look like.

The leading principle of ODATA development process is simplification. We will strive to separating complex RFC structures into simple entities – it is improving your data model and optimizes performance, as you might need to run your SAPUI5 app on a mobile device – smaller queries run faster.

So we recommend building entity for each single structure, and implement methods that are allowed to be executed withing each structure separately. This would allow cleaner project data and requests reuse.