ABAP_to_the_Future

Designing a Report Interface 10.2
Figure 10.4 INITIALIZE Method Parameters
Take a look through the parameters in the signature for the INITIALIZE methods.
Start with the importing parameters ID_REPORT_NAME and ID_VARIANT. You’ve
most likely already worked out a reason you need a variant; no two users ever
quite like to see the exact same column s in the same report. Because you don’t
want to have 23 virtually identical report s all with similar column layouts, you
tend to write reports with a large numberof columns, most of them hidden. Then
the users can choose the ones they like to look at and save this information in a
variant. Any report worth its salt has the display variant as an input parameter on
the selection screen. (The reason you pass in both the name of this display variant
and also the report name is that this is needed to distinguish identically named
display variants for different reports.)
Then, there’s the optional parameter IO_CONTAINER, which is a container, as discussed
in Section 10.1.1—that is, an areaof the screen where you want the report
to appear. You could have four different reports appearing on the one page, or an
area at the top for unprocessed items and an area at the bottom for unprocessed
items with the two areas having different layouts, or a tree at the top and a grid
at the bottom and the user drags items from the grid onto the tree. In all of these
examples, you need to specify where the report being initialized should appear. If
you just want the whole screen as per no rmal, then you don’t need to pass anything
in.
Next comes an importing table: IT_USER_COMMANDS. As noted earlier, all the standard
SAP report technologies give you a nice inbuilt series of buttons that appear
at the top of the screen to sort and filter the data, export the data to Excel, and so
on. A lot of the time, you also want to add some of your own buttons to invoke
another transaction or report, be it cu stom or standard, using data from this
417