What does it do? The statement DEFINE SERVICE> implements a CDS service definition> with the name service> in CDS SDL>. The name service> is in the same namespace as the CDS entities> defined with CDS DDL> and must satisfy the appropriate naming conventions. The service definition exposes the CDS entities cds_entity1>, cds_entity2>, ... for a business service>. Each CDS entity is exposed using its own statement EXPOSE> within the curly brackets. Each statement must be closed by a semicolon ;>. At least one CDS entity must be exposed. The following CDS entities can be specified:
CDS views>
CDS abstract entities>
CDS custom entities> For each CDS entity, the addition AS> can be used to specify an optional alias name alias1>, alias2>, ... The CDS entity is exposed under this alias name and it must be used when the business service is accessed. In syntax checks and when the service definition is activated, the relationship between the exposed CDS entities is not verified. The optional annotations @service_annot1>>, @service_annot2>>, ... can be specified in front of the statement DEFINE SERVICE>. The optional addition PROVIDER CONTRACTS>> can be used to define a provider contract contract > for the service definition in question. A provider contract defines the scenario for which the service definition in question is intended. It is a prerequisite for releasing the service definition in question under the C0 release contract for extensibility. For further details, see topic TITLE >.
Latest notes:
If a service definition exposes multiple CDS entities, these entities should be related semantically. For example, if a CDS view with CDS associations is exposed in a service definition, it is recommended that the association targets of each CDS association are exposed as well. Together with the root entity > of a RAP business object> all other CDS entities of the composition tree> should also be exposed.
If a service definition is used in a business service, it must be linked with a RESTful> protocol using a service binding>. The service definition itself, however, is independent of the protocol in question and can be used with different protocols in multiple service bindings.
Further restrictions apply to the CDS entities in question when using a service definition in a service binding. For example, the definition must have at least one key field or the cardinalities of the CDS associations must be defined correctly.
No service bindings can be defined for service definitions that expose CDS abstract entities. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 The following service definition exposes CDS views that are related to each other under their own names by CDS associations. SRVD DEMO_SD_ASSOC_SCARR_SPFLI ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 The following service definition exposes a CDS view under an alias name. SRVD DEMO_SD_CROSS_JOIN ABAP_EXAMPLE_END
ABAP_EXAMPLE_ABEXA See Consuming Business Services>. ABAP_EXAMPLE_END