Thursday, 30 November 2017

OData and SAP Netweaver Gateway. Part I

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
Th 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. Now OData is managed by the Oasis Organisation .
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 Resourcesinstead 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.

No comments:

Post a Comment