Doubt about BAPI_MATERIAL_SAVEREPLICA and COMMIT / ROLLBACK

[alejandro_bindi]

This BAPI allows to create or modify several materials at once. My doubt is how the transaction should be handled. As you know common practice after any BAPI execution is to check for errors in RETURN table, then if some are found call BAPI_TRANSACTION_ROLLBACK or else call BAPI_TRANSACTION_COMMIT.

In the case of this BAPI, following this approach with a batch of e.g. 100 materials, causes that if even only one of them has errors, all the remaining 99 are also not updated. Also, the application log is not saved in SLG1 even if using NOAPPLLOG = space.

The possible solutions I see would be a) to update 1 material at a time (which is pointless since BAPI_MATERIAL_SAVEDATA should be used for that, and also would hurt performance), OR b) call BAPI_TRANSACTION_COMMIT in any case (errors or not).

I haven't found any piece of documentation in function module nor OSS/SMP about this issue. So I'm afraid that doing this would cause any kind of inconsistencies. Also, I don't fully understand the role of the NO_ROLLBACK_WORK parameter (it rollbacks the whole update or the single errored material?).

I've run out of time for investigating this further so I'd appreciate comments from people experienced in using this BAPI.

Many thanks and regards

[SuhaSaha]

Hello Alejandro,

Below are my observations to your queries:

1. "In the case of this BAPI, following this approach with a batch of e.g. 100 materials, causes that if even only one of them has errors, all the remaining 99 are also not updated"
   • I'm not surprised to see this behaviour. This BAPI is for mass maintenance of materials & error in one material will cause the entire lot to be rolled back - atomicity of an SAP LUW
2. " Also, the application log is not saved in SLG1 even if using NOAPPLLOG = space."
   • Did you check for the application log object "MATU"? Actually the Appl. log gets generated based on SY-SUBRC values returned after the call to the FM 'MATERIAL_MAINTAIN_DARK', so you need to debug & check why it is not getting generated
3. " I don't fully understand the role of the NO_ROLLBACK_WORK parameter (it rollbacks the whole update or the single errored material?)."
   • Read the comments for NO_ROLLBACK_WORK, SAP states it might lead to data inconsistencies(for obvious reasons) & caller should use it at his/her own risk

Hope i'm able to lessen your confusion!

BR,

Suhas

[alejandro_bindi]

Thank you Suhas, in reply to your comments:

1. I agree, since each BAPI call represents a transaction, the whole batch would have to be correct or not updated at all. But I wanted to check if this worked differently since I saw some posts around here recommending to do a COMMIT in any case.

2. I already checked in SLG1 with MATU, It works as I say. Only gets generated when I do the COMMIT, hence with the ROLLBACK I do in case of errors, the log doesn't get saved. It makes sense of course, I suppose it happens because the log is saved in update task just like the material changes, so it all gets rolled back. But this difficults error analysis, in fact the log is most needed in case of errors right? So I don't get the point of that behaviour. Anyway I solved on my own with the return table.

3. I already saw the comments on the parameter NO_ROLLBACK_WORK, so I had no intention to send X, it just added to my uncertainty about the transaction handling of this particular BAPI.

Overall I think this BAPI is not much intuitive. Another think that bugs me is the create/update tries it does for each material, disregarding the INS / UPD FUNCTION fields in the parameters.

Anyway, I found a way to solve this with some workarounds (I have a way to exclude the errored materials in my program via a select-option so I can run it a second time and update the rest), so I'll leave it as it is for now at least (it's an all-or-nothing update).

Thanks and regards