Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Applying filters to F4 Search help - how so with many entries?

Former Member
0 Kudos

Hello all,

I have a problem that I have to filter a search help for employees. We use a DB view that unions infotypes 1, 2 and 105. Now I need to restrict potential employees to a given company code BUKRS.

I now invoke search help in REQUEST ON-VALUE REQUEST within a DynPro screen and call function module F4IF_INT_TABLE_VALUE_REQUEST which I am passing the restricted internal table.

Fine, that works - however, in the DynPro (which is actually used as an EWT within our portal), the entire internal table is sent to the frontent instead of, say, 250 or so.

The search help dialog offers the possibility to manually restrict for first and last name - is it perhaps possible, that this search only applies on the server (ITAB) and just returns the results according to the user input?

Otherwise, sending all potential employees to the frontend is consuming too much resources (time and traffic).

In function group SDHI there is an "example" module F4IF_SHLP_EXIT_EXAMPLE which tries to explain how to use callbacks but from my point of view I understand very few (it misses the big picture).

Do you know an alternative, e.g. using the other module F4IF_FIELD_VALUE_REQUEST and to apply a filter to BUKRS using a callback mechanism? There are module parameters indicating that possibility (passing some report?). Perhaps one of you has some sample code, because I am much more trained in BAPI and web stuff only...

Any hints? Thank you in Advance!

Regards,

Timo

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

if I can understand you, you tell me that you search information in the view and all found records (let´s say 300) are saved in the internal table, which in time you pass to function F4IF_INT_TABLE_VALUE_REQUEST for display. Now, you think it is too much to display 300 records because of time and traffic.

Try this:

REPORT ztest NO STANDARD PAGE HEADING.

TABLES mara.

DATA: mytable TYPE TABLE OF ddshretval WITH HEADER LINE.

DATA l_repid TYPE syrepid.

PARAMETERS p_mtart LIKE mara-mtart.

AT SELECTION-SCREEN ON VALUE-REQUEST

FOR p_mtart.

l_repid = sy-repid.

CALL FUNCTION 'F4IF_FIELD_VALUE_REQUEST'

EXPORTING

tabname = 'MARA'

fieldname = 'MTART'

dynpprog = l_repid

callback_program = l_repid

callback_form = 'F4CALLBACK'

TABLES

return_tab = mytable

EXCEPTIONS

field_not_found = 1

no_help_for_field = 2

inconsistent_help = 3

no_values_found = 4

OTHERS = 5.

START-OF-SELECTION.

*&----


*

*& Form F4_form

*&----


*

  • Exclude all material types that start with F & H

*----


*

FORM f4callback

TABLES record_tab STRUCTURE seahlpres

CHANGING shlp TYPE shlp_descr

callcontrol LIKE ddshf4ctrl.

DATA: aux_struc TYPE ddshselopt.

MOVE: 'H_T134' to aux_struc-shlpname,

'MTART' TO aux_struc-shlpfield,

'E' TO aux_struc-sign,

'CP' TO aux_struc-option,

'F*' TO aux_struc-low.

append aux_struc to SHLP-SELOPT.

MOVE: 'H_T134' to aux_struc-shlpname,

'MTART' TO aux_struc-shlpfield,

'E' TO aux_struc-sign,

'CP' TO aux_struc-option,

'H*' TO aux_struc-low.

append aux_struc to SHLP-SELOPT.

ENDFORM. "F4_form

5 REPLIES 5

Former Member
0 Kudos

Hi,

if I can understand you, you tell me that you search information in the view and all found records (let´s say 300) are saved in the internal table, which in time you pass to function F4IF_INT_TABLE_VALUE_REQUEST for display. Now, you think it is too much to display 300 records because of time and traffic.

Try this:

REPORT ztest NO STANDARD PAGE HEADING.

TABLES mara.

DATA: mytable TYPE TABLE OF ddshretval WITH HEADER LINE.

DATA l_repid TYPE syrepid.

PARAMETERS p_mtart LIKE mara-mtart.

AT SELECTION-SCREEN ON VALUE-REQUEST

FOR p_mtart.

l_repid = sy-repid.

CALL FUNCTION 'F4IF_FIELD_VALUE_REQUEST'

EXPORTING

tabname = 'MARA'

fieldname = 'MTART'

dynpprog = l_repid

callback_program = l_repid

callback_form = 'F4CALLBACK'

TABLES

return_tab = mytable

EXCEPTIONS

field_not_found = 1

no_help_for_field = 2

inconsistent_help = 3

no_values_found = 4

OTHERS = 5.

START-OF-SELECTION.

*&----


*

*& Form F4_form

*&----


*

  • Exclude all material types that start with F & H

*----


*

FORM f4callback

TABLES record_tab STRUCTURE seahlpres

CHANGING shlp TYPE shlp_descr

callcontrol LIKE ddshf4ctrl.

DATA: aux_struc TYPE ddshselopt.

MOVE: 'H_T134' to aux_struc-shlpname,

'MTART' TO aux_struc-shlpfield,

'E' TO aux_struc-sign,

'CP' TO aux_struc-option,

'F*' TO aux_struc-low.

append aux_struc to SHLP-SELOPT.

MOVE: 'H_T134' to aux_struc-shlpname,

'MTART' TO aux_struc-shlpfield,

'E' TO aux_struc-sign,

'CP' TO aux_struc-option,

'H*' TO aux_struc-low.

append aux_struc to SHLP-SELOPT.

ENDFORM. "F4_form

0 Kudos

Hello Jorge,

Thanks for your reply. I implemented your code and it seems to work (however I succeed filtering PERNR but not BUKRS - but that is another issue).

What happens now in GUI is that again I retrieve a restricted list according to callback limitations. Problem still is, that these entries are too much. What I am looking for is a search help that allows the user first to enter e.g. a name pattern and then to display the list of possible values.

And only this list needs to be filtered according to company code.

So, this callback seems to do the same than I do, namely to first select a limited table w/ SQL.

So, reagardless of if I am filtering with SQL or the callback, the potential employee list is still to large.

Do you have an idea how to achieve this? Problem is just, that the SH shows potential entries before the user additionally enters further search criteria.

While "my" search help requires to apply hard-wired filter (namely company code)

plus user-given filter criteria and only then show the list filtered by those information in the GUI.

Thank you very much,

Timo

0 Kudos

Ah, okay, I played around a little bit more. It seems that the callback just filters the initial table shown in the SH, but it is still possible to search for others - that is nice, so I can send an initial empty table to the GUI and the user still can search others.

User can still search for employees of other company code, so is there a possibility to narrow potential data the hard way (means the user cannot override)?

Thank you!

Timo

0 Kudos

Me again... stupid me: module F4IF_INT_TABLE_VALUE_REQUEST also knows about a callback which I knwo how to write thanks to your help!

So, I do my SQL on a given view that retrieves a list of all valid potential employees within my given BUKRS.

Then I use the callback to set the retrieval SH table to initial, so that the user has to enter a name pattern etc. The list updates in SH GUI and only contains entries as defined by the user plus my hard-wired restrictions to the company code, so the user cannot override.

Thank you very much!

Regards,

Timo

0 Kudos

Hello again,

I want to dig into further detail...

Problem is that I want to separately define the columns visible in the result table and the fields used for intput. I hop that I can do this in the callback form of function module F4IF_INT_TABLE_VALUE_REQUEST ...

I am able to define the fields by modifying the FIELDS_TAB param, but that always reflects in changes to both, input fields and result table columns.

Reasin is that I am using search help for infotype 2 - there is a matchcode column for last name which is uppercase. So I have to use that fields for searching (NCHMC instead of NACHN) - that is working pretty fine - however, the result table of course also shows the result in uppercase letters, so I would prefer to show other columns than defined for input.

Do you have any ideas?

The callback form has e.g. changing params SHLP and CALLCONTROL - I have not found different definitions - I only know how to predefine select options by using the SHLP-SELOPT ... however, I am sure that this is the way to go...

Thanks and regards,

Timo