Get Example source ABAP code based on a different SAP table
Service Bindings A service binding is a repository object defined in a form-based tool in ABAP Development Tool (ADT) that binds a CDS service definition with a RESTful protocol and provides it as a business service to be used outside of AS ABAP. The following service binding types are currently available:
Different variants of OData can be used as the RESTful protocol:
OData in versions 2 and 4
OData for UIs or Web APIs
OData for UIs is designed for access to business services using UI technologies like SAPUI5. The data provided by a business service contains control elements for user interfaces. These elements are themselves defined by framework-specific annotations in the CDS entities in question.
OData for Web APIs is limited to the data-only content of the business services and does not contain any control elements for user interfaces.
The Information Access (InA) protocol can be used for analytical queries .
ABAP SQL Services When a service binding is activated, it makes the business service accessible in accordance with the protocol used. This involves technologies such as SAP Gateway and the RAP query engine. BEGIN_SECTION VERSION 5 OUT To provide access to the OData-based data outside AS ABAP, ICF services are created. They are visible in transaction SICF.
The ICF node of a service binding is /sap/opu/odata/sap/SB_NAME, where SB_NAME is the name of the service binding in uppercase letters.
A client can access the ICF node and use it for reads in accordance with the OData protocol, for example as follows:
Access to the metadata of the OData service
.../sap/opu/odata/sap/SB_NAME/$metadata
Access to the data of a CDS entity cds_entity exposed in the service definition:
.../sap/opu/odata/sap/SB_NAME/cds_entity
Passing formal parameters to CDS entities with input parameters
If the service binding for the root entity of a RAP business object is defined by the RAP behavior definition and behavior pools, transactional HTTP POST requests can be used to access the ICF node. The internal frameworks are responsible for calling the methods of the handler classes in the behavior pools in the correct order. END_SECTION VERSION 5 OUT When a service binding is activated, the service definition used is checked to verify whether it meets the requirements of the internal underlying framework. The following restrictions currently apply:
The CDS entities of the service definition must have at least one key field.
The cardinality of CDS associations must be defined correctly.
No service binding can be defined for service definitions that expose CDS abstract entities.
The input parameters of the CDS entities must be typed with reference to simple types or data elements. A direct typing with built-in dictionary types is not allowed.
Depending on the OData version, not all data types are supported for the elements of the CDS entities.
The names of actions defined in RAP BDL cannot produce naming conflicts and cannot exceed a certain length, as specified by the OData version.
The parameter structure of actions defined in CDS BDL cannot overlap with the key fields of the CDS entity.
A service binding must match the provider contract of the service definition, if a provider contract is defined.
Latest notes:
Once a service binding is activated, the form-based tool of ABAP Development Tool (ADT) shows the associated URL and enables comprehensive testing of the service.
SAP Gateway offers OData client proxies in order to access OData data of an AS ABAP. These are of special use for OData data of business services. BEGIN_SECTION SAP_INTERNAL_HINT The TADIR key for a service binding is <(>R3TR SRVB<)>. END_SECTION SAP_INTERNAL_HINT NON_V5_HINTS
The default HTTP request handler of an ICF service created when a service binding is activated is the class /IWFND/CL_SODATA_HTTP_HNDL_OAT in SAP Gateway. ABAP_HINT_END
ABAP_EXAMPLES_ABEXA See Consuming Business Services. ABAP_EXAMPLE_END
