HCM Processes & Forms: The Secrets of Search Helps and OADP….REVEALED! – part 4
This is the continuation of the previous blog (part 3) where we finished our discussion of OADP configuration.
Search Help WebDynpro ABAP components and usage in HCM P&F Forms
Each HCM P&F “search help” is actual a WebDynpro ABAP component. For our example , we are looking at the search help used for “Org Unit”. This is WDA “HRASR_C_ORGUNIT”.
HCM P&F Search Help WDA Components
Within the Component Controller of each “search help”, you will see a method GET_ORGVIEWGROUP . This is what sets the value for “which” OADP Organizational View Group to use for the OADP component.
method GET_ORGVIEWGROUP .
orgviewgroup = ‘ASR_ORG_SEARCH’.
The Component Controller calls this method before it sets up the OADP Component and calls it as a pop-up window in the method call_popup.
The view ORG_SEARCH subscribes to the button event “OK” of the pop-up window in its initialization method WDDOINIT. When the user makes a selection in the pop-up and clicks the “OK” button, this view then picks this up in the method ONACTIONOK where it then “sees” which Org Unit was selected to then set in the context binding. This is how it “sets” the values of what the user selected back into the context to then go back to the form….that is “if” the user put the correct fields on their form…more on that in a bit. But how does this pop-up window know to “pop up a window” and “what” to put in it?
The Mystery of the HRASR_FORM_WINDOW
But how is the pop-up window triggered? All search help WDA components we write must implement the interface IF_HRASR00_FORM_WINDOW. This interface has ONE simple method…CALL_POPUP. This is the same method we redefined in our Component Controller. But how is this called?
In our ISR interface for our Adobe Interactive Form, we define a “special field”, HRASR_FORM_WINDOW as…
(*Note, you can not add HRASR_FORM_WINDOW directly into your Form Scenario fields via transactionHRASR_DT as you will get this error:
At the same time, when you go to “synch” your Form Scenario fields to your ISR Scenario, your ISR interface will be overwritten. You will then have to manually go back into your ISR interface, add the field, active the interface, then go into your form and make sure the field is in your form context as well. If not…which is usual…you need to manually select from your ISR interface context and “drag” it over to your form context. Sounds fun eh!?!?! haha)
Then in our form itself, we will define a “button” next to the field we want to use for a “Search Help”. For example,
This button has special scripts in the “mousedown” event.
$record.CONTROL_PARAM.ISR_EVENT = “USER_EVENT_POPUP”
$record.HRASR_FORM_WINDOW.DATA[*].FIELD.value = “HRASR_C_ORGUNIT”
So, when the user clicks the button, we are simply filling the “HRASR_FORM_WINDOW” field with the name of our search help WDA component. The WDA HRASR00_PROCESS_EXECUTE application’s FORM_EDIT controller’s method WDDOMODIFYVIEW handles the HCM P&F events and in this case, it handles the “USER_EVENT_POPUP”.
METHOD wddomodifyview .
DATA component_name TYPE string.
CONSTANTS hrasr_form_window TYPE qisrdfieldname VALUE ‘HRASR_FORM_WINDOW’.
CONSTANTS user_event_popup TYPE string VALUE ‘USER_EVENT_POPUP’.
CONSTANTS user_event_check TYPE string VALUE ‘USER_EVENT_CHECK’.
It gets the WDA component name we passed in the “HRASR_FORM_WINDOW” name.
* Evaluate name of search component
component_name = wd_comp_controller->isr_interface->get_special_data_with_index(i_fieldindex = 1 i_fieldname = hrasr_form_window ).
Now, since any search help WDA we create must implement the “CALL_POPUP” method, it simply takes the name of the WDA component we passed (HRASR_C_ORGUNIT) and calls the CALL_POPUP method.
* Launch popup and Initialize variable for help component name so
* that help popup is only launched once.
i_fieldindex = 1
i_fieldname = hrasr_form_window
i_fieldvalue = space ).
wd_comp_controller->raise_popup( component_name = component_name ).
Which in turn calls…
if_form_window->call_popup( EXPORTING special_data = special_data ).
This in turn fires our Component Controller’s method CALL_POPUP to implement it as we wanted.
(* side note class CL_WDR_CLIENT_ABSTRACT_HTTP method HANDLE_REQUEST is also called in this stack and has the funny piece in it….
application_name = if_wdr_client~application_name
appl_props = m_appl_props_tmp
cl_wdr_client_ssr=>todo_cleanup( ‘Evil hack because of missing support in RR_APPLICATION’ ).“#EC NOTEXT
data pers_service type ref to cl_wdr_personalization_service.
….so “some” people at SAP do in fact have a sense of humor!)
How does the selection get onto the form?……..Form Field Bindings
Earlier, we talked about how our Search Help WDA Component “view” will “listen” for the “OK” button event (meaning the user picked something) and will then set the “context bindings” to then show the selected fields on the form.
So now the pop-up window fires for us for the Search Help, but how does the data get back onto our form? Well, this one was not obvious to me at first. It took some digging but I noticed something “curious” in the sample processes SAP uses search helps in themselves. When I looked back at the component/view contexts of the WDA search help Component “HRASR_C_ORGUNIT”, I noticed:
Then on the form, I noticed two fields defined there with bindings to “form fields” defined in the form scenario:
So THAT is the ONLY link. The form must have fields defined and bound to the same names used in the context of the Search Help WDA. Because of the binding, as the WDA fills the context based on the user’s selections, the form fields will then pick these up automatically.
In Part 5, we discuss the OADP Webdynpro ABAP component that is used within all of the standard HCM P&F search helps…