What Is the OData Channel Development Paradigm for SAP?

Let’s look at the OData channel development paradigm, which describes the programming model used by the SAP Gateway runtime.

The OData channel for SAP Gateway allows you to develop content by defining object models and registering a corresponding runtime DPC. The advantage of the OData channel paradigm is a certain freedom with respect to development; entire DDIC definitions and local interfaces of the SAP backend system can be used to develop SAP Gateway services. In addition, OData query options can be leveraged in your SAP backend systems so that only data that has been requested by the client is selected from the SAP backend system and sent back over the wire. This specificity results in highly optimized services and major performance improvements due to smaller data transfers.

With respect to the OData programming model, SAP Gateway services consist of four components:

• MPC: Implemented to provide the runtime representation of your model definition.
• DPC: Called at runtime to perform data requests.
• Technical service name: Used to register the service in the SAP backend system together with the technical model name.
• Technical model name: Used to register the service in the SAP backend system together with the technical service name.

The technical service name and technical model name are automatically generated with the MPC and DPC when generating a project using the Service Builder.

Model Provider Class

The MPC is an ABAP class that provides the runtime representation of your model definition—that is, the MPC defines the EDM of a service. As such, all model information that you’ve defined in your project is generated into the MPC. Therefore, you must regenerate the MPC every time you change the model definition in your project. The MPC is important because everything you find in the service metadata document of an OData service published via SAP Gateway has programmatically been defined in the MPC.

Technically, the model definition is generated into two classes:

• Base class: Technically, the base class is derived from the /IWBEP/CL_MGW_PUSH_ABS_ MODEL superclass and has the suffix _MPC.
• Extension class: The extension class has the base class as the superclass and has the suffix _MPC_EXT. The extension class will be registered via the technical model name. In the extension class, you can choose which methods to redefine and which methods to inherit from the base class.

In most cases, a developer doesn’t need to touch the model provider extension class with the suffix _MPC_EXT as generated by the Service Builder. An exception to this rule is, for example, if you want to build SAP Gateway services with features that can’t (yet) be modeled using SAP Gateway tools. In this case, a developer can redefine methods in the model provider extension class. The figure below shows the model provider base class at the top, which inherits from /IWBEP/CL_MGW_PUSH_ABS_MODEL. ZCL_ZPRODUCT_MPC_EXT is the subclass of the model provider class. The DEFINE method is overwritten.

Model Provider Class Deep Dive

Usually, a developer doesn’t need to tap into the coding of the MPC being generated by the Service Builder. But let’s still take a closer look at the methods being generated to get a better understanding of the underlying framework.

The GET_LAST_MODIFIED method is the basis for a handshake between the SAP backend system and SAP Gateway to start a refresh of the cached metadata of the service on the SAP Gateway backend and the SAP Gateway server after the class has been changed. This method shouldn’t be changed manually.

In the entity type-specific DEFINE methods, the Service Builder generates the coding that creates the parts of the OData model that define the entity types and the entity sets that are based on entity type. The properties are created, and those properties that have been marked as a key field in the Service Builder are set as key fields in the coding:

lo_property = lo_entity_type->

create_property( iv_property_name = 'ProductID'

iv_abap_fieldname = 'PRODUCT_ID' ).

lo_property->set_is_key( ).

Finally, the entity type is bound to a DDIC structure, and one or more entity sets are created. Note that an entity type that is bound to an existing DDIC structure can leverage conversion exits as well as the labels of the data elements from the DDIC. The medium field label of a data element is used as sap:label by default:

...

lo_entity_type->

bind_structure( iv_structure_name =

   'BAPI_EPM_PRODUCT_HEADER' iv_bind_conversions = 'X' ).

...

lo_entity_set = lo_entity_type->

create_entity_set( 'Products' )

In the DEFINE_ASSOCIATION method, you can find the generated code that defines associations, association sets, referential constraints, and navigation properties of an OData model.

Data Provider Class and Data Provider Extension Class

The DPC is an ABAP class that provides all methods required to handle OData requests. It’s called at runtime to perform these requests; essentially, we’re talking about the runtime representation of your service implementation. For instance, a DPC executes CRUD-Q operations, among many more operations.

Again, you can find an extension class (suffix _DPC_EXT) and a base class (suffix _DPC). The data provider extension class inherits from the DPC base class, as shown in the figure below. We can see the methods that have been inherited by the extension class from the base class for CRUD-Q and query operations and one method that has been redefined in the extension class for the code-based implementation. The DPC extension class is registered via the technical service name. So, the extension class is executed in your OData service.

Note that, in the DPC, some methods are specific to an entity set, and some are not.

Data Provider Class Deep Dive

For each entity set, the Service Builder creates methods that are called by the framework if a create, read, update, and delete (CRUD) method is sent to this entity set. For an entity set called <ENTITYSET>, the methods created in the base class are shown in this table.

Additional methods available apply not only for a single entity set but for all of them (non-entity-set-specific methods). Examples of these methods include methods handling $EXPAND statements, deep insert statements, or statements that are called when a function import is performed. Let’s take a closer look at these examples: 

• GET_EXPANDED_ENTITY and GET_EXPANDED_ENTITYSET: Handling of $expand statements is offered by the SAP Gateway framework out of the box in a generic way after you’ve modeled the appropriate navigation property and implemented the handling of navigation properties. In some situations, you might instead handle $expand requests by a specific application implementation. Examples are certain BAPIs such as BAPI_EPM_SO_GET_LIST that, along with the header data, also retrieve line items. In this case, when retrieving the sales order header data for a certain sales order, the corresponding sales order items are also read. If the entity set is also called to expand the line items alongside the sales order header, this results in unnecessary database requests.
• CREATE_DEEP_ENTITY: The counterpart of the $expand statement is the deep insert statement, which calls the CREATE_DEEP_ENTITY A typical example is the case where a sales order can only be created alongside at least one sales order item. In contrast to the $expand statement, there’s no generic handling of a deep insert request. The developer must implement this method.
• EXECUTE_ACTION: The EXECUTE_ACTION method is a non-entity-set-specific method as well. This method rather service semantic and is called if a function import into an OData service is called. Function imports allow you to execute functions that can read and/or write data. Function imports are suitable whenever the business scenario requires data to be read or changed that can’t be modeled into an entity where you can use CRUD-Q methods.5

Technical Considerations

OData channel development can take place either on the SAP backend system or on the SAP Gateway server, as shown in the final figure. Both options are suitable for certain use cases and have their advantages. Wherever you develop, the BEP component must be installed in that system, or you must use a system based on SAP NetWeaver 7.40 or higher.

Editor’s note: This post has been adapted from a section of the book SAP Gateway and OData by Carsten Bönnen, Ludwig Diehl, Volker Drees, André Fischer, and Karsten Strothmann.