Application Development and Automation 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: 
Read only

Parllel cursor

Former Member
1,102

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.

6 REPLIES 6
Read only

michael_piesche
Active Contributor
960

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).

  1. Please make yourself familar with the following information,
  2. then actually attempt to code your parallel cursor logic, and
  3. if you continue to have issues with that, I will be glad to help you out

General guidelines for Parallel Cursors would be the following:

  • all tables need to be sorted by the key(s) to compare against
  • key comparison <, >, = are used to increase the cursor, or to 'wait' for the next possible match
  • a (parallel) cursor is necessary for each nested loop or read table
  • the (parallel) cursor marks the (FROM) index of a nested table where you continue the 'search' for the next record, without actually searching the entire table
  • Together, the sorted keys and the parallel cursor, create the magic of the performance improvement compared to actual table searches, in case of huge sets of table data with large amounts of matching keys
  • Hence, it is not at all usefull for small datasets and in cases, where there are only few matching keys
  • Parallel Cursors make the coding a little messier compared to straight forward LOOP/READ by KEY statements, leading to higher testing efforts as well

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:

  • If ITAB1 has n1 entries and ITAB2 has n2 entries, the time needed for
    the nested loop with the straightforward algorithm is O(n1 * n2),
    whereas the parallel cursor approach takes only O(n1 + n2) time.
    The above parallel cursor algorithm assumes that ITAB2 contains only
    entries also contained in ITAB1.
    If this assumption does not hold, the parallel cursor algorithm
    gets slightly more complicated, but its performance characteristics
    remain the same.
Read only

0 Kudos
960

Thanks for your Valueble Information

Read only

matt
Active Contributor
960

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.

Read only

960

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.

Read only

matt
Active Contributor
960

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.

Read only

michael_piesche
Active Contributor
0 Kudos
960

vivek70, please follow up on your open question.

  • comment answers or your question if there are still open issues.
  • otherwise mark an answer as accepted if it helped you solve your problem
  • or post an answer of yourself and accept it if you found another useful solution yourself
  • or redirect your question to another question that is related and was useful to solve your problem
  • in the end, close your question