METHOD PARALLEL_READ.
    DATA:lv_taskid        TYPE c LENGTH 8,
         lv_index         TYPE c LENGTH 4,
         lv_current_index TYPE int4,
         lt_task          LIKE it_orders,
         lt_attachment    TYPE crmt_odata_task_attachmentt.

* TODO: validation on iv_process_num and lines( it_orders )
    DATA(lv_total) = lines( it_orders ).
    DATA(lv_additional) = lv_total MOD iv_block_size.
    DATA(lv_task_num) = lv_total DIV iv_block_size.
    IF lv_additional <> 0.
       lv_task_num = lv_task_num + 1.
    ENDIF.
    DO lv_task_num TIMES.
      CLEAR: lt_task.
      lv_current_index = 1 +  iv_block_size * ( sy-index - 1 ).
      DO iv_block_size TIMES.
        READ TABLE it_orders ASSIGNING FIELD-SYMBOL(<task>) INDEX lv_current_index.
        IF sy-subrc = 0.
          APPEND INITIAL LINE TO lt_task ASSIGNING FIELD-SYMBOL(<cur_task>).
          MOVE-CORRESPONDING <task> TO <cur_task>.
          lv_current_index = lv_current_index + 1.
        ELSE.
          EXIT.
        ENDIF.
      ENDDO.

      IF lt_task IS NOT INITIAL.
        lv_index = sy-index.
        lv_taskid = 'Task' && lv_index.
        CALL FUNCTION 'ZJERRYGET_ATTACHMENTS'
          STARTING NEW TASK lv_taskid
          CALLING read_finished ON END OF TASK
          EXPORTING
            it_objects = lt_task.
      ENDIF.
    ENDDO.

    WAIT UNTIL mv_finished = lv_task_num.

    rt_attachments = mt_attachment_result.

  ENDMETHOD.

METHOD READ_FINISHED.
    DATA: lt_attachment TYPE crmt_odata_task_attachmentt.

    ADD 1 TO mv_finished.
    RECEIVE RESULTS FROM FUNCTION 'ZJERRYGET_ATTACHMENTS'
    CHANGING
      ct_attachments              = lt_attachment
    EXCEPTIONS
      system_failure        = 1
      communication_failure = 2.

    APPEND LINES OF lt_attachment TO mt_attachment_result.

  ENDMETHOD.

In function module ZJERRYGET_ATTACHMENTS, I still use the attachment single read API:

FUNCTION ZJERRYGET_ATTACHMENTS.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IT_OBJECTS) TYPE  CRMT_OBJECT_KEY_T
*"  CHANGING
*"     VALUE(CT_ATTACHMENTS) TYPE  CRMT_ODATA_TASK_ATTACHMENTT
*"----------------------------------------------------------------------

DATA(lo_tool) = new zcl_crm_attachment_tool( ).

ct_attachments = lo_tool->get_attachments_origin( it_objects ).

ENDFUNCTION.

So in fact I didn’t spend any effort to optimize the single read API. Instead, I call it in parallel. Let’s see if there is any performance improvement.

In this test report, first I generate an internal table with 100 entries which are opportunity guids. Then I perform the attachment read twice, one done in parallel and the other done sequentially. Both result are compared in method compare_read_result to ensure there is no function loss in the parallel version.

Testing result ( unit: second )

It clearly shows that the performance increases with the number of running ABAP sessions which handles with the attachment read. When the block size = 100, the parallel solution degrades to the sequential one – even worse due to the overhead of WAIT.

( for raw test result screenshot, you can find it here )

For sure in productive usage the number of block size should not be hard coded.

In fact in my test code why I use the variable name iv_block_size is to express my respect to the block size customizing in tcode R3AC1 in CRM middleware 🙂

All related source code could be found from my github.