04-11-2012 2:49 PM
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
04-11-2012 4:34 PM
Hello Alejandro,
Below are my observations to your queries:
Hope i'm able to lessen your confusion!
BR,
Suhas
04-11-2012 4:34 PM
Hello Alejandro,
Below are my observations to your queries:
Hope i'm able to lessen your confusion!
BR,
Suhas
04-11-2012 8:03 PM
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