Explaining Data Services

One important aspect of the architecture of the World Wide Web is the use of abstract interfaces for component communication. These abstract interfaces are presented as connectors. A client and a server each use a connector component. There is a contract between both connectors that defines the application protocol. It defines the documents, their format, and the behavior. Any protocol can be chosen. By using the connector concept, both client and server are largely independent and exchangeable. Each connector translates the documents exchanged on the communication channel to the internal representations both on the server and on the client side, and vice versa.

The OData protocol defines such a contract by specifying a uniform protocol that has the necessary qualities. For instance, a connector attached to an SAP back-end system translates between ABAP APIs and OData entities. SAP Gateway is such a connector.

On the other side, a client connector translates between OData entities and the APIs of the consumer platform. The connector is specified here. As a consequence, any client platform with libraries supporting the contracted OData format can communicate with any server supporting the same contract.

OData follows the Representational State Transfer (REST) architecture design paradigm in the sense that the protocol transfers representations of the state of resources. The term resource denotes data that is addressable and accessible. The standard address representation or resource is the Uniform Resource Identifier (URI). A client requests a resource from a server by sending a request to a URI. The server processes the request by translating the URI to internal address data to access or manipulate the data, and then assemble the response.

OData is an open standard originally developed by Microsoft but now managed by the Oasis Organization. It is based on the Atom Publishing and Atom Syndication standards, which, in turn, are based on XML (Extensible Markup Language) and HTTP(S) (HyperText Transfer Protocol (Secure)). JSON (JavaScript Object Notation) is an alternative to XML to structure data.

The objective of the OData protocol is to provide a vendor-neutral, web-based API that fully complies with the design principles of Representational State Transfer (REST). OData provides database-like access to server-side resources. In this context, OData is also called ODBC for the Web.

OData is also extensible. This enables SAP to supplement the data types used by OData with extra information from the ABAP Data Dictionary. Another example is metadata-driven development for Web and mobile like SAP Fiori elements.

OData is available in version 2 (V2), version 3 (V3), and version 4 (V4). The versions are built on each other extending the previous version by adding new features. Most OData services are based on V2. SAP Gateway supports OData V2 since AS ABAP 7.00 and OData V4 since AS ABAP 7.50. OData V3 was skipped in SAP Gateway and is therefore not supported.

In current real-life applications, JSON (JavaScript Object Notation) is used instead of Atom and XML for structuring data. It needs considerably less meta-information, which reduces the amount of data transferred greatly. Atom and XML, in contrast, are used precisely because of the extensive meta-information when it comes to development.

Each OData service is represented by a URI, called the service root URI. A URI is a uniform resource identifier, which is a string of characters used to identify a resource by name and address. This type of identification enables interaction with representations of the resource across a network using specific protocols like OData.

To consume an OData service for read, you just need a browser and the OData service base URI. The service document is the highest-level description of an SAP Gateway service. It shows the basic information about the available data. From here, it is possible to call further information on the service, and of course the data itself, by adding URI parameters.

To get data from the service, add the name of an entity set of the service to the base URI. You get a list of entities of that type, which could be the content of a database table.

The entities of an OData service are defined in an Entity Data Model (EDM). Entity types define properties and navigations to other entity types. These associations define relation constraints based on key properties of the entity types. A navigation property is then used to actively navigate between entities during runtime. For every entity type, at least one entity set is defined. These are shown in the service document and used to request data from the OData service.

By adding the OData option $metadata to the service root URI, the metadata document of the service is shown. The whole EDM is defined here and available at runtime. Application developers and all the wizards in development environments create their applications based on this information.

One of the main features of OData is that it uses the existing HTTP verbs GET, PUT, POST, and DELETE at addressable resources identified in the URI. Conceptually, OData is a way of performing database-style create, read, update, and delete operations on resources through HTTP verbs.

By building URIs based on the rules of OData, a wide variety of data requests can be performed. These requests can often be mapped directly to SQL requests accessing data in a database.

Calling the service URI of an OData service in a GET request, results in the service document. Adding the name of an entity set to the base URI, results in a list or set of all entities. This is called a query request.

Adding the unique key of an entity in brackets to a query request results in a single entity having this key. Character-based keys must be put in apostrophes. This is called a read request.

Adding a navigation property of the entity type to a read request separated by a slash results in a single entity or a set of entities depending on the multiplicity of the association. This is called a navigation request.

OData specifies a simple, yet powerful query language that allows a client to request arbitrary filtering, sorting, paging, and so on. A client is able to express, via query string parameters, the amount, and order of the data that an OData service returns for the resource identified by the URI. The names of all query string parameters defined by OData are prefixed with a "$" character.

First, the structure of the data transferred from the server to the client can be formatted, for example, in JSON or XML. The data volume can be reduced by filtering data sets and by selecting the relevant data properties only. Paging is another way to reduce data traffic. Sorting guarantees the right sequence of the entities within a requested entity set. A client can also instruct the server to include associated data entries in the response, which is called inlining. This technique avoids subsequent read operations.

The versions of OData are additive. New versions include features of previous versions in the same way as they were used back then. But they are enhanced with additional features. This also counts for query options. One exception here is "counting" because the two ways to count in OData V2 were combined in just one in OData V4.

In OData V4, data can also be searched and computed. Both require a specific implementation depending on the application scenario.

An OData request consists of a server address, service URI, entity set, and additional query options. There are many combinations of query options possible. A full documentation is available at http://www.odata.org.

SAP offers various OData providers. SAP Gateway (up to the end of 2014 known as SAP NetWeaver Gateway) provides a single entry point to access business data of ABAP-based systems such as the SAP Business Suite or SAP S/4HANA. The SAP HANA Extended Applications Services (XS) has the same role in SAP HANA – just to name another important OData provider.

By using OData, business data can be shared among multiple environments and platforms. SAP knowledge is not required for the consumption of the data. Usually client-based applications consume SAP Gateway services and interact directly with the user. Applications in a Web browser are a common example.

However, it is also possible for an SAP Gateway service to be used as an API (Application Programming Interface) by a server-based application. Additional servers can be added to the communication path to enhance the possibilities for client and server. For mobile devices, the SAP Mobile Services add additional value to the applications.

For AS ABAP 7.00 to 7.31, SAP Gateway consists of individual add-ons that provide the OData functionality. These can be divided into the following areas:

Runtime

Provides the OData and thus the SAP Gateway service externally via the URI.

Design Time

Contains the development environment and programs for processing the requests to the service.

First introduced in AS ABAP 7.40 and finalized in AS ABAP 7.51, all add-ons are merged in the software component SAP_GWFND (SAP Gateway Foundation). This offers everything needed for the OData runtime and design time.

There are three possible deployment options for SAP Gateway (hub is a synonym for front-end server (FES)):

Hub deployment with development in back-end server (BES)

A hub deployment offers the possibility of routing and composition of multiple back-end systems. It is the single point of access to back-end systems when using OData. This increases security and flexibility in operation.

This is the recommended setup for SAP Business Suite.

Hub deployment with development in front-end server (FES)

When developing in the FES, data is only read via RFC-enabled function modules from the BES, which enables access to data of a BES not able to provide an OData service on its own. This grants more freedom in selecting a system as data source.

This is the recommended setup for integrating multiple BES with different releases.

Embedded deployment

When developing in the BES, the application source code has direct access to the definition of the data and other repository objects. This increases performance and efficiency in development.

This is the recommended setup for SAP S/4HANA.

The SAP Gateway Service Maintenance (transaction /IWFND/MAINT_SERVICE) provides a list of all the OData V2 services registered in the system. Complete management of the SAP Gateway services is carried out here. The transaction is divided into three areas:

• Service Catalog (service name, description, and many other settings)
• ICF Nodes (maintenance of the ICF services and testing of the service)
  Hint

  Since SAP_GWFND 7.58, an ICF node is optional for calling an SAP Gateway service. The OData V2 services are then directly linked to the node /sap/opu/odata.
• System Aliases (maintenance of the connection to the back-end)
  Hint

  For services not connecting to other systems, the Processing Mode is set to Co-deployed only and no system alias is assigned.

OData V4 services are not registered as single instances. Instead, a service group consisting of multiple services is published. These service groups are created using the SAP Backend Service Administration (transaction /IWBEP/V4_ADMIN) and shipped by SAP or created by developers.

The SAP Gateway Service Administration (transaction /IWFND/V4_ADMIN) is used to publish service groups so that the services inside can be consumed in applications.

Using the SAP Gateway Client (transaction /IWFND/GW_CLIENT), all functions of an OData service can be tested. For a read request, it is enough to enter the request URI and execute. For a create, update, and delete request, more adjustments must be made, for example, a request body filled with data must be created. All adjustments can be saved as test cases for later usage.

The SAP Gateway Client can handle data formats like XML (Atom) and JSON for both OData V2 and V4 services.

Apart from these transactions, there are several more for SAP Gateway. All transactions are connected to each other via buttons and menu entries. Therefore, you can jump from the service maintenance to the client and back.