** TEAM FPM ** – A New Filter UIBB
In this blog we would like to introduce a new Generic UIBB which serves as an analytical data browser and can be used for deep drill-down into specific segments of your (potentially big) data. In combination with a results list you may find your filtered data records and finally navigate into specific object maintenance.
Let’s compare this with the FPM Search UIBB which has gained a wide usage, and search pages are the most prominent entry points into FPM applications, in particular for object maintenance. What is the typical use case for the FPM Search UIBB? The user enters specific search criteria e.g. a plant, a date and time, a company code, text fragments for a text search, or even some document identifiers (key fields). In other words: The user knows what she or he is searching for. This is of course a valid use case and in many situations exactly what the user needs.
But what if the user wants to browse a (potentially huge) set of data, analyze the distribution of records or values into specific dimensions, maybe recognize some conspicuousness and finally find and analyze some particular data? You may think of a manager who browses a large set of sales orders and likes to dynamically analyze how the total amounts split into regions, functional areas, plants, lines of business – anything; today these attributes, tomorrow others. This is what the new FPM Attribute Filter UIBB can provide. In case you cannot foresee the use case or you can foresee that both may be needed it can be the best solution if you offer two entry pages for object maintenance: A search page and a filter page.
Here is a screen shot showing how a filter page may look like at runtime.
On the left-hand-side you can multi-select among the various attributes. For each selected attribute, a value table is displayed which shows how the data are split into the distinct attribute values. The values are displayed together with their record counts (“Hits”) or, alternatively, a measurable attribute (numeric attributes, amounts or quantities), depending on the configuration. Each value table displays a configured maximum number of values, and the user can request further value packages by pressing the “More lines” link. The value table headers display the totals. Selecting values in a table means applying the value filter to all tables to the right. The feeder class is informed on all value table selections so that a separate results List UIBB can be enabled to display only the records surviving all these filters.
How does the UIBB configuration look like? As usual, the available attributes provided by the feeder class in the GET_DEFINITION method are displayed in the repository and can be moved into the attribute schema table. All this is quite the same as for other UIBBs, but the specific music plays in the General Settings, and you can directly observe any setting change in the preview panel. For example, if you enter a “Count Attribute”…
…by selecting LOCCURAM from the value help, then you can see in the preview that now amounts with currency reference are displayed instead of the hit counter. (Of course their can only be faked sample values at design time.)
But note: If you assign amounts or quantities you should make sure that you have fixed references at runtime. It does not make sense to compute totals of mixed EUR, USD and JPY!
Similarly you can check what happens if you adjust “Row Count” and “Package Size”. It is a good idea to keep the package size one less than the row count as the the “More lines” link will be immediately visible without scrolling. You can put the package size larger but it does not make much sense to put it smaller as you would waste space in the UI. You can also adjust the value table width or switch off the percentage bar. Moreover, if you are unhappy with the panel text “Filter” you can remove the panel and e.g. place the Attribute Filter UIBB in an OVP panel with an arbitrary title.
How has a feeder class to be coded? We won’t go into the details of the feeder interface IF_FPM_GUIBB_ATTRIBUTE_FILTER and better refer to the standard document and the video tutorial. But let us just make some few qualitative remarks. Most of the interface methods are pretty standard. In GET_DEFINITION you provide a structure descriptor (RTTI) and field descriptions with fixed values, currency and quantity references and you can indicate which fields allow sort and filter operations and can be counters (such as the LOCCURAM example above). Method FLUSH is just for the event roundtrip – there are no fields to be changed by the user. The main difference to other FPM UIBBs is that the PROCESS_BEFORE_OUTPUT phase is split into three methods instead of a single GET_DATA method. We have a begin and end method. In between the method GET_VALUES is called for each selected attribute, and here the feeder class has to provide the value table packages. For a hard-coded example, you may check the delivered sample feeder class CL_FPM_TEST_ATTR_FILTER_SBOOK which is assigned in test application configuration FPM_TEST_ATTRIBUTE_FILTER.
But do you really need to code an own feeder class? Probably not, since the SADL feeder class CL_FPM_SADL_ATTRIBUTE_FILTER can be configured on any DDIC table with arbitrary joins via foreign key relations, or any CDS view. Even more: We can easily generate an entire Search&Filter UI for that. This is similar as described already for BOPF-based transaction but simpler: We start the FPM Workbench (Transaction FPM_WB) and select the “Wizard for Creating FPM App based on Business Entities”.
We enter an application name, apply a local namespace. Next Step: As Business Entity Source, we select the good-old “Data Dictionary” and as Business Entity we enter “SBOOK”, the good-old flight bookings table. Next Step: We join the “Airline” (table SCARR). Next Step: We select “Add Filter Page” and then the appearing “As Default Page” checkbox. For fun we add a Chart UIBB in stacked layout and do other stuff like this.
Check the preview, go to the next step and save! This is what we get:
Simply cool! Play around with it, select values, test all buttons, navigate to the search page and back – you will enjoy it!
This blog is based on SAP_UI 7.40 SP11 (SAPK-74011INSAPUI).
After having seen this already at TechEd this year this blog is really nice and provides more details. One question though: can you provide some information on the prerequisites, e.g. only 740 running on Hana? Or is a backport to 731 possible in the future?
thanks for the feedback and remarks. Actually I had just added some SP info a few minutes ago but this was probably just a little too late. So the release is indeed 740 with SAP_UI SP11. A downport to 731 is currently not planned. Hana is no prerequisite if you are not using the SADL feeder on the very low 740 SAP_BASIS SPs. Nevertheless the aggregated view of the attribute filter shows optimized performance on big data in conjunction with a Hana DB.
thanks for the quick reply. I saw the SP remark after I posted, so indeed a little too late for my question. Anyway would've asked about a 731 downport. 😉
Some how GET_VALUE is not triggering for me and due to that no data is displayed 🙂 . Any Idea? helpful comments? We have SAP_UI - SP-0012.
method GET_VALUES is only called once the first attribute is selected from the attribute table on the UI.