BAPI_MATERIAL_SAVEDATA in simulation mode

[sankar1781]

Hi Experts,

After I have verified multiple threads and of no use (as those answers were not up to my expectation), I am posting this question here.

Requirement is to trigger the MATMAS IDoc from one system to another system, I have to call the BAPI_MATERIAL_SAVEDATA (or any other BAPI which helps to create Material Master data) using RFC call to connect the target system to find the BAPI Return messages but not to save the Material Master i.e., in Simulation mode and back to the source system to process further (correct the errors or proceed to perform the IDoc process).

Problem here is, it creates the Material Master data even though I declared the FM call BAPI_TRANSACTION_ROLLBACK (not declared the BAPI_TRANSACTION_COMMIT)

How to avoid creating the Material master and run only under simulation mode.

Please share your valuable solutions.

Thanks & Regards.

[thkolz]

If you check the where-used-list of BAPI_MATERIAL_SAVEDATA, you can see that - as for each BAPI - a BAPI_TRANSACTION_COMMIT needs to be performed afterwards in order to write the changes to the DB.

Without this COMMIT you can simulate a material creation without really creating it.

To validate that no COMMIT is performed, you can start SE37 and execute the BAPI in debugging via CRTL+F7.
Then press Shift+F5 and create a breakpoint at ABAP Statement COMMIT WORK.
Afterwards press F8.
It would really surprise me if it stops at any COMMIT WORK statement.

Best regards,
Thorsten.

[DominikTylczyn]

Out of curiosity - you have wrote in your comment "the COMMIT is performed in MATERIAL_MAINTAIN_DARK which is called inside BAPI_MATERIAL_SAVEDATA". Now it looks like BAPI_COMMIT_WORK needs to be executed after BAPI_MATERIAL_SAVEDATA to persist changes.

So I wonder which it is actually:

1. is COMMIT executed during BAPI_MATERIAL_SAVEDATA and BAPI_COMMIT_WORK is not needed
2. or is COMMIT not executed during BAPI_MATERIAL_SAVEDATA and BAPI_COMMIT_WORK is required?

Or maybe the code you have found call BAPI_COMMIT_WORK superfluously?

[thkolz]

Hi 3a9e4ce873a94034b33dc62b0ce600ee,

actually I don't really know if the COMMIT is performed or not.
I'd say no, because in the standard code I've checked there's always a call of BAPI_COMMIT_WORK after BAPI_MATERIAL_SAVEDATA.
Also SAP states that in the notes regarding this BAPI.

Personally I don't think that BAPI_MATERIAL_SAVEDATA is behaving differently than all other BAPIs.
In MATERIAL_MAINTAIN_DARK there's the parameter CALL_MODE which is set to CALL_MODE_BAPI by BAPI_MATERIAL_SAVEDATA.
I guess that this also has an influence to the COMMIT behavior of MATERIAL_MAINTAIN_DARK.

Best regards,
Thorsten.

[raymond_giuseppi]

• The BAPI_MATERIAL_SAVEREPLICA carries a TESTRUN parameter, could you consider using it in your landscape/version?
• Also are you sure the COMMIT WORK is triggered by the BAPI_MATERIAL_SAVEDATA and not an implicit commit, after RFC session closed or some dirty exit/BAdI code for example (try to build a wrapper of the BAPI + ROLLBACK WORK)

[sankar1781]

Hi c12b61ded10b4e18beae75c3b6218d2c, 3a9e4ce873a94034b33dc62b0ce600ee, and raymond.giuseppi,

Great help and awesome response.

My assumption (using enhancement and a RETURN command before commit) is also considered here as a correct approach.

Thank you everyone for your time and valuable answers.

Have a great day. Will come back and update the final result then will close the thread.

Thank you.

[thkolz]

Good luck 😉

[thkolz]

Unlike other BAPIs it seems that BAPI_MATERIAL_SAVEDATA performs an automatic COMMIT.

I just found this thread stating that you can use MATERIAL_MAINTAIN_DARK to maintain a material in simulation mode (there's importing parameter KZ_TEST).

But MATERIAL_MAINTAIN_DARK is not RFC-enabled, so it means that you might need to build a wrapper RFC-FM around it.

[DominikTylczyn]

I don't think so - the BAPI is used in MM17 and MM17 can be used in test mode. Nevertheless it is easy to check - the BAPI can be run in SE37, with a break point on COMMIT WORK statement. If it stops there, it means the function doesn't follow BAPI programming model.

[sankar1781]

Hi c12b61ded10b4e18beae75c3b6218d2c,3a9e4ce873a94034b33dc62b0ce600ee,

Thank you both first for your prompt response.

c12b61ded10b4e18beae75c3b6218d2c: MATERIAL_MAINTAIN_DARK will not work for me and as per my requirement and said, I am using MATMAS and creating material master using 'BAPI_MATERIAL_SAVEDATA'. So what are all the inputs I am passing from source system that all has to be checked in this RFC approach.

3a9e4ce873a94034b33dc62b0ce600ee, I am assuming that when this RFC calls and before the commit work , can I try any implicit or enhancement works to exit before it hits the commit? will it work?

When there is a possibility to add enhancement and declare a Return command then it behaves to come out from the RFC call and back to the source system program, so I believe it works.

Please do let me know.

Thanks again.

[DominikTylczyn]

sankar1781 Have you checked about COMMIT WORK in BAPI_MATERIAL_SAVEDATA with SE37 as I suggested?

[sankar1781]

Hi 3a9e4ce873a94034b33dc62b0ce600ee,

Sorry, you are telling me to look where the COMMIT WORK written in BAPI_MATERIAL_SAVEDATA and see any possibilities to use RETURN before committing it. If yes, then yes... I looked the spot and investigating on it.

Let me know if my understanding is wrong.

Thanks.

[thkolz]

Hi sankar1781,

As written before, the COMMIT is performed in MATERIAL_MAINTAIN_DARK which is called inside BAPI_MATERIAL_SAVEDATA:

You can't control this from outside, because importing parameter KZ_TEST is set to ' ' inside MATERIAL_MAINTAIN_DARK.

You can create an enhancement and do the RETURN here (maybe you should check for your RFC user or via FM RFC_SYSTEM_INFO if it's a RFC call).

Good luck.

Best regards,
Thorsten.

[DominikTylczyn]

c12b61ded10b4e18beae75c3b6218d2c Looks like you are right and COMMIT is executed.

[thkolz]

Hi 3a9e4ce873a94034b33dc62b0ce600ee,

I'm not so sure 😉

Best regards,
Thorsten.

[DominikTylczyn]

sankar1781 c12b61ded10b4e18beae75c3b6218d2c raymond.giuseppi

I've tested BAPI_MATERIAL_SAVEDATA in SE37. Indeed the BAPI persists changes by itself without additional COMMIT WORK. That is done with the call to MATERIAL_MAINTAIN_DARK:

    CALL FUNCTION 'MATERIAL_MAINTAIN_DARK'
      EXPORTING
        flag_muss_pruefen   = 'X'
        sperrmodus          = 'E'
        max_errors          = 0
        p_kz_no_warn        = 'N'
        kz_prf              = headdata-inp_fld_check
        kz_verw             = 'X'
        kz_aend             = 'X'
        kz_dispo            = 'X'
*       KZ_TEST             = ' '
*       NO_DATABASE_UPDATE  = ' '
        call_mode           = call_mode_bapi
        call_mode2          = call_mode2
*       USER                = SY-UNAME
*       SUPPRESS_ARRAY_READ = ' '
        flg_mass            = flag_online
        iv_change_doc_tcode = '(BAPI)'             "note 1050255&1682898

Notice that neither KZ_TEST nor NO_DATABASE_UPDATE are set while calling MATERIAL_MAINTAIN_DARK.

The bottom line is that BAPI_MATERIAL_SAVEDATA doesn't follow BAPI programming model as BAPI should not persist data and should require BAPI_TRANSACTION_COMMIT. The issue could be reported to SAP for either fixing or a clear consulting note explaining how BAPI_MATERIAL_SAVEDATA handles commits.

Best regards

Dominik Tylczynski

[raymond_giuseppi]

At least they (SAP) should provide documentation on the following parameters

• FLAG_ONLINE
• FLAG_CAD_CALL
• NO_DEQUEUE
• NO_ROLLBACK_WORK

Seems information related to some corrections of DI solution were lost in time...