** TEAM FPM ** – A new marker interface to asynchronously load GUIBBs

Long loading times of GUIBBs can undermine the overall performance of an application. If you have to deal with GUIBBs that show a considerable latency in getting the data, then asynchronous approaches may help to let the screen be still responsive and more user friendly.

In one of my last blogs I described a procedure that used the Floorplan Managers Asynchronous Events, which was delivered with SAP NetWeaver 731 SP 7.

This time I will briefly sketch another possibility that you may use from SAP NetWeaver 751 SAP_UI SP 1. It is based on the new feeder marker interface IF_FPM_GUIBB_ASYNC, that will initialize the GUIBB in a parallel work process, in which expensive tasks can be outsourced.

As prerequisite the web browser must meet the HTML5 WebSocket standards. Furthermore, verify that ICF Service FPM_APC has been activated in transaction SICF.

The Feeder class undergoes a serialization when asynchronous loading is started, and another deserialization when the asynchronous loading is finished. Mind that data references are not considered during the serialization and deserialization.

The feeder interface IF_FPM_GUIBB_ASYNC offers two methods:

Method IS_ASYNC

In this method you can indicate the level of asynchronism with returning parameter RV_IS_ASYNC. Domain FPMGB_ASYNC_LEVEL offers three possible values:

• 00: No Asynchronism
• 01: Level 1
• 02: Level 2

The asynchronous level defines the point in time at which the method GET_DATA of interface IF_FPM_GUIBB_ASYNC is called in a parallel work process. See further details below.

The decision whether a GUIBB should be asynchronously loaded (or not) might depend on a current context. For this you may use the following importing parameter: IT_PARAMETER (Parameter Values), IV_COMPONENT_NAME (Component Name), IS_CONFIG_KEY (Configuration Key) and IV_INSTANCE_ID (Instance ID).

Method GET_DATA

This method is called in a parallel work process.

Here you can implement an expensive data processing and/or data retrieval. The result can be the basis for the first rendering of a GUIBB or it can serve as a pre-processor for the later process before output.

The obtained data can be persisted as class attribute of an elementary type, structure or internal table. If you decide for a data object, then it should be marked with interface IF_SERIALIZABLE_OBJECT.

Levels of Asynchronism

There are currently two asynchronous levels that are being supported (see Figure below):

• Level 0 means that there is no asynchronism. It results in the standard sequence of Feeder methods calls during initialization of a GUIBB.
• Level 1 means that the parallel work process is started before method INITIALIZE (interface IF_FPM_GUIBB) is being called.
• Level 2 means that the parallel work process is started after method INITIALIZE (interface IF_FPM_GUIBB) is being called.

Figure 1: Asynchronous levels and the associated sequence of feeder method calls

During the asynchronous state, i.e. while method GET_DATA of interface IF_FPM_GUIBB_ASYNC runs in a parallel work process, the GUIBB is visualized with text “Loading Data  …”.  In addition all events from the FPM Event Loop are not propagated to the GUIBB. When the asynchronous loading is finished, then FPM event FPM_ASYNC is raised for the corresponding source GUIBB. From this time the GUIBB takes part in the FPM Event Loop, so you may interpret the FPM_ASYNC event as a kind of FPM_START event.

Demo Applications

There are a couple of demo application configurations that you may try, e.g.:

• FPM_TEST_CHART_ASYNC_LOAD
• FPM_TEST_GUIBB_LIST_ATS_ASYNC
• FPM_TEST_FORM_GL2_EDIT_MODE_AS

Figure 2: Demo application FPM_TEST_CHART_ASYNC_LOAD