OData Services

1. What it is?
- RESTful Webservices
- The link between backend and frontend
- Client-Server Communication

2. Workflow/Lifecycle

- Backend -> Create/activate OData service -> Generate Runtime Objects -> Enhance &
Extend the service with CRUD operations -> Add service URL in sapui5 configuration
file and use http requests in controllers to communicate client-server
3. Entities

- The OData Services is an EDM (Entity Data Model)

- Data Model consists of a set of data entities and relationships between them
- An Entity is an instance of an entity type (for example Employee)
- An Entity Set is a collection of multiple entities (for example Employees)
- Each entity has a unique key (can be composed from multiple properties) which helps to
uniquely identify one entity from a set/collection
- All entity sets and operations are grouped as an entity container, which represents the
service’s model

4. OData Creation methods and CRUD methods implementation

- Direct from ABAP tables/views/structures

- Using BW queries/objects
- From CDS Views (depending on requirements, there are different ways)
- Others (data model from file, RFC)

Steps:

a. Go to transaction SEGW
b. Create new project

c. For ABAP Dictionary Objects expand the project, and right-click on Data Model ->
Import -> DDIC Structure
For CDS Views (which you want to extend the service) expand the project, and right-
click on Data Model -> Reference Data Source
For CDS Views which you want to use only for get operations and associations,
create the CDS Views with the annotation: @OData.publish: true and it will
automatically create an OData service and there is no need to create project in
SEGW, will see it in one of the following steps
d. After importing every DDIC Structure and create the corresponding
entities/associations or include the CDS View which automatically creates all the
associations defined in CDS and entities, generate the runtime objects: will generate
the corresponding implementation classes for the CRUD operations which can be
than implemented in order to make the http requests functional.
CRUD -> Create Read Update Delete – in rest services terms : POST(Create),
GET(Read), PUT(Update), DELETE(Delete)

After generation and saving the project you can start to implement the CRUD by
accessing the class:
e. To create the http requests and maintain the service, you must add the service in the
Service Catalog
Steps: Go to transaction /n/IWFND/MAINT_SERVICE (use /n, otherwise the t-code
is not working because of the beginning /I) -> Add Service -> Search for your service
created in SEGW (notice that it adds at the end of the name _SRV, so either you add
it on your search, either write the name of the SEGW project with * at the end), or
search for your CDS View created with the annotation for publishing OData -> Get
Services -> select it and press Add Service

f. Go back to Service Catalog and search in the services list for your new service
 g. You will find there the entity sets defined in your service and the details of the
service. If you have the CRUD methods implemented, you can test them further and
the URLs provided there will be later used in your UI5 application.

You can also test it in the browser by copying the Request URI in HTTP:

5. Associations
Associations define relationship between tables and in OData services they are useful for
navigation between entities. For example: we have an entity set projects and one entity set
clients. Every project entity has one specific client and holds the client’s ID. If you want to
see the client detail starting from a specific project, you can create association between
project and client with the navigation option “toClient”. Like this you can use the same URI
with a simple extension instead of taking the ID and requesting a different entity from the
entityset Clients. The concept of association is used in CDS Views also and by creating a
service based on CDS Consumption view, the associations are generated and there is no need
to code yourself the navigation.

SAPUI5

Important documentation link for SAPUI5: https://sapui5.hana.ondemand.com/#/controls

1. MVC Architecture

Model-View-Controller (MVC) is used in SAP UI5 development to keep the application

data separate from the user interactions.
MVC helps the developer to create separate layers for the application which can
communicate with each other.

Model-View-Controller pattern has 3 layers:

1. Model – It is the part which is responsible to retrieve the data from the
database. It also set and update the data. SAPUI5 provides different type of models, such
as OData Models. They enable binding of controls to data from OData services. The
OData model supports two-way, one-way and one-time binding modes.
2. View – It defines the user interface and helps showing the information to
users. View is based on the model. SAPUI5 provides different types of views: XML
views, JS views, JSON views and HTML views.
 3. Controller – Every action made by the user is handled in the controller. The
methods of the controller define the interaction between the model and the view.

For every functionality you desire to create in the user interface, you have to define a
function in the controller and create the control in view. For example if you create a
button a in view, you give it a “press” function with the name “onPress” and in the
controller you implement the function “onPress” with the desired command functionality
(text popups, nagivation to another view, etc..).

2. OData Consumption & Data Binding

The most important file which needs to be created in SAPUI5 applications is the
Manifest.json. This is a configuration file where you provide information such as data
sources (where do you take the data from backend, in our case is the URL for out OData
service), routing and navigation between different views and sapui5 app configuration.

For recognizing the manifest, we create a Component file which will be initialized in
index as the primary part of the application and specify the metadata of the app as the
manifest file, and set the to initialize the routing specified in the manifest.

->manifest
-> Component.js
 ->index.html

After we configure the URL for the OData Service, the next step is to bind the data model
to our UI components.
For simple get entity set in a table it is possible to only declare the path in the table items
in the view->property binding (views can be either js, either xml) , for binding the
navigation, get one entity dynamic or post, put, delete, the controller is needed because it
creates action, managed by the controller.

Example for get entity set in view of type XML:

Because the name of our model is empty (in manifest) , if you put nothing in front of you
extension of the service with explicit entity set, it will recognize the main service added in
manifest with the adding in the end of “/ZTI_ODATA”.
Example:
In manifest we declared our OData service like this:
"dataSources": {
 "demo": {
"uri": "proxy/http/nagos4hci.aes-demo.cloud:8000/sap/opu/odata/sap/ZTI_ODATA_SRV/",
"type": "OData",
"settings": {
"odataVersion": "2.0"
}
}
}

The demo data source is our service URL.

Then, we added in manifest our Models (OData is our Model in the MVC Architecture in UI5):

"models": {
"": {
"dataSource":"demo"
}
}

We can see that the model name is empty, so when you call it in data binding of an entity set, you
do not specify any name and continue the path with your entity set name.

In our case we have /ZTI_ODATA is the entity set, so when the app will bind the data, it will
request the following link:

proxy/http/nagos4hci.aes-demo.cloud:8000/sap/opu/odata/sap/ZTI_ODATA_SRV/ZTI_ODATA

There is also the option to create the model in the controller and then bind it to the elements of the
view you want:

var sServiceUrl = "/sap/opu/odata/sap/ZTI_ODATA_SRV/";

//Adding service to the odata model
var oModel = new sap.ui.model.odata.ODataModel(sServiceUrl, false);
//Setting model to the table
oTable.setModel(oModel);
oTable.bindAggregation("items", {
path: "/ZTI_ODATA"
});

OData models have functions to bind and to perform crud operations which are creating requests
to server:

1. OData.request(
{
requestUri : path
method : "GET"
}
);

2. OData.request(
{
requestUri : path

method : "PUT",

headers : oHeaders,
 data
:{

property1: DataFromView1
property2: DataFromView2
…
propertyN: DataFromViewN

}
}

3. OData.request(
{
requestUri : path

method : "POST",

headers : oHeaders,
data
:{

property1: DataFromView1
property2: DataFromView2
…
propertyN: DataFromViewN

}
}

4. OData.request(
{
requestUri : path

method : "DELETE"
}
}
The path is the URL of the specific request from OData service. Update(PUT), GET entity, Delete
requires ID in the path in order to make the server understand which entity you want to get, delete
or update.

For example:

Get EntitySet proxy/http/nagos4hci.aes-

demo.cloud:8000/sap/opu/odata/sap/ZTI_ODATA_SRV/ZTI_ODATA
Get Entity proxy/http/nagos4hci.aes-
demo.cloud:8000/sap/opu/odata/sap/ZTI_ODATA_SRV/ZTI_ODATA(team_id=1,employee_
id=1)
Create entity proxy/http/nagos4hci.aes-
demo.cloud:8000/sap/opu/odata/sap/ZTI_ODATA_SRV/ZTI_ODATA
Delete entity proxy/http/nagos4hci.aes-
demo.cloud:8000/sap/opu/odata/sap/ZTI_ODATA_SRV/ZTI_ODATA(team_id=1,employee_
id=1)
Update Entity proxy/http/nagos4hci.aes-
demo.cloud:8000/sap/opu/odata/sap/ZTI_ODATA_SRV/ZTI_ODATA(team_id=1,employee_
id=1)
 3. Routing and navigation

In the manifest we configure our routing for better navigation between views. For example, if we
have a list o employees and we want to navigate to a view with details of one specific employee,
we create a dynamical navigation:

a. Create routing in manifest:

"config": {
"routerClass": "sap.m.routing.Router",
"viewType": "XML",
"viewPath": "demo1.demo1",
"controlId": "demo1",
"controlAggregation": "pages"
},
"routes": [
{
"pattern": "",
"name": "demo2",
"target": "demo2"
},
{
"pattern": "demo3/{employeeId},{teamId}",
"name": "demo3",
"target": "demo3"
}
],
"targets": {
"demo2": {
"viewName": "demo2",
"viewLevel":1
},
"demo3": {
"viewName": "demo3",
"viewLevel":2
}
}
},

b. Create navigation functionality in controllers (controller of parent view and controller of child
view):

Parent controller:

onPress:function(oEvent){
oRouter.navTo("demo3", {
employeeId : oEvent.getSource()
.getBindingContext()
.getProperty(
"employee_id"),
teamId : oEvent.getSource()
.getBindingContext()
.getProperty(
"team_id")
});

Child controller:

onInit: function () {
oRouter = sap.ui.core.UIComponent.getRouterFor(this);
 var oView = this.getView();
oRouter.getRoute("demo3").attachMatched(this._onRouteMatched, this);
},
_onRouteMatched : function (oEvent) {
var oArgs, oView;
oArgs = oEvent.getParameter("arguments");
oView = this.getView();
// var path = "/ZTI_ODATA(team_id=" + oArgs.teamId + ",employee_id=" +
oArgs.employeeId + ")";
oView.bindElement({
path : "/ZTI_ODATA(team_id=" + oArgs.teamId + ",employee_id=" +
oArgs.employeeId + ")",
events : {
change: this._onBindingChange.bind(this),
dataRequested: function (oEvent) {
oView.setBusy(true);
},
dataReceived: function (oEvent) {
oView.setBusy(false);
}
}
});

We pass the arguments important for the URL in dynamically and use them to create our path
for data binding, and also pass them to the routing mechanism specified in manifest to create
the URL of our web app.

ABAP CDS Views

1. Definition and concept

According to SAP, CDS Brings Conceptual and Implementation Level Closer Together.
CDS is an infrastructure layer for defining semantically rich data models, which are represented as
CDS views. In a very basic way, CDS allows developers to define entity types (such as orders,
business partners, or products) and the semantic relationships between them, which correspond to
foreign key relationships in traditional entity-relationship (ER) models. CDS is defined using an SQL-
based data definition language (DDL) that is based on standard SQL with some additional concepts,
such as associations, which define the relationships between CDS views and annotations, which direct
the domain-specific use of CDS artifacts. Another example is expressions, which can be used in
scenarios in which certain CDS attributes are considered as measures to be aggregated.
➔ Platform independent views
➔ Code Push-Down

2. VDM types
a. Basic (interface view)
b. Composition (interface view)
c. Consumption
It is VDM or the Virtual Data Model. Virtual means that does not exist. In other terms, VDM is a
proxy for the CDS, arranged and manipulated in a way so that it gives a better representation of the
data. Therefore it is called Data Model. VDM is built in layers of CDS Views whch have their own
specific tasks.
-BASIC

Basic CDS views are developed to expose the Master Data like Customer Master, Material MAster,
Business Partner etc. They consume the physical SAP tables to read data. They are also called
INTERFACE views and for naming standards SAP use ‘I’ in between of the view name : *_I_*

-COMPOSITE:

These views are configures as an Association of Master data sets OR Master data and Transactional
data. They can consume Basic Views or other Composite views to read data. For naming standards,
SAP use ‘CO’ in between of the view name: *_CO_*

-CONSUMPTION

These views are created as the last layer of CDS analytical Model. These are the final views ready for
consumption by the UI tools – Bex, Lumira, Webi, Analysis for Office etc. to be accessed by business
users in the from of a report. These views can consume all other Basic or Composite Views to read
data and create a final data set to be fed into the UI tools for reports based on business requirements.
For naming standards, SAP start the view name with ‘C’: C_*

Useful documentation links:

https://www.youtube.com/c/AnubhavOberoy/videos -> youtube channel with well explained SAP

tutorials

https://sapyard.com/tutorials-on-sap-abap-on-hana/

https://sapyard.com/vdm-1-s-4hana-embedded-analytics-using-cds-virtual-data-model/

https://sapyard.com/vdm-2-s-4hana-embedded-analytics-using-cds-virtual-data-model-value-helps-
annotations/

https://sapyard.com/vdm-3-s-4hana-embedded-analytics-using-cds-virtual-data-model-meta-data-
extensionsmde/