Varad
SAP Netweaver Gateway and OData SAP . Section I: A Brief History :- One area we need to stay up to date with is SAP HANA as the database, S/4 HANA, and then SAP ABAP on HANA for technical people like ourselves. However, every ABAPer will eventually come across another cluster of OData, SAP NetWeaver Gateway, SAPUI5, and SAP Fiori in their projects.
We had several requests from readers to include a series on OData and NetWeaver Gateway after the quite lengthy “Fundamental Tutorial Series on SAP ABAP on HANA” (maybe, soon we will offer Advance Tutorial Series on ABAP on SAP HANA).
We first postponed the thought to publish on the same topic because SCN and other blogs have some pretty excellent lessons on the issue.However, as of late,.
Now let’s get going.
OData
OData, as everyone knows, stands for “Open Data Protocol.” Every player is required to abide by a set of regulations known as the protocol. To clarify, OData interface is an open standard that may be used by any non-SAP application, program, software, or device that can communicate with SAP over the HTTP(s) protocol and manipulate (read, write, edit, and comprehend, i.e., parse and create) an XML document. Because OData services are based on the HTTP protocol, they can be accessed by any programming language that supports the HTTP stack.
To put it another way, OData is a Web protocol that allows data to be shared and unlocked, releasing it from the silos that some software programs have. The OData protocol allows serialization to occur in several widely used forms, such as Atom/XML and JSON. Developers can create cross-platform mobile and web applications with OData.
Organizations can use OData to create services with the high degrees of cross-platform interoperability and data integration needed for today’s complicated business.
SAP Netweaver Gateway
The SAP Application Layer is where SAP NetWeaver Gateway is located, as seen in the diagram below. It is the window through which data can be transferred to and from SAP and seen by others.The outside world can send HTTP(s) messages, and SAP will reply with OData.Note that OData is a free and open source
As long as both server side (SAP) and client side (Outer World) development can communicate with each other via HTTP, they can be developed in entirely separate programming languages.
“Consumers” of OData Services are also clients who use the service to query and change data from OData Services. In a similar vein, “Producers” of OData services are servers that make the services available via endpoints.
RFC/BAPI or web services were the methods used by outside, non-SAP developers to access to SAP before OData. In certain situations, the web developers who are not SAP developers required to be aware of the data structures that were passed from SAP beforehand. The innards of a SAP system had to be at least somewhat understood by the non-SAP developers. However, the
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.
By now, you should be aware that the Data is hosted by the Server and that clients can use the Service to obtain and modify the resources. One or more endpoints, or services that make reference to resources, are exposed by servers. To query or change data, clients or non-SAP World developers simply need to know the server side endpoints to use the service.
The communication gap between SAP and non-SAP web developers has been eliminated with the introduction of OData. Right now, it’s open book. OData can be used without any expense or license agreement.
Just so you know, Microsoft created and first released OData. Not SAP. ABAPers are surprised.
Why is OData known as the Web’s ODBC (Open Database Connectivity)?
Answer: OData provides server-side resource access similar to a database. OData is therefore sometimes referred to as “ODBC for the Web.”Bewildered? Let’s make things simpler.
Unaffected by operating systems or database management systems, ODBC is a common API for accessing DBMSs. In order to convert the queries that applications ask for into instructions that the database management system (DBMS) can comprehend, ODBC adds drivers between the Application layer and the DBMS. OData facilitates data communication between producers and consumers in a similar manner to middleware. Similar to ODBC, there is a standard method for consuming data that is independent of the producer (SAP or Non-SAP OData).
Why was OData required by SAP?
Answer: The “Point-to-Point” method of SAP to Non-SAP connectivity existed prior to the release of OData. A single SAP application required two distinct designs for two distinct platforms or organizations.Duplication of work, effort, time, and resources resulted from this.
Look at the picture below. Multiple interfaces have been developed to meet the needs of various end users (browsers, mobile devices, cloud, custom devices, software, etc.) for extracting the same data from SAP.
This indicated that there was inadequate scalability, a more complicated system landscape, and more administrative work.
“One Data Model -> One API -> Multiple End-User Experiences” is an alternative to the point-to-point method. Please review the picture that follows. The needs of numerous end applications can be met by a single OData service in conjunction with SAP NetWeaver Gateway.
This approach provides one solution to any environment, any platform and any experience. Moreover, no SAP knowledge required for consumption of OData.
Which OData competitor is closest to you?
Google GData is the answer.
One of the main factors SAP used to select OData over GData was its extensibility. This is especially helpful in situations where this protocol needs to explain data that are unique to SAP, such currency fields. The currency amount and the currency code are two distinct values that are contained in a currency field.
The Hyper Text Transfer Protocol, or HTTP, is essential to OData. Thus, it merits a brief notice.
The foundation of HTTP is Client-Server Architecture. The Web Server is the Server that responds to the HTTP request sent by the Browser, and the Browser is the Client that receives the response.”WHAT” can be transmitted between a client and a server is defined by HTTP. TCP/IP protocols handle “HOW” data packets are sent via HTTP.
Statelessness: What is it?
Answer: After a response has been provided, the Web Server forgets about every single HTTP request it has received. Web servers are incapable of recalling or remembering an earlier request. We refer to this as statelessness.
RESTful: What is it?
The technology that can be used to read, write, and change data on the Web outside of SAP is called OData, and it is inspired by REST.REpresentailant State Transfer is referred to as REST.REST is an architectural approach that uses a simple, lightweight protocol to facilitate machine-to-machine communication. It acts as an alternative to RPC (Remote Procedure Calls) and Web Services. REST is resource-based as opposed to action-based like RPC or SOAP.
Because the services are actually interacting with resources rather than operations, they are referred to as REST services. Unified Resource Identifiers, or URIs, are used in all client-server communications across the HTTP protocol and HTTP method. In actuality, the Resources (such as POHeader, POItem, Customer, Vendor, etc.) are represented by the URI. Additionally, in a RESTful service, after locating the Resource,
POHeaderSet, POItemSet, and ZEKKOEKPOSet are “Resource” names in the OData Service mentioned above. “Operation” names include Create, Delete, GetEntity, GetEntitySet, and so on.The client, or the outside world, must contact the URI with the resource details in order to use this OData service. Additionally, the only verbs required by the outside world to fetch, create, and update data at the server side are GET, POST, and PUT. For all OData, these verbs are consistent and standardized.The real server-side actions and methods, such as Create, GetEntity, and GetEntitySet, that are called in the background, are not necessary for clients to understand.
It’s also crucial to remember that several URIs pointing to the same Resource can have the same outcome. Let’s examine it using the example below.
POHeaderSet(‘4500004723’)/HeaderToItemNav is the second URL (/sap/opu/odata/sap/ZGW_PURCHASE_SRV).
The Resource is accessed by the two URIs mentioned above.
How is the SAP Netweaver Gateway on your system detected?
Answer: SAP Netweaver Gateway had three add-ons: GW_CORE, IW_FND, and IW_BEP, both at NW 7.3 and earlier.While IW_BEP was utilized for Gateway Backend functionalities, GW_CORE and IW_FND were necessary for Gateway Server functionalities.
Following the 7.4 release, the three components are combined into a single SAP_GWFND component known as Gateway Foundation.
TThis simply serves as an introduction to SAP Netweaver Gateway and OData, along with a few terms that are connected. In the next sections, we will delve further into the real-world applications of OData.We will explore the creation of OData services, experimenting with GET, POST, PUT, and other activities, as well as redefining backend methods to suit our needs. Additionally, we will examine and learn how to handle the data model navigations and associations. Ultimately, SAPUI5 Applications will be developed to utilize our OData service.
Navigating the Heights: Understanding Governor Limits in Salesforce
