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:
- To register similar OData Service:
- To consume similar oData Service in Fiori App:
- 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:
- To consume similar oData Service in Fiori-App
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:
- To consume similar oData Service in Fiori-App
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“
- Request URI is “/sap/opu/odata/sap/ZTEST_ODATA_SRV/MaterialListSet”
- consider above business case “1. Odata Service to get one table records via RFC” where odata service’s
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:
- Create
- Delete
- GetEntity (Read)
- GetEntitySet (Query)
- 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…….
I like all the information in one place. Adding the definitions was a nice touch. It helps to put everything into perspective.
Nice blog with not just links, but also added information, As you've noticed I've read quite a few of these. I would recommend them to anyone learning the basics. Or looking to pick up a trick or two.
Michelle
Hi Dilip , You have a customer in me when you have your book out . I am sure it will be a best seller. Thank you for your time and efforts to put this together. It is a huge help.
Really Nice very helpful, I always used GET POST with Deep Entity set , now I have seen one service call multiple output table (Entity sets) which is lot of help in my project to call all drop downs data at once, instead of repeat calling .. Thanks a ton for all this with real use case scenarios ..
Its nice to hear, that, this blog has helped you all……
Regards,
Dilip.
Hi Dilip,
We have a service which returns item table in the oData service. At each line item we need to pass a text table (Comments and long text of variable length, might be a paragraph) do you know how do we handle large text fields or variable text tables in oData service? If you have any blog to point at that will be awesome
Thanks,
Ransome
Hi Ransome,
About data return in Table format:
About long text var length in field:
Regards,
Dilip
Dilip
Nice jog.I like it.Very thanks.
Best regards
George
Nice blog..
is continuation part is published?
Vijay
Hi Vijay,
I have certain in draft format, but couldn't get time to finish it.
Will try soon.
Thanks for your interest.
Regards
Dilip
Thank you Pandey, its very helpful. Pl. help me to answer my question, as below,
We are listing out around 1000 order numbers on UI with checkbox ability, well. now user want to select RANDOMLY around 500 orders out of displayed 1000 numbers and want to read its header data, pl. let me know how can I build oData service? I mean, how I can build a query bcz I guess specifying user selected all 500 orders numbers on the query is not a good idea?
Hi Shivaraju,
In List-Box, you should be displaying important header fields like below example:
https://sapui5.hana.ondemand.com/#/entity/sap.m.ObjectListItem/sample/sap.m.sample.ObjectListItemMarkers
Thanks & Regards,
Dilip Pandey
Thank you Dilip for your answer. OK, but just out of my curiosity pl. let me know how can we query/pass user's selected those 500 PO numbers to Odata to fetch data from ECC's EKKO table?
Hi Shivaraju,
Sorry for late reply, By now, you have already addressed your case. However, for your information, please find below details:
You can do batch selection of records to post it into SAP-odata-service.
In one of the our requirement, we had given provision in fiori-App list for multiple selection of requests and this way approver has option to approve multiple requests (of specific type) in one attempt.
We had designed oDataservice like Header/Item case, where all selected requests were passed in odataService in Item manner, keeping header status-field as "Approved" vice versa consumed RFC (inside oDataService) gets the batch selected records.
Please note: I'm not sure of 500 records selections w.r.t. oDataService's ITEM table limitations. You should give a try.
Thanks & Regards,
Dilip Pandey
Hello Mr.Dilip,
It was a nice blog with lot of information. Appreciate your efforts. I just want to understand detailed process for accessing BAPIs using ODATA service. Is there any specific blog for reference that explains in detail about the BAPI calls from UI5 or external systems using ODATA service?