Skip to Content

Generic Expanded Entity Implementation

NetWeaver Gateway provides GET_EXPANDED_ENTITY method for retrieving an entity together with Child entities, via. navigation properties. This approach provides better performance compared to calling individual entities separately for fetching data.

The general approach for implementing GET_EXPANDED_ENTITY involves explicitly specifying which child entities can be retrieved along with parent entity through hardcoding of the navigation properties in the method implementation. This requires populating the data in the nested properties of the parent structure carrying the same name as navigation property names and then adding the navigations to standard exporting parameter ET_EXPANDED_TECH_CLAUSES to inform the framework that the expand clause has already been catered by custom implementation.

This can lead to unnecessary code duplication and introduce erroneous handling when dealing with large entities with multiple Navigation properties. You can find sample code using this approach here.

In this blog, I present an alternate approach to implementing GET_EXPANDED_ENTITY for entities containing multiple navigation properties. This involves a single implementation of the GET_EXPANDED_ENTITY supporting all of the navigations in a generic way. A real-world example is the Fiori My Inbox application which has to support several associations through navigation properties, such as Attachments, Comments, Task Details, etc. in addition to any custom navigations.

To contrast the generic approach from the usual way, I have demonstrated pseudo-code for the common approach below.

Pseudo code example:

ls_leave_request-header_id = ‘100’.
ls_leave_request -leaverequestitems = VALUE #( ( ) ( 1 ) ( 2 ) ). “Sample – An array of integers

The alternate approach involves dynamically checking the $expand clause coming from the UI and parsing it to prepare data for the navigations requested by UI at runtime. Then finally appending the same in the ET_EXPANDED_TECH_CLAUSES.

However, this approach will require rework only when new features are incorporated which in turn will change the oData model (changes like navigations added or removed) and the corresponding front end developments as well.

Also in this example, I cover navigations till second level. It can be enhanced to any level technically but then the implementation complexity needs to be weighed in with comparison of future use cases and maintenance of the newly induced complexity.

The gateway project modelling used for this example is below.

Figure 1: Entity with Navigation property

Create a new method (for modularization) and call before the actual data fetch

Figure 2: New method’s call before data fetch

Figure 3: Method’s interface

METHOD check_prepare_expand_clause.
    " Structure
    DATA  : ls_expand_sub_children      TYPE /iwbep/if_mgw_odata_expand=>ty_s_node_child.
    " Internal tables

    DATA : lt_expand_children     TYPE STANDARD TABLE OF /iwbep/if_mgw_odata_expand=>ty_s_node_child,
           lt_expand_sub_children TYPE STANDARD TABLE OF /iwbep/if_mgw_odata_expand=>ty_s_node_child.
*                      Start Of Code-                                 *

    CLEAR : es_leave_req_expand_clauses ,et_expanded_tech_clauses.

    " Check the expand clauses and do the append of technical clauses appropriately

    IF io_expand IS BOUND.

      lt_expand_children =  io_expand->get_children( ).

      LOOP AT lt_expand_children INTO DATA(ls_expand_children).

        CASE ls_expand_children-tech_nav_prop_name.

            " Association - Leave Request Items
            APPEND ‘LEAVEREQUESTITEMS’ TO et_expanded_tech_clauses.

            es_leave_req_expand_clauses-leaverequestitems = abap_true.
            lt_expand_sub_children = ls_expand_children-node->get_children( ).

            READ TABLE lt_expand_sub_children INTO ls_expand_sub_children INDEX 1.
            IF sy-subrc IS INITIAL.
              " Sub Association - Assignments
              IF ls_expand_sub_children-tech_nav_prop_name EQ  ‘LEAVEREQUESTASSIGNMENTS’.
                APPEND ‘LEAVEREQUESTASSIGNMENTS’ TO et_expanded_tech_clauses.
                es_leave_req_expand_clauses-assignments = abap_true.
        CLEAR : ls_expand_children, ls_expand_sub_children, lt_expand_sub_children.

Code Snippet 1: Dynamically prepare expand clauses


Figure 4: New method’s call before data fetch


Please share your feedback and experiences.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.