2020 Apr 05 10:24 PM
My requirment is to use parllel cursor with 4 or 5 loops. i want to convert this code how
LOOP AT it_mard INTO wa_mard.
wa_final-matnr = wa_mard-matnr.
wa_final-werks = wa_mard-werks.
wa_final-lgort = wa_mard-lgort.
wa_final-labst = wa_mard-labst.
CLEAR: wa_mseg, wa_ser03, wa_objk.
LOOP AT it_mseg INTO wa_mseg WHERE matnr = wa_mard-matnr
AND werks = wa_mard-werks
AND lgort = wa_mard-lgort.
wa_final-aufnr = wa_mseg-aufnr.
LOOP AT it_ser03 INTO wa_ser03 WHERE mblnr = wa_mseg-mblnr.
LOOP AT it_objk INTO wa_objk WHERE obknr = wa_ser03-obknr.
CLEAR: wa_final-status2.
IF wa_mseg-bwart = '261'. -----------------------
wa_final-status = 'Consumed'.---------------------
wa_final-status2 = 'active'.----------------------
CLEAR: wa_final-plnbez, wa_final-bldat.
READ TABLE it_afko INTO wa_afko WITH KEY aufnr = wa_mseg-aufnr.
IF sy-subrc = 0.
wa_final-plnbez = wa_afko-plnbez.
ENDIF.
READ TABLE it_mkpf INTO wa_mkpf WITH KEY mblnr = wa_mseg-mblnr.
IF sy-subrc = 0.
wa_final-bldat = wa_mkpf-bldat.
ENDIF.
-------------------------------------------------------------------------------------reaming to add
ELSEIF wa_mseg-bwart = '551'.
CLEAR: wa_final-status2.
wa_final-status = 'Scrap'.
wa_final-status2 = 'Inactive'.
IF wa_final-status = 'Scrap'.
CLEAR wa_final-aufnr.
ENDIF.
wa_final-date = ''.
ENDIF.
wa_final-sernr = wa_objk-sernr.
SHIFT wa_final-sernr LEFT DELETING LEADING '0'.
APPEND wa_final TO it_final.
ENDLOOP.
ENDLOOP.
ENDLOOP.
* -----------------------------------------------------------------
LOOP AT it_view INTO wa_view WHERE matnr = wa_mard-matnr
AND b_werk = wa_mard-werks
AND b_lager = wa_mard-lgort.
CLEAR: wa_final-plnbez,wa_final-bldat.
IF wa_view-b_lager = '112A' OR wa_view-b_lager = '113A' OR wa_view-b_lager = '114A' OR wa_view-b_lager = '111V'.
CLEAR: wa_final-status2.
wa_final-status = 'Issue To Production'.
wa_final-date = wa_view-aedat.
wa_final-status2 = ''.
IF wa_final-status = 'Issue To Production'.
CLEAR wa_final-aufnr.
ENDIF.
ELSE.
CLEAR: wa_final-status2.
wa_final-status = 'Available'.
wa_final-date = ''.
wa_final-status2 = ''.
IF wa_final-status = 'Available'.
CLEAR wa_final-aufnr.
ENDIF.
ENDIF.
wa_final-sernr = wa_view-sernr.
SHIFT wa_final-sernr LEFT DELETING LEADING '0'.
APPEND wa_final TO it_final.
ENDLOOP.
ENDLOOP.
2020 Apr 06 5:22 AM
There are many ways to implement a parallel cursor, and it all depends on how the data in the different tables have matching keys (e.g from cardinality 1:1 to 0..m:0..n).
General guidelines for Parallel Cursors would be the following:
Most basic form of a parallel cursor is this:
" Both tables sorted by key K (whereas ITAB1 has a unique key and ITAB2 doesnt)
I = 1.
LOOP AT ITAB1 INTO WA1.
LOOP AT ITAB2 INTO WA2 FROM I.
IF WA2-K <> WA1-K.
I = SY-TABIX.
EXIT.
ENDIF.
" ... " -> a match has been found, the logic for the match happens here
ENDLOOP.
ENDLOOP.
Documentation for above coding from SAP on parallel Cursor in ABAP objects performance examples:
2020 Apr 06 6:07 PM
2020 Apr 06 2:31 PM
I'd venture to say that you do not have a requirement to implement parallel cursor. You may have a requirement to improve the performance. Parallel cursor is the old way of doing this. Nowadays (i.e. that past twenty years) use HASHED tables for preference, or SORTED tables. With these there is no need for parallel cursor, leading to simpler and possibly even faster code.
2020 Apr 06 3:47 PM
In terms of "simpler", I do agree.
In terms of "performance", I disagree. A parallel cursor can improve the performance in certain instances, especially when the the overlapping of matching keys in the tables is large enough, because there is never a search performed and the next match is 'found' in O(1). Whereas on average a hashed table has a search performance of O(1), but in the worst case of O(n) and the worst case for a sorted table is O(log n) and on average more than O(1).
The question always is, does the gained performance outweigh the development, testing and maintenance of the coding.
And the OPs requirement is "to use parllel cursor", so I am not going to question that, because otherwise, a SELECT with JOINs or even a CDS view could be even better.
2020 Apr 06 8:40 PM
Fair point, but I always question "requirements" which actually mean "I've a problem, here's my solution, how can it work". So it is worth suggesting better techniques. In order of preference:
1. CDS
2. SELECT/JOIN
3. HASHED/SORTED TABLES
4. Parallel cursor.
I've worked with datasets in the millions of records - I've never needed to use parallel cursor in the past 20 years. I doubt very much the OP's problem is such a special snowflake that it does need it.
2020 May 13 3:55 PM
vivek70, please follow up on your open question.