Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member182421
Active Contributor
4,480
ComponentSupport Package
BBPCRMSAPKU70204
SAP_ABAPSAPKA73105
SAP_BASISSAPKB73105
WEBCUIFSAPK-73105INWEBCUIF

SAP_BW

SAPKW73105

Before start, sorry for awful look of the code snippets, SAP is currently working on this: Re: Why does the syntax highlighting not work

The Scenario

We want to set default values as search criteria and we can't implement the note 2045936 - Default Values for Advanced Search Pages (which looks very promising, but lit's not compatible with my current release :sad: )

What, Where and How

That's the most difficult part, decide what to do and most important WHERE, once you got that, the How comes alone, I will focus on a specific scenario because I don't want to transform this blog in a philosophical thing, but between me and you, it is :wink: .

The Example

Let's enhance the BP search (BP_HEAD_SEARCH) to don't show the "set to archive"  BPs, as I see it right know you have at least 3 options:

Use a BADI enabled for the search (BADI_CRM_BUPA_IL_SEARCH_EXT)

I always choose the BADI as long as is possible, don't forget the UI is the technology which is evolving faster, specially in latest years, Imagine tomorrow SAP decide to replace the whole WebUI for a SAP Fiori ecosystem, you will need to place, so why we don't use always the BADI approach? in this scenario the filter will be totally transparent to the user and this can be good or bad: "why this is giving no results?"

Another consideration before going straight to the BADI method is evaluate the performance, my selection should be performed before the standard? after? and that depends on the detail of the BADI, in our example, the BADI is called before the standard selects any data.

Enhance the WebUI controller method (CL_BP_HEAD__MAINSEARCH/DO_PREPARE_OUTPUT)

For the scenario which I described, the best solution, easy to maintain and user friendly, he or she can decide which criteria to use before the search. Important: don't forget to update the context node  me->typed_context->search->build_parameter_tab( ). otherwise the BOL changes won't be published and you will lose the information.


DATA: lo_qs              TYPE REF TO cl_crm_bol_dquery_service,
           lo_qs_col        TYPE REF TO if_bol_bo_col,
           lo_iterator      TYPE REF TO if_bol_bo_col_iterator,
           lo_param_ent TYPE REF TO if_bol_bo_property_access.
   super->do_prepare_output( EXPORTING iv_first_time = abap_false ).
   IF iv_first_time = abap_true.
     lo_qs ?= me->typed_context->search->collection_wrapper->get_current( ).
     lo_qs_col ?= lo_qs->get_selection_params( ).
     lo_iterator = lo_qs_col->get_iterator( ).
     lo_param_ent = lo_iterator->find_by_property( iv_attr_name = |ATTR_NAME|
                                                                               iv_value       = |XDELE| ).
     IF lo_param_ent IS BOUND.
       lo_param_ent->set_property( EXPORTING iv_attr_name = |SIGN|
                                                                             iv_value         = |I|   ).                                   
       lo_param_ent->set_property( EXPORTING iv_attr_name = |OPTION|
                                                                             iv_value         = |EQ|   ).
       lo_param_ent->set_property( EXPORTING iv_attr_name = |LOW|
                                                                             iv_value         = |N|   ).
       me->typed_context->search->build_parameter_tab( ).
     ENDIF.
   ENDIF.

Enhance the WebUI controller method for the search (CL_BP_HEAD__MAINSEARCH/EH_ONSEARCH)

Well that's probably the worst option, if we talk about behaviour is a mix of the other two, you can use the parameter and hide it or you can use the parameter and show it after search.

If the parameter is not on the screen, we'll add it, use it for the search and update the query parameters on the frontend. If is not in the screen, we just set the values as we wish.


  DATA: lo_qs        TYPE REF TO cl_crm_bol_dquery_service,
        lo_qs_col    TYPE REF TO if_bol_bo_col,
        lo_iterator  TYPE REF TO if_bol_bo_col_iterator,
        lo_param_ent TYPE REF TO if_bol_bo_property_access. lo_qs ?= me->typed_context->search->collection_wrapper->get_current( ).
  lo_qs_col ?= lo_qs->get_selection_params( ).
  lo_iterator = lo_qs_col->get_iterator( ).
  lo_param_ent = lo_iterator->find_by_property( iv_attr_name = |ATTR_NAME|
                                                iv_value     = |XDELE| ).
  IF lo_param_ent IS NOT BOUND.
    lo_param_ent ?= lo_qs->insert_selection_param( iv_index     = lo_qs_col->size( ) + 1
                                                   iv_attr_name = |XDELE|
                                                   iv_sign      = |I|
                                                   iv_option    = |EQ|
                                                   iv_low       = |N| ).
  ELSE.
    lo_param_ent->set_property( EXPORTING iv_attr_name = |SIGN|
                                          iv_value     = |I|   ).
    lo_param_ent->set_property( EXPORTING iv_attr_name = |OPTION|
                                          iv_value     = |EQ|   ).
    lo_param_ent->set_property( EXPORTING iv_attr_name = |LOW|
                                          iv_value     = |N|   ).
  ENDIF.
  me->typed_context->search->build_parameter_tab( ).
  super->eh_onsearch( EXPORTING htmlb_event    = htmlb_event
                                htmlb_event_ex = htmlb_event_ex ).

This option is in case we disabled the field via configuration so we use it for the search but we don't want to show it to the user.


DATA: lo_qs        TYPE REF TO cl_crm_bol_dquery_service,
         lo_qs_col    TYPE REF TO if_bol_bo_col,
         lo_iterator  TYPE REF TO if_bol_bo_col_iterator,
         lo_param_ent TYPE REF TO if_bol_bo_property_access.
   lo_qs ?= me->typed_context->search->collection_wrapper->get_current( ).
   lo_qs_col ?= lo_qs->get_selection_params( ).
   lo_iterator = lo_qs_col->get_iterator( ).
   lo_param_ent = lo_iterator->find_by_property( iv_attr_name = |ATTR_NAME|
                                                 iv_value     = |XDELE| ).
   IF lo_param_ent IS NOT BOUND.
     lo_param_ent ?= lo_qs->insert_selection_param( iv_index     = lo_qs_col->size( ) + 1
                                                    iv_attr_name = |XDELE|
                                                    iv_sign      = |I|
                                                    iv_option    = |NE|
                                                    iv_low       = |Y| ).
   ENDIF.
   me->typed_context->search->build_parameter_tab( ).
   super->eh_onsearch( EXPORTING htmlb_event    = htmlb_event
                                 htmlb_event_ex = htmlb_event_ex ).
   IF lo_param_ent IS BOUND.
     lo_qs_col->remove( iv_bo = lo_param_ent ).   ENDIF.

Conclusion

As you see there's no straight forward solution, the solution depends plenty on your landscape, business process and user demands. Every solution has its pros and cons, if you are in control of all of this, everything will go smooth :wink:

Cheers!

Luis

4 Comments
Labels in this area