In this blog post I will share my personal view on the importance of OData within the SAP ecosystem, how it enables us to easily integrate and extend our systems/applications and how you can produce and consume OData services.
From the OData.org website, OData (Open Data Protocol) is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs. There are numerous explanations in SAP Commmunity on what OData is, so I will not repeat here what others have explained so well before.
As mentioned in the OData website... OData allows the creation and consumption of queryable and interoperable APIs in a simple and standard way. Its metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client applications and tools. Multiple SAP applications/services have OData APIs and it has become the preferred protocol to expose data that lives within SAP applications and make it available for other to use. Personally, I see OData as a “connecting point” that facilitates interoperability between SAP and non-SAP applications.
What I like the most about developing OData services is that they can be consumed by many different application types. It is possible to develop a mobile app, a web app, create a report or use it for integration purposes and all of these use cases communicating with a single OData service.
So, how can you create OData services using SAP technologies/tools and non-SAP tools?
Now that you know how you can create OData services, lets see some how you can consume these services.
As mentioned previously, OData has become the preferred protocol to expose data that lives within SAP applications. As you can imagine, there are various tools that "understand" OData (by consuming the service metadata) and simplify developing our extensions/integrations.
Where can you find more about OData?
As you can see, OData is widely used by different SAP products. There are multiple way of producing OData services, lots of SAP applications/services expose OData APIs and also multiple avenues to consume these APIs. I hope this blog post gives you an idea of why OData is important in the SAP ecosystem and the value and flexibility it provides when integrating/extending your SAP applications.
From the OData.org website, OData (Open Data Protocol) is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs. There are numerous explanations in SAP Commmunity on what OData is, so I will not repeat here what others have explained so well before.
OData diagram
If you want to learn a bit about the history and origins of OData, I recommend you reading - Monday morning thoughts: OData blog post by dj.adams.sap
As mentioned in the OData website... OData allows the creation and consumption of queryable and interoperable APIs in a simple and standard way. Its metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client applications and tools. Multiple SAP applications/services have OData APIs and it has become the preferred protocol to expose data that lives within SAP applications and make it available for other to use. Personally, I see OData as a “connecting point” that facilitates interoperability between SAP and non-SAP applications.
What I like the most about developing OData services is that they can be consumed by many different application types. It is possible to develop a mobile app, a web app, create a report or use it for integration purposes and all of these use cases communicating with a single OData service.
I highly recommend watching the Back to basics: OData series by dj.adams.sap if you want to understand in detail what OData is.
Producing OData services
So, how can you create OData services using SAP technologies/tools and non-SAP tools?
- SAP Gateway: Exposes data from SAP backend systems in the form of OData services, which can be consumed by mobile/web applications to extend system functionality.
- Cloud Application Programming (CAP) Model: Services created using the Cloud Application Programming model are OData services. Which means that you can easily create RESTful, queryable APIs by following CAP. Also, OData annotations can be specified in Core Data Services (CDS) models which allows us to specify UI labels/properties that can used by service consumers. See CAP OData documentation.
- SAP Cloud Integration: You can develop OData APIs that expose existing data sources, such as SOAP, as OData endpoints. These OData APIs can be consumed by SAP Fiori apps, SAP BTP Mobile Services, or any other custom app, to implement user-centric scenarios. See Developing an OData API project.
- SAP API Management: An API proxy can be created in API Management to expose OData services. This is an interesting approach if you want to expose internal OData services to the outside world by using SAP Cloud Connector. See API Proxy.
- Not SAP only: Remember that OData is an open standard specification, it is not SAP-specific. You can also create/consume OData services using open source libraries. See the different OData libraries available if you want to learn how to create OData services in your favourite programming language, e.g. Python, .Net, Swift.
Now that you know how you can create OData services, lets see some how you can consume these services.
Consuming OData services
As mentioned previously, OData has become the preferred protocol to expose data that lives within SAP applications. As you can imagine, there are various tools that "understand" OData (by consuming the service metadata) and simplify developing our extensions/integrations.
- Fiori Elements: We can use SAP Fiori elements to create SAP Fiori applications based on OData services and annotations. See How to use SAP Fiori Elements and SAP Fiori Elements now supports OData v4.
- SAP Mobile services and mobile products: OData services deliver quality data so they can be consumed by mobile applications directly. Applications developed with SAP AppGyver, SAP Mobile services, the SAP BTP SDK for iOS, SAP BTP SDK for Android can consume OData services. See Mobile Services.
- SAP Analytics Cloud: You can define OData Services based on SAP S/4HANA, SAP BW systems, SAP HANA systems, and SAP Business Planning and Consolidation (BPC) systems to execute actions on the services. Also consume OData services for reporting purposes. See SAP Analytics Cloud - Using OData and Import Data connection to OData Service.
- Non-SAP: In the end, an OData service is a RESTful service, meaning that it can be consumed by any application/programming language that is able to communicate via HTTP. For example, you can develop a Python/Go/Rust app/service that communicates with an OData service.
More OData....
Where can you find more about OData?
- If you want to learn more on how to produce and consume OData services, I recommend having a look at the different tutorials available at https://developers.sap.com.
- In the SAP API Business Hub you can find the different SAP products that expose OData APIs, e.g. SAP S/4HANA, SAP SuccessFactors, SAP Fieldglass and more.
- SAP Graph aims to simplify how developers interact with SAP data. This will be achieved by providing a unified API consolidating the data models of data sources like SAP S/4HANA, SAP Sales Cloud and SAP SuccessFactors into one. Guess what standard it follows.... yes, OData. See SAP Graph documentation.
As you can see, OData is widely used by different SAP products. There are multiple way of producing OData services, lots of SAP applications/services expose OData APIs and also multiple avenues to consume these APIs. I hope this blog post gives you an idea of why OData is important in the SAP ecosystem and the value and flexibility it provides when integrating/extending your SAP applications.
- SAP Managed Tags:
9 Comments
