Show TOC

Expand in Framework and Data ProviderLocate this document in the navigation structure

A request with a $expand query option enables the reading of entries of an entity together with an associated entity. For example, if you want to read a Sales Order (therefore an entity) and all its associated Items you can execute one request using the $expand query option.



You can also run a $expand statement to retrieve multiple Sales Orders (therefore an entity set) including related SalesOrderItems.



OData Channel APIs

The following application interfaces are provided:

Enhancements of /IWBEP/CL_MGW_ABS_DATA:

  • Implementation of GET_EXPANDED_ENTITYSET

  • Implementation of GET_EXPANDED_ENTITY

Expand in Framework and Data Provider

Framework Expand

By default SAP Gateway provides a generic $expand implementation, which requires no implementation effort. The generic $expand statement is handled by the framework and was formerly called “generic expand”. When looking at the example above of reading a Sales Orders entity set including related SalesOrderItems entity set, the framework will do the following:

  1. It calls the GET_ENTITYSET implementation for Sales Orders.

  2. For each Sales Order retrieved by the GET_ENTITYSET implementation, the framework calls the related GET_ENTITYSET implementation for the items in a LOOP.

However, there is an alternative to the framework $expand.

Data Provider Expand

The data provider $expand which used to be called “basic expand” is based on the data provider and requires implementation effort. The following methods need to be redefined in the related DPC class to enable the data provider $expand functionality:

  • For reading an entity with an associated entity set (possible use case: you want to read a Sales Order and its associated Sales Order Items):


  • For reading an entity set together with an associated entity set (possible use case: you want to read multiple Sales Orders and all associated Sales Order Items):


Once the methods above are redefined, the data provider $expand is active instead of the framework $expand.

Performance Considerations

In some cases the implementation of data provider $expand can lead to a better performance than the framework $expand, depending on the implementation itself and especially on how the data from the business application is fetched.

Consider the following example of a data provider $expand implementation in method /IWBEP/IF_MGW_APPL_SRV_RUNTIME-> /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_EXPANDED_ENTITYSET:

METHOD /iwbep/if_mgw_appl_srv_runtime~get_expanded_entity.
          selparamsoid = lt_selparamsoid
          soheaderdata = lt_soheaderdata
          soitemdata   = lt_soitemdata.

The framework $expand example that would achieve the same looks different. Since there is no specific framework $expand implementation, it is necessary to implement the related GET_ENTITY/GET_ENTITYSET methods:

METHOD salesorders_get_entity.


        so_id      = ls_so_id
        headerdata = ls_soheaderdata.


METHOD salesorderitems_get_entityset.


        soitemdata = lt_soitemdata.



In the example of the data provider $expand implementation it is possible to fetch application data including Sales Order entity set and associated Sales Order Item entity set using only one function call. In such a use case data provider $expand might lead to better performance than framework $expand.

Initial Handling for $expand

When $expand is used the backend framework returns the "inline" data to the hub framework in the form of a table containing a flag which shows whether an “inline” structure is initial or not. Thus you can see whether this "inline" data is initial or not.