Using class CL_ABAP_PARALLEL for mass parallel dialog work processes

[Dan_M]

Using class CL_ABAP_PARALLEL is a convenient way to mass process in parallel dialog work processes.  This can be especially powerful in a system with more dialog vs other types of work processes.  Due to limited documentation, there was a small learning curve when I first implemented this in an S4/HANA on-premise system on SAP_BASIS version 7.54.  I’m writing this blog to help others with their implementation of this class.

Important SAP Notes to consider

• 2791374 - Downport of class CL_ABAP_PARALLEL


• 3164040 - SSI_DISPATCH: SM50 and SM51 needed when called by CL_ABAP_PARALLEL

Setup overview

In this example there will be two local classes (to make it an easy copy/paste test).  The XSTRING data type is used to universally pass different kinds of data between the two classes.

1. Local class MAIN
   
   
   
   1. The start and end point for the main logic outside of parallel processing
   
   
   
   


2. Local class SINGLE_TASK
   
   
   
   1. Inherits from CL_ABAP_PARALLEL
   
   
   2. Contains logic to process one of the parallel task records at a time
   
   
   
   

Logic overview for class MAIN

• Collect the necessary data for all the tasks


• EXPORT all the task data and any shared task data


• Create an instance of SINGLE_TASK passing parameters to control how many resources are used
  
  
  
  • See the Constructor parameters listed below
  
  
  
  


• Call the RUN Method of SINGLE_TASK passing all the collected data for all tasks and receiving the results for all tasks
  
  
  
  • See the RUN Method parameters listed below, including the results/output structure details
  
  
  
  


• IMPORT the task results to process them

Logic overview for class SINGLE_TASK

• The DO Method is called once per task data record


• IMPORT the single task record and any shared task data


• Process the data as necessary


• EXPORT the task results

Constructor parameters of CL_ABAP_PARALLEL

• P_NUM_TASKS
  
  
  
  • If supplied, this will simply override P_NUM_PROCESSES
  
  
  
  


• P_TIMEOUT
  
  
  
  • Amount of seconds the dialog process can run before automatically timing out
  
  
  
  


• P_PERCENTAGE
  
  
  
  • Limits the number of simultaneous parallel processes by calculating the system allowable max parallel tasks across all application servers and reduces it according to the percentage.
  
  
  • For example, if there are two application servers with each having 100 as their max parallel task count and P_PERCENTAGE = 75; then the internal logic would limit the number of simultaneous parallel processes to 150
  
  
  • This value is ignored if P_NUM_PROCESSES is less than the % calculation
  
  
  
  


• P_NUM_PROCESSES
  
  
  
  • Limits the number of simultaneous parallel processes
  
  
  • This is ignored if the number is greater than the allowable maximum parallel tasks across all application servers.
  
  
  • This value is also ignored whenever P_PERCENTAGE calculates to a lower number
  
  
  
  


• P_LOCAL_SERVER
  
  
  
  • Optionally restrict the simultaneous parallel processes to only the current application server
  
  
  • This also impacts the internal calculations used for P_PERCENTAGE and P_NUM_PROCESSES
  
  
  
  

Notes: Class CL_SSI_DISPATCH is primarily controlling the server dispatch logic.  Function Module RS_ABAP_PARALLEL is used internally for executing the parallel tasks.

RUN Method parameters of CL_ABAP_PARALLEL

• P_IN_TAB
  
  
  
  • Table of XSTRING values used as input for the parallel dialog tasks
  
  
  • One input row per dialog task
  
  
  
  


• P_IN_ALL
  
  
  
  • Single XSTRING value
  
  
  • Shared record that’s available in all parallel dialog tasks
  
  
  
  


• P_DEBUG
  
  
  
  • Debugging flag is used to skip the parallel framework and directly/sequentially call the DO Method
  
  
  
  


• P_OUT_TAB
  
  
  
  • Table of XSTRING values
  
  
  • One output row per dialog task
  
  
  • Structure fields
    
    
    
    • RESULT - XSTRING of results populated within the DO Method
    
    
    • INDEX – Index of the table in P_IN_TAB
    
    
    • TIME – Seconds of runtime
    
    
    • MESSAGE – Error message for timeouts and other failures
    
    
    
    
  
  
  
  

Conclusion

Hopefully these details save you some time when implementing class CL_ABAP_PARALLEL yourself.  I’ve found this especially useful when programing a mass data correction utility and the timeframe to run it is limited.  I’ve attached an example program which is self contained by using local classes.  There are also some test classes for CL_ABAP_PARALLEL which provide useful examples.

 

REPORT zparallel_test.



CLASS main DEFINITION.



  PUBLIC SECTION.



    TYPES:

      BEGIN OF shared_record,

        process_mode TYPE c LENGTH 1,

      END OF shared_record,



      single_record TYPE scarr-carrid,



      BEGIN OF task_result,

        carrid TYPE scarr-carrid,

        count  TYPE i,

      END OF task_result.



    CLASS-METHODS process.



ENDCLASS.



CLASS single_task DEFINITION

  INHERITING FROM cl_abap_parallel.



  PUBLIC SECTION.



    METHODS: do REDEFINITION.



ENDCLASS.



*This is the only statement outside of the classes

main=>process( ).



CLASS main IMPLEMENTATION.



  METHOD process.



    DATA: tasks_input        TYPE cl_abap_parallel=>t_in_tab,

          task_input_single  TYPE xstring,

          single_record      TYPE single_record,

          tasks_input_shared TYPE xstring,

          shared_record      TYPE shared_record,

          task_result        TYPE task_result.



    shared_record-process_mode = 1.



*   Since the process_mode value is shared across all tasks, store 

*   it in the shared variable (tasks_input_shared) instead of

*   repeating it for every task input record (tasks_input)



*   To be imported by SINGLE_TASK->DO

    EXPORT buffer_task_shared = shared_record 

      TO DATA BUFFER tasks_input_shared.



*   Get data to be processed.  EXPORT each record and collect them all into

*   table tasks_input.

    SELECT

      carrid

    FROM scarr

    INTO @single_record.



*     To be imported by SINGLE_TASK->DO

      EXPORT buffer_task = single_record TO DATA BUFFER task_input_single.

      INSERT task_input_single INTO TABLE tasks_input.



    ENDSELECT.



*   Create the instance while configuring the resource usage

    DATA(parallel) = NEW single_task(

*                          p_num_tasks     = 8

*                          p_timeout       = 200

*                          p_percentage    = 50

*                          p_num_processes = 20

*                          p_local_server  =

                         ).



    DATA(debug) = ' '.



*   Perform the tasks in parallel

    parallel->run(

      EXPORTING

        p_in_tab  = tasks_input

        p_in_all  = tasks_input_shared

        p_debug   = debug

      IMPORTING

        p_out_tab = DATA(tasks_output)

    ).



    LOOP AT tasks_output ASSIGNING FIELD-SYMBOL(<task_output_single>).



*     Something went wrong, like a timeout, if the message has a value

      IF <task_output_single>-message IS NOT INITIAL.

        WRITE: / 'Task Error:', <task_output_single>-message.

      ENDIF.



      IF <task_output_single>-result IS NOT INITIAL.

*       Exported from SINGLE_TASK->DO

        IMPORT buffer_result = task_result 

          FROM DATA BUFFER <task_output_single>-result.



        WRITE: / task_result-carrid, task_result-count.

      ENDIF.



    ENDLOOP.



  ENDMETHOD.



ENDCLASS.



CLASS single_task IMPLEMENTATION.



  METHOD do.



*   I referenced the MAIN local class instead of using the data dictionary

*   for the ease for copy/paste

    DATA: shared_record TYPE main=>shared_record,

          single_record TYPE main=>single_record,

          task_result   TYPE main=>task_result.



*   Exported by MAIN->PROCCESS

    IMPORT buffer_task_shared = shared_record FROM DATA BUFFER p_in_all.



*   Exported by MAIN->PROCCESS

    IMPORT buffer_task = single_record FROM DATA BUFFER p_in.



*   Other shared values I like to include are a simulation/update flag

*   and a level for the logging detail

    CASE shared_record-process_mode.

      WHEN '1'.



*       Incredibly simplistic example which doesn't warrant parallel processing

        SELECT

          carrid,

          COUNT( * )

        FROM sflight

        WHERE

          carrid = @single_record

        GROUP BY

          carrid

        INTO ( @task_result-carrid, @task_result-count ).



        ENDSELECT.



      WHEN '2'.

    ENDCASE.



*   To be imported by MAIN->PROCESS

    EXPORT buffer_result = task_result TO DATA BUFFER p_out.



  ENDMETHOD.



ENDCLASS.