ABAP Parallel cursor is a nice technique to improve the performance of the nested loops. There are always few things to remember while implementing the parallel cursor.
What is Parallel Cursor?
When there are nested loops, you would need to use the WHERE clause to find the matching entries from the inner LOOP. The typical WHERE clause would scan entire table to find the matching key. The cost of finding the one key would remain same for each row in the outer LOOP. With more entries in the Outer LOOP, the total processing time for scanning the inner table would add up very fast.
That’s when you want to use the Parallel Cursor – Read the Key of the inner table, Loop from that key when entry is found, exit the table when keys are not same anymore. Read Parallel Cursor – To speed up performance of Nested LOOP and Parallel Cursor – 2: without using READ to brush up your parallel cursor knowledge.
Don’t Use SY-TABIX
When you READ the inner table with the key, you get the index of the entry is set in the field SY-TABIX. You would need to use this field to start the inner loop. You could simply use the SY-TABIX from the READ, just like this:
DATA: it_vbak TYPE STANDARD TABLE OF vbak. DATA: it_vbap TYPE STANDARD TABLE OF vbap. DATA: ls_vbak LIKE LINE OF it_vbak. DATA: ls_vbap LIKE LINE OF it_vbap. DATA: lt_nums TYPE STANDARD TABLE OF i. DO 10 TIMES. ls_vbak-vbeln = sy-tabix. APPEND ls_vbak TO it_vbak. ENDDO. ls_vbap-vbeln = 3. ls_vbap-posnr = '001'. APPEND ls_vbap TO it_vbap. ls_vbap-vbeln = 3. ls_vbap-posnr = '002'. APPEND ls_vbap TO it_vbap. DO 10 TIMES. APPEND sy-tabix TO lt_nums. ENDDO. FIELD-SYMBOLS: <lfs_vbak> LIKE LINE OF it_vbak, <lfs_vbap> LIKE LINE OF it_vbap. SORT: it_vbak BY vbeln, it_vbap BY vbeln. LOOP AT it_vbak ASSIGNING <lfs_vbak>. READ TABLE it_vbap TRANSPORTING NO FIELDS WITH KEY vbeln = <lfs_vbak>-vbeln BINARY SEARCH. if sy-subrc eq 0. LOOP AT it_vbap FROM sy-tabix " << ASSIGNING <lfs_vbap> . IF <lfs_vbap>-vbeln <> <lfs_vbak>-vbeln. EXIT. ENDIF. * Rest of the logic would go from here... READ TABLE lt_nums TRANSPORTING NO FIELDS WITH KEY table_line = '7'. * SY-TABIX is different now ENDLOOP. endif. ENDLOOP.
That’s reason, you should always use the local variable store the SY-TABIX before looping through the Inner table.
Subsequent Usage
When you need to use the selected data outside of the Inner loop, you can’t just use the Workarea or the Field-Symbol that you have used for inner loop. The reason behind this is the approach of the parallel cursor. You need to LOOP through the inner table from the Index. You exit the loop when the keys are not matching. This means that, you are now probably in the next row in the inner LOOP table.
LOOP AT it_vbak ASSIGNING <lfs_vbak>. READ TABLE it_vbap TRANSPORTING NO FIELDS WITH KEY vbeln = <lfs_vbak>-vbeln BINARY SEARCH. if sy-subrc eq 0. LOOP AT it_vbap FROM sy-tabix " << ASSIGNING <lfs_vbap> . IF <lfs_vbap>-vbeln <> <lfs_vbak>-vbeln. EXIT. ENDIF. * Rest of the logic would go from here... ENDLOOP. if <lfs_vbap>-kwmeng is not initial. " This would be next subsequent entry in the table IT_VBAP endif. endif. ENDLOOP.
Your learning
Do you have any more leaning to share?
Instead of using read and loop, can we use sorted table and loop with the key? What would be the performance impact?
Hi and thanks. But where is the problem? READ command inside the inner cycle changes SY-TABIX value, but after ENLOOP and LOOP the inner cycle again, the SY-TABIX is reset back to the right value (and icremented by 1 of course).
Hello Rajesh,
SORTED table and READ with BINARY has almost same performance. I did ran a performance comparison once – ABAP Internal Table Performance for STANDARD, SORTED and HASHED Table. Once you have a TABIX, you can proceed on looping the inner table.
Thanks,
Naimesh Patel
Hello Martin,
Yes, you are absolutely correct. SY-TABIX is set back to what it was before + 1. But issue would be in debugging, it would be keep on changing and you wont know what row you have started reading the inner table. I think it would make more sense to use a specific variable, just to make things more clear.
Thanks for your inputs.