Skip to Content
Author's profile photo Uwe Kunath

Perform Save-operations using a wire transaction handler in the FPM


In the previous blog post I figured out how wiring based on business objects might work in the Floorplan manager. The example application provides a Search component to select records based on the table SFLIGHT. Once a result entry has been selected, the flight data record is shown in a detail view below the result list. While the result list is implemented by a List-UIBB, the detail view is implemented by a Form-UIBB.

Any follow-up steps have not been implemented then, this includes also the possibility to save the edited record back to the database.

The subject of this blog post is how a Save-operation could be implemented based on a wire transaction handler.

I decided to not use the interface IF_FPM_TRANSACTION which can be implemented by any UIBB in the application, rather, I decided to use a Transaction Handler for wire models.  The drawback of this approach is that a wire transaction handler cannot serve as a target for wires, hence, has usually no access to Business objects.

One opportunity to pass the business object to the handler might be to share it as a singleton instance. This requires the existence of a registry or any other singleton mechanism. Another possibility is the data exchange based on events.

In this very blog post, the business object is going to be shared as a parameter of the FPM_SAVE- event.

For now, let’s again recap the wires which are in use by the demo application. However besides this introduction it is strongly recommended to read the previous blog post if you did not yet read it.

The existing application

The selection criteria and the selection of the flight list is implemented by the list selection wire (ZCL_FPM_DEMO_WIRE_FLIGHT_SEL which implements ZIF_FPM_DEMOWIRE_SFLIGHT_SEL).

03 - Wires of the application I.png

The selected flight data record is represented by an instance of type ZIF_FPM_DEMO_WIRE_SFLIGHT.

04 - Wires of the application II.png

Both wires have specific operations offered to the UIBBs or OVP Exit which use these wires.


In this blog post, the first wire is going to be extended to hold a lead selection instance of the second wire. The second wire which represents a single flight data record will be enhanced with a Save-operation. In combination with some other changes, this allows the user to edit the flight data and save it back to the database.

Sharing the business object

A new Save-Button will be added to the application’s OVP toolbar.

In order to allow the wire transaction handler to access the business object, the OVP exit will catch  the Save-Event which is triggered by the save- button and will enrich the event data with a new Name-Value Pair which represents an instance of a saveable business object, that is, the wire which represents a single entry of the flight data list (It would be a good idea to work with an abstraction to the specific flight data instance as well, so we can possibly reuse the wire transaction handler later on in another application)

Since the OVP exit has access to the list selection instance only we need to provide access to the selected business object through the list selection wire.

Enhancements to the current application

First of all, we include an OVP-toolbar button to allow the user to trigger the Save-operation.

Save button.PNG

The list selection wire will need to store the selected flight record to allow the OVP Exit to get access to the currently selected record. Therefore the methods GET_LEAD_SELECTION and SET_LEAD_SELECTION  are added to the interface ZIF_FPM_DEMO_WIRE_FLIGHT_SEL which describes, what operations have to be supported by this wire. In the implementing class, a new attribute MO_LEAD_SELECTION is included and the corresponding Getter- and Setter method are implemented.


Now we need to call SET_LEAD_SELECTION in ZCL_FPM_DEMO_FLIGHT_LIST, method IF_FPM_GUIBB_LIST~PROCESS_EVENT, which handles the lead selection event in the list.

METHOD if_fpm_guibb_list~process_event.
  DATA lo_datacontainer TYPE REF TO zif_fpm_demo_wire_flight_sel
  lo_datacontainer ?= mo_connector->get_output( ).
  CASE io_event->mv_event_id.
      CHECK lo_datacontainer IS NOT INITIAL.
      READ TABLE mt_sflight INTO ls_sflight INDEX iv_lead_index.
      IF sy-subrc = 0.
        CREATE OBJECT mo_sflight TYPE zcl_fpm_demo_wire_sflight.
        mo_sflight->set_sflight( ls_sflight ).
        lo_datacontainer->set_lead_selection( mo_sflight ).

The selected flight record is show in the detail section of the screen. Its feeder does not yet have a FLUSH-implementation which needs to be implemented. Its purpose would be to transfer the entered values back to the flight record instance.
Therefore the form feeder class ZCL_FPM_DEMO_FORM_SFLIGHT_DET receives a FLUSH-method implementation:

METHOD if_fpm_guibb_form~flush.
  CHECK mo_connector IS NOT INITIAL.
  mo_sflight ?= mo_connector->get_output( ).
  CHECK mo_sflight IS NOT INITIAL.
  FIELD-SYMBOLS <ls_data> TYPE any.
  ASSIGN is_data->* TO <ls_data>.
  DATA ls_sflight_key LIKE ms_sflight.
  MOVE-CORRESPONDING <ls_data> TO ms_sflight.
  MOVE-CORRESPONDING <ls_data> TO ls_sflight_key.
  ms_sflight-carrid = ls_sflight_key-carrid.
  ms_sflight-connid = ls_sflight_key-connid.
  ms_sflight-fldate = ls_sflight_key-fldate.
  mo_sflight->set_sflight( ms_sflight ).

Now, the OVP exit has also access to the currently selected flight record instance through its configured list selection wire. The OVP exit is implemented by the webdynpro component ZWDYN_FPM_FLIGHT_OVP_EXIT. The implementation of method OVERRIDE_EVENT_OVP now needs to try to read the flight record instance from the wire model and enrich the Save-Event with the flight record data object. Please note that we pass an instance of type ZIF_FPM_DEMO_SAVEABLE rather than ZIF_FPM_DEMO_WIRE_SFLIGHT.

METHOD override_event_ovp.
 wd_this->mo_ovp = io_ovp.
  DATA lo_event TYPE REF TO cl_fpm_event.
  DATA: lo_datacontainer TYPE REF TO zif_fpm_demo_wire_flight_sel,
        lo_saveable TYPE REF TO zif_fpm_demo_saveable.
  DATA lv_port_identifier TYPE fpm_model_port_identifier.
 lv_port_identifier = zif_fpm_demo_wire_flight_sel=>gc_name.
  lo_event = io_ovp->get_event( ).
  CASE lo_event->mv_event_id.
    WHEN if_fpm_constants=>gc_event-save OR if_fpm_constants=>gc_event-save_and_back_to_main.
 lo_datacontainer ?= wd_this->mo_feeder_model->get_outport_data( iv_port_type = 'LS' iv_port_identifier = lv_port_identifier ).
          CHECK lo_datacontainer IS BOUND.
          lo_saveable ?= lo_datacontainer->get_lead_selection( ).
 lo_event->mo_event_data->set_value( iv_key = zif_fpm_demo_saveable=>gc_event_parameter_id iv_value = lo_saveable ).
        CATCH cx_sy_move_cast_error.

ZIF_FPM_DEMO_SAVEABLE serves as a generic interface for a save operation. It is implemented by the wire which represents the flight record (ZCL_FPM_DEMO_WIRE_SFLIGHT)


The class ZCL_FPM_DEMO_WIRE_MODEL_TRANS serves as the application wire transaction handler. It implements the standard FPM interface IF_FPM_WIRE_MODEL_TRANSACTION and therefore takes part in the event loop. The method AFTER_PROCESS_EVENT is implemented and handles the SAVE-Event which will later on be triggered once the Save-Button has been pressed. The method implementation tries to read an instance of type ZIF_FPM_DEMO_SAVEABLE from the event data and eventually call the SAVE-Method.

METHOD if_fpm_wire_model_transaction~after_process_event.
  DATA: lo_savable TYPE REF TO zif_fpm_demo_saveable.
  CASE io_event->mv_event_id.
    WHEN if_fpm_constants=>gc_event-save OR if_fpm_constants=>gc_event-save_and_back_to_main.
 EXPORTING iv_key = zif_fpm_demo_saveable=>gc_event_parameter_id
 IMPORTING ev_value = lo_savable ).
          CHECK lo_savable IS NOT INITIAL.
 lo_savable->save( ).
        CATCH cx_sy_move_cast_error.

Once the transaction handler class has been implemented, we register the transaction handler in the OVP-Component FPM_OVP_COMPONENT, Configuration ZFPM_DEMO_OVP_FLIGHT_SEARCH

Register wire transaction model.PNG

Why should we not simply enhance the OVP-Exit?

The reason why I didn’t just implement the Save-operation directly in the OVP-Exit is the Separation of concerns design principle.

In the case of having an exit only and no transaction handler, the OVP Exit would have to evaluate the save event and trigger the SAVE-Method, besides its task of updating the OVP floorplan title with the number of results. Also, an OVP Exit is not reusable in OIF or GAF floorplans, and this would also apply to its transaction logic, if coupled too strongly.

Right now, with the current implementation, it only does, what an exit is intended to do: It catches certain events like the Save-event and enriches it with some data, if necessary. The actual SAVE-Method call is triggered by another component which actually does not care about how or by whom the  event has been enriched – it just expects the business object along with the event data. This decouples the execution of the SAVE-Command from other aspects of the application and eventually leads to a better design and maintainability. There is no real benefit yet, but in case a more complex transaction logic would be needed, we could easily provide the implementation of these aspects, like commits or rollbacks, in a specific transaction handler, not within the OVP Exit.

Download the nugget file here

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Aliaksandr Shchurko
      Aliaksandr Shchurko


      Author's profile photo Former Member
      Former Member

      Really nice article.  I am interested in the nugget sample file provided to further explore.  I have installed and ran the SAPLink program to import but am getting an error on both this and the previous related article.  Has anyone else experienced this and have a solution?

      Author's profile photo Uwe Kunath
      Uwe Kunath
      Blog Post Author

      Dear Rene, does it work with this newer version?

      Author's profile photo Former Member
      Former Member

      Thanks for the reply Kunath, I tried this version you supplied and get the same issue.  The first two classes (zcl_fpm_demo_flight_list and zcl_fpm_demo_flight_search) are installed successfully but then get the message "ouch, your pants are on fire..better go get help".

      I took the liberty and debugged a bit and found the following.  I posted my results in Code Exchange under the SAPLink project.  I hope it's useful to you.

      Author's profile photo Uwe Kunath
      Uwe Kunath
      Blog Post Author

      Rene, thank you. There was an export error with SAPLink. Try this out:

      You will need to active non-webdynpro-component interfaces first, then continue with the classes. As SAPLink import certain method implementations multiple times, wich leads to activation errors, you will neede to remove duplicate ones manually in the code perspective of the respective class.

      Author's profile photo Former Member
      Former Member

      Thanks again Kunath, this version I was able to import successfully.  I did have some issues with duplicate methods but I believe I got rid of them since I was able to activate the problem classes. 

      I do have another question, as this line was preventing me from activating the web dynpro components.  In the ZWDYN_FPM_DYNAMIC_CONTAIN component-componentcontroller-create_component method (and one other area, I don't recall right off top) there is a DATA declaration that has a type ref to that is not recognized nor could I find any reference anywhere but it doesn't seem to be used anywhere.

      DATA lo_conf TYPE REF TO /leos/cl_comp_config.

      I only ask because when I run the application and click the "Flight demo" button, nothing seems to happen and I wanted to be sure that this declaration I commented out wasn't part of the issue.

      Thanks again!

      Author's profile photo Uwe Kunath
      Uwe Kunath
      Blog Post Author

      Thank you Rene,

      You are absolutely right that this decalarations are never used. When you press "Search" in the Search-UIBB, the Method ZIF_FPM_DEMO_WIRE_FLIGHT_SEL~APPLY_SELECTION of class ZCL_FPM_DEMO_WIRE_FLIGHT_SEL needs to be invoked. Selection criteria must not be initial. If not, check if ZCL_FPM_DEMO_FLIGHT_LIST, Method IF_FPM_GUIBB_LIST~PROCESS_EVENT invokes this method properly. If not, there might be a wiring issue which needs to be solved by you according to the blog post as SAPLink might have missed to transport some settings...

      Author's profile photo Former Member
      Former Member

      Thanks so much for your assistance Kunath!  Worked through this (and learned in the process) and got it working.  I will be showing this to my peers who are interested in wiring for our project.  🙂

      Author's profile photo Former Member
      Former Member

      Hi Kunath,

      I have a scenario in ESS where I need to add a freestyle standard webdynpro component  to a OVP Model with 3 UIBB's. The Standard Webdynpro component is for adding Multiple attachments to the Content Server.

      I added the WD Component as a 4th UIBB and created the Wire for the same, For Connector Class, I have given the same class which the other 3 UIBB's are using. I am Not sure what to give in the wire model parameter under ( Connector Parameters - First Level Relation Name )


      I am able to see the same once it is executed, but once I add the attachments and click on the save button, I don't think the main Component is considering the one which I added. Please suggest me if I need to write any code to connect the same with the existing 3 UIBB.

      Thanks in advance.

      Author's profile photo Alfredo Gomez Ripoll
      Alfredo Gomez Ripoll

      I´ve been trying to make this good practice to work in my 7.03 trial versión but I can´t continue and I don´t know if the reason is that it´s not posible to do it with the trial versión or what .

      With SAPLINK ( I think I´ve downloaded the last versión ; in the selection screen it´s written SAPLINK 0.1.3 , however I´ve installed it from the file saplink_install-01.5alpha) I had the problem that was not posible to extract the freestyle wd ZWDYN_FPM_FLIGHT_OVP_EXIT in the trial , the error is:

      " UIBB key is not valid ( component ZWDYN_FPM_FLIGHT_OVP_EXIT , config ID ZWDYN_FPM_FLIGHT_OVP_EXIT , Instance ID ) .

      Then I decided to integrate it manually with the other 3 GUIBB (which were downloaded correctly) ; to do so I´ve created the wd component ZWDYN_FPM_FLIGHT_OVP_EXIT , added interface IF_FPM_UIBB_MODEL to get in the component controller the method GET_MODEL_API where , if I´m not wrong , I should obtain variable wd_this->mo_feeder_model which it´s used in method after_process_event .

      To obtain such variable I´ve found this example in SDN:

      if wd_this->mo_feeder_model is initial .

      * Create wire feeder model

      wd_this->mo_feeder_model = /plmu/cl_frw_Factory=>get_wire_model(

          iv_abbid = 'MY_ABBID'

          io_component_controller = wd_this ) .

      endif .

      * Return wire feeder model

      ro_feeder_model = wd_this->mo_feeder_model .

      When trying to use class /plmu/cl_frw_Factory I´ve found that it doesn´t exist in the trial versión (It´s part of component SAP_BS_FND which it´s not included in 7-03 trial) .

      The question is:

      ¿I´m doing it correctly and it´s not posible to make it work this practice in the trial versión without installing SAP_BS_FND , for what I haven´t the permissions to download from Marketplace?


      ¿is there any alternative way to obtain wd_this->mo_feeder_model which doesn´t use class /plmu/cl_frw_Factory (and that I could see in wd component ZWDYN_FPM_FLIGHT_OVP_EXIT if i had been able to extract it with SAPLINK) .

      The exercise is excellent to learn the wiring between the standard GUIBB using objects , Thank you very much Mr. Kunath for the work .

      Author's profile photo Uwe Kunath
      Uwe Kunath
      Blog Post Author

      looks like something went wrong. Your proposed fix to get the connector output won't work. Please let me know your email adress and I'll send you a transport request...

      Author's profile photo Alfredo Gomez Ripoll
      Alfredo Gomez Ripoll

      Being rigorous previous comment should have been included in the blog "Wiring based on Business Objects in Floorplan Manager" ;  the after_process_event method mentioned in that previous comment is the one mentioned in the blog "Wiring based on Business objects in Floorplan manager".

      Author's profile photo Alfredo Gomez Ripoll
      Alfredo Gomez Ripoll

      Thank you very much Mr.  Kunath ,

      I´m looking forward to seeing the solution .

      my email:

      Maybe I wrote too son the coment , because, later on, while tring to find myself an alternative I found the thread:

      where it´s proposed one solution based on the use of an assistance class ( implementing IF_FPM_FEEDER_MODEL ) in the freestyle wd component and I was just now trying to check .

      Thank you very much for your kind help and have a happy new year 2014 ¡¡