Changes don’t commit after RFC of ME_INFORECORD_MAINTAIN_MULTI

I’m calling ME_INFORECORD_MAINTAIN_MULTI with an RFC. The purchase info records get a new number, but the changes aren’t commited to the db.

The commit is supposed to be implicit after a RFC, but it isn’t. I’ve tried adding an explicit COMMIT WORK after the function call, but this didn’t help.

The changes are commited properly if I use a regular function call (not remote), however performance is very slow.

Please help.

FORM CALL_BAPI_PIR.
  lv_taskname = |PIR-{ lv_sentjobs WIDTH = 3 ALIGN = RIGHT PAD = '0' }|.

    CALL FUNCTION 'ME_INFORECORD_MAINTAIN_MULTI'
     STARTING NEW TASK lv_taskname
     DESTINATION IN GROUP DEFAULT
     PERFORMING RETURN_BAPI_PIR ON END OF TASK
      EXPORTING
        testrun          = p_test
      TABLES
        t_eina           = GT_ME_EINA
        t_einax          = GT_ME_EINAX
        t_eine           = GT_ME_EINE
        t_einex          = GT_ME_EINEX
        return           = GT_ME_INFORECORD_RETURN
       EXCEPTIONS
         system_failure        = 1 MESSAGE lv_exceptionmsg
         communication_failure = 2 MESSAGE lv_exceptionmsg
         resource_failure      = 3
     .
     CASE sy-subrc.
       WHEN 0.
         lv_sentjobs = lv_sentjobs + 1.
         COMMIT WORK.
       WHEN 1 OR 2.
         MESSAGE lv_exceptionmsg TYPE 'I'.
         WRITE: / lv_taskname, ':', lv_exceptionmsg.
     ENDCASE.
ENDFORM.

FORM RETURN_BAPI_PIR USING TASKNAME.
  DATA INFO LIKE RFCSI.
  RECEIVE RESULTS FROM FUNCTION 'ME_INFORECORD_MAINTAIN_MULTI'
    IMPORTING
      RFCSI_EXPORT = INFO
      RETURN = GT_ME_INFORECORD_RETURN.
  lv_recvjobs = lv_recvjobs + 1.
ENDFORM.

Solution

With RFC, there’s an implicit database commit at some point of time in the calling program, but not in the RFC session, like there’s no implicit database commit after SUBMIT.

You may chain several function module calls in the same RFC session, and to chain a SAP LUW commit in the RFC session you may call the function module BAPI_TRANSACTION_COMMIT to do a COMMIT WORK. The solution then depends on the type of RFC you use.

In your case, you use asynchronous RFC with a callback i.e. with wait, so the solution will be to

• indicate KEEPING TASK at RECEIVE RESULTS so that to keep the RFC session open after calling ME_INFORECORD_MAINTAIN_MULTI
• use WAIT FOR ASYNCHRONOUS TASKS so that BAPI_TRANSACTION_COMMIT is called sequentially after ME_INFORECORD_MAINTAIN_MULTI has ended.

CALL FUNCTION 'ME_INFORECORD_MAINTAIN_MULTI'
       STARTING NEW TASK lv_taskname
       DESTINATION IN GROUP DEFAULT
       PERFORMING RETURN_BAPI_PIR ON END OF TASK
...
       EXCEPTIONS
         system_failure        = 1 MESSAGE lv_exceptionmsg
         communication_failure = 2 MESSAGE lv_exceptionmsg
         resource_failure      = 3.
IF sy-subrc = 0.

  WAIT FOR ASYNCHRONOUS TASKS UNTIL lv_recvjobs = lv_sentjobs.

  CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
        STARTING NEW TASK lv_taskname " <====== reuse existing RFC session/closed implicitly right after
        DESTINATION IN GROUP DEFAULT
        EXCEPTIONS
          system_failure        = 1 MESSAGE lv_exceptionmsg
          communication_failure = 2 MESSAGE lv_exceptionmsg
          resource_failure      = 3.
...
FORM RETURN_BAPI_PIR USING TASKNAME.
  DATA INFO LIKE RFCSI.
  RECEIVE RESULTS FROM FUNCTION 'ME_INFORECORD_MAINTAIN_MULTI'
    KEEPING TASK " <============== add this to not close the RFC session
    IMPORTING
      RFCSI_EXPORT = INFO
      RETURN = GT_ME_INFORECORD_RETURN.
  lv_recvjobs = lv_recvjobs + 1.
ENDFORM.

NB:

• I did not handle the exceptions to simplify the demonstration.
• If you run the RFC under several task names, several RFC sessions are started, so you must call BAPI_TRANSACTION_COMMIT in each of these RFC sesssions.