With ALV and FPM lists, SAP provided very powerful and convenient tools to represent lists in SAPGUI, WebDynpro UIs or SAP NetWeaver Business Client. These tools have been very well adapted to the paradigm of databases being the bottleneck. In this context it is an efficient design to select the data into an ABAP table and to execute the UI operations like paging, sorting, aggregation and filtering on the ABAP application server. Handing over this internal table as data source to the reuse components ALV and FPM list is their basic principle and the reason why they can provide these operations out of the box: they have control over the result set.
In times of SAP HANA, you may think about pushing down data base centric operations to the database and presenting the data differently to the end user. Why not browse through the complete database content, which you are allowed to see, without truncation? Why not start the application with displaying the first page of the data and simply offering a search field to narrow down the result set - instead of starting with a selection screen? Why not start with an aggregated list in which you can drill down?
To a certain extend this user experience can be provided with the classical ALV and FPM lists. But the whole data being selected into an ABAP table, the size of the ABAP memory and the time to copy the data into the ABAP memory are limiting factors. So for mass data it is not a good idea to start the application without a selection screen.
With ABAP 7.40 on SAP HANA, ALV and FPM lists support such UI designs still being as convenient for the application developer as the classical version. How can this be achieved? Remember that the basic principle for these reuse components is to have knowledge about the result set. That does not mean that they must have the complete data of the result set under control, as it is the case in the classical versions. But they need some basic information like the size of the result set in order to determine the size of the scroll bar, or the knowledge how to provide the data for the next page for example.
So with ALV and FPM on SAP HANA we changed the programming paradigm. Instead of selecting the data into an ABAP table, the application developer instruments ALV or FPM with the necessary information to access the data, like tables to be read, parameters to be used or authorization checks to be performed. With this information, the UI state - page number for example - and the user authorizations the infrastructure creates a select statement on the HANA database retrieving only the data which is necessary to display the actual page.
The following videos will illustrate what that means for the end user and the developer.
New ways to navigate the data with SAP HANA
In times of SAP HANA, you may think about pushing down data base centric operations to the database and presenting the data differently to the end user. Why not browse through the complete database content, which you are allowed to see, without truncation? Why not start the application with displaying the first page of the data and simply offering a search field to narrow down the result set - instead of starting with a selection screen? Why not start with an aggregated list in which you can drill down?
To a certain extend this user experience can be provided with the classical ALV and FPM lists. But the whole data being selected into an ABAP table, the size of the ABAP memory and the time to copy the data into the ABAP memory are limiting factors. So for mass data it is not a good idea to start the application without a selection screen.
New programming paradigm
With ABAP 7.40 on SAP HANA, ALV and FPM lists support such UI designs still being as convenient for the application developer as the classical version. How can this be achieved? Remember that the basic principle for these reuse components is to have knowledge about the result set. That does not mean that they must have the complete data of the result set under control, as it is the case in the classical versions. But they need some basic information like the size of the result set in order to determine the size of the scroll bar, or the knowledge how to provide the data for the next page for example.
So with ALV and FPM on SAP HANA we changed the programming paradigm. Instead of selecting the data into an ABAP table, the application developer instruments ALV or FPM with the necessary information to access the data, like tables to be read, parameters to be used or authorization checks to be performed. With this information, the UI state - page number for example - and the user authorizations the infrastructure creates a select statement on the HANA database retrieving only the data which is necessary to display the actual page.
The following videos will illustrate what that means for the end user and the developer.
ALV and FPM on SAP HANA - The Difference
Get what it means from an end user point of view and how it works in principal
ALV transformation and beyond
See how to transform an existing ALV application into ALV on SAP HANA and get some ideas of what is possible with this changed paradigm
FPM transformation and beyond
See how to transform an existing FPM application into FPM list on SAP HANA, how the application creation tool supports it and get some ideas beyond
Further advantages
Beside the new UI scenarios, you get rid of some limitations of the classical ALV or FPM dealing with mass data: You do not have to wait for the first page until the complete result set is copied to the ABAP memory. You never get a memory exception as the data for one page only is selected into the
ABAP memory. You also do not have to struggle with truncated list – e.g. sorting and not finding the entry you expected, or aggregating and getting
questionable results. The whole list processing is stateless, which is a clear advantage in mobile scenarios. And last but not least the new programming paradigm is very conservative with respect to resource consumption.
Limitations
You may ask if there are no limitations with the ALV and FPM on SAP HANA. The classical solution is very fast in processing the second page because of the data the UI uses being already available in the ABAP memory. In the new version, processing any page is as fast as the database is as each data centric operation on the UI (e.g. paging, sorting, aggregation) is pushed down to the database.
And very important to know is that the sorting on the database is a binary sort, not a lexical one as on the ABAP table.
Should the classical tools be replaced by the SAP HANA version?
No, if the end users do not complain about the limitations of the classical versions, there is no business reason for a change. But if you often see memory dumps for a certain UI in your system, if the users complain about the truncation parameter or if create a new application – then you should have a closer look at ALV or FPM on SAP HANA.
Source: scn.sap.com
No comments:
Post a Comment