Two questions regarding BAPI_MATERIAL_SAVEDATA

[gary_king2]

I have read through the currect posted questions on this subject but I don't think that neither of my questions have been asked or answered.

1) When extending a material to new plants/ storage location and or Sales area do we need to provide the CLIENTDATA structure when calling the BAPI?. I'm creating the material and all it's plants/SLOC's etc but after the first creation of the material I assume I no longer need to provide all the CLIENDATA as well of Unit of measure and description data either that are specific to the Material. At present each time I extend a material to a new plant/'sloc I am providing the same data in the CLIENTDATA structure.Will it work if NULL this structure as well as UOM and MAKT tables for this BAPI when extending to plants?.

2) I am currently committing (BAPI_TRANSACTION_COMMIT) or rolling back depending on whether the call to materail_savedata bapi is successful, or not. However, when you do something similar in LSMW you can specifiy how many records per commit that you want, to help speed it up. How can I do that in my example. If I'm extending to say 100 Plants per material I could just commit at the end of that Materials requirements and force a commit before I move onto the next material. However, if there's an error halfway through processing Plants for a given material I would have to roll back everything for that material. So when LSMW does its commit per 1000 records, which obviously must span across multiple materials, how do they deal with a particular error encountred without rolling back the updates for the other materials. Does that make sense as aquestion?

We have an Oracle database, and yes I am using WAIT='X' when using the bapi_transaction_commit.

[Sandra_Rossi]

PS 1: it is BAPI_MATERIAL_SAVEDATA (BAPI, not BAP)

PS 2: it's best to ask questions separately (I think it's in the Rules Of Engagement), because people may search for answers/ or answer only one question at a time.

[gary_king2]

1). Clearly I have mentioned that I'm already using said BAPI, so clearly that's a typo. Thanks for pointing that out though, I will correct that by the time you read this.

2. Both points are related to BAPI_MATERIAL_SAVEDATA, and both points are related to performance, so regardless of the searching, to me that right togrther. And, while we are on this subject, on my EI browser when I search for BAPI_MATERIAL_SAVEDATA using this sight it shows a number of finds, of which all I can see is the heading and not the content, so I can't decide on which one to read unless I click on it and open it, which makes your point about search Null and Void.

Don't get me wrong, I am gald to have feedback, but there also needs to a rule whereby answers to posts need to contain some attempt at answering the question, in which yours most definitely does not.

By the way, I clearly said there were two questions, both on the subjet of what was identified in the subject line. I have found multiple posts where several questions have been asked, and where they have not been stated in the initial posting they have resulted in a labourious reply to an answer asking yet another question, because that's the way peoples minds work. For me it's better to ask all your questions up front. Also, I note that you yourself have asked multiple questions in one of your own posts. 😉

https://answers.sap.com/questions/138849/looking-for-static-check-for-call-function-with-mi.html

[Sandra_Rossi]

Sorry, I didn't mean to be offending. My comment was not an answer of course (in SCN, the comments and answers are completely distinct).

[matt]

Moderator note:

There is a rule that answers must be answering the question. However, Sandra's comment is not an answer, it's a comment in the comment section.

It is entirely correct and proper to raise queries concerning the question in the comments.

It is also correct for members of this site to indicate customary usage.

While it might on some occasions be right to post more than one question, and there's no hard and fast rule, generally it is better to post each question individually. To me the questions are sufficiently distinct to warrant being asked separately. However, since you've asked them together, it makes sense, this time to keep them that way.

[Sandra_Rossi]

Answer only for question 2:

The logic of committing several records of one package in LSMW is in fact the logic implemented in the IDOC technology: if one IDoc returns an error (type ‘E’), then there’s no rollback, it’s assumed that there shouldn’t be any update ; if one IDoc update is aborted (message type ‘A’), then all the IDocs of the package are rollbacked, and SAP restarts the processing of the whole package except all those IDocs which had previously failed. It may sound counter-performing, but SAP is expecting that most of IDocs are valid (i.e. if not, then people should change the software which sends the IDocs to validate the IDocs before sending them).

It’s up to you to choose whether you want to implement the same logic. Note that you may use the logic without implementing it, by creating/executing IDocs instead of calling the BAPI.

[gary_king2]

Many thanks for that. That's an interesting point about teh return of error (E) and no rollback. I have seen a lot of example code using BAPI_MATERIAL_SAVEDATA though, and all seem to use the BAPI_TRANSACTION_ROLLBACK after encountering an error, but I have never really queried that. I shall investigate further.

[gary_king2]

I have now identified that the cleint data structure does not need to be passed everytime the BAPI_MATERIAL_SAVEDATA is called, and neither does the description or UOM tables either. If you just updating or extending to new plants/Sales orgs for example, then these structure/tables can be initial, which does save a great deal of time.

Also, As I'm updating or creating for a material and upto 100 plants for that material I'm commit at the very end of the material's plant update/creations. It's an all or nothing apprach, so any error and everything for the material either gets rolled back or committed.