Evaluation of the Concepts of the ALV Flavors
The technology of the ALV with IDA on an in-memory database represents a modern alternative to SAP List Viewer (ALV) on a conventional database. In this respect it is useful to compare in detail the two variants of the most important table display in SAP GUI for Windows. This section contains a schematic comparison of the two scenarios.
- ALV in a system landscape based on a conventional database:
Data is selected by the application (step 2), and the complete dataset is passed in an internal table to the ALV. The ALV keeps a data reference to the table (1) and displays this data. No data copy is made; the original data is sorted (3). The filter (3) does not reduce the dataset, it makes a note of the filtered data indexes. The other important ALV operations, such as subtotals (3), aggregations (3), and paging (3) are evaluated from the ITAB - the ALV does not know about the database table.
- ALV with IDA in a system landscape based on an in-memory database:
The application prescribes to the ALV with IDA which table data is read from and which selection criteria are used (1). When the first page is requested by the UI, the ALV selects the data (2). Sorting and filtering functions are executed by the in-memory database (3). Each change to the UI that creates a roundtrip (includes simply scrolling through data) is collected as a request in an SQL command and forwarded to the database (3). Only the data required for the current display is read from the database. This keeps the dataset that is actually processed on the application server small, which results in higher performance and less memory consumption.
The typical program flow or programming model is also different in this evaluation of concepts.
The left column contains typical processing blocks when using SAP List Viewer for simple tables. The right column contains the same processing blocks when using SAP List Viewer with IDA.
| SAP List Viewer * | SAP List Viewer with Integrated Data Access |
|---|---|
| ALV control is instantiated, and the container is assigned, and if required, the screen too. | The ALV control is instantiated, and the container is assigned (and if required, the screen too) in the same way (see also, Embedding in SAP GUI) |
| Data is selected with one or more SQL statements ( select expressions) and select options (WHERE clause) are transferred in the application program. | Select options (see Setting Selection Options) are transferred in ALV API. A more powerful Data Retrieval interface, such as Complex Conditions, and Text Search Across the Whole Table are available. |
| A simple internal table with no deep structures is transferred to the ALV. | The DDIC view/table name is transferred using the create method. |
| These steps must be enhanced for more complex applications: | |
| Fields from the select expression can be enhanced with fields containing business logic or UI logic and stored in an internal ABAP table. | To differentiate and edit business logic, we recommend you move it to the database. For local business logic or UI information for which ALV services (sorting, filtering, aggregation, text search) have to be deactivated, use Calculated Fields (see also, List Fields) |
| Application logic is implemented by registering events and enhancing the toolbar. | Application logic is implemented by registering events (see Toolbar Functions) and enhancing the toolbar (see Designing Toolbars). |
| The table layout, buttons, and icons are configured with the API. | For the initial display, see Column Format |
| Some function options are dependent on the database used in your system landscape (see Database Awareness. Database-specific functions, such as text search with fuzzy logic can be provided. |
|
* When using classes CL_GUI_ALV_GRID, CL_SALV_TABLE (in-container or fullscreen display) or function module REUSE_ALV_GRID_DISPLAY.