Problem using BAPI_MATERIAL_SAVEDATA as RFC

[former_member218100]

Hi All,

I am using the FM BAPI_MATERIAL_SAVEDATA as an RFC from a remote system to update the MRP Profile (MARC-DISPR). The issue is the return message gives me a success message of 'Material Successfully created or Extended' but when I go to the target system the value is not changed.

I went directly into the target system and executed the BAPI using the same values. This time the data was updated into the table. I am not sure why the data did not get get updated when I am using the BAPI as a RFC call from an external system.

I am using the following code. Please let me know what i am missing.

   SELECT * FROM ztd_master_data
            INTO TABLE gt_material_tab
            WHERE (gt_where_clauses).
          IF sy-subrc = 0.
            SORT gt_material_tab BY matnr.
            DELETE ADJACENT DUPLICATES FROM gt_material_tab COMPARING matnr.
            LOOP AT gt_material_tab INTO DATA(la_material_tab).
              headdata-material = la_material_tab-matnr.
              headdata-mrp_view = 'X'.


              marcout-plant = la_material_tab-werks.
              marcoutx-plant = la_material_tab-werks.

           READ TABLE gt_result ASSIGNING FIELD-SYMBOL(<fs_result>) WITH KEY zvalue = <fs_cond>-zrule.
              IF sy-subrc = 0.
                marcout-mrpprofile = <fs_result>-zvalue.
                marcoutx-mrpprofile = 'X'.
              ENDIF.
             CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
                DESTINATION lv_rfcdest
                EXPORTING
                  headdata       = headdata
                  plantdata      = marcout
                  plantdatax     = marcoutx
                IMPORTING
                  return         = return
                TABLES
                  returnmessages = returnmes.

              READ TABLE returnmes INTO DATA(la_returnmes) WITH KEY type = 'E'.
              IF sy-subrc NE 0.
* Commit to release the locks
                CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
                  DESTINATION lv_rfcdest
                  EXPORTING
                    wait = 'X'.
              ELSE.
                CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'
                  DESTINATION lv_rfcdest.
              ENDIF.

[Sandra_Rossi]

It should work the same in the two systems. No visible problem with your code (anyway, as you said, it works if you run it in the server system without the remote calls).

The only possible difference is that your RFC destination uses a different user than the one you use to test directly in the other system.

[RaymondGiuseppi]

Have you checked the authorizations in the target system, you need the same authorization as when you run directly on the system, but also an RFC authorization for the called function groups (authorization object S_RFC) - you could start an autjorization trace in target system

Did you also check with transaction SM21 in target system for some errors triggered in update task

In your code:

• You use WAIT option, so you can get an error message returned in RETURN parameter of BAPI_TRANSACTION_COMMIT. (check it or remove the WAIT option)
• You didn't check the exceptions raised by a synchronous RFC call

" Sample
CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
  DESTINATION lv_rfcdest
  EXPORTING
    headdata              = headdata
    plantdata             = marcout
    plantdatax            = marcoutx
  IMPORTING
    return                = return
  TABLES
    returnmessages        = returnmes
  EXCEPTIONS
    system_failure        = 1 MESSAGE msg
    communication_failure = 2 MESSAGE msg.
" ...
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' 
  DESTINATION lv_rfcdest
  EXPORTING
    wait   = 'X'
  IMPORTING
    return                = return
  EXCEPTIONS
    system_failure        = 1 MESSAGE msg " here optional as it already work fine in first call
    communication_failure = 2 MESSAGE msg.

[former_member218100]

Hi,

Thanks for the replies. I am able to update another field i.e. EKGRP (Purchasing Group) but not the MRP Profile (DISPR) field. Not sure why is that.

Thanks,

Ashok