cancel
Showing results for 
Search instead for 
Did you mean: 

RESTful ABAP - Object Detail Page of Fiori App which uses CDS Custom Entity

mpasupathy
Discoverer

Hello all,

Background:

I am creating a Fiori Application using the RESTful ABAP Programming model. A CDS Custom Entity serves as the data model. As described in the Developer Guide, I am binding this CDS Custom Entity to an ABAP Class. This ABAP Class is basically the "Query Provider". Inside this Query Provider class, the method - IF_RAP_QUERY_PROVIDER~SELECT( ) is implemented. I am getting the first screen of the app (i.e. the List Report Page) fine.

And my goal is - When I click on one of the rows of the list, the app should navigate to the Object Detail Page where more information about the row clicked should be shown. There is no need to implement any transactional capabilities. So Behaviour Definition/Implementation does not come into the picture, I think.

Question:

When I click on one of the rows of the list, the control again comes to the SELECT( ) method and executes it again. I want to avoid this, because this method has already been executed in the process of displaying the first screen (i.e. the List Report Page). Now, for the Object Detail Page, I want to display certain details about the row clicked alone (and those details are already available in an internal table). There is no need to execute the complete SELECT( ) again.

In classical ABAP Interactive List Reporting, if I remember correctly, there were system variables like SY-LSIND which indicated the hierarchy of a certain page in a list. In the Query Provider Class, is there something like SY-LSIND, based on which I branch out the logic for the Object Detail Page? In other words, how do I know programmatically, if I am currently in the List Report Page or in the Object Detail Page? Can I write logic which will get executed only for the Object Detail Page?

Pardon if this is something very basic. I did not find this in the documentation/Developer Guide. It would be great if I could have some guidance from the RAP Gurus like andre.fischer . Thank you.

Accepted Solutions (0)

Answers (2)

Answers (2)

BhargavaReddy
Active Participant

Hi,
First, regarding the RAP Sevices, the services (OData protocol) is used stateless communication, which means that the session will be closed after the response is provided.

So in this case, each request opens a new session to get the data. Does not contain previous sessions or any data.

In your case, for custom entity, The framework always calls only the method IF_RAP_QUERY_PROVIDER~SELECT( ) to get data whether you trying to get_entitySet() or get_enetity(<key>).

But the method provides some information to get data like Paging, Filters, Sorters, etc. Based on that information you can select data.

DATA(lo_filter) =  io_request->get_filter( ).
    TRY.
        DATA(lt_filter_range) = lo_filter->get_as_ranges( ).

        DATA(lv_filter_string) = lo_filter->get_as_sql_string( ).

      CATCH cx_rap_query_filter_no_range.
        CLEAR lt_filter_range.
    ENDTRY.<br>DATA(ls_Paging) =  io_request->get_paging( ).

And the method IF_RAP_QUERY_PROVIDER~SELECT( ) can't tell where you are(list/detail page), since the Query Provider implemented only for getting data by given input. and RAP doesn't pass any UI application state info to Query Provider class.


Thank you,
Best Regards,
Bhargava

MatthiasH
Explorer
0 Kudos

Hi,

RAP passes the information "QUERY/READ" in the object variable io_request. But unfortunately it´s private and there is no public method to access it:

MatthiasH
Explorer
0 Kudos

Hi mpasupathy,

I found a workaround.

In case of a READ request (object detail page) the page size of import parameter io_request is set to the certain value "-1", which is defined as interface constant if_rap_query_paging=>page_size_unlimited.

If you want to call some coding only in case of a READ request, you can implement it as follows:

IF io_request->get_paging( )->get_page_size( ) = if_rap_query_paging=>page_size_unlimited.
  ... your coding ....
ENDIF.

Best regards,

Matthias