How Does It Work?

The OData Channel Generation Tool retrieves the model definition from either of the following sources:

• edmx file (Entity Data Model file, an XML file created with Microsoft Visual Studio™ Entity Data Model Designer).

• OData service metadata document

Based on the model definition, it generates all the objects needed for the OData Channel as follows:

• Model Provider Superclass (MPSC).

  The class <Prefix><ModelProvider>_BS contains an implementation of the DEFINE method that contains the imported model. The GET_LAST_MODIFIED method is updated each time the model is (re)generated.

• Model Provider Class (MPC)

  The class <Prefix><ModelProvider> includes a structure for each OData entity type. This is for extensibility reasons since it inherits data from the MPSC and does not add any methods or attributes. You use the MPC class to register the model.

  You do not have to redefine the inherited methods; but you can do this for manual extensions of the model. If you make changes to the inherited methods, these will not be overwritten during regeneration unless you explicitly select the Overwrite Developer Classes checkbox. If you want to extend the model definition programmatically, you redefine the DEFINE method within this class. This ensures the generated code and user code are separated and, if you regenerate the implementation, your custom coding is not overwritten because the tool does not recreate the MPC class by default.

• Data Provider Superclass (DPSC).

  To facilitate the implementation of a data provider, multiple classes are generated. In addition there is an interface and a class for each entity type in the model. The generated code in the DPSC dispatches to the corresponding entity class. In some cases, you might want to use a central implementation for all entities (as in the case of EXECUTE_ACTION). You can use the DPC (see below) for this, and you can also use it to redefine a generated method in the DPSC.

• Data Provider Class (DPC).

  The DPC contains multiple inherited methods that are not part of any interface, such as COPY_DATA_TO_REF. These inherited methods are utility methods. For example, COPY_DATA_TO_REF copies data and returns a TYPE REF TO DATA required for many methods in the data provider interface.

• Content developer class interfaces, describing the methods that you must implement, as well as their parameters. The interfaces are implemented by the content developer classes.

• Content developer classes that must be implemented at the end of the generation process. This is where you implement business logic to extract and/or modify business data. These classes are the only objects that you need to implement.

The tool uses a default mapping to map entity types to ABAP types, and, if the edmx file already contains mapping information (for example, from entity types to DDIC data elements), the mapping assignments are displayed on the screen. You can change and maintain the proposed mapping assignments and also define a binding structure for each entity type.

For more information about working with the OData Channel Generation Tool, see Using the OData Channel Generation Tool.