Every time you deal with GUIBBs that load large amount of data, then asynchronous approaches may help to let the screen be still responsive and more user friendly. Since this topic is frequently discussed in the forum, I decided to describe a possible solution based on the FPM Asynchronous Events and Web Dynpro Notification Service, which was delivered with SAP NetWeaver 731 SP7.
The idea is quite simple: During the initialization phase we register an asynchronous FPM event (e.g. FILL_DATA) via interface IF_FPM and start a RFC function module in a parallel work process, doing the expensive data retrieval. Once this is done, Web Dynpro Notification Service is used to trigger the asynchronous FPM event that brings the data to the user interface.
Let's start with the Feeder Class: At method IF_FPM_GUIBB~INITIALIZE you may apply the following code:
METHOD if_fpm_guibb~initialize. * create event DATA lo_event TYPE REF TO cl_fpm_event. CREATE OBJECT lo_event EXPORTING iv_event_id = 'FILL_DATA'. * source uibb lo_event->ms_source_uibb-component = iv_component_name. lo_event->ms_source_uibb-config_key = is_config_key. lo_event->ms_source_uibb-instance_id = iv_instance_id. * register event DATA(lv_id) = cl_fpm_factory=>get_instance( )->register_asynchronous_event( lo_event ). * create id (char32) for task mv_task = 'TEST_FILL_DATA_ASYNC'. * get data in new task CALL FUNCTION 'FPM_TEST_FILL_DATA_ASYNC' STARTING NEW TASK mv_task CALLING fill_data ON END OF TASK EXPORTING iv_notification_id = lv_id EXCEPTIONS OTHERS = 1. ASSERT sy-subrc EQ 0. ENDMETHOD.
whereas the class attribute MV_TASK is of type CHAR32.
Next you have to define a public feeder method (e.g. FILL_DATA) that acts as callback to bring the results of the parallel work process into the feeder instance:
METHOD fill_data. CHECK mt_data IS INITIAL AND p_task EQ mv_task. RECEIVE RESULTS FROM FUNCTION 'FPM_TEST_FILL_DATA_ASYNC' IMPORTING et_data = mt_data EXCEPTIONS OTHERS = 1. ASSERT sy-subrc EQ 0. ENDMETHOD.
The feeder method GET_DATA (in this case for a Chart UIBB) may look like this:
METHOD if_fpm_guibb_chart~get_data. * disable actions at fpm start IF io_event->mv_event_id EQ cl_fpm_event=>gc_event_start. set_action_usage( EXPORTING iv_enabled = abap_false CHANGING ct_action_usage = ct_action_usage cv_action_usage_changed = ev_action_usage_changed ). ENDIF. CHECK iv_raised_by_own_ui EQ abap_true. * set data io_chart_data->get_table_model( )->set_data( mt_data ). * enable actions set_action_usage( EXPORTING iv_enabled = abap_true CHANGING ct_action_usage = ct_action_usage cv_action_usage_changed = ev_action_usage_changed ). ENDMETHOD.
Here the GUIBB specific toolbar actions are being disabled at FPM_START and enabled once the table MT_DATA has been filled.
Last but not least we have a look in the RFC enabled function module FPM_TEST_FILL_DATA_ASYNC. Once all data are available, the Web Dynpro Notification Service (Method UPDATE_EVENT_STATUS) is used to trigger the asynchronous FPM Event on the client side.
FUNCTION fpm_test_fill_data_async. *"---------------------------------------------------------------------- *"*"Local Interface: *" IMPORTING *" VALUE(IV_NOTIFICATION_ID) TYPE WDR_NOTIFICATION_ID OPTIONAL *" EXPORTING *" VALUE(ET_DATA) TYPE FPM_T_CVOM_DATA *"---------------------------------------------------------------------- * get data CALL FUNCTION 'FPM_TEST_FILL_DATA' IMPORTING et_data = et_data. * delay: just for simulating an expensive data load WAIT UP TO 5 SECONDS. * inform notification service IF iv_notification_id IS SUPPLIED. cl_wd_notification_service=>update_event_status( EXPORTING event_id = iv_notification_id event_status = cl_wd_notification_service=>c_status_done ). ENDIF. ENDFUNCTION.
The above described solution is used also in test application configuration FPM_TEST_CHART_ASYNC_LOAD, which comes with SAP NetWeaver 751 SAP_UI SP0. Here you will find also a WebSocket based approach that is provided with our brand new ABAP Push Channel for FPM Events that will be described in this forum soon 
Thanks for your attention!