7    Creating OData Services with SAP Gateway

OData services are required to connect SAP Fiori to the back-end SAP system. This chapter gives you an overview of service-generation methods and offers step-by-step instructions for generating OData services using SAP Gateway Service Builder.

Before we begin creating and extending SAP Fiori apps, we need to make clear some basic concepts about OData services and SAP Gateway Service Builder. The main objective of this chapter is to give you an in-depth look at OData services and SAP Gateway Service Builder, as well as the process of creating an OData service. We’ll walk you through service-generation methods using SAP Gateway Service Builder, and at the end of this chapter, we’ll work through a couple of simple exercises to explain the three main steps in service creation: data model definition, service implementation, and service maintenance.

In Chapter 1, we introduced the REST protocol, OData protocol, and SAP Gateway. SAP Gateway and OData service creation is a big topic. Our intent is to discuss certain scenarios or methods of service generation that will enable you to better understand the processes when creating or extending SAP Fiori apps in the next chapters. In this chapter, you’ll learn three different ways to create data models and generate OData services using SAP Gateway Service Builder.

We start with an overview of OData concepts by exploring the documents with an example in Section 7.1 and then guide you through the various terms in SAP Gateway Service Builder in Section 7.2. In Section 7.3, we’ll first introduce you to import functions to build a data model, use an example of Sales Order Header data from the Business Object Repository (BOR), and show you how to build a data model and generate an OData service (Section 7.3.1). Then, we’ll provide an overview of the second method to generate data models and OData services by redefining services (Section 7.3.2). Finally, we finish Section 7.3 by showing you how to create an OData service on top of an SAP Business Explorer (BEx) query (Section 7.3.3).

7.1    Introduction to OData

By now, you know that OData is the open standard that provides standard platform-agnostic interoperability and access to data sources via websites. OData was built on web technologies such as HTTP, AtomPub, XML, and JavaScript Object Notation (JSON) to provide access to information from a variety of applications. It was designed to provide a RESTful API that is accessible by forming an appropriate URI and assigning it to the corresponding HTTP header. The biggest advantage of OData services is that they’re multichannel and developed to serve many applications. Put simply, OData is used to expose, access, and modify information from different sources.

In the following sections, we’ll discuss the basics of an OData service and OData queries.

7.1.1    OData Service Basics

In this section, we’ll cover the basic structure of an OData service. Let’s start with simple operations that can be performed using the OData protocol.

We’ll use the standard OData service of a Create Sales Order app, which you activated in Chapter 4, Section 4.2, to understand the concepts of an OData service. Follow these steps to view the OData service of the app:

  1. Log in to your ABAP front-end server.
  2. Run Transaction IWFND/MAINT_SERVICE.
  3. Filter External Service Name for “SRA017_SALESORDER*”, then press (Enter) (see Figure 7.1).
    Service Name

    Figure 7.1    Service Name

  4. Select the service, then click Gateway Client (see Figure 7.2).
    Gateway Client Button

    Figure 7.2    Gateway Client Button

  5. Click Execute (see Figure 7.3).
    Executing Service

    Figure 7.3    Executing Service

An OData service is a logical data model that depicts how users perceive the model behind the UI. Essentially, anything that’s possible with the UI becomes part of the API, and each OData service is represented with a service root URI. There are two types of documents accompanying each OData service:

  1. Service document
    This shows the details about the entity set.     Figure 7.4 shows the service document with seven entities: Customers, Products, Product Images, Sales Orders, Product Attributes, Order Items, and Partner Addresses.
  2. Service metadata document
    This gives you the structure of an OData service. It describes the Entity Data Model     (EDM) of the source. In the service metadata document, the data is described in EDM terms, using XML for describing models called the Conceptual Schema Definition Language (CSDL). An EDM describes the organization and the relationships between different data resources with models and entity types within a particular business scenario. Figure 7.5 shows an example of what the OData feed looks like from SAP. Run the following URL in your browser to view the service metadata document of the Create Sales Order service:
    http://<host>:<port>/sap/opu/odata/sap/SRA017_SALESORDER_CREATE_SRV/$metadata
    Service DocumentServicedocument

    Figure 7.4    Service Document

    Service Metadata Document

    Figure 7.5    Service Metadata Document

Let’s now dive deep into the EDM and the corresponding parts of the service metadata document. We’ll explain each element as we work through the Create Sales Order OData service.

In the service metadata document, expand EntityContainer, where the service metadata document defines EntitySets belonging to one service. EntitySets listed in the service document and the service metadata document are exactly the same (see Figure 7.6).

EntitySet

Figure 7.6    EntitySet

Entity sets group entities, and all the entities of one entity set are of the same entity type. For example, a Customer entity set is a set of Customer instances (see Figure 7.7), and all Customer instances are of the Customer entity type.

EntityType

Figure 7.7    EntityType

Entities are structured as records with a key, under the entity types. For example, expand the Customer entity type, and you’ll notice the keys (Customer ID, Division, etc.).

An association defines the relationship between two entity types, and every association includes two association ends (entity types). An association end states the entity type elements, the roles of each of the entity type elements, and the cardinality rules for each association end. For example, expand the CustomerSalesOrder association in the service metadata document (see Figure 7.8), and you’ll see that the end types are Customers and Sales Order, and the cardinality is one to many (i.e., one customer can have many products).

Association

Figure 7.8    Association

For example, to read the list of customers from an OData service, replace $metadata with customers at the end of the service URL. Initially you might find this very confusing, but eventually you’ll get used to all these terms, and you’ll be able to understand an OData service very easily.

7.1.2    OData Service Queries

Now that you understand how to read a service, let’s move on to the most important operations—that is, the CRUD operations. OData uses the existing HTTP verbs (POST, GET, PUT, and DELETE) against addressable resource identifiers in the URI. Figure 7.9 shows the HTTP methods in SAP Gateway client.

HTTP Methods

Figure 7.9    HTTP Methods

The following list describes the different requests used for entities:

OData specifies a simple query language that allows the client to request random filters, sorts, or pages. Table 7.1 shows some of the most important query options.

Operation Query Option
Filtering $filter
Projecting $select
Sorting $orderby
Paging $page
Inlining $expand

Table 7.1    OData Query Options

The following are some examples of OData service queries:

In this section, you learned about the two OData service documents in detail, as well as what entity, entity set, entity container, and different query options are. You’ll see a lot of these in subsequent chapters, especially when we create or extend existing apps.

Now, let’s discuss how to build an OData service using SAP Gateway Service Builder.