Skip to Content

Every time you deal with GUIBBs that show considerable latency in getting the 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 750 SAP_UI SP 5. Here you will find also a WebSocket based approach that is provided with our brand new ABAP Push Channel for FPM Events.

A further improvement comes with SAP NetWeaver 751 SAP_UI SP0. Here you can simply apply a marker interface to asynchronously load any GUIBB 😉

Thanks for your attention!

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

    1. Simon Hoeg Post author

      Hi George,

      the Web Dynpro Notificaion Service polls every 1-2 seconds, so I guess there is no timeout after 30 minutes.But you should verify this in a test application …

      Regards,

      Simon

      (0) 
      1. George Shi

        Thanks for the reply

        We have test a FPM application by calling wait 30s in async FM, after 30 minutes there is no retrun and UI got session time out.

        So my question is what’s the meaning of service polls every seconds, is this behavior that keep refresh the UI to prevent session timeout? or any other parameter profile (ICM/….) we should setup in case our async fm need executed more than 30 minutes?

        (0) 
        1. Simon Hoeg Post author

          Hi George,

          today I tested this with test application FPM_TEST_ASYNCHRONOUS_EVENT via Chrome Browser by entering 1800 seconds (~30 Minutes).

          So this test has been successful, i.e. not timeout after 30 minutes! Can you please verify this on your side?

          In case it does not work, I recommend to create an OSS Message on BC-WD-CMP-FPM. Then we could debug directly on your system.

          Regards,

          Simon

          (0) 

Leave a Reply