Dynamic loading of Layout Variant in ALV-Grid Output List?

[Lukas_Weigelt]

Hello folks,

System Information:

NW AS 7.03 ABAP Stack 731 Level 8, ECC 606 (EHP 6) with SAP_HR 604 Level 69 and EA_HR 607 (HR-Renewal 1) Level 20

Background:

The Report RPTARQDBVIEW (part of the HCM Leave Request application) is used for a selection of ABSREQ-typed receipts from the receipt database and allows for an output of an ALV-grid list.

Requirement/Problem:

The Report's ALV-output has to be loaded with a certain Layout Variant for a particular group of users, either depending of the user's R/3 Roles or due to a specific initial Transaction Code that is used to access the report in the first place.

What I did so far / Idea for an implementation / Question:

I've searched for the terms "ALV_Grid, Layout Variant, Dynamically, List Output" and found no information sources whatsoever concerning my problem (maybe my search parameters are nonsense?). I expected or rather hoped there to be some kind of magical output-variant-thingy I can use as a standard method to achieve my requirement but haven't found one, so I've debugged the horrible vast overhead of the frame program down to cl_gui_alv_grid-> set_table_for_first_display which I can theoretically enhance and interpret some prior set memory flag to execute some custom coding and just programatically implement my requirement with this means; this does work out. However, maybe I'm just blind to a more elegant and simpler solution which I didn't find/don't know of.

Any input is appreciated, especially that with a slap to the face and a pointing to a trivial SAP-Standard approach.

Cheers, Lukas

[Former Member]

Hi Lukas,

For the trivial SAP standard approach, I guess the enhancement way is the only one...so to dig probably!

What I would do is encapsulate the program RPTARQDBVIEW within a Z one in wich the layout would be just a parameter on the selection screen...No need to copy the program, you just need to copy the existing selection screen (with the new parameter for the alv layout variant), then submit the standard program with your custom parameters and output your ALV as per your requirement.

I would say..Z but clean approach (sometimes you need to live with it )

To get the output of the standard report, you will first need to initialize the ALV runtime buffer with the method:

     cl_salv_bs_runtime_info=>set( display = abap_false
                                                       metadata = abap_false
                                                       data = abap_true ).

Then submit:

submit rptarqdbview (with list of selection criteria) and return.

Then get your data back from the ALV buffer with:

     data lr_data type ref to data.
     field-symbols <t_data> type any table.

     cl_salv_bs_runtime_info=>get_data_ref( importing r_data = lr_data ).
     cl_salv_bs_runtime_info=>clear_all( ).
     assign lr_data->* to <t_data>.

And finally you can play around with outputting <t_data> with any ALV variant or other settings...

     cl_salv_table=>factory( importing r_salv_table = lr_table
                                           changing t_table = <t_data> ).

...(set ALV options)

...set layout variant:

     data lo_layout type ref to cl_salv_layout.
     data l_variant type slis_vari.

     lo_layout = lr_table->get_layout( ).
     set_initial_layout( l_variant ).        

...and display

     lr_table->display( ).

Cheers!

Manu.  

[Lukas_Weigelt]

Hi Manu,

Thank you! Very interesting approach. I didn't think of 'encapsulating' the ALV instance around the original report with a Z one yet. Seems a little more sophisticated than my approach with the enhancements but also more elegant and cleaner. Additionally, your solution shows me that I apparently did not overlook some well hidden "right-click-problem-solved"-solution

I'll keep the thread "unanswered" a bit longer, maybe there are still other approaches.

Cheers, Lukas

[Former Member]

Hi Lucas,

Well I think enhancements are always to be considered first, anyway...

I used the above approach to allow more flexibility on a standard report and enhance the output. I must say It is really easy to implement, once you gave it a try, you'll keep that in mind, for sure

Don't think there is any other magic solution though I'll keep following then

Br,

Manu.

[Former Member]

Hi Lukas

Here's a blog that explains the CL_SALV_BS_RUNTIME_INFO class in a little more detail.

Regards

Glen

[Lukas_Weigelt]

Thanks, Glen, I'll take a look at your blog.

Cheers, Lukas

[Jelena_Perfiljeva]

Hi Lukas,

We don't use HR, so I can only see the selection screen for this report, but the main problem here is that it doesn't provide a parameter for the layout. But I'm guessing otherwise you wouldn't be posting this.

With this in mind, I suspect that a simple "wrapper" for the selection screen won't help because the report should be capable of accepting the layout name and then that name needs to be passed to ALV (looks like this report is actually using good old REUSE_ALV_GRID_DISPLAY). So to "feed" the layout name to ALV in this case, I'm afraid, only some brutal enhancement will do.

However, if the users are planning to use this just as a report, without triggering other functions (in which case there could be additional security concerns), then maybe it'd be easier to just create a custom report or query. I don't recommend this often, but at some point it might make more sense than trying to break standard.

[Former Member]

Jelena Perfiljeva wrote:

With this in mind, I suspect that a simple "wrapper" for the selection screen won't help because the report should be capable of accepting the layout name and then that name needs to be passed to ALV (looks like this report is actually using good old REUSE_ALV_GRID_DISPLAY). So to "feed" the layout name to ALV in this case, I'm afraid, only some brutal enhancement will do.

Yup it helps the idea with the wrapper is that the standard report is then only responsible of the data selection, the Z wrapper program takes care of the view part, whatever the layout, setting or output type you need to apply...

Cheers,

Manu.

[Lukas_Weigelt]

Hey Jelena,

With this in mind, I suspect that a simple "wrapper" for the selection screen won't help because the report should be capable of accepting the layout name and then that name needs to be passed to ALV (looks like this report is actually using good old REUSE_ALV_GRID_DISPLAY). So to "feed" the layout name to ALV in this case, I'm afraid, only some brutal enhancement will do.

Aye, ultimately. Which is what I initially did (not exactly within the FM but at some point prior, otherwise the logic is inconsistent and won't always work) and which I'll keep this way for this particular use case. But "brutal enhancements"? Tsk. Tsk. My enhancements are always nice and gentle to the standard sources and only kill them softly in unavoidable cases 😆

Cheers, Lukas

[Jelena_Perfiljeva]

Manu, but the SAP report is a bit more than just ALV display. There are some other functions that apparently could be triggered (like I said, we don't use HR, so I couldn't run it, but that's what I've noticed based on a very quick review). Wouldn't this functionality be lost with this approach?

[SuhaSaha]

Hello Lukas,

I had a look at the source code of the report and this is what i can propose -

1. Enhance the include RPTREQDBVIEW_SELSCREEN, to add a parameter P_VARI. I am not sure how to maintain the selection-text for it. May be you can try with SELECTION-SCREEN COMMENT.
2. Enhance the subroutine ground_list and copy the original logic for ALV display inside the enhancement. Pass the value of P_VARI defined in step(1) to the variant structure gs_variant. You have to do this because gs_variant is defined as a local variable Remember to leave the enhancement and the subroutine once the ALV is displayed.

I'm not sure if this is some kind of a dirty hack. I'm happy with Step(1), but with (2) i wish we had some kind of overwrite-exit for subroutines too

Let me know what you think of this solution.

BR,

Suhas

[Lukas_Weigelt]

Hi Suhas,

your approach goes into a similar direction as my initial one, but I still like mine better 😜

I enhanced FORM PBO (it's really a form called like  that, it's not a Dynpro Module) in LSLVC_FULLSCREENF01 and force (nice and gently) gt_grid-s_variant to eat a certain variant according to certain parameters. This still sucks to a certain extent because I'm meddling with a global parameter, but it's thankfully not leading to an inconsistent program flow.

 i wish we had some kind of overwrite-exit for subroutines too 

+1. And for macros. Or no, nevermind, better put all macros in sacks and drown them.

Thank you all for your ideas and approaches! I'll set the thread assumed answered now.

Cheers, Lukas