The below post takes about how to implement GET_EXPANDED_ENTITY and GET_EXPANDED_ENTITYSET for deep structures like parent-child or header-item.
The usual flight demo data is used. Below are 2 DDIC structures are created to design our gateway project data model.
Create a SEGW project and create the entity type by importing from the DDIC structure ZFLLT_CODE.
create another entity type by importing from the DDIC structure ZFLLT_CONN.
So what we have now are 2 entity types and there corresponding entity sets.
Let’s create an association between these 2 entity types and their cardinality is 1..M.
The association KEY mapping between two entity types.
During the association also the navigation property [ CodeToConn] is created. Remember here the ABAP fieldname is CODETOCONN for the navigation. It will be used later.
Generate the run time artifacts- We have the service, DPC EXT class and others.
Register the service in the gateway.
Test the service in the gateway client and we receive OK status.
Now we will implement specific methods of the DPC ext class. First for the GET method.
If we go to the method implementation it is implemented in the DPC_EXT super class.
As we have two entity sets- it is already making call to specific methods depending on the entity set . No need to be done anything here.
Now we have to redefine these two methods for the two entity sets.
The two get entity methods-
The code for the get entity.
The code for the get entity.
Let’s test the ety_codeSet(‘AA) in the gateway client-
Test the ety_connSet in the gateway client-
Now the time is to see the GET_ENTITYSET method of the DPC EXT and this is implemented in the super class DPC. These are autogenerated codes and nicely structured. Calls specific method depending on the entity set types.
So lets redefine these two methods-
Here is the code for the codeSet entity set.
Here is the code for the connSet entity set.
Now time to test the entity sets in the gateway client. Test the codeSet entity set. So it brings multiple records.
Similarly test the other entity set- connSet and we see multiple records.
So far so good. Till now we tested either individual entity type or set. Now lets test the Navigation.
We have created an association with navigation named as – CodeToConn in our gateway project.
So lets test that. On the request URI provide the root entity set followed by the navigation path name. It brings the dependent/child set for the carrid = ‘AA’. It makes use of the get_entity and get_entityset method to fetch the result set.
Till now we have redefined the below 4 methods.
Lets see the GET_EXPANDED_ENTITY & GET_EXPANDED_ENTITYSET method. These two methods are called if in the request URI – $expand is used.
The method is implemented in the super class [ multi level super class].
So the method- GET_EXPANDED_ENTITY makes call to the GET_ENTITY method.
So the method- GET_EXPANDED_ENTITYSET makes call to the GET_ENTITYSET method.
Now time is to test- in the request URI provide the addition – expand with the navigation path name- “CodeToConn”.
Here we receive the result- its a deep structure. One header with multiple items. It technical sense for one SCARR record multiple SPFLI records.
Similarly we can test the entity set with the expand addition and navigation.
Below is the result- Its deep.
In above what happens in the background. Let’s under stand the technical flow-
Request URI- ety_codeSet(‘AA’)/?$expand=CodeToConn – The call goes to GET_EXPANDED_ENTITY and from there is goes to GET_ENTITY to get the header part of deep structure. Then it goes to the GET_EXPANDED_ENTITYSET and then goes to the GET_ENTITYSET to get the item details.
Request URI- ety_codeSet/?$expand=CodeToConn _ In this case the GET_EXPANDED_ENTITYSET is called in a loop for each of the header to get its item.
The result looks ok but in the backend there is a loop is going on to select items for each header and this often leads to performance bottleneck.
To overcome this situation we can redefine the EXPANDED methods.
Let’s start with GET_EXPANDED_ENTITY. First we have to declare the deep structure.
Below LS_AIRLINE is a deep structure with header and item as a table. The item table name should be the ABAP name of the navigation ‘CODETOCONN’.
The sample code provided below- this code may not work for all possible different scenarios but gives a headstart to quickly understand the simple things.
Now test –
Lets see something interesting- if we look at the ER_ENTITY which we suppose to fill with values, see its structure at runtime.
Its a deep structure- Header details with item table and the item table component name is CODETOCONN [ the navigation name ].
That’s why we declare our structure similarly.
Lets test the entityset with expand.
We have just redefined the method but not implemented any code.
If we look at the ER_ENTITYSET then its a deep table- each row contains header details and item table.
So here is the implementation. We have declared an internal table which is deep.
Time to test-
We get the result. This is efficient from the performance point of view.