Quantcast
Channel: SCN : All Content - SAP CRM: Webclient UI - Framework
Viewing all articles
Browse latest Browse all 4552

Set default values on a search view

$
0
0
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 )

 

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 .

 

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

 

 

Cheers!

 

Luis


Viewing all articles
Browse latest Browse all 4552

Trending Articles