SAP (Fiori) OData Service Examples

Overview

• Main objective of this blog is to put different oData Service blogs (of mine) at one place with respect to their business case summary.
• And to put brief info of different terms used in oData Service creation/consumption.
• This blogs will be updated time to time as soon as new business case blog is ready..

OData Service Examples w.r.t. Business cases:

1. Odata Service to get one table records via RFC

• A business case where we want to fetch material master table records. Following blogs can be referred for same:
• To create similar OData Service:
  •  Create OData Service in SAP Fiori Server
• To register similar OData Service:
  • Register OData Service in SAP Fiori Server
• To consume similar oData Service in Fiori App:
  • SAP Fiori – Consume OData Service, CSS, i18n properties in UI5 Application
• Please Note:
  • OData service Registration happens once for one service. Registration Steps are common.

2. Odata Service to post multiple table as a request in a single call

• A business case where, in a single service call, we want to send multiple tabular requests and in response we want to get results in separate table structure. Following blogs can be referred for same:
• To create similar OData Service:
  • SAP oData Service [POST]: Multiple Table Input
• To consume similar oData Service in Fiori-App
  • Call oData Service in Fiori App (Eclipse): ‘Create’ operation

3. Odata Service to get multiple table response in a single call

• A business case where, in a single service call, we want to get multiple tabular results, which data may be used for drop-downlist.
• To create similar OData Service:
  • SAP oData Service [GET]: Multiple Table Output
• To consume similar oData Service in Fiori-App
  • Call oData Service in Fiori App (Eclipse): ‘Read’ operation

4. Odata Service to consume a REST-Services

• In a fiori-app, where data need to be accessed from a non-sap system.
• This non-sap system has a REST-Service technique for data exchange to out-side world.
• So, in fiori-App, we need an oData-Service which can consume/talk to non-sap’s REST-Service for data Exchange.
• To create similar OData Service:
  • SAP oData Service [GET]: Consume REST Service

There are many different terms/objects been used during creation/implementation of above oData Service examples, which are been summarized as follows: (Please note: Below definitions are been extracted from different links on internet and been related to my business-case blogs for better & brief understanding.)

OData

• The Open Data Protocol (OData) is a data access protocol built on core protocols like HTTP and commonly accepted methodologies like REST for the web.
• OData interface is an open standard that can be consumed by any application, program, software or device of the Non-SAP World that can connect with SAP using the HTTP(s) protocol and can manipulate (read, write, modify and understand i.e. parse and construct) an XML document.
• OData is REST-inspired technology for reading, writing, and modifying information on the Web (not just SAP).
• Advantages of OData
  • Since the protocol is HTTP based, any programming language with HTTP stack can be used for consuming OData services
  • The OData interface is implemented using XML or JSON. Both of these formats are well known, plain text protocols for the transmission of information over the Web.
  • Data message is self-describing. So any non-SAP Web developer can understand the content of the OData message.
  • With the advent of OData, the communication barrier between SAP and Non-SAP Web Developers is removed. It is an Open book now. There is no cost or license agreement needed for the use of OData.

HTTP:

• HTTP (Hyper Text Transfer Protocol) is based on Client-Server Architecture.
• The Browser is the Client which sends HTTP request and Web Server is the Server which sends the response back to the browser.
• HTTP defines
  • “WHAT” can be transferred between Client and Server.
  • “HOW” the data packets are transferred via HTTP is handled by TCP/IP protocols.

Stateless

• Every single HTTP request that is received by the Web Server is forgotten after a response has been sent across. Web Servers do not remember or recall the previous request. This is called stateless.
• Odata services have this nature.

REST (REpresenational State Transfer)

• REST is an architectural style that uses simple and lightweight mechanism for inter-machine communication.
• It is an alternative to the RPC (Remote Procedure Calls) and Web Services.
• REST is ‘Resource-based’, unlike RPC or SOAP which are Action-based.
• REST Services are working with ‘Resources’ instead of ‘Operations’.

URI (Unified Resource Identifier)

• In REST services, any communication between client and services are using URI over HTTP protocol using HTTP method.
• The URI is really the representation of the Resources (EntitySets like MaterialList, DocType, VendorList etc).
• In RESTful service, once Resource been identified, we work with a uniform interface because it uses HTTP methods to work with the resource.
• HTTP methods are as below:
  • GET       is to get the representation of an existing resource.
  • POST     is to add new resource into the system.
  • PUT        is to modify the existing resource
  • DELETE is to remove the resource from the system.
• So, the client does not need to know what the exact operation name defined in the service contract to call that method.
• For example:
  • consider above business case “1. Odata Service to get one table records via RFC” where odata service’s
    • Request URI is “/sap/opu/odata/sap/ZTEST_ODATA_SRV/MaterialListSet”
      
    • Resource      is “MaterialListSet”
      
    • Operation     is  “GET“
    • Protocol       is  “HTTP“
• 

Creations of OData Service:

We create oData service in SAP-Fiori (front-end) system using t-coed ‘SEGW’. Below screen displays different components of oData

EntityType & EntitySet

• Entity-Type is a structure (or a work area which holds just one row)
• Entity-Set is an internal table (holds more than one entity/rows).

Property:

• This is to define the fields of the structure/work area and internal table Service Implementation

Service Implementation

• Service Implementation folder has MaterialListSet Operations auto generated.
• These are ABAP Methods which would be triggered when the relevant endpoints would be called.
• Auto generated operations are:
  1. Create
  2. Delete
  3. GetEntity (Read)
  4. GetEntitySet (Query)
  5. Update

MPC & DPC

• Two classes, MPC and DPC are also generated along with Base and Extended Class.
• DPC and MPC are not connected by any coding. They talk to each other via Configuration.
• MPC (Model Provider class)
  • This defines the Gateway Service interface.
  • This is used to define model.
  • We can use the method Define to create entity, properties etc using code based implementation.
  • We rarely use MPC extension class.
• DPC (Data provider class)
  • This provides the Gateway Service functionalities.
  • It is used to code our ‘CRUDQ’ methods as well as function import methods.
  • We write all our logic in redefined methods of DPC extension class.
• The ‘CRUDQ’ methods:
  • This is nothing but Create, Read, Update, Delete and Query operations which we can do in oData Service.

Association & Navigation:

• These are two important properties available in SAP Netweaver Gateway to associate two/multiple entity types.
• Example:
  • If we want to push Header and Items data at a time in one call and in acknowledgement we want output in Result entity. This is can be achieved using association and navigation property
  • Above business case can be referred for same:
    • “1. Odata Service to get one table records via RFC“

Query Operation (GET_ENTITYSET):

• If we want to get all records of a table via oData Service, then we re-define method ‘GET_ENTITYSET‘ of DPC.
• It returns an array or internal table in defined Entity structure format.
• Example:
  • Suppose our fiori app wants to display all records from MARA table in some DropDownList (F4 help box).
  • Above business case examples can be referred i.e.
    • “2. Odata Service to post multiple table as a request in a single call“
    • “3. Odata Service to get multiple table response in a single call“

Read Operation (GET_ENTITY):

• If we want to fetch only one record based on input, then we redefine method ‘GET_ENTITY‘ of DPC.
• Example:
  • Suppose our fiori application wants to connect to SAP using OData service by providing the Material number and pull only that Material numbers details from MARA table.

The $expand Query (GET_EXPANDED_ENTITYSET):

• The $expand query option is very powerful and allows us to provide multiple entities and/or entity sets in one single service call, instead of performing several calls subsequently
• For $expand query to work, an association or navigation property should be created.
• And we implement ‘GET_EXPANDED_ENTITYSET‘ method.
• Example:
  • Above business case example can be referred for same i.e. “3. Odata Service to get multiple table response in a single call“

Deep Insert (Create_Deep_Entity):

• To post/push Header and line items together to the back-end RFC via oData Service, we follow Create_Deep_Entity approach.
• The ‘Create_Deep_Entity’ approach is also called as Deep Insert in SAP OData service
• Deep insert is used to POST the nested structure of feed/collections to the back-end system.
• By implementing this we can reduce the no.of OData calls made to the SAP Netweaver Gateway server.
• Entity sets (Header, Item and Result) which are used should be associated, means while calling one Entity set (for e.g. say Header), we should use Item and Result Entity Sets as well, thus in a single call we are using three Entity Sets thus avoiding no.of OData calls.
• This can be achieved by the concept of Association and Navigation properties.
• Example:
  • Above business case example can be referred for same i.e. “2. Odata Service to post multiple table as a request in a single call“

To be continued…….