Hello,
I'm working on custom planning function type that implements IF_RSPLFA_SRVTYPE_IMP_EXEC_REF (planning on reference data).
The EXECUTE method of the implementing class has I_TH_REF_DATA TYPE HASHED TABLE as an 'importing' parameter. This table actually includes my reference data. The structure of the table is defined dynamically at runtime in accord with the structure of an aggregation level. It includes all characteristics and keyfigures that the aggregation level is comprised from.
To avoid full scan of the table I want to loop over it using some kind of 'partial' key that includes only limited set of characteristics. Product assistance suggests something like that:
DATA spfli_tab TYPE HASHED TABLE
OF spfli
WITH UNIQUE KEY primary_key
COMPONENTS carrid connid
WITH NON-UNIQUE SORTED KEY city_from_to
COMPONENTS cityfrom cityto
WITH NON-UNIQUE SORTED KEY city_to_from
COMPONENTS cityto cityfrom.
LOOP AT spfli_tab ASSIGNING <spfli> USING KEY city_from_to.
This, however. does not apply to my task, as the table I_TH_REF_DATA is defined somewhere inside planning engine and I have no control over its structure, keys included.
I know beforehand the structure of the aggregation level, and want to loop using a key that includes, let's say, characteristics 0FISCPER, 0CURRENCY, ZSCOPE and ZVERSION. I need something like
LOOP AT I_TH_REF_DATA ASSIGNING <fs_line> USING KEY COMPONENTS '0FISCPER' '0CURRENCY' 'ZSCOPE' 'ZVERSION'
However, it seems that ABAP syntax does not provide for that.
Please advise, how can I loop over a dynamic hashed table avoiding full table scan?
Thank you,
Val
Request clarification before answering.
Hello val.teem
Have a look at this example based on the VBAP table.
DATA:
ld_row TYPE REF TO data,
ld_table TYPE REF TO data,
lt_vbap_hashed TYPE HASHED TABLE OF vbap WITH UNIQUE KEY vbeln posnr.
FIELD-SYMBOLS:
<ls_row> TYPE any,
<lt_table> TYPE ANY TABLE.
CREATE DATA ld_row LIKE LINE OF lt_vbap_hashed.
ASSIGN ld_row->* TO <ls_row>.
CREATE DATA ld_table LIKE SORTED TABLE OF <ls_row> WITH NON-UNIQUE KEY vbelv.
ASSIGN ld_table->* TO <lt_table>.
<lt_table>[] = lt_vbap_hashed[].If the key field provided does not exist in the newly created table, then an exception CX_SY_TABLE_KEY_SPECIFICATION will be raised. If not handled it will result in a short-dump.
You'll probably need to provide the WHERE condition in a dynamic way, for example.
cond = 'col2 > dref->*'.
LOOP AT itab INTO line FROM 10 TO 25 WHERE (cond).
APPEND CONV string( line-col2 ) TO output.
ENDLOOP. Kind regards,
Mateusz
Edit: Added the dynamic key definition, as it may not be clear.
DATA:
lt_key TYPE TABLE OF string.
APPEND 'VBELV' TO lt_key.
CREATE DATA ld_table LIKE SORTED TABLE OF <ls_row> WITH NON-UNIQUE KEY (lt_key).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello val.teem
For some reason I'm not able to respond to your comment...
First of all, let me mark that I don't know your current scenario as well as you do. You choose what you thing is best for you and that's cool. You know your situation and needs best.
I don't like to have a complicated solution, when a simple one would suffice. Sometimes it (complicated solution) is necessary and gives a lot of added value to the system (e.g.: configuration). Sometimes something simpler will do just fine.
Here's an example code for the EXECUTE logic, for your consideration (based on the VBAP table). Notice, that except for the key field VBELV everything else is dynamic in the EXECUTE method. For this particular example the result of the method is the first row of the newly created sorted table (here a LOOP based on a dynamic WHERE clause could be used).
CLASS lcl_z DEFINITION.
PUBLIC SECTION.
INTERFACES:
if_rsplfa_srvtype_imp_exec_ref.
ENDCLASS.
CLASS lcl_z IMPLEMENTATION.
METHOD if_rsplfa_srvtype_imp_exec_ref~execute.
DATA:
ld_row TYPE REF TO data,
ld_table TYPE REF TO data,
lt_key TYPE TABLE OF string.
FIELD-SYMBOLS:
<ls_row> TYPE any,
<lt_table> TYPE SORTED TABLE.
CREATE DATA ld_row LIKE LINE OF i_th_ref_data.
ASSIGN ld_row->* TO <ls_row>.
APPEND 'VBELV' TO lt_key.
CREATE DATA ld_table LIKE SORTED TABLE OF <ls_row> WITH NON-UNIQUE KEY (lt_key).
ASSIGN ld_table->* TO <lt_table>.
<lt_table>[] = i_th_ref_data[].
READ TABLE <lt_table> ASSIGNING <ls_row> INDEX 1.
INSERT <ls_row> INTO TABLE c_th_data.
ENDMETHOD.
ENDCLASS.
" test execution in the test report
DATA:
ls_tmp TYPE vbak,
lt_vbap_source TYPE HASHED TABLE OF vbap WITH UNIQUE KEY vbeln posnr,
lt_vbap_result TYPE HASHED TABLE OF vbap WITH UNIQUE KEY vbeln posnr,
lo_msg TYPE REF TO if_rsplfa_msg,
lo_param_set TYPE REF TO if_rsplfa_param_set.
SELECT *
INTO TABLE lt_vbap_source
FROM vbap
UP TO 100 ROWS.
BREAK-POINT. " just to see what's going on
DATA(lo_z) = NEW lcl_z( ).
lo_z->if_rsplfa_srvtype_imp_exec_ref~execute(
EXPORTING
i_r_param_set = lo_param_set " empty for test, because required
i_th_ref_data = lt_vbap_source
i_s_block_line = ls_tmp " empty for test, because required
i_r_msg = lo_msg " empty for test, because required
CHANGING c_th_data = lt_vbap_result ). Data on the start of the method:
Original data in the method (notice the key, blue columns):
Copied data in method (notice the key):

Data as a result:

That's it from me on this topic. As mentioned before, michael.piesche 's code will work just fine, too.
Kind regards,
Mateusz
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.