Show TOC

Metadata DefinitionLocate this document in the navigation structure

A model provider class (MPC) defines the object model and the annotations of your service. It must inherit from /IWBEP/CL_V4_ABS_MODEL_PROV.

This class implements interface /IWBEP/IF_V4_MODEL_PROVIDER which contains the following interfaces:
  • IWBEP/IF_V4_MP_BASIC

    This interface contains method DEFINE that is used to create a service model and the corresponding annotation model.

    /IWBEP/CL_V4_ABS_MODEL_PROV always throws a “Not implemented” exception to indicate that DEFINE needs to be implemented in the sub-classes.

  • IWBEP/IF_V4_MP_ADVANCED

    This interface contains method GET_LAST_MODIFIED that returns a timestamp for cache-handling and methods to provide language dependent annotation texts.

    Method GET_LAST_MODIFIED is implemented in /IWBEP/CL_V4_ABS_MODEL_PROV and only needs to be redefined if your model depends on information that is not reflected in the model provider class. The default implementation of this method derives the last modified timestamp based on the changed timestamp of the model provider class (MPC) itself.

Model Finalization
Once method /IWBEP/IF_V4_MP_BASIC~DEFINE has been processed, the framework executes a model finalization to do the following:
  • Set default values for attributes of metadata artefacts that have not been set.

  • Complete information on references between metadata artefacts.

  • Derive framework-internal information for efficient access to metadata during runtime.

  • Set the model to ‘read-only’.

The last step ensures that metadata artefacts can only be changed during processing of the model provider.

Access to metadata artefacts through interfaces /IWBEP/IF_V4_MED_<MetadataArtefactType> is forbidden outside the model provider class. Instead, you need to use the read-access interfaces /IWBEP/IF_V4_MED_<MetadataArtefactType>_R. They provide GET-methods only.

The service model needs to be consistent. The framework makes the following provisions to ensure consistency:

  • Attributes of metadata artefacts are set through specific methods. They default or reset other attributes if required. They also implement early checks that lead to immediate exceptions in case of failure. For example, a CREATE method throws an exception if the given name does not comply with the naming conventions or has already been used.

  • During finalization, model issues are detected if defaulting or derivation algorithms fail.
  • After finalization, the framework executes a comprehensive model validation.
Comments

All model artefacts - like, for example, an entity type or a property - are identified by their internal names only. The EDM (external) names can only be set as attributes.

Artefacts are created with an internal name that needs to comply with the ABAP naming conventions. Internal names starting with SAP_ are reserved names and must not be used. The corresponding name exposed in the service metadata document is defaulted from this internal name or may explicitly be specified using method SET_EDM_NAME. Both names may always be retrieved using /IWBEP/IF_V4_MED_ELEMENT~GET_INTERNAL_NAME or /IWBEP/IF_V4_MED_ELEMENT~GET_EDM_NAME.

Predefined types (also known as EDM types like Edm.String, Edm.Int32, and so on) are not represented as objects during model creation. The interfaces for metadata artefacts that can be typed with primitive types carry methods SET_<EdmType>. They are mutually exclusive. The last method call wins.

Entity types or complex types can be created with or without reference to an ABAP structure. If created with reference to a structure it is either possible to let the framework create a property for each field in the structure automatically, or the properties may be created individually. In the latter case, the internal name of the property needs to fit to the field name in the structure. ABAP type information is derived automatically and EDM type information is being defaulted. If an entity type or complex type is created without reference to a structure then the properties need to be added individually. Again, it is possible to create a property with reference to an ABAP type that provides the necessary type information. If a “plain” property is created the EDM type must be set using a SET_<EdmType> method.

Primitive properties with an ABAP Dictionary reference are optionally enriched with additional information by the framework.
  • Some annotations like labels can be derived from the data element texts.

  • Value helps can be derived from the fixed values of a domain, for example.
  • Conversion can be derived from the conversion routine of a domain, for example.

Certain specializations are not modeled as specific metadata artefact types but are represented by attributes of a metadata artefact. For example, actions or functions become bound actions or bound functions if a binding parameter is defined for them.