Showing the pop-ups/dialog boxes for information, confirmation etc in WDA HCMPF is tricky. We have to spend some time and also have to understand the HCMPF framework for showing the popups. So I thought its better to have a wiki which could help the community.

         Initially I was under impression that the new WDA HCMPF framework doesn’t support the pop ups but by digging little deep I understood that I was wrong. I realized there are at least two ways to show pop ups. I will go ahead and will explain both the options. You can use what ever you like.

1. Using FPM to show pop up dialog boxes.

As the WDA HCMPF is based on FPM architecture, we can use the underlying FPM methods to show the dialog boxes. We can use the FPM’s OPEN_DIALOG_BOX method to show informational, confirmation and also can design any other custom dialog box as per the requirement. Here we have the required flexibility in designing our own form for popup.

Here is the sample code:

data lo_fpm type if_fpm.

* Get FPM instance

lo_fpm = cl_fpm_factory=>get_instance( ).

“Show the dialog box

if  lo_fpm is bound .

     lo_fpm->open_dialog_box( ‘<Dialog_box_ID>’ ).

endif.

Using the passed dialog box id, it will open the respective dialog box.

Let’s see where we need to define dialog box.

        The WDA HCMPF uses the application config ASR_PROCESS_EXECUTE_OVP_CFG to show the new WDA Process and Forms applications. If we take a close look at application config, we will understand how to introduce and add the dialog boxes.

ASR_PROCESS_EXECUTE_OVP.jpg

     We need to add our dialog box here. To do this we need to make copy of the application config ASR_PROCESS_EXECUTE_OVP_CFG to ZASR_PROCESS_EXECUTE_OVP_CFG and have to add our required dialog boxes. And then we need to update/configure the launch pad to use the newly created application config for the WDA HCMPF applications.

 

Let see an example of how to add and configure the dialog box in the application config.

a) Go to the newly created config and click add dialog box:

        In the dialog box, we can show different kinds of UIBBs or even we can have the custom WDA application. I have used the From UIBB with component FPM_FORM_UIBB_GL2 so that in case if we have to show any of the HCMPF form fields etc, it would be easy. Also in case if we have to add any custom buttons/events etc, it would be easy to handle from the HCMPF Generic Service.

Agree_Dialog_box_Config.jpg


ZWD_AGREEMENT.jpg

b) Set the properties of the dialog box:

        In screen shot we can see different attributes. Through “Button Sets” we can have different types of predefined button to the dialog box.

Agree_Dialog_Box_Properties.jpg

 

c) Update the launch pad:

        To use the newly created app config ZASR_PROCESS_EXECUTE_OVP_CFG.

Note: In case if we are executing the application directly from the transaction “HRASR_DT”, we have to modify the url to use ZASR_PROCESS_EXECUTE_OVP_CFG instead of ASR_PROCESS_EXECUTE_OVP_CFG

Launch_pad.jpg

       This is how popup will look like:

Popup.jpg

Event Handling:

        Some times, based on the button clicks we might have to perform some actions. So how do we handle the events?

        If we use the default buttons provided by the framework, they just raise the events to close the dialog box and from the HCMPF frame work i.e. from the generic service we will not be able to find which button click was done.

        For handling the dialog box button events, we need to add the required buttons though the design time and associate the buttons with respective user define events. So once we click on the buttons the control would go back to the HCMPF Generic Service and there we can write the required business logic.

Poup_event_handling.jpg

      At the end of the business logic, we need to write the code to close the popup which we have opened. It can be done by raising the even FPM_CLOSE_DIALOG which will close the popup.

if lo_fpm is bound.

    lo_fpm->raise_event_by_id( ‘FPM_CLOSE_DIALOG’ ).

endif.

2. Using NEEDS_CONFIRMATION method of HCMPF feeder class

        SAP uses the needs_confirmation method of feeder class to show the confirmation popups. We can use same method for writing the post exist enhancement to show the pop ups for our custom events. Here we can show only informational or confirmation popups.

Let’s see in detail how to show confirmation popups by enhancing the feeder class. Here we are just going to write a post exit that too without any business logic, until we don’t write any business logic, I think it should be ok to enhance feeder class.


a) Implement post exit for IF_FPM_GUIBB_FORM_EXT~NEEDS_CONFIRMATION in the feeder class CL_HRASR00_FPM_FEEDER

Here is the sample implementation.

data: lt_confirmation_text type string_table,

         lo_confirmation_request type ref to cl_fpm_confirmation_request.

if io_event->mv_event_id eq ‘<event_name>’. “Provide the event name here

      append ‘Do you agree?’ to lt_confirmation_text.

      create object lo_confirmation_request

        exporting

                it_confirmation_text   = lt_confirmation_text

               iv_window_title        = ‘Agreement ‘

               iv_button_text_approve = ‘I Agree’

                iv_button_text_reject  = ‘Cancel’.

      eo_confirmation_request = lo_confirmation_request.

      me->obj->core_object->a_check_fired = abap_true.

      me->obj->core_object->a_data_changed = abap_false.

endif.


b)    Raise the event to show popup

        From the generic service implementation, call the FPMs raise event for showing the confirmation popup. Before raising the event, create the user defined event and provide the required implementation in the generic service for that event.


      Here is the sample implementation:

(While raising the event, we are informing the HCMPF framework that event is raised by the HCMPf Form)

        data: lt_params     type         apb_lpd_t_params,

              ls_param      like line of lt_params,

              io_event_data type ref to  if_fpm_parameter,

              lo_event      type ref to  cl_fpm_event.

        ls_param-key = ‘MS_SOURCE_UIBB-COMPONENT’.

        ls_param-value = ‘FPM_FORM_UIBB_GL2’.

        append ls_param to lt_params.

        ls_param-key = ‘MS_SOURCE_UIBB-CONFIG_ID’.

        ls_param-value = ‘<HCMPF_Fom_Name>’.”Need to give the HCMPF Form name

        append ls_param to lt_params.

        ls_param-key = ‘MS_SOURCE_UIBB-CONFIG_TYPE’.

        ls_param-value = ’00’.

        append ls_param to lt_params.

        io_event_data = cl_fpm_parameter=>create_by_lpparam( it_parameter = lt_params ).

        lo_event = cl_fpm_event=>create_by_id( iv_event_id   = ‘<event_name>’    “Give the event name

        io_event_data = io_event_data ).

        lo_event->ms_source_uibb-component = ‘FPM_FORM_UIBB_GL2’.

        lo_event->ms_source_uibb-config_id = ‘<HCMPF_Fom_Name>’.”Need to give the HCMPF Fomr name

        lo_event->ms_source_uibb-config_type = ’00’.

       lo_fpm->raise_event( io_event = lo_event ).

   Upon raising the event, need confirmation gets invoked and there the framework checks to see if this particular event needs any confirmation, depending upon our post exit implementation, it will show the confirmation dialog. Upon clicking the “I Agree” button, the respective implementation in generic service will get called.

   We can refer to following help.sap.com link to know more about the dialog boxes. http://help.sap.com/SAPhelp_nw73/helpdata/en/23/102a78b5184affbd0da0546f1ebf6a/content.htm?frameset=/en/78/08fcd9fa454adb89792f0556f5d712/frameset.htm

         Also from the FPM Developers guide we can find more information about FPM.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e0d500f5-5205-2e10-43a6-dd023a5d0818?overridelayout=true

To report this post you need to login first.

11 Comments

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

  1. Christopher Solomon

    Late to seeing this one! Very nice! I like how you did it.

    Curiously, I tried something similar in the past….just playing around with “talking” to FPM from my own generic service. I found that in my “initialize” method, I could not get referene to the FPM factory instance. However, I could from “DO_OPERATION” method. My guess is that because the HCM P&F framework has not yet initiated the FPM framework when it initializes our form scenario step that that FPM instance is not actually “alive” yet. Have you seen the same thing?

    You could also just launch a WDA directly in a new window and pass back information too (like doing a F4 to launch a WDA). Then you wouldn’t need a new “ZASR_PROCESS_EXECUTE_OVP_CFG” configuration.

    Keep up the blogging!

    (0) 
    1. Yugandhar Reddy Post author

      Thank you Christopher.

      In the initialize also we should be able to get the FPM reference. I think most likely you might have run the app from the backend transaction, try to launch the app from portal and see, once we launch the app from portal then all the required FPM initializations etc would be done.

      I was able to launch the WDA  as you said from F4 but not from the generic service code, that’s the reason why I had to go for custom config for defining the popup. But in case if we can launch the WDA directly from generic service do let me know, we can update the wiki with that info.

      (0) 
      1. Christopher Solomon

        Hmmmm might be a version difference or something….but yep, no dice getting the FPM instance from “initialize”….but easily done in “do operation”. And yes, tried it both from executing/testing from the app launched from HRASR_DT as well as in the portal directly. Interesting.

        Yes….I can see how you did it out of the backend service and why you did it as you did. Was just offering up another way. Curious though as why you would want to go back through the backend service and not directly launch it from the FPM form? Seems like extra layer to go through but is an interesting way of using a backend service to get it done.

        (0) 
  2. Tal Tzafriri

    Hi,

    It’s a great blog. Thanks! 🙂

    I used option 1 (Using FPM to show pop up dialog box) and it works very well except for transfering events from the pop-up to my generic service.

    As you described, I added the required buttons through the design time of the pop-up and associate the buttons with respective user define events. So once I click on the buttons the control should go back to the P&F generic service and there I can write the required business logic.

    Unfortunately, I found out that these buttons doesn’t trigger my generic service unless I show on the pop-up a mandatory field from my P&F process. If the fields on the pop-up are not defined as mandatory in my P&F process than events from the pop-up don’t trigger my generic service.

    Moreover, also in the case of a mandatory field on the pop-up, after entering value to the field and pressing on the buttons the events doesn’t trigger my generic service.

    Do you have any ideas how to solve it?

    Thanks in advance!

    (0) 

Leave a Reply