cancel
Showing results for 
Search instead for 
Did you mean: 

object locked when update with BAPI

Former Member
0 Kudos

Just a background--We have a scenario to create sales order in SAP, and then have a real time interface from SAP to legacy to create the orders in mainframe based order entry system. When the legacy order entry system created the order, it send backs an acknowledge message to say "Hi, I have created the item", and update the order status to reflect this. It will send back the acknowledge per each line item base, and we use a customer BAPI to update SAP order.

The issue is, if the order has multiple items (can be up to 100+), which means multiple BAPI will send back form legacy to update the same SAP order in almost the same time, and create the following error

TYPE=''E'', Message (ID:V1, NUMBER:042): "Sales document 10000358 is currently being processed (by user WGAO)", LOG_NO:, LOG_MSG_NO:000000 (PARAMETER:, ROW:0, FIELD:, SYSTEM:DEV150)

Any input on how to solve this issue.

We are at SP15, and I prefer to use asynchronous RFC call with auto BAPI commit, and also prefer the setting be Exactly Once.

Accepted Solutions (1)

Accepted Solutions (1)

moorthy
Active Contributor
0 Kudos

Hi wgao,

Adding to the Claus explanation, you can set the exceptions for the BAPI and you can check where exactly it is happening ..

And one more thing, just thought, if you have multiple RFC call for each line item, then try to increase the maximum number connections more than 1 in the Receiver RFC adapter..

Regards,

Moorty

Answers (2)

Answers (2)

claus_wallacher
Active Participant
0 Kudos

Hi Wenning,

if you use a custom BAPI to update your order, you should adjust this BAPI in such a way that you check the return code of your update calls and if you get the return message V1 042, you can have the system wait for a period of time and start the update call again.

Regards,

Claus

Former Member
0 Kudos

Claus and Moorty,

I like the idea you suggest, but I even perfer the some parameters of the RFC adapter can handle it. I mean, the adapter hold its self for a little while, retry and then tell me it is wrong, instead of back to me immediately. Any thougt on this.

Former Member
0 Kudos

I seen this situation in other projeg, we used BPM and collect logical records (correlated by so and so) and then, processed in sequence, if first one success, then send second one. That way it make sure that first record is processed before second one.

But u could also see if you change 'in order' in interface determination to see if that resolve ur problem before the above option.

claus_wallacher
Active Participant
0 Kudos

Hi,

your problem is based on the the way, the SAP backend processes database updates. This is what happens:

You call a BAPI, that performs the complete logic, prepares the database updates <b>and</b> returns a success message to the caller.

The BAPI COMMIT actually ends the logical unit of work. This means that the actual database update is now triggered.

Since you already received the success message it is possible that you try to access these data while they are in fact still being processed on database level (and therefore still locked for any changes).

Regards,

Claus

Former Member
0 Kudos

Hi, Claus,

Thanks for the explanation. Any thought on how to address this issue?

--Wenning