Normally, when multiple users update a same object at the same time, there will be such kinds of Bdoc errors, for instance, “Business Partner XXX is currently being processed by XXX or Object requested is currently locked by user XXX”. Since the object is being edit and already locked by the current queue, other queues try to edit the same object fails and result in lock error in the Bdoc.

In order to resolve these kind of Bdoc errors (caused by locked object), it is possible to schedule a job to reprocess them in bulk via T-code SMW20. The report RSMWAPP01 is also the same. You could schedule this report to run periodically in the background. Using this report, you can specify Bdocs based on Bdoc type and Bdoc state as the input parameters.

/wp-content/uploads/2015/11/report_823630.png

In addition, there are some other middleware parameters can help resolving this kind of error.

You can maintain the following parameters in table SMOFPARSFA via T-code SM30 for cases where the Bdoc is only temporarily blocked.

1. As mentioned in note 785046:

Key: FLOW

Parameter Name:  WAIT_FOR_ENQUEUE

Parameter Value:  X

Parameter Value 2: <a whole number indicating the WAIT time in seconds>

2. As mentioned in note 722854:

Key:    R3A_COMMON

Parameter Name:       WAIT FOR UPDATE

Parameter Name 2:    <R3 adapter object>

Parameter Value:       X

3. As mentioned in note 705650:

Key: R3A_COMMON

Parameter Name: UPDATE_QUEUES_RESTART

Parameter Name 2: <queue name>

Parameter Value: < seconds for queue time until the restart>

Parameter Value 2: <number of restart attempts>

Comment: RETRY TO PROCESS TEMPOARY LOCKED BDOCS-MSG

In “parameter name 2” field, you can specify the queue name and the “*” can be used in the queue name.

After the parameters added, you can clear the current queues and retest with newly created queues.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply