Getting Started with the Floorplan Manager
In this tutorial i explain how to simply create your first application with the Floorplan Manager(FPM) based on web dynpro ABAP.
We create a simple selection and show the results in a list UIBB. For the data exchange between the two GUIBBs we use eventing. The data come from the well known sflight table.
1. Create empty application
Open tool for creating FPM-applications (SE80 -> Web Dynpro[right click] -> Create -> FPM-application) or TCODE: FPM_WB
Now we save our new application (local or in a package and select transport request if needed)
now we could test your empty application, but at for now this is senseless so we should edit the configuration in FLUID.
Now we can insert a title for our application. Maybe “My first steps with the Floorplan Manager”? 🙂
2. An easy list
Before we can add our list to the Floorplan we must create a feeder class for the list,
so that the list knows what data to show, how to display this data and some other things.
You can do thas in Eclipse, or in SE24(oldschool:-)).
But as more developers (still) use SE24 to do that i decided also to use SE24 for this tutorial.
In our class we must implement the Interface IF_FPM_GUIBB_LIST
Now we must create all methods by clicking on them or using quick help in Eclipse.
2.1 Define table form
Now we have to define how the list in our application should look like. We do that in the get_definition method ouf our class.
DATA lt_sflight TYPE STANDARD TABLE OF sflight. DATA ls_field_description LIKE LINE OF et_field_description. eo_field_catalog = CAST #( cl_abap_tabledescr=>describe_by_data( p_data = lt_sflight ) ). DATA(lo_sflight_line_descr) = CAST cl_abap_structdescr( eo_field_catalog->get_table_line_type( ) ). LOOP AT lo_sflight_line_descr->components ASSIGNING FIELD-SYMBOL(<ls_sflight_line_descr>). ls_field_description-name = <ls_sflight_line_descr>-name. ls_field_description-allow_aggregation = abap_true. ls_field_description-allow_filter = abap_true. ls_field_description-allow_sort = abap_true. APPEND ls_field_description TO et_field_description. ENDLOOP.
now we could show an empty list. Wow 🙂
2.2 Fill list with data
Before we add our list to the Floorplan, we must fill it with data. We do that in the get_data method.
data lt_sflight TYPE STANDARD TABLE OF sflight. select * from sflight into corresponding fields of TABLE lt_sflight. ct_data = lt_sflight. ev_data_changed = abap_true.
2.3 Add list to Floorplan
Now we have done the magic and only have to add our list to the Floorplan. We do that in the FLUID.
Select list component.
Now we must define a configuration for the list and add a title for it. We must click on save and select “create configuration” on top right
or select the wrench on top right on the list uibb when hovering it.
Now we must choose a package and a transport request or save it as a local object. We do the last.
Finaly we can choose our feeder class. We insert the name of our created class and click enter.
Now we have to select the columns we want to show in the list.
Then we save the application and if we test it (directly in SE80 or if we choose “Test” on
additional features on top right in the fluid) we see our list works 🙂
2.4 Filter, group, search…
We have done the most in our get_definition method. Now we must activate the functions in FLUID.
3. Search and eventing
We must create a feeder class again and have to implement the interface IF_FPM_GUIBB_SEARCH for the search.
We only had to implement get_defiinition method for the beginning.
DATA ls_sflight TYPE sflight. eo_field_catalog_attr = CAST #( cl_abap_structdescr=>describe_by_data( ls_sflight ) ).
Now we must add a search-UIBB to the Floorplan according to the same principle than we do with our list. In the component configuration of our list we choose the search fields and save.
Now we have a searchmask in our application.
The last step is the communication between searchmask and the list. The best variant to do that is the eventing(my opinion :-)). If you click on the search button an event gets fired and then gets collected by the list. We can attach data to the event like our search criteria.
Now we must expand our feeder class for the list.
DATA mo_field_catalog TYPE REF TO cl_abap_structdescr.
DATA mo_field_catalog TYPE REF TO cl_abap_structdescr.
DATA lt_where_string TYPE rsds_where_tab. IF io_event->mv_event_id = 'FPM_EXECUTE_SEARCH'. DATA(lo_fpm_event_params) = NEW cl_fpm_parameter( ). TRY. cl_fpm_guibb_search_conversion=>to_abap_select_where_tab( EXPORTING it_fpm_search_criteria = it_fpm_search_criteria iv_table_name = 'SFLIGHT' io_field_catalog = mo_field_catalog IMPORTING et_abap_select_table = lt_where_string ). CATCH cx_fpmgb. RETURN. ENDTRY. lo_fpm_event_params->if_fpm_parameter~set_value( EXPORTING iv_key = 'SEARCH_CRITERIA' iv_value = lt_where_string ). DATA(lo_fpm_event) = NEW cl_fpm_event( iv_event_id = CONV #( 'EV_SEARCH_CRITERIA' ) io_event_data = lo_fpm_event_params ). DATA(lo_fpm) = cl_fpm=>get_instance( ). lo_fpm->raise_event( io_event = lo_fpm_event ).
Now the event gets fired if a an user clicks on “Search”. But now we must collect the event in our list and use the search criteria for our selection. We must expand our get_data method for the list.
data lt_sflight TYPE STANDARD TABLE OF sflight. data lt_where_tab TYPe rsds_where_tab. if iv_eventid->mv_event_id EQ 'FPM_START'. select * from sflight into corresponding fields of TABLE lt_sflight. ct_data = lt_sflight. ev_data_changed = abap_true. "Nach jeder Datenänderung muss das Event auf true gesetzt werden elseif iv_eventid->mv_event_id EQ 'EV_SEARCH_CRITERIA'. CLEAR ct_data. iv_eventid->mo_event_data->get_value( EXPORTING iv_key = 'SEARCH_CRITERIA' IMPORTING ev_value = LT_WHERE_TAB ). select * from sflight into corresponding fields of TABLE lt_sflight where (lt_where_tab). ct_data = lt_sflight. ev_data_changed = abap_true. endif.
Now if the search is excecuted the list could change its result based on the search criteria and the result looks like this.