BAPI_MATERIAL_SAVEDATA in background task

[life1]

Hi,

Case: There is a need to extending material with a specific view like plant, warehouse, Sales Organizations, etc. Due to the very large amount of data, it was decided to start the extending process in the background task.

• Created FM: "call function Z_ASSIGN_PROC in background task"
• Inside of FM: loop by materials, inside of loop: BAPI_MATERIAL_SAVEDATA

But, after running fm in background task, i see to many DIA process in SM50. They take up all the free processes, and it is very stressful to the system...

Can anybody explain, why this happens?

Why are DIA processes created instead of BTS?

Is it possible to wrap DIA processes of BAPI_MATERIAL_SAVEDATA to the one BTC process?

Main program like:

  loop at lt_matnr assigning field-symbol(<ls_matnr>).

    if lines( lt_id ) = c_counter.

      do.

        loop at lt_id assigning field-symbol(<ls_id>).

          data(lv_tabix) = sy-tabix.

          call function 'STATUS_OF_BACKGROUNDTASK'
            exporting
              tid           = <ls_id>-tid
            tables
              errortab      = lt_errtab
            exceptions
              communication = 1
              recorded      = 2
              rollback      = 3
              others        = 4.

          if sy-subrc = 0.

            data(lv_exit) = abap_true.
            delete lt_id index lv_tabix.

            exit.

          else.

            lv_exit = abap_false.

          endif.

        endloop.

        if lv_exit = abap_true.

          exit.

        endif.

      enddo.

    endif.

    lv_taskname = <ls_matnr>.

      call function 'Z_ASSIGN_PROC'
        in background task
        exporting
          iv_matnr              = <ls_matnr>
          it_werks              = s_werks[]
          it_lgnum              = s_lgnum[]
        exceptions
          communication_failure = 1
          resource_failure      = 2
          system_failure        = 3
          others                = 4.

      call function 'ID_OF_BACKGROUNDTASK'
        importing
          tid  = ls_tid
          fnum = lv_fnum.

      append value #(
                      tid  = ls_tid
                      fnum = lv_fnum
                    ) to lt_id.

      " Start'Z_ASSIGN_PROC'
      commit work.

endloop.

FM Z_ASSIGN_PROC like:

loop at lt_t001w assigning field-symbol(<ls_t001w>).

" fill bapi's structures

  call function 'BAPI_MATERIAL_SAVEDATA'
	...
  if sy-subrc = 0.

        call function 'BAPI_TRANSACTION_COMMIT'
          exporting
            wait = abap_true.
  endif.

  loop at lt_warehouse assigning field-symbol(<ls_wh>) where werks eq <ls_t001w>-werks.

"   fill bapi's structures

    call function 'BAPI_MATERIAL_SAVEDATA'
	...
    if sy-subrc = 0.

          call function 'BAPI_TRANSACTION_COMMIT'
            exporting
              wait = abap_true.
    endif.

  endloop.

endloop.

[Sandra_Rossi]

In background task means transactional RFC (tRFC).

All kind of RFC run in DIA workprocesses only.

No, it can't run in BTC workprocesses.

There are some profile parameters to adjust the maximum number of DIA workprocesses which can be assigned to RFC tasks. You should ask your administrator some proposals to less stress the system.

[RaymondGiuseppi]

You can use the Background RFC once, during execution of standard transaction to prevent breaking of the LUW.

But during the execution of the FM, use a RFC asynchronous call and handle the number of currently running processes, either use a RFC server group (RZ12)

" to use a RZ12 defined group (with limits in its definition)
 CALL FUNCTION 'Z_ASSIGN_PROC' STARTING NEW TASK nbtask
                DESTINATION NONE IN GROUP group
                CALLING minus1 ON END OF TASK.

NB: Also handle the foillowing exceptions in the call : system_failure, communication_failure and resource_failure.

or, if you don't (want to) use a group, handle the number of task yourself (+1 after call, -1 in the called method).

NB: To get max/available number of process use FM SPBT_INITIALIZE at start of loop.

If you actually want to use batch process, then don't call your FM RFC mode, but rewrite your code in a small report, and use JOP_OPEN/SUBMIT/JOB_CLOSE instead.