Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

SAP (Fiori) OData Service Examples

dilipkkp2412
Contributor
‎04-10-2018 11:34 AM

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



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



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:



 

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.......

14 Comments
Labels in this area
Popular Blog Posts