Component | Support Package |
---|---|
BBPCRM | SAPKU70204 |
SAP_ABAP | SAPKA73105 |
SAP_BASIS | SAPKB73105 |
WEBCUIF | SAPK-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
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: )
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: .
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:
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.
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.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
10 | |
7 | |
6 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 |