This interface is the entry point for every OData Channel model definition to define the required OData artifacts.
Method CREATE_ACTION
This method adds an action / service operation / function import to the OData model.
Parameter |
Description |
---|---|
IV_ACTION_NAME |
Value |
RO_ACTION |
Instance |
Method CREATE_TAG
This method creates a service tag: an action or an OData function import. Actions are pre-packaged chunks of business logic that go beyond simple CRUD operations on data object instances.
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 |
See also 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
This method includes a data model from another OData Channel service exposed on the SAP Gateway, that is, IW_BEP data models. The API can be used to compose data models from different services, that is, to include an external data model. The composition is defined in the system in which the software component IW_BEP is installed. The software component IW_BEP can be installed on an SAP Business Suite backend system or on an SAP Gateway hub system.
The service of the external data model must exist 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 is converted into a request BookingsListedInHana?$filter=ID eq ‘100’ to the HANA data provider.
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) |
The external name of the service as specified in the BEP-registration. |
IV_SERVICE_VERSION (optional) |
Technical version of the service |
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 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 a SAP Gateway ODC Model using the Model Name / Model Version (Model ID) in BEP. 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 run time behavior.
Parameter |
Description |
---|---|
IV_TECH_MODEL_NAME |
Technical name of model |
V_MODEL_VERSION |
Technical version of model |
SET_MODEL_FEATURES
This method sets different model features via parameter IS_MODEL_FEATURES. The following model features can be currently set:
use_cache_handshake_busi_req (activates the cache handshake for business requests).
use_edm_mapping_sp10 (use the EDM mapping as developed in support package 10) Note that the default is the previous EDM mapping.
use_long_label_for_property
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.
Example of enabling the cache handshake for business requests:
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.
Method SET_SERVICE_SCHEMA_VERSION
An application developer can use this method to set the SAP schema version.
Example:
<Schema Namespace="com.sap.TEA.TestApplication" xml:lang="en" sap:schema-version="0001" xmlns="http://schemas.microsoft.com/ado/2008/09/edm">
This can be considered a sub-version of the service version.
If not set explicitly, the default schema version is 0000. This is not supported for service composition. That is, in case of service composition the value is always 0000.
Parameter |
Description |
---|---|
IV_SERVICE_SCHEMA_VERSION |
Schema version |
Method SET_SCHEMA_NAMESPACE
An application developer can use this method to set the schema namespace attribute for the metadata document.
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>
Method INCLUDE_MODEL_BY_SERVICE_ID
Note that this method is obsolete and should not be used any more.
This method Includes a model from another OData Channel Service exposed on the SAP Gateway system, i.e. backend models. The API can be used to compose Object Models from different services, i.e. to include an external model. For example, the composition is defined in 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 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.
It is currently not possible to define navigation properties for entities of included models. In future an user exit (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.
Method INCLUDE_MODEL_BY_MAPPING_ID
Note that this method is obsolete and should not be used any more.
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, i.e. to include an external model. For example, the composition is defined in 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 future an user exit (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