ABAP Development: HowTo handle frontend events

The Visual business frontend component will fire events to be handled in the backend in order to allow the application to react on user actions. The central place which receives all events first is the control adapter. It decodes the event data which is transferred as a XML document and triggers the followup processes. The event data consists of two major parts:

• the event it self with source object information and related data and
• all data changes that happened on the frontend until the event was raised.

In cases changed data was submitted with the event those changes get published with event DATA_CHANGED of the control adapter IF_VBI_CONTROL_ADAPTER. This event needs to handled by the application in order to accept the changes on the backend. Changes are kept on the frontend (and get re-send) until a new object state is provided from the backend. The latter happens automatically when you update an object in the scene manager.

Note

For performance reasons the frontend sends only the actually changed fields. Thus many fields in the tables published with the DATA_CHANGED event are empty. The information about the actual changed fields is given in sub-table CHANGED_FIELDS for each entry in the object tables coming as event data.

Currently the only change in the native client is the change of the selection state. For that change it is not required to listen to the DATA_CHANGED event, since it is also published as SELECT event.

After processing the data changes the actual event is decoded and published. The publishing sequence is as follows:

• the control adapter raises event CONTROL_EVENT with the event data
• this event is handled by the application class passing the event on to the service provider method IF_VBI_SERVICE_PROVIDER~HANDLE_SCENE_EVENT first
• in case the service provider does not confirm the handling (by setting CV_EVENT_HANDLED = ABAP_TRUE) the application class call one of its sub-event handlers:
  • GET_DETAILS
  • GET_CONTEXT_MENU
  • HANDLE_DRAG_DROP
  • HANDLE_FCODE
• if the sub-handler does not confirm the handling the event is passed on further by raising event APPLICATION_EVENT. This event is handled intended to be handled by the surrounding UI technology, WDA or FPM, and to be published further in the technology specific format, e.g. as WDA event of the component controller or as FPM event.

Details on how to handle certain events can be found in separate HowTo's.

UI independent event handling

According to the event handling sequence given above you can handle events either you own service provider specialization or in you application specialization. In the first case you have to redefine method IF_VBI_SERVICE_PROVIDER~HANDLE_SCENE_EVENT. The base class implementation handles already the following events:

• Object Select / Deselect
• Object delete
• Display Scene
• Clear Scene

In case you don't want to handle those event one you own make sure to call the super implementation.

Hint

All predefined scene events are available as constants in interface IF_VBI_CONST structure attribute GC_EVENT.

If you decide to handle events in a derived version of the application class you can first redefine the above mentioned sub-handler methods GET_DETAILS, GET_CONTEXT_MENU, HANDLE_DRAG_DROP, and HANDLE_FCODE. The latter gets all event IDs which are not covered by the first three or the service provider. It is mainly intended for handling application specific event ID belonging to context menu functions. If you need more control about the event handling you can also redefine application class method HANDLE_EVENT. This allows you also to bypass the service provider.

Native WebDynpro application

When embedding the Visual Business reuse component in a native WebDynpro application you can register for the events fired by the component controller of the component VBI_WD_VISUAL_BUSINESS.
The events are:

• APPLICATION_LOADED - fired after the initialization of the Visual Business frontend control. At this event you may add an initial set of object to the map.
• CONTEXT_MENU_REQUEST - fired when the user request a context menu (via right mouse click)
• DETAIL_REQUEST - fired when the user requests a detail window for an object (via double click).
• DROP - fired when the user drags an object to another compatible object and drops it there.
• FCODE_SELECT - fired if the user selects an entry from a context menu or press a link / button on the detail window.

Most of the events have parameters, which provide further details on the event.