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.
The following application interfaces are provided:
This interface provides the following methods:
This interface provides method COMPARE_TO.
Enhancements of /IWBEP/CL_MGW_ABS_DATA:
Implementation of GET_EXPANDED_ENTITYSET
Implementation of GET_EXPANDED_ENTITY
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:
It calls the GET_ENTITYSET implementation for Sales Orders.
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.
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. [...] CALL FUNCTION 'BAPI_EPM_SO_GET_LIST' TABLES selparamsoid = lt_selparamsoid soheaderdata = lt_soheaderdata soitemdata = lt_soitemdata. [...] ENDMETHOD.
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. [...] CALL FUNCTION 'BAPI_EPM_SO_GET_DETAIL' EXPORTING so_id = ls_so_id IMPORTING headerdata = ls_soheaderdata. [...] ENDMETHOD. METHOD salesorderitems_get_entityset. [...] CALL FUNCTION 'BAPI_EPM_SO_GET_LIST' TABLES soitemdata = lt_soitemdata. [...] ENDMETHOD.
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.
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.