mysapbook: Parallel Processing technique in SAP ABAP and its Advantages

For some SAP reports, the nights are getting too short. Especially at customers with large volumes of data, some SAP reports that customarily run in the background processing system (such as material planning runs) may have run times of many hours. It can be difficult to finish such jobs in the “night-time” that is available, especially if dialog users are spread across several time zones.

With Release 3.1G, SAP offers a solution to the “short nights” problem: parallel-processed background jobs. Long-running SAP reports can now implement parallel processing, which lets them parcel out the work to be done to available dialog work processes in the SAP system and then collect the results.

Parallel processing is implemented in ABAP reports and programs, not in the background processing system itself. That means that jobs are only processed in parallel if the report that runs in a job step is programmed for parallel processing. Such reports can also process in parallel if they are started interactively.

Important Note: Parallel-processing is implemented with a special variant of asynchonous RFC. It’s important that you use only the correct variant for your own parallel processing applications: the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword. Using other variants of asynchronous RFC circumvents the built-in safeguards in the correct keyword, and can bring your system to its knees

Below is the sample code which will guide us to implement Parallel Processing in future whenever needed.

*&---------------------------------------------------------------------*
*& Report ZPAR_PARALLEL_PROCESS
*&
*&---------------------------------------------------------------------*

REPORT zpar_parallel_process.

TABLES : mara.
DATA : bapimatdoa TYPE bapimatdoa,
       bapireturn TYPE bapireturn.
DATA : system TYPE rzlli_apcl,
       taskname(8) TYPE c,

index(3) TYPE c,
snd_jobs TYPE i,
rcv_jobs TYPE i,
exc_flag TYPE i,
mess TYPE c LENGTH 80.

TYPES : BEGIN OF type_material,
          desc TYPE maktx,
        END OF type_material.

DATA : material TYPE TABLE OF type_material WITH HEADER LINE,
       i_mara TYPE STANDARD TABLE OF mara.

DATA: functioncall1(1) TYPE c.
CONSTANTS: done(1) TYPE c VALUE 'X'.

FIELD-SYMBOLS: <fs_mara> TYPE mara.

SELECT-OPTIONS s_matnr FOR mara-matnr.

SELECT * FROM mara INTO TABLE i_mara WHERE matnr IN s_matnr.

**********************************************************************************
* RFC Server Group created from transaction RZ12
* It will be the config for Parallel processing.
* We can keep it as DEFAULT. In our case it is 'parallel_generators'
**********************************************************************************
system = 'parallel_generators'.

LOOP AT i_mara ASSIGNING <fs_mara>.
index = sy-tabix.
CONCATENATE 'Task' index INTO taskname. " Generate Unique Task Name

**********************************************************************************
* Below is the SYNTAX for calling our own FM (For which we need Papallel processing)
*
* CALL FUNCTION func STARTING NEW TASK task
*              [DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]
*              parameter_list
*              [{PERFORMING subr}|{CALLING meth} ON END OF TASK].
*
* We can keep the syntax as DESTINATION IN GROUP DEFAULT instead of
*                           DESTINATION IN GROUP system
*
* The above syntaxes will creates Different task name TASK in a     separate work process.
* Each such task executes “process_parallel” in a separate work process.
*
**********************************************************************************
CALL FUNCTION 'BAPI_MATERIAL_GET_DETAIL' STARTING NEW TASK taskname
    DESTINATION IN GROUP system
    PERFORMING process_parallel ON END OF TASK
    EXPORTING
      material              = <fs_mara>-matnr
    EXCEPTIONS
      system_failure        = 1 MESSAGE mess
      communication_failure = 2 MESSAGE mess
      resource_failure      = 3.
CASE sy-subrc.
    WHEN 0.
      snd_jobs = snd_jobs + 1.

    WHEN 1 OR 2.

      MESSAGE mess TYPE 'I'.
    WHEN 3.
      IF snd_jobs >= 1 AND
      exc_flag = 0.
        exc_flag = 1.

        WAIT UNTIL rcv_jobs >= snd_jobs

        UP TO 5 SECONDS.

      ENDIF.

      IF sy-subrc = 0.
        exc_flag = 0.

      ELSE.

        MESSAGE 'Resource failure' TYPE 'I'.

      ENDIF.

    WHEN OTHERS.

      MESSAGE 'Other error' TYPE 'I'.

ENDCASE.
ENDLOOP.

WAIT UNTIL rcv_jobs >= snd_jobs.

LOOP AT material.
WRITE : material-desc.
ENDLOOP.

*&---------------------------------------------------------------------*
*&      Form process_parallel
*&---------------------------------------------------------------------*
* Each task will execute “process_parallel” in a separate work process.

*----------------------------------------------------------------------
FORM process_parallel USING taskname.

rcv_jobs = rcv_jobs + 1.

RECEIVE RESULTS FROM FUNCTION 'BAPI_MATERIAL_GET_DETAIL'
IMPORTING
material_general_data = bapimatdoa.
bapireturn = bapireturn.
functioncall1 = done.

APPEND bapimatdoa-matl_desc TO material.
ENDFORM.

-----------------------------------------------------------------------

Program without Parallel Processing:

Here with normal loop process (without using parallel processing), the control would wait for each record inside the loop until the FM would return the values.

*&---------------------------------------------------------------------*
*& Report ZPAR_LOOP
*&
*&---------------------------------------------------------------------
REPORT ZPAR_LOOP.

TABLES : MARA.
DATA : BAPIMATDOA TYPE BAPIMATDOA,
BAPIRETURN TYPE BAPIRETURN.

DATA: i_mara TYPE STANDARD TABLE OF mara.

FIELD-SYMBOLS: <fs_mara> TYPE mara.

SELECT-OPTIONS S_MATNR FOR MARA-MATNR.

SELECT * FROM mara INTO TABLE i_mara WHERE matnr IN s_matnr.

LOOP AT i_mara ASSIGNING <fs_mara>.
CALL FUNCTION 'BAPI_MATERIAL_GET_DETAIL'
EXPORTING
MATERIAL = <fs_mara>-matnr
IMPORTING
MATERIAL_GENERAL_DATA = BAPIMATDOA.
write : BAPIMATDOA-MATL_DESC.
ENDLOOP.

With Parallel Processing (Runtime Analysis – SE30)