APIs, APIs, APIs: when building an extension for a product like S/4HANA, in the end it is all about APIs and about extensions point, meaning points where you can hook into existing applications and processes.
In my previous blogs, I wrote about the tools that you can use for extending S/4HANA (see, for example https://blogs.sap.com/2015/09/30/the-key-user-extensibility-tools-of-s4-hana/). In this blog, I want to guide you through the tools where you can find the related APIs and extension points.
External (Web Service) APIs
External APIs (Web Service) are listed on the SAP API Hub. You can find them under https://api.sap.com/ -> API Packages -> SAP S/4HANA Cloud and SAP Hybris Marketing Cloud. These APIs can be used for integration and side-by-side extensibility for example on SAP Cloud Platform. For additional information, read also my blog on https://blogs.sap.com/2016/10/19/s4hana-extensibility-connect-sap-s4hana-cloud-sap-hana-cloud-platform-hcp/.
You can see here the screenshot with the list of S/4HANA APIs (more than 170 at the time of revisiting the API hub in May 2018, and but I expect that this number still increasing)
Let me add some information about the differences between On-premise and Cloud:
In SAP S/4HANA Cloud, each API comes with a communication scenario (typically with a technical name SAP_COM_xxxx) that is indicated in the detailed screen of an API together with the documentation. You can use the the name of the communication scenario to activate the service as described in my blog https://blogs.sap.com/2016/10/19/s4hana-extensibility-connect-sap-s4hana-cloud-sap-hana-cloud-platform-hcp/. Together with the communication scenario, SAP deliveres a user role and additional configuration content that is applied when creating the communication arrangement.
In SAP S/4HANA (on-premise) you have to do some configuration steps. If the API is of type OData, go to the OData Gateway, call transaction /IWFND/MAINT_SERVICE, click Add, select a backend system. If the service is available in the backend system, you can configure it. Then you have to define a role and a technical user to be able the call it. (This is what is automated by the comm scenario in S/4 HANA Cloud). For details, please refer to the Gateway documentation. If the API is a SOAP API, then you have to do the “usual” steps to configure a SOAP API.
In general, APIs that are available in S/4HANA Cloud are also in the on-premise version in a “Cloud first” way: this means SAP is shipping quartely Cloud releases and the on-premise version that is shipped once a year will contain the APIs of the previous Cloud versions.
CDS/VDM Views are the S/4HANA read APIs for in-app extensibility. You can use them
- to build new analytical apps (so-called cubes and queries, and on top of them analytical reports and KPIs)
- in custom code extensions (“BAdIs”)
- to build your own custom CDS views and expose these views as OData service as external API.
You can see all released CDS Views in the following tools:
- View Browser Fiori app
- Custom CDS Views Fiori app (released CDS views except analytical queries)
- Custom Analytical Queries Fiori app (released CDS views of type analytical query)
- ABAP Development Tools for Eclipse: “Released Objects” Repository tree
The first three tools are available in Cloud and on-premise, the Eclipse tool is available in on-premise only.
The following screenshot shows the View Browser (contained in the Fiori catalog SAP_CA_BC_ANA_AQD_PC in SAP S/4HANA Cloud).
You can open the details screen a CDS view and inspect the view properties. In the Fiori app Custom CDS Views and Custom Analytical Queries, you can also do a data preview in this app.
The following screenshot shows the “Released Objects” Repository tree in ADT:
You can configure the tree in Eclipse with: New Repository Tree -> Released Objects
When updating this blog, there were >1300 released CDS views available.
You can find also documentation on CDS/VDM Views in the S/4HANA product assistance (https://help.sap.com -> SAP S/4HANA Cloud) -> Product Assistance -> Generic Information -> Analytics -> CDS Views).
You can also find information on released CDS view on SAP API Business Hub, Content Types, CDS Views.
What is CDS and VDM? In short, we can say that CDS is a technology, while VDM stands for the semantical model.
CDS (Core Data Services) is a key component of the SAP technology for levering qualities such as:
- Capture and share business-rich data models using the SAP HANA relational model
- Enrich the data models with specific semantics e.g. for UI, draft, analytics, search, actions and events. It’s also enabling the S/4HANA APIs
- Leverage SAP HANA optimally in most relevant scenarios
- Enable and standardize esp. zero downtime, verticalization, extensibility, access control (based on ABAP authority objects)
- Integration into ABAP programming model and improve development productivity
- Exposure of CDS models and data to SAP Cloud Platform, e.g. for Business Objects Cloud and extension apps
SAP Virtual Data Model (VDM) represents the simplified and harmonized business oriented semantically enriched data model. “Virtual” refers to the fact that the VDM semantical model may deviate from the historically grown persistent model of database tables to make it simpler and easier to understand. In SAP S/4HANA, the VDM is established by specifically classified/annotated CDS Views.
This is a short impression, the complete CDS/VDM story is a subject for a subsequent blog.
Analytical Queries are the base objects for analytical UIs (KPIs and Reports). Technically they are also CDS/VDM View, but with a very specific semantics. You can see all released SAP Analytical Queries in the overview page of the Custom Analytical Queries app.
Business Contexts for Custom Fields and Logic
Business Contexts are SAP entities that can be extended by custom fields and/or custom logic. Typically, business contexts represent “business document tables” or “business object nodes”, Examples for extensible business contexts are: Billing Document, Billing Document Item, Billing Due List Item.
You can find the list of extensible business context in the Extensibility Cockpit Fiori app (in Fiori catalog SAP_CA_BC_EXT_COCKPIT_PC) with this app, you can explore all business contexts that are enabled for field extensibility and the related data sources, services, enhancement options, etc. Or you can find them in the Custom Fields and Logic Fiori app.
The following screenshot shows the Extensibility Cockpit Fiori app:
When revisiting the app during my lat update of this blog, I was seeing >180 business contexts enabled for custom field and/or logic enhancement.
You can also start your investigation by Fiori app: In the Fiori Appl Library ( Fiori Apps Library ) you can find the information on the extensibility for Fiori apps. Open the App Details for a Fiori app, and go to section Implementation Information, Extensibility.
For example select SAP Fiori Apps for SAP S/4HANA, All Apps, find “Manage Purchase Orders”, go to section Implementation Information, Extensibility. Here you can find the technical information in the UI (“BSP containing SAPUI5 application”) and the link to the extensibility documentation. In the extensibility documentation you can find the business contexts, that belong to the Fiori app and additional information, such as information on BAdIs (but not necessarily the complete list of all BAdIs, which is available in the Extensibility Cockpit).
Class API can be used in custom logic as re-use methods. When writing this blog, there is no browser for class APIs available. You must go into the coding and use the code completion (cntrl + blank) to see the available class API together with its signature.
In total, there are >80 class APIs available at the time of updating this blog.
SAP has defined the API hub as the central place for publishing all external APIs. The publishig of APIs for S/4HANA has started, I exect more an more APIs appearing here.
For in-app extensibility, internal APIs (CDS views and classes) and extension points are used. A central tool for discovery is still missing, so for the time being you must use different tools when searching for APIs and extension points. This should be fixed by a central tool in the future. I will be happy to report on the discovery tool in a future blog once this is available.