SAP HANA as the database, S/4 HANA and then SAP ABAP on HANA for technical folks like us is one area which we need to keep ourselves abreast with. But there is another cluster of OData, SAP NetWeaver Gateway, SAPUI5 and SAP Fiori which every ABAPer will stumble upon in his/her projects sooner if not later. we received numerous requests from our readers to put a series on OData and NetWeaver Gateway.
As there are some really good tutorials on this subject in SCN and other blogs, initially we deferred the idea to write on the same topic. But now, with the repetitive request from our beloved subscribers, we would try our best to put the series on OData and NetWeaver Gateway in a simple and systematic way so that all the beginners on this topic can learn and benefit from our page.
Let’s start.
OData
As everyone says, OData is the acronym for “Open Data Protocol”. The protocol is a set of rules which every player has to follow. To put it straight, 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. Since the protocol is HTTP based, any programming language with HTTP stack can be used for consuming OData services.
In other words, OData is a Web protocol for unlocking and sharing data; freeing it from silos that exist in some software applications. The OData protocol supports serialization in multiple popular formats, including JSON and Atom/XML. With OData, developers are able to build cross-platform Web and mobile Applications.
With OData, organizations can develop services with the high levels of data integration and cross-platform interoperability that are required by the modern day complex business.
SAP Netweaver Gateway
The below figure shows that SAP NetWeaver Gateway sits in SAP Application Layer. It is the Window for outside world to peep into SAP and transfer data to/from SAP. Outer world can send HTTP(s) message and SAP would provide them with OData. Also note, OData is an open source to exchange data over the Internet. SAP Netweaver Gateway (blue box within Application Layer in the below picture) is a technology that seamlessly connects devices, platforms and environments to SAP Enterprise Data using the OData services. SAP Netweaver Gateway offers connectivity to SAP Business data using any programming language and without the need of strong SAP development knowledge.
Both Client side (Outer World) and Server side (SAP) development can be in completely different programming languages as long as both are able to communicate with each other via HTTP.
Clients that consume the service to query and manipulate the data from OData Services are also called as “Consumers” of OData Service. Similarly, Servers that expose the OData services via endpoints are known as “Producers” of OData services.
Prior to OData, external non-SAP developers have connected to SAP using RFC/BAPI or web services. In those cases, the non-SAP developers (Web developers) needed to know before hand the structures of the data passed from SAP. The non-SAP developers needed to have at least a basic knowledge of the internal workings of an SAP system. But the scenario has changed with OData.
Advantages of OData for Programmers and Developers.
i. 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.
ii. OData message is self-describing. So any non-SAP Web developer can understand the content of the OData message without the knowledge of ABAP or how SAP works.
It is understood by now that Server hosts the Data and Clients can call the Service to retrieve the resources and manipulate them. Servers expose one or more endpoints which are Services that refers to the Resources. Clients or non-SAP World developers only need to know the Server side endpoints to call the service to query or manipulate the data.
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.
FYI: Microsoft originally developed and introduced OData. Not SAP. Surprise for an ABAPer. ? . Citrix Systems Inc., IBM Corp., Microsoft Corp., Progress Software, SAP AG, WSO2 etc collaborated together to standardize the OData for implementation of a RESTful API.
Why is OData called ODBC (Open Database Connectivity) of the Web?
Ans: OData offers database-like access to server-side resources. Hence, OData is also described as “ODBC for the Web”. Confused? Let’s simplify it.
ODBC is a standard API to access the DBMS, independent of the database management systems or operating systems. ODBC achieves this by adding drivers between the Application layer and the DBMS to translate the queries requested by the applications into instructions which DBMS can understand. Similarly, OData acts like middleware between producers and consumers to communicate data. There is a uniform way to consume data and is independent of the producer (SAP or Non-SAP OData) much like ODBC.
What was the need for OData in SAP?
Ans: Before the introduction of OData, there was the “Point-to-Point” solution for SAP to Non-SAP integration. One application for two different organizations or platforms needed two different design in SAP. This led to duplication of work, effort, time and money.
Check the below image. For pulling the same data from SAP, there are multiple interfaces created to cater the need of multiple end users (browsers/mobile/cloud/custom devices/software etc).
This mean there was poor scalability, increased system landscape complexity and increased administration effort.
The alternative to Point-toPoint solution is “One Data Model -> One API -> Multiple End-User Experiences”. Please check the image below. One OData service along with SAP NetWeaver Gateway suffices all the needs of multiple end applications.
This approach provides one solution to any environment, any platform and any experience. Moreover, no SAP knowledge required for consumption of OData.
What is the nearest competitor of OData?
Ans: GData from Google.
OData’s extensibility feature was one of the most important reasons why SAP chose OData over GData. This is particularly useful in cases where SAP specific values need to be described in this protocol; for instance, currency fields. A currency field contains two separate values, the currency amount and the currency code. These two values must always be treated as a linked pair and OData’s extensibility allows for this.
HTTP (Hyper Text Transfer Protocol) is an integral part of OData. So it deserves a small mention. ?
HTTP 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.
What is stateless?
Ans: 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.
What is RESTful?
Ans: OData is REST-inspired technology for reading, writing, and modifying information on the Web (not just SAP). 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 called as REST services because the Services are really working with Resources instead of Operations. Any communication between client and services are using URI (Unified Resource Identifier) over HTTP protocol using HTTP method. The URI is really the representation of the Resources (like POHeader, POItem, Customer, Vendor etc). Also, in RESTful service, once you identified the Resource, you will be working with a uniform interface, because it uses HTTP methods (GET, PUT, POST and DELETE) to work with the resource. So, the client does not need to know what the exact operation name defined in the service contract to call that method. GET method is used whenever we need to get the representation of an existing resource. POST is used to add new resource into the system. PUT is to modify the existing resource and DELETE is to remove the resource from the system. No matter what is the Service in whatever Platform, GET, PUT, POST, DELETE remains the same.
Still confusing? Let us try to understand with the below real example (Do not worry, how we created it. We will learn how to create them in our next post).
In the above OData Service, POHeaderSet, POItemSet, ZEKKOEKPOSet are “Resource” names. Create, Delete, GetEntity, GetEntitySet etc are the “Operation” names. While calling this OData services, the outside world (Client) needs to call the URI with the Resource details. Also, outside world only needs to use GET, POST, PUT etc verbs to pull data, create data and update data etc at the server side. These verbs are uniform and standardized for all OData. Clients do not need to know the server side actual methods or operations like Create / GetEntity / GetEntitySet etc which are called behind the scene.
It is also important to note here that it is possible to have multiple URIs pointing to the same Resource with the same output. Let us check it with the below example.
URI 1: /sap/opu/odata/sap/ZGW_PURCHASE_SRV/POItemSet(Ebeln=’4500004723′,Ebelp=’00010′)
URI 2: /sap/opu/odata/sap/ZGW_PURCHASE_SRV/POHeaderSet(‘4500004723’)/HeaderToItemNav
The above two URIs point to the same Resource.
How to check if your system has SAP Netweaver Gateway?
Ans: At NW 7.3 and prior to NW 7.3, SAP Netweaver Gateway had three add-ons namely GW_CORE, IW_FND and IW_BEP. The GW_CORE and IW_FND components were required for Gateway Server functionalities, whereas IW_BEP was used for Gateway Backend functionalities.
After 7.4 release, all the three components are bundled into a single component SAP_GWFND called Gateway Foundation.
This is just the introduction of OData and SAP Netweaver Gateway along with some related terminologies. In the subsequent parts, we will dive deeper in the actual practical scenarios of OData. We will learn how to create OData services, play with the GET, POST, PUT etc operations along with the backend methods which need to be re-defined to meet our requirement. We will also check Navigations and Associations of Data Models and learn how to handle them. At the end, we will build SAPUI5 Applications to consume our OData service.
