Explaining OData

Objectives

After completing this lesson, you will be able to:

  • Explain SAP Gateway
  • Explain OData
  • Develop OData Service

SAP Gateway Introduction

Challenges of Modern Communication

Modern communication, which uses various communication devices, allows a wide range of possibilities to access a SAP system. Nowadays, this is one of the biggest integration challenges. To simplify data access, it must therefore be possible to access the information services of a SAP back-end system via a standard interface. This option is offered via the SAP Gateway using the OData protocol.

SAP Gateway is used by SAP Business Suite and SAP S/4HANA to publish OData services built on top of the ABAP application server. SAP Gateway enables consumption of SAP Business Suite and SAP S/4HANA data for people-centric applications across multiple channels.

SAP Gateway Deployment Options

You can install SAP Gateway independent of consumer technologies, however the software components installed for the consumer technologies must also be installed on one SAP Gateway server. You can connect multiple consumer technologies to one SAP Gateway instance.

Deployment Options are:

Central Hub Deployment: The SAP Gateway core components can be deployed in a standalone system, either behind or in front of the firewall. In addition, you can install the optional components for central hub deployment in your standalone system. For SAP NetWeaver 7.02, 7.03, and 7.31, you can install the component IW_BEP either in this hub system and/or in the back-end system. For SAP NetWeaver 7.40 or SAP NetWeaver 7.50 and higher, the core component SAP_GWFND is installed as standard and includes the functional scope of IW_BEP.

Embedded Deployment: The core components for SAP Gateway and any optional back-end components are deployed together in the SAP Business Suite back-end system. For this deployment option, you need a back-end system only, and not a dedicated SAP Gateway central hub system.

The figure Deployment Options provides a simplified overview of the different deployment options available to you.

Depending on your Preferred Deployment, different development options are available for SAP Gateway Foundation:

  • Central Hub Deployment (service development in the SAP Business Suite back-end system).

  • Central Hub Deployment (service development in SAP Gateway Foundation hub system).

  • Embedded Deployment (service development in the SAP Business Suite system).

Central Hub Deployment (service development in SAP Business Suite

When you develop SAP Gateway in the back-end system, Gateway server functionality is only used on one dedicated server, the hub system. You deploy the services on the back-end systems and register it on the server.

Therefore, the Gateway service is deployed in the Gateway back-end systems, where either IW_BEP is deployed or where the back-end system is running on top of SAP NetWeaver 7.40, leveraging core component SAP_GWFND.

Central Hub Deployment (service development in SAP Gateway Foundation hub system)

When you use hub deployment with development in the hub, the Gateway server functionality is only on one dedicated server, the hub system. In contrast to development in the back-end system, service deployment takes place on the hub system. Use this option when either no development in the back-end system is required or if you are not allowed to deploy the add-on IW_BEP in the back-end, in case of releases prior SAP NetWeaver 7.40. In this case, you are limited to the interfaces that are accessible through the RFC in the back-end.

Embedded Deployment (service development in the SAP Business Suite system)

In case of the embedded deployment option, development takes place in the SAP back-end system, which is in this case the same as the SAP Gateway system. You register and publish your services in the SAP back-end system, for example: SAP Business Suite / SAP S/4HANA.

Central Hub Deployment of SAP Gateway Foundation has the Following Advantages:

  • Routing and composition of multiple systems is supported.

  • Dedicated SAP Gateway Foundation content is available.

  • Content can be deployed without touching the SAP Business Suite system.

  • Decoupled lifecycle of consumer applications from the SAP Business Suite system.

  • Central management of routing and connectivity with SAP Business Suite systems.

  • SAP Gateway Foundation capabilities need to be deployed only once within the landscape.

  • Better security, as a request is validated at the dedicated box and consequently attacks on the SAP Gateway Foundation system will not automatically affect the SAP Business Suite system.

  • A separate SAP Gateway Foundation system can be implemented in a demilitarized zone (DMZ) for external access.

  • Independent innovation speed of SAP Gateway Foundation and the connected SAP Business Suite systems.

  • Development of context specific to SAP Business Suite system within the SAP Business Suite system enables you to reuse data stored in the SAP Business Suite system easily since development takes place in the system in which your data is stored. This development is bound to the lifecycle of the SAP Business Suite system.

Deployment Embedded in the SAP Business Suite System has the Following Advantages:

  • Direct local access to metadata and business data, meaning easy reuse of data.

  • Less runtime overhead as one remote call is reduced.

  • No content merge for different applications required.

  • No additional, separate SAP Gateway Foundation system required.

  • Lower total cost of ownership as there is one less system to maintain.

However, note the following considerations:

  • The innovation speed of SAP Gateway Foundation and the SAP Business Suite system need to be synchronized.

  • Devices need to be integrated with the SAP Business Suite system on a point-to-point basis.

  • Cross-system composition is not advisable.

  • Central SAP Gateway Foundation content is not available. Content specific to SAP Business Suite is used in SAP Business Suite system.

OData

OData (Open Data Protocol) is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs. OData helps you focus on your business logic while building RESTful APIs without having to worry about the various approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats, query options, etc. OData also provides guidance for tracking changes, defining functions/actions for reusable procedures, and sending asynchronous/batch requests.

OData RESTful APIs are easy to consume. The OData metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client proxies and tools.

On March 17, 2014, the Open Data Protocol in version 4.0 and the OData JSON format in version 4.0 were officially released as OASIS standards.

OData works based on entities. So defined, typed classes with properties. Where conventional APIs required external documentation so that you could see what the API returns for certain queries, OData provides metadata.

The advantages are:

  • It is based on REST.

  • Documentation takes place via the metadata.

  • The corresponding classes can be generated from the metadata according to the entities.

  • Use of filters, counters and more functionalities to select data from the data pool.

  • And even more.

OData supports two formats for representing the resources (Collections, Entries, Links, etc) it exposes:

  • Atom-Syndication Format

    The Atom-Syndication Format is an XML-based format designed for exchanging information in the form of web feeds i.e. a headline of news page or even the complete structure of a web page.

  • JSON (Java Script Object Notation)

    In OData protocol version 4.0, JSON format is the standard for representing data. JSON provides a format with which it is possible to exchange data between different systems. The semantic is similar to JavaScript and correspond to a subset of the language elements. Unlike XML, JSON also reduces definition overhead.

Developing OData Services

You have various development options to create an OData Service:

  • Manual generation

    You can create the Model-Provider-Class and the Data-Provider-Class, as well as the technical model and the technical service manually. Choosing this way, you have to familiarize yourself with OData API.

  • Generation in the Object Navigator (SE80)

    Create a technical model in the Object Navigator (SE80) and generate the Model-Provider-Class (MPC) and the Data-Provider-Class (DPC) from existing RFC function modules, Business Object Repository (BOR) objects, or SAP-GUI-screens. You can then also have the technical service generated in the Object Navigator. Ideally, you do not have to code at all with this approach.

  • Generation in the Gateway Service Builder (SEGW)

    SAP Gateway Service Builder provides you with an easy-to-use set of tools for creating services. It has been conceived for the code-based OData Channel and supports you throughout the development life cycle of a service. The Gateway Service Builder allows you to describe the object model and to generate the entire Model-Provider-Class and part of the Data-Provider-Class from this description. The Gateway Service Builder can also generate the technical model and the service. If you choose this way, you only have to code the data access.

Regardless of which option you choose, you have to create the OData-Service in the service catalog manually. For creating the OData-Service, use transaction: /IWFND/MAINT_SERVICE.

Service Creation

The development of services using the Gateway Service Builder takes place in the SAP back-end system.

The Gateway Service Builder supports the following development steps:

  1. Project Creation

    The process starts when you create a project in the Gateway back-end system. To create a project, use the transaction code: SEGW. The Service Builder bundles the artifacts you need to develop in a project.

  2. Data Model Definition

    In this phase, you define the model your service is to be based on. That is, you define the entity types, entity sets, associations, and so on that underlie your service.

  3. Service Implementation

    In this phase, you implement the operations that are supported by the service. Here, the runtime objects (ABAP classes and other repository objects) that make up a Gateway service are generated. The actual implementation of the service can be done either by writing code, or by mapping the methods of an OData service to the methods of a data source. In this phase, you also register the service in the backend.

  4. Service Maintenance

    In this phase, you activate (or publish) the service on the SAP Gateway hub system that has been registered in the SAP backend system.

Data Model Definition

An OData service is a logical data model that describes entities by using associations and operations. The figure, Data Model Example, shows a simple logical data model and the associations between the entity types. In this example, we want to expose a service to access business partners, sales orders, sales order line items, products, and the contacts of business partners.

When building the OData model in the Service Builder, you can reuse existing data structures, or manually create model components.

There are two types of documents associated with each OData service:

  • Service document
  • Service metadata document

Both document types can be retrieved from a server by means of a HTTP GET call. The service document is available at the Service Root URI and is formatted in Atom or JSON. If you click on the hyperlink, you send a HTTP GET call to the server and the server responds with the service document.

Service Builder Tree Structure

The Service Builder provides a nice tree view folder structure to organize the different components of a data model. This structure provides one folder for each of the following:

  • Entity Types
  • Complex Types
  • Associations
  • Entity Sets
  • Association Sets
  • Function Imports

In the figure, Data Model in Service Builder, the example entity data model consists of the five entity types: Product, BusinessPartner, SalesOrder, SalesOrderItem, and Country (not yet modeled in the Service Builder).

Gateway Service Implementation

The results of the design-time activities in the SAP Gateway Service Builder are mirrored in ABAP classes and two new Gateway-specific repository objects.

An OData service is based on two regular ABAP classes:

  • A Model Provider Class (MPC)
  • A Data Provider Class (DPC)

The MPC defines the model and metadata of the service. The DPC provides the functionality of the Gateway Service. Both the MPC and the DPC are registered as a service by the Service Builder when the project is generated.

The two base classes contain logic, which is generated by the Service Builder. The logic in the base classes is overwritten every time the project is regenerated. For this reason, you should not modify the code in these classes, as the Service Builder overwrites their contents.

The extension class names have the suffix EXT. An extension class is a subclass of the base class that is created once, only when the project is generated for the first time. An extension class initially contains no logic. The Service Builder provides the extension class for you to write your own code. Regenerating the project does not overwrite your code in the extension classes, therefore the service implementation takes place in the data provider extension class.

Usually, there is no need to maintain the MPC_EXT also.

Examine and Test an OData Service

ExerciseStart Exercise

Log in to track your progress & complete quizzes