This interface is the entry point for every OData Channel model definition to define the required OData artifacts.
The data provider may set an age in the data provider methods for GET_ENTITY_TYPE / GET_ENTITY_SET which is translated into an HTTP response header without further calculation.
Method CREATE_ACTION
This method adds an action, service operation, or function import to the OData model.
Parameter |
Description |
---|---|
IV_ACTION_NAME |
Value |
RO_ACTION |
Instance |
Parameter | Description |
---|---|
IV_ACTION_NAME | Importing the external name of the action as it will be available in the service document |
RO_ACTION | Returns the created action |
For more information, see Service Tagging.
Method GET_ACTION
This method retrieves an action from a OData model by name.
Parameter |
Description |
---|---|
IV_ACTION_NAME |
Value |
RO_ACTION |
Instance |
Method GET_COMPLEX_TYPE
This method gets a complex type by name.
Parameter |
Description |
---|---|
IV_CPLX_TYPE_NAME |
Value |
RO_COMPLEX_TYPE |
Instance |
Method CREATE_COMPLEX_TYPE
This method adds a complex type to the OData model.
Parameter |
Description |
---|---|
IV_CPLX_TYPE_NAME |
Value |
RO_COMPLEX_TYPE |
Instance |
Method CREATE_ENTITY_TYPE
This method adds an EntityType to the OData model.
Parameter |
Description |
---|---|
IV_ENTITY_TYPE_NAME |
Value |
RO_ENTITY |
Instance |
Method GET_ENTITY_TYPE
This method gets an EntityType by name.
Parameter |
Description |
---|---|
IV_ENTITY_TYPE_NAME |
Value |
RO_ENTITY |
Instance |
Method CREATE_ASSOCIATION
This method adds an association to the data model which links to EntityTypes.
Parameter |
Description |
---|---|
IV_ASSOCIATION_NAME |
Value |
IV_LEFT_TYPE |
Name of the left EntityType. |
IV_RIGHT_TYPE |
Name of the right EntityType. |
IV_LEFT_CARD |
Association cardinality of the left EntityType. |
IV_RIGHT_CARD |
Association cardinality of the right EntityType. |
RO_ASSOCIATION |
Instance |
Method GET_ASSOCIATION
This method gets an association of the data model.
Parameter |
Description |
---|---|
IV_ASSOCIATION_NAME |
Value |
RO_ASSOCIATION |
Instance |
Method SET_NO_CONVERSION
This method controls whether any conversion should be called for runtime representations of this data model.
Parameter |
Description |
---|---|
IV_NO_CONVERSION |
Flag to decide whether any conversion should be called during runtime. |
Method GET_NO_CONVERSION
This method indicates whether conversions are called or not, during runtime.
Parameter |
Description |
---|---|
RV_NO_CONVERSION |
Value |
Method INCLUDE_MODEL_BY_NAME
The service of the external data model must be registered on the SAP Gateway hub system and be up and running.
The ID of the service and the name of the data model have to be provided to the method. This information is stored on the SAP Gateway hub and is resolved during runtime to create, for example, the metadata document and the business data for the routing. This means that for entities of the external data model, the system alias assigned to the service of the external data model is used instead of the system alias assigned to the original service including that data model.
During activation, the service maintenance function uses the provided service IDs and data model names to find a corresponding service. Therefore the included services have to be activated first, as otherwise the activation of the composition service will lead to an incomplete composition service or even an error.
It is possible to define associations to the entities of the included data model, although they do not exist at this time. 1:1 and 1:n relations can be defined pointing from the new data model to the included external data model.
When defining the association, you define the left side of it (from the current data model existing in IW_BEP) with the standard method /IWBEP/IF_MGW_ODATA_MODEL~CREATE_ASSOCIATION.
It is necessary to define referential constraints for these associations as they are resolved generically during runtime by the framework on the SAP Gateway hub system.
During the runtime based on these referential constraints a request like Flight(ID=100)/BookingsListedInHana might be converted either into a request BookingsListedInHana(ID=100) or BookingsListedInHana?$filter=ID eq ‘100’ depending on the referential constraints. If the keys of the target entity fit either to the key of the source entity or are mapped appropriately in the referential constraints then the key notation is used, otherwise the filter is filled. The resolution behaviour can be overruled by your own BAdI implementation (see below).
It is currently not possible to define navigation properties for entities of included data models.
Enhancement Spot /IWFND/ES_MGW_MDL_COMPOSITION can be used to overwrite the link resolution behavior.
You can find an example in method DEFINE of class /IWBEP/CL_MGW_MED_EXT_COMP_MDL.
Parameter |
Description |
---|---|
IV_TECH_MODEL_NAME |
Technical name of model. |
IV_MODEL_VERSION |
Technical version of model. |
IV_EXT_SERVICE_NAME (Optional) |
External name of the service as specified in the BEP registration (optional). |
IV_SERVICE_VERSION (Optional) |
Technical version of the service (optional). |
Details
For every association, an association set is required. The creation of the association set is done automatically when calling method /IWBEP/IF_MGW_ODATA_MODEL->CREATE_ASSOCIATION.
In case of model composition, the creation of the association set is not automatically. Instead, do the following:
Deactivate the defaulting by setting the import parameter IV_DEF_ASSOC_SET to FALSE in method /IWBEP/IF_MGW_ODATA_MODEL->CREATE_ASSOCIATION.
Create the corresponding association set explicitly by calling /IWBEP/IF_MGW_ODATA_MODEL->CREATE_ASSOCIATION_SET
The model include is done dynamically. It does not need a registration of the depending service or model during the registration of the hosting service. Changes are directly reflected after the metadata cache is invalidated.
Method EXTEND_MODEL
This method extends an ODC model using the model name / model version (model ID). This method overwrites all existing defined metadata by the metadata of the extended model. So use this method only once and as the first statement:
This method overwrites all existing defined metadata by the metadata of the extended model. So use it as the first statement and only once in the model definition. Multiple extensions are not supported. Extend_Model only supports the metadata extension of a model, and has no impact on the run time behavior.
In the model definition, multiple extensions are not supported. The Extend_Model method only supports the metadata extension of a model and has no impact on the runtime behavior.
Parameter |
Description |
---|---|
IV_TECH_MODEL_NAME |
Technical name of model |
IV_MODEL_VERSION |
Technical version of model |
Note that the default is the previous EDM mapping.
This method should be placed in the coding at the beginning of the DEFINE method of your model provider class (MPC) to make sure that the model features will be valid for all model artifacts.
Cache Handshake for Business Requests
By setting this model feature the cache handshake for OData business requests will be activated for the service. With OData business requests all read/create/update/delete requests are meant, but not $metadata or service document requests. The cache handshake for business requests makes sure that an exception will be raised and the response will have the HTTP status code 503 (service unavailable) in case an OData business request was executed and the metadata cache on your hub system was outdated. After this error had occurred, the metadata cache on your hub system should be cleaned-up automatically by the system. The next OData business request of this service should work. Therefore, simply execute the OData business request again that has led to this error (or in fact any other OData business request of this service). If the automatic cache clean-up did not work, you need to clean up the metadata cache manually on your hub system for the current model.
EDM Mapping in Support Package 10
Use EDM mapping from support package 10 and note that the default mode is the previous EDM mapping.
Use Long Label for Property
Labels for properties based on ABAP Dictionary elements will be taken as default from the long description if the long text does not exceed 20 characters.
METHOD define. DATA ls_model_features TYPE /iwbep/if_mgw_appl_types=>ty_s_model_features. super->define( ). ls_model_features-use_cache_handshake_busi_req = abap_true. model->set_model_features( ls_model_features ). ENDMETHOD.
The application can use this method to set the SAP schema version, for example <Schema Namespace="com.sap.TEA.TestApplication" xml:lang="en" sap:schema-version="0001" xmlns="http://schemas.microsoft.com/ado/2008/09/edm">.
Parameter | Description |
---|---|
IV_SERVICE_SCHEMA_VERSION | Schema version |
Parameter | Description |
---|---|
IV_NAMESPACE | Namespace |
The schema namespace appears in the metadata document as follows:
<Schema Namespace="Tea_test_application_NS" xml:lang="en"..
<Property Name="Location" Type="Tea_test_application_NS.CT_Location" Nullable="false" />
<NavigationProperty Name="My_Team" Relationship="Tea_test_application_NS.Team_of_Employee" FromRole="FromRole_Team_of_Employee" ToRole="ToRole_Team_of_Employee" />
<Association Name="Team_of_Employee" sap:content-version="1> <End Type="Tea_test_application_NS.Worker" Multiplicity="*" Role="FromRole_Team_of_Employee" /> <End Type="Tea_test_application_NS.Team" Multiplicity="1" Role="ToRole_Team_of_Employee" />
<EntityContainer Name="Tea_test_application_NS_Entities" m:IsDefaultEntityContainer="true">
<ComplexType Name="CT_Location"> <Property Name="Country" Type="Edm.String" MaxLength="255" sap:text="Country" /> <Property Name="City" Type="Tea_test_application_NS.CT_City" Nullable="false" /> <Property Name="Complex_type_City" Type="Tea_test_application_NS.CT_City" Nullable="false" /> </ComplexType>
This method Includes a model from another OData Channel Service exposed on the SAP Gateway system, that is backend models. The API can be used to compose Object Models from different services, that is to include an external model. For example, the composition is defined in the backend system system, but resolved on the SAP Gateway system.
To attain this, the following conditions should be met:
The service of the external model must exist on the SAP Gateway system and be up and running.
The ID of the service and the name of the model have to be provided to the method. This information is stored on the SAP Gateway and resolved during runtime to create the metadata document and for the business data for the routing. This means that for entities of the external model the system alias assigned to the service of the external model is used instead of the system alias assigned to the original service including that model.
During activation the Registration Report uses the provided service IDs and model names to find a corresponding service. Therefore the included services should be activated first, otherwise the activation of the composition service will lead to an incomplete composition service or might even throw errors.
It is possible to define associations to the entities of the included model, even if they do not exist at that time. 1:1 and 1:n relations can be defined pointing from the new model to the included external model.
When defining the association you define the left side of it (from the current model existing in BEP) with the standard method /IWBEP/IF_MGW_ODATA_MODEL~create_association
It is necessary to define referential constraints for these associations as they are resolved generically during runtime by the framework on the SAP Gateway.
During runtime based on these referential constraints a request like Flight(ID=100)/BookingsListedInHana is converted into a request BookingsListedInHana?$filter=ID eq '100 to the HANA data provider.
Currently, it is not possible to define navigation properties for entities of included models. In future, an exit user (BADI) is planned to overwrite the link resolution (and possibly also the dispatching) behavior.
Method DEFINE of class /IWBEP/CL_MGW_MED_EXT_COMP_MDL
Details
For every association an association set is required. The creation of the association set is done automatically when calling the method:
/IWBEP/IF_MGW_ODATA_MODEL->CREATE_ASSOCIATION
In case of model composition, the creation of the association set is not automatic. Instead, do the following:
Deactivate the defaulting by setting the import parameter IV_DEF_ASSOC_SET to FALSE in method /IWBEP/IF_MGW_ODATA_MODEL->CREATE_ASSOCIATION.
Create the corresponding association set explicitly by calling /IWBEP/IF_MGW_ODATA_MODEL->CREATE_ASSOCIATION_SET
The composition must have been done BEFORE the service is created on the SAP Gateway system via transaction /IWFND/MAINT_SERVICE.
This method includes a model from generic SAP Gateway Integration Service exposed on the SAP Gateway, for example, . HANA or BW services. The API can be used to compose Object Models from different services, that is to include an external model. For example, the composition is defined in the backend system, but resolved on the SAP Gateway system.
To attain this, the following conditions should be met:
The service of the external model must exist on the SAP Gateway system and be up and running.
The External Mapping ID of the service as displayed on the SAP Gateway has to be provided to the method interface. This information is stored on the SAP Gateway and resolved during runtime to create for example, the metadata document and for the business data for the routing. This means that for entities of the external model, the system alias assigned to the service of the external model is used instead of the system alias assigned to the original service including that model.
During activation the Registration Report uses the External Mapping ID to find a corresponding service. Therefore the included services should be activated first, otherwise the activation of the composition service will lead to an incomplete composition service or might even throw errors.
It is possible to define associations to the entities of the included model, although they do not exist at this time. 1:1 and 1:n relations can be defined pointing from the new model to the included external model.
When defining the association you define the left side of it (from the current model existing in BEP) with the standard method /IWBEP/IF_MGW_ODATA_MODEL~create_association
It is necessary to define referential constraints for these associations as they are resolved generically during runtime by the framework on the SAP Gateway.
During runtime based on these referential constraints, a request like Flight(ID=100)/BookingsListedInHana is converted into a request BookingsListedInHana?$filter=ID eq '100 to the HANA data provider.
In the future, an exit user (BADI) is planned to overwrite the link resolution (and possibly also the dispatching) behavior.
Method DEFINE of class / IWBEP/CL_MGW_MED_BW_COMP_MDL