Basic Principles and advantages

• Basic Principles
• Only retrieve from the database data which is to be displayed on the screen.
• Use database services where possible – ALV features pushed down to the database.
• Data described declaratively instead of passing big internal tables.
• Advantages
• Retrieval of results is much faster.
• Better performance and reduced memory consumption
• Improved user experience

How ALV works

 

The SAP List viewer with IDA offers ABAP developers the option to take advantage of SAP HANA, without having to present the user with a new or different interface. Using the ALV with IDA, it is possible to display huge amounts of data, with the expected sorting and grouping functions that users are familiar with, but without big performance issues.

The ALV with IDA is based on the following principles:

• Only select the data in the database that is supposed to be displayed.
• In addition, all calculations such as aggregating and grouping data, or adding columns whose values are computed from other columns, should be performed in the database.

 

The figure, Classical ALV, shows the approach to displaying data using the classical ALV. The steps shown provide an example of what the ABAP application would typically do, as follows:

• The application performs authorization checks and extracts relevant data from the database into an internal table.
• Business data, such as calculated fields, can then be added to the internal table contents.
• UI information may also be added
• The internal table is passed to the ALV services, which then manipulate the data according to user requirements.
• The required data is displayed on the screen.

 

Technical Differences between ALV IDA and Classical ALV

 

 

The classical ALV requires all data to be first loaded into an internal table in order to display it, and typically this is larger than what is displayed to the user in the end. This initial load can lead to very long waiting times for the end-user, or even short dumps due to memory consumption. Due to these issues, the user may restrict the amount of data beforehand, leading to incomplete data sets.

 

Once data is loaded, all processing takes place in the ABAP stack on the internal table, for example, sorting the dataset, filtering the data set, grouping aggregating, or adding calculated columns. Even paging through the result set happens in the ABAP stack. All these processing steps can take a long time, and again consume a large amount of memory when dealing with large amounts of data.

 

 

The ALV optimized for HANA is significantly different from the classical ALV.

 

Authority checks, table functions, and other processes that were previously carried out by the application are now performed by the database. The application only has to pass the details to the new ALV API(IDA); for example, a WHERE clause can be sent to the database by calling relevant methods.

 

Additional UI information is still handled by the application.

 

The amount of data is severely restricted by the database before it is displayed on the UI, and there is no longer a need to store the displayed data inside an internal table.

 

Package SALV_IDA_TEST contains sample programs using the ALV Optimized for SAP HANA.

 

End-User Perspective

 

 

The ALV optimized for SAP HANA will look and feel familiar to end users who have worked with the classical ALV, but there are some differences in functionality and behavior.

 

 

Select Options