I recently got in touch with OData in connection with the ABAP Programing Model for SAP Fiori. However, there is more than only this one programing mode. There is SEGW, there is RAP and CAP… I'm aware of the fact that various documents/blogs have been published on the topic of OData already, but for sake of completeness and staying comprehensive, I will touch parts here which you might already know. Aim is to get an overview of OData and how it can be utilized in the SAP ecosystem. The structure of this blog-post is as follows:
1) What is Odata?
2) How is this useful in SAP-systems?
3) Cheat-Sheet - using OData services
4) Implementing OData services
4.1) Classical ABAP
4.2) SAP Fiori programming model
4.3) RAP and CAP
5) OData vs. InA
6) Summary
7) Transactions & Resources
...but first of all, there is OData. So, what is OData?
“OData (Open Data Protocol) is an OASIS standard that defines the best practice for building and consuming RESTful APIs. (…) The OData metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client proxies and tools. Some of them can help you interact with OData even without knowing anything about the protocol.” (Source: Understand OData in 6 steps · OData - the Best Way to REST)
What this definition states, actually is: With OData you can request, exchange and modify data by using URIs via the HTTP protocol… Oh wait, but what’s with APIs, REST and SOAP? (See here for an comprehensive explanation of the differences: Difference between SOAP, REST, ODATA and HTTP protocols - ABusiness Tech and REST oder SOAP? (redhat.com)). Long story short: OData is an open standard, based on REST (Representational State Transfer) and therefore uses the CRUD operators as HTTP-requests (GET, POST, PUT, DELETE) to facilitate machine-to-machine communication. The payload is encoded using JSON or the Atom Syndication Format. This way loosely coupled client-server architectures are being made possible. It is, by definition, independent of any programing language, platform or software product.
The OData service is called via an URI, which encodes the requested service (server, service and entity), and additional selections in the parameters.
A simple OData URI looks like this:
Example URI to retrieve alle persons (you can test these using postman😞
Result (snippet):
Example URI to retrieve a specific person:
Result:
You can find more examples at "Understand OData in 6 steps · OData - the Best Way to REST" which uses the OData example service https://services.odata.org/.
Let’s look at the different parts of the URI in detail:
There are different versions of OData, the most common ones, currently used in the SAP-area are V2 and V4. To read more about the differences, see: "Is it time to switch to OData v4? | SAP Blogs" and "What's New With OData 4: OData 2 vs. OData 4 - DZone Big Data".
The specification of V2 and V4 can be found here:
V2: Overview (OData Version 2.0) · OData - the Best Way to REST
V4: Documentation · OData - the Best Way to REST
For more information on OData see the blog post from Anubhav Pandey – “OData – Everything that you need to know (Part 1)”. Part 1 to 3 discusses the general topics about HTTP, REST and OData. Parts 4 to 10 walks you through a creation of an OData service and the registration of the service (as seen here in this blog post in chapter “(1) Creating an OData service using “classical” ABAP”).
If you want to know about the history of OData see: Monday Morning thoughts odata by DJ Adams
OData can be used to access SAP backend-systems from various kinds of frontends. It became famous as the data source for SAP Fiori Elements and UI5, but is – by no means – limited to that. For examples see: https://blogs.sap.com/2018/04/10/sap-fiori-odata-service-examples/
https://blogs.sap.com/2018/08/13/beauty-of-odata/ gives a nice use case including Excel.
The following tables show some of the parameters and options when consuming an OData service. The URI has this structure:
URI:
Parameter, which can be added to the URI:
Query Options (part):
In general, there are three types of query options in OData: system query options (define the amount and order of data returned, eg. Select, filter,..), custom query options (extensibility mechanism, used eg. in sap-ds-debug flag) and parameter aliases (defines aliases for use in entity keys).
Using the system query options as parameter, you can reduce, filter, sort or page the resultset, coming back from the OData service. See the documentation for more details:
(1) OData Version 4.01. Part 2: URL Conventions (oasis-open.org)
Complete Example of an OData request URI:
The additional options like $filter, $expand, .. need to be implemented in the service.
There are different ways to create an OData service. Which one to use depends on the SAP release you are using. (1) will describe the classical ABAP way. However in S/4-systems there are more suitable ways to create an OData service based on CDS. Namely it’s the (2) ABAP programing model for FIORI and its successor the (3) use of CDS by RAP and CAP (see https://blogs.sap.com/2021/05/19/a-step-by-step-process-to-post-odata-services-in-sap-sap-hana-syste...). The blog post “OData service development options” gives an overview over all these available options and gives recommendations, when to use which. The suggestion there is stated: “Which option you can or should go for first of all depends on the underlying SAP Basis release of your SAP Business Suite or S/4 HANA system […], and which version of OData (V2, V4) you want to use or that you must use.” And “there is a clear recommendation for using CDS already in older releases.”
see: About ABAP Programming Model for SAP Fiori - SAP Help Portal
See: Compact Feature Availability Matrix of ABAP Programming Models: RAP vs. BOPF vs. Gateway | SAP Blogs
For details on the evolution of the programing models, see:
• https://www.youtube.com/watch?v=SkfXkamR5nY (SAP Community Call – Odata Service Development Options) and Presentation of the SAP Community call "OData service development options - Be prepared for the ABAP...
• Compact Feature Availability Matrix of ABAP Programming Models: RAP vs. BOPF vs. Gateway | SAP Blogs
• Evolution of the ABAP Programming Model | SAP Blogs
• OData service development options | SAP Blogs
The “SAP Gateway Service Builder” (transaction SEGW) can be used to create an OData service. It’s a half-graphical modeling tool – using a code-based approach to build the CRUDQ methods (Create, Read, Update, Delete). It generates two ABAP-classes (model provider MPC and data-provider DPC). Don’t change these classes manually, as they are overwritten on every re-generation of the service – you can add custom logic in extension-classes (*_DPC_EXT or *_MPC_EXT), where you redefine the CRUDQ-methods. See this blog for a quick overview of the tool: Exploring/Understanding Gateway Service Builder (SEGW) | SAP Blogs
The “ABAP Programming Model for SAP Fiori” has been introduced since NW 7.5. It’s based on Core Data Services (CDS) for the data model, BOPF for transactional processing and SAP Gateway (SEGW)/ OData for the service exposure: (see Source). See this blog post for a walk through and “getting started with the ABAP Programming Model for SAP Fiori”: Getting Started with the ABAP Programming Model for SAP Fiori | SAP Blogs
In short, the needed steps are as follows:
(1) Create a CDS view as Data Model in ADT
(2) Generate OData Service with auto-exposure based on SADL (Service Adaptation Description Language) by adding the annotation “@OData.publish:true” to the CDS.
(see here for different possibilities: Exposing CDS Entities as OData Service - SAP Help Portal). As a result “several SAP Gateway artifacts” are being created, which need to be activated in the SAP Gateway Hub for exposure (/n/IWFND/MAINT_SERVICE).
(3) Consume data (test using the SAP Gateway Client)
Screenshot taken, when following the tutorial: Implement the CDS View as Data Model - SAP Help Portal:
(1) CDS data model
(2) Auto-Exposure
Check in /IWFND/MAINT_SERVICE.
(3) Consume Data and add Quick Actions using BOPF
E.g. by creating a SAP Fiori Elements Application. See this blog for details:
How to develop a transactional app using the new ABAP Programming Model for SAP Fiori | SAP Blogs
Further Information:
About ABAP Programming Model for SAP Fiori - SAP Help Portal
Expose CDS Views as OData Service | SAP Blogs (Be careful, this is for systems <= NW 7.40. For >= NW 7.50 there is no need to use SEGW, but it is sufficient to use the CDS annotation @OData.publish: true).
Create Fiori app using CDS with BOPF- For beginners Part 1 | SAP Blogs
Be prepared for the ABAP Programming Model for SAP Fiori | SAP Blogs
Getting Started with the ABAP Programming Model for SAP Fiori | SAP Blogs
The “ABAP RESTful [Application] Programming Model” (RAP) is the successor of the “SAP FIORI Programming model”. Though it’s an evolution, it’s at the same time a paradigm shift in two ways: Firstly, the SAPGUI-transaction SGEW is no longer used – all the development is done in Eclipse. There is no need for the use of the BOPF-framework – instead it’s based on CDS and ABAP-based behavior definitions and implementations. (See https://blogs.sap.com/2019/10/25/getting-started-with-the-abap-restful-programming-model/).
See the official documentation for more information: According to that, RAP “supports the development of all types of Fiori applications as well as publishing Web APIs. It is based on technologies and frameworks such as Core Data Services (CDS) for defining semantically rich data models and a service model infrastructure for creating OData services with bindings to an OData protocol and ABAP-based application services for custom logic and SAPUI5-based user interfaces” (Quote: SAP Help Portal | ABAP RESTful Application Programming Model) - See also there for architectural overview.
If the OData service will be consumed by Fiori, so called annotations can be added, which are “additional metadata, which provide abstract definitions of data semantics” (ebd.) and are used to generate the Fiori-UI in a declarative way: You can use them to specify where a field should be shown and assign additional behavioral aspects (like, are CRUD operations allowed). These annotations can be defined locally through XML annotations or using ABAP CDS or CAP CDS in the backend (see RAP/CAP).
The steps are (use solely ADT to do so):
(1) Create the CDS Data Model (CDS interface-views and projection-views)
(2) Optional. Add a “metadata extension” (MDE) and add UI annotations
(3) Create the service definition and service binding to expose the OData-Service
(4) Add behavior definitions and implementations
(5) Optional. Add Actions, Determinations, Validations
For details see: Prepare the RAP-Based Travel Service | Tutorials for SAP Developers
And GitHub - SAP-samples/teched2020-DEV260: DEV260 - Build SAP Fiori Apps with the ABAP RESTful Applicat...
The created objects from DEV260 look like this in the ADT project explorer:
For the “SAP Cloud Application Programming Model” (CAP) the mission “Build Your First OData-Based Backend Service | Tutorials for SAP Developers“ gives a good impression how it will be implemented using BAS (Business Application Studio) on BTP.
For further information see:
Modernization with the ABAP RESTful Application Programming Model (RAP) | SAP Blogs
Getting Started with ABAP Core Data Services (CDS) | SAP Blogs
Spotlight on ABAP for SAP HANA – Again | SAP Blogs
InA (Information Access) is an analytical protocol to leverage the full analytical potential of the backend and the database. It’s used among others in SAC (SAP Analytic Cloud) tunnel-connections (see SAP Analytics Cloud Tunnel Connectivity and its use cases | SAP Blogs).
Quote from the help: “Generally speaking, Information Access (InA) is a definition for a JSON object model that reflects the analytic or planning request of the user. The query model for analytic requests consists of a description of the designated result set. It describes the data selection and calculations in a multidimensional way, which is usually in the form of a two-dimensional grid (i.e. a pivot table). The query model is not, however, restricted to the two-dimensional form; it can also have fewer or more than two axes.” (https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/LATEST/en-US/b927adfbde28407396312ecf41...)
While OData is the main connection in Fiori, the InA connection is used for Design Studio, SAC Online connection and BusinessObjects... (https://blogs.sap.com/2019/06/08/analytics-in-s4hana-real-shape-of-embedded-analytics-and-beyond-emb...)
OData provides a powerfull way to access data in a loosly coupled architecture. It’sagnostic toward programing language, platform or software product – but a perfect match with SAP.
Next steps for me: I’ll dig deeper into this in regard of CAP and OpenUI5.
Classical ABAP:
CDS:
See: CDS Views: Tools and Tables - SAP NetWeaver Business Warehouse - Community Wiki
Getting Started · OData - the Best Way to REST - Short introduction to OData
SAP Gateway | SAP Community - SAP Hompeage regarding OData
OData – Everything that you need to know (Part 1) | SAP Blogs
XOData - Visualize and Explore OData Services Online (pragmatiqa.com)
SAP Training GW100: SAP Gateway – Building OData Services
1) What is Odata?
2) How is this useful in SAP-systems?
3) Cheat-Sheet - using OData services
4) Implementing OData services
4.1) Classical ABAP
4.2) SAP Fiori programming model
4.3) RAP and CAP
5) OData vs. InA
6) Summary
7) Transactions & Resources
...but first of all, there is OData. So, what is OData?
What is OData?
“OData (Open Data Protocol) is an OASIS standard that defines the best practice for building and consuming RESTful APIs. (…) The OData metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client proxies and tools. Some of them can help you interact with OData even without knowing anything about the protocol.” (Source: Understand OData in 6 steps · OData - the Best Way to REST)
What this definition states, actually is: With OData you can request, exchange and modify data by using URIs via the HTTP protocol… Oh wait, but what’s with APIs, REST and SOAP? (See here for an comprehensive explanation of the differences: Difference between SOAP, REST, ODATA and HTTP protocols - ABusiness Tech and REST oder SOAP? (redhat.com)). Long story short: OData is an open standard, based on REST (Representational State Transfer) and therefore uses the CRUD operators as HTTP-requests (GET, POST, PUT, DELETE) to facilitate machine-to-machine communication. The payload is encoded using JSON or the Atom Syndication Format. This way loosely coupled client-server architectures are being made possible. It is, by definition, independent of any programing language, platform or software product.
The OData service is called via an URI, which encodes the requested service (server, service and entity), and additional selections in the parameters.
A simple OData URI looks like this:
http://<host>:<port>/<serviceRoot>/<ResourcePath>?<QueryOptions>;
Example URI to retrieve alle persons (you can test these using postman😞
https://services.odata.org/v4/TripPinServiceRW/People
Result (snippet):
Example URI to retrieve a specific person:
https://services.odata.org/v4/TripPinServiceRW/People?$filter=contains(FirstName, 'Ronald')
Result:
You can find more examples at "Understand OData in 6 steps · OData - the Best Way to REST" which uses the OData example service https://services.odata.org/.
Let’s look at the different parts of the URI in detail:
| Part | Description |
|---|---|
| <host> | The public endpoint URI for the OData service. For test purpose the public service of odata.org can be used: https://services.odata.org/ |
| <ServiceRoot> | The Service being used. Comparable to a database in SQL |
| <ResourcePath> | What data/entity should be retrieved. Eg. People. Comparable to a table in SQL |
| <QueryOptions> | See chapter “Cheat Sheet” for more details. Comparable to a selection in SQL. |
There are different versions of OData, the most common ones, currently used in the SAP-area are V2 and V4. To read more about the differences, see: "Is it time to switch to OData v4? | SAP Blogs" and "What's New With OData 4: OData 2 vs. OData 4 - DZone Big Data".
The specification of V2 and V4 can be found here:
V2: Overview (OData Version 2.0) · OData - the Best Way to REST
V4: Documentation · OData - the Best Way to REST
For more information on OData see the blog post from Anubhav Pandey – “OData – Everything that you need to know (Part 1)”. Part 1 to 3 discusses the general topics about HTTP, REST and OData. Parts 4 to 10 walks you through a creation of an OData service and the registration of the service (as seen here in this blog post in chapter “(1) Creating an OData service using “classical” ABAP”).
If you want to know about the history of OData see: Monday Morning thoughts odata by DJ Adams
How is this useful in SAP-Systems?
OData can be used to access SAP backend-systems from various kinds of frontends. It became famous as the data source for SAP Fiori Elements and UI5, but is – by no means – limited to that. For examples see: https://blogs.sap.com/2018/04/10/sap-fiori-odata-service-examples/
https://blogs.sap.com/2018/08/13/beauty-of-odata/ gives a nice use case including Excel.
Cheat-Sheet – Using OData services
The following tables show some of the parameters and options when consuming an OData service. The URI has this structure:
URI:
| URI | Result |
|---|---|
| http://<host>:<port>/<serviceRoot>/ | Odata-Service Root URL |
| <root-URL>/<ResourcePath> | Show specific entity-Set of the service |
Parameter, which can be added to the URI:
| Parameter ($/&) | Result |
|---|---|
| $sap-ds-debug=true | Render JSON-result as HTML |
| $format=json | Use JSON as export-result |
| $metadata | Show metadata (entity model) of ODATA service in the form of XML (CSDL: Conceptual Schema Definition Language) |
| $batch | Use OData-batching to make several operations atomic. |
Query Options (part):
| Parameter | Example | Result |
|---|---|---|
| $select | $select=col1,col2,col3 | Select specific columns |
| $filter | $filter=startswith(CompanyName,'Fruit') | Filter returned rows. See (1) for details if filter values. |
| $expand | $expand=BusinessPartner/Order | Show data for the referred entities as well (eg. all orders of the selected business partners). |
| $orderby | $orderby=Country/Name,City,Street | Return result in the specified order |
| $top | $top=5 | Only return a specific number (eg. 5) top results. |
| $skip | $skip=3 | Omit the first n (eg. 3) results. |
In general, there are three types of query options in OData: system query options (define the amount and order of data returned, eg. Select, filter,..), custom query options (extensibility mechanism, used eg. in sap-ds-debug flag) and parameter aliases (defines aliases for use in entity keys).
Using the system query options as parameter, you can reduce, filter, sort or page the resultset, coming back from the OData service. See the documentation for more details:
(1) OData Version 4.01. Part 2: URL Conventions (oasis-open.org)
Complete Example of an OData request URI:
http://host/service/Customers?$select=Addresses($filter=startswith(City,'H');$top=5;$orderby=Country...
The additional options like $filter, $expand, .. need to be implemented in the service.
Implement an OData service
There are different ways to create an OData service. Which one to use depends on the SAP release you are using. (1) will describe the classical ABAP way. However in S/4-systems there are more suitable ways to create an OData service based on CDS. Namely it’s the (2) ABAP programing model for FIORI and its successor the (3) use of CDS by RAP and CAP (see https://blogs.sap.com/2021/05/19/a-step-by-step-process-to-post-odata-services-in-sap-sap-hana-syste...). The blog post “OData service development options” gives an overview over all these available options and gives recommendations, when to use which. The suggestion there is stated: “Which option you can or should go for first of all depends on the underlying SAP Basis release of your SAP Business Suite or S/4 HANA system […], and which version of OData (V2, V4) you want to use or that you must use.” And “there is a clear recommendation for using CDS already in older releases.”
see: About ABAP Programming Model for SAP Fiori - SAP Help Portal
| Method | ABAP Platform | OData | Usage |
|---|---|---|---|
| (1) classic ABAP programming (SEGW) | <=7.4 | V2 (4?) | SEGW, ABAP (optional CDS as source) |
| (2) ABAP programming model for SAP Fiori | <= 7.5 (Draft capability >= 7.51) | V2 | CDS based BOPF (optional SEGW) |
| (3) ABAP RESTful Programming Model (RAP) | >= 7.54 (S/4HANA 1909); SAP BTP ABAP Environment (1808) | V2,V4 | CDS, Behavior Definition & Implementation |
| (3a) Cloud Application Programming Model (CAP) | SAP BTP, Cloud Foundry | V2,V4 | CDS, Behavior Definition & Implementation |
See: Compact Feature Availability Matrix of ABAP Programming Models: RAP vs. BOPF vs. Gateway | SAP Blogs
For details on the evolution of the programing models, see:
• https://www.youtube.com/watch?v=SkfXkamR5nY (SAP Community Call – Odata Service Development Options) and Presentation of the SAP Community call "OData service development options - Be prepared for the ABAP...
• Compact Feature Availability Matrix of ABAP Programming Models: RAP vs. BOPF vs. Gateway | SAP Blogs
• Evolution of the ABAP Programming Model | SAP Blogs
• OData service development options | SAP Blogs
Creating an OData service you can use: (1) “Classical” ABAP (needed for ABAP platform <= 7.4), which comes with significant higher efforts. (2) “SAP Fiori programing model” (ABAP platform = 7.5.4) or SAP BTP, Steampunk/RAP and CAP (SAP BTP) both using CDS views. (see openSAP Fiori-EA1, Week1, Unit 4).
(1) Creating an OData service using “classical” ABAP
The “SAP Gateway Service Builder” (transaction SEGW) can be used to create an OData service. It’s a half-graphical modeling tool – using a code-based approach to build the CRUDQ methods (Create, Read, Update, Delete). It generates two ABAP-classes (model provider MPC and data-provider DPC). Don’t change these classes manually, as they are overwritten on every re-generation of the service – you can add custom logic in extension-classes (*_DPC_EXT or *_MPC_EXT), where you redefine the CRUDQ-methods. See this blog for a quick overview of the tool: Exploring/Understanding Gateway Service Builder (SEGW) | SAP Blogs
After the service has been created, it needs to be registered and can be listed, using the transaction /n/IWFND/MAINT_SERVICE (note the /n/ in advance). To test the service use transaction /n/IWFND/GW_CLIENT) – it’s like a postman (Postman API Platform) inside your SAP-System 😉
This method for creating OData services had been available since ABAP platform <= 7.4, but will still continue to work in newer release like S/4. The used OData-Version is V2.
There are also some good blog posts providing a walkthrough in creating an OData service:
A Step by Step process to create Odata services in SAP / SAP HANA system | SAP Blogs
A Step by Step process to Post Odata services in SAP / SAP HANA system | SAP Blogs
https://blogs.sap.com/2020/11/24/introduction-to-odata-and-how-to-implement-them-in-abap/
A SAP Gateway Demo system (ES5) can be accessed via: (sapdevcenter.com). Be not too excited though, it’s only read access – to develop your own OData services you need to find another system of your own.. (see New SAP Gateway Demo System available | SAP Blogs).
SEGW:
/n/IWFND/MAINT_SERVICE
Program /IWFND/SUTIL_GW_CLIENT (through button “SAP Gateway Client”):
(2) Creating an OData service using SAP Fiori programming model
The “ABAP Programming Model for SAP Fiori” has been introduced since NW 7.5. It’s based on Core Data Services (CDS) for the data model, BOPF for transactional processing and SAP Gateway (SEGW)/ OData for the service exposure: (see Source). See this blog post for a walk through and “getting started with the ABAP Programming Model for SAP Fiori”: Getting Started with the ABAP Programming Model for SAP Fiori | SAP Blogs
In short, the needed steps are as follows:
(1) Create a CDS view as Data Model in ADT
(2) Generate OData Service with auto-exposure based on SADL (Service Adaptation Description Language) by adding the annotation “@OData.publish:true” to the CDS.
(see here for different possibilities: Exposing CDS Entities as OData Service - SAP Help Portal). As a result “several SAP Gateway artifacts” are being created, which need to be activated in the SAP Gateway Hub for exposure (/n/IWFND/MAINT_SERVICE).
(3) Consume data (test using the SAP Gateway Client)
“With the concept of auto-exposure, a new and simple way of creating OData services has been introduced. Here, the OData model definition as well as the OData service runtime is provided generically, based on SADL (Service Adaptation Description Language)” (quote from Generating OData Service With Auto-Exposure - SAP Help Portal). SAP recommends using the auto-expose feature for simple data models. (ebd.)
Screenshot taken, when following the tutorial: Implement the CDS View as Data Model - SAP Help Portal:
(1) CDS data model
Be careful. If you follow the tutorial, you need to be on an ABAP onPrem System. If you use an ABAP in the Cloud system, you need to stick to the reduced ABAP set, and eg. cannot access “SEPM_I_SalesOrderItem_E” directly.
(2) Auto-Exposure
Check in /IWFND/MAINT_SERVICE.
(3) Consume Data and add Quick Actions using BOPF
E.g. by creating a SAP Fiori Elements Application. See this blog for details:
How to develop a transactional app using the new ABAP Programming Model for SAP Fiori | SAP Blogs
Further Information:
About ABAP Programming Model for SAP Fiori - SAP Help Portal
Expose CDS Views as OData Service | SAP Blogs (Be careful, this is for systems <= NW 7.40. For >= NW 7.50 there is no need to use SEGW, but it is sufficient to use the CDS annotation @OData.publish: true).
Create Fiori app using CDS with BOPF- For beginners Part 1 | SAP Blogs
Be prepared for the ABAP Programming Model for SAP Fiori | SAP Blogs
Getting Started with the ABAP Programming Model for SAP Fiori | SAP Blogs
(3) Creating an OData service with RAP and CAP
The “ABAP RESTful [Application] Programming Model” (RAP) is the successor of the “SAP FIORI Programming model”. Though it’s an evolution, it’s at the same time a paradigm shift in two ways: Firstly, the SAPGUI-transaction SGEW is no longer used – all the development is done in Eclipse. There is no need for the use of the BOPF-framework – instead it’s based on CDS and ABAP-based behavior definitions and implementations. (See https://blogs.sap.com/2019/10/25/getting-started-with-the-abap-restful-programming-model/).
See the official documentation for more information: According to that, RAP “supports the development of all types of Fiori applications as well as publishing Web APIs. It is based on technologies and frameworks such as Core Data Services (CDS) for defining semantically rich data models and a service model infrastructure for creating OData services with bindings to an OData protocol and ABAP-based application services for custom logic and SAPUI5-based user interfaces” (Quote: SAP Help Portal | ABAP RESTful Application Programming Model) - See also there for architectural overview.
If the OData service will be consumed by Fiori, so called annotations can be added, which are “additional metadata, which provide abstract definitions of data semantics” (ebd.) and are used to generate the Fiori-UI in a declarative way: You can use them to specify where a field should be shown and assign additional behavioral aspects (like, are CRUD operations allowed). These annotations can be defined locally through XML annotations or using ABAP CDS or CAP CDS in the backend (see RAP/CAP).
The steps are (use solely ADT to do so):
(1) Create the CDS Data Model (CDS interface-views and projection-views)
(2) Optional. Add a “metadata extension” (MDE) and add UI annotations
(3) Create the service definition and service binding to expose the OData-Service
(4) Add behavior definitions and implementations
(5) Optional. Add Actions, Determinations, Validations
For details see: Prepare the RAP-Based Travel Service | Tutorials for SAP Developers
And GitHub - SAP-samples/teched2020-DEV260: DEV260 - Build SAP Fiori Apps with the ABAP RESTful Applicat...
The created objects from DEV260 look like this in the ADT project explorer:
For the “SAP Cloud Application Programming Model” (CAP) the mission “Build Your First OData-Based Backend Service | Tutorials for SAP Developers“ gives a good impression how it will be implemented using BAS (Business Application Studio) on BTP.
If you are struggling with all the abbreviations take a look at my older blog-post: BTP, SCP, CAP, RAP… OMG | SAP Blogs.
For further information see:
Modernization with the ABAP RESTful Application Programming Model (RAP) | SAP Blogs
Getting Started with ABAP Core Data Services (CDS) | SAP Blogs
Spotlight on ABAP for SAP HANA – Again | SAP Blogs
OData vs. InA
InA (Information Access) is an analytical protocol to leverage the full analytical potential of the backend and the database. It’s used among others in SAC (SAP Analytic Cloud) tunnel-connections (see SAP Analytics Cloud Tunnel Connectivity and its use cases | SAP Blogs).
Quote from the help: “Generally speaking, Information Access (InA) is a definition for a JSON object model that reflects the analytic or planning request of the user. The query model for analytic requests consists of a description of the designated result set. It describes the data selection and calculations in a multidimensional way, which is usually in the form of a two-dimensional grid (i.e. a pivot table). The query model is not, however, restricted to the two-dimensional form; it can also have fewer or more than two axes.” (https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/LATEST/en-US/b927adfbde28407396312ecf41...)
While OData is the main connection in Fiori, the InA connection is used for Design Studio, SAC Online connection and BusinessObjects... (https://blogs.sap.com/2019/06/08/analytics-in-s4hana-real-shape-of-embedded-analytics-and-beyond-emb...)
Summary
OData provides a powerfull way to access data in a loosly coupled architecture. It’sagnostic toward programing language, platform or software product – but a perfect match with SAP.
Next steps for me: I’ll dig deeper into this in regard of CAP and OpenUI5.
Transactions
Classical ABAP:
| Transaction | Function |
|---|---|
| SEGW | SAP Gateway Service Builder |
| /IWFND/MAINT_SERVICE | Register and list services |
| /IWFND/GW_CLIENT | Test OData URIs |
| /IWFND/TRACES | Trace a service |
| /IWFND/ERROR_LOG | Show service error logs |
CDS:
| Transaction | Function |
|---|---|
| SDDLAR | CDS repair and analytics |
| SACM | Access Control Management |
| RSRTS_QUERY_CHECK | Test for CDS-based queries |
See: CDS Views: Tools and Tables - SAP NetWeaver Business Warehouse - Community Wiki
Resources
Getting Started · OData - the Best Way to REST - Short introduction to OData
SAP Gateway | SAP Community - SAP Hompeage regarding OData
OData – Everything that you need to know (Part 1) | SAP Blogs
XOData - Visualize and Explore OData Services Online (pragmatiqa.com)
SAP Training GW100: SAP Gateway – Building OData Services
- SAP Managed Tags:
12 Comments
