RSNAST00 - Object is blocked

[Former Member]

Working on a project to start sending Sales/Order Confirmations once a day. I've changed a few sales output master data (VV12) to indicate the timing as "1" - Schedule with periodic job as opposed to "4" - Send Immediately. This is working fine. The output remains in a state of not-porcessed when viewing it via VA03 after order is saved.

The issue, however, is when I scheduled RSNAST00 to run in batch. For example, one order may have two outputs. One for the SP and the other for the SH. Well, when RSNAST00 is run, I will get a message stating "Object is blocked (object key 000<ordernumber>, application V1...) for one of the two outputs. Then, a second message stating that 1 out of 1 output was processed successfully. So, I go back and look at the output via VA03, and yes, I see one is now "green", while the other is still "yellow". I verify this against the NAST table.

Now, I can go right back to RSNAST00 and run that job again with the exact same variant and this time, the second output will process. Why is this happeneing and why didn't it process the first time? I did not change anything on the Sales Order.

To further complicate, I can create an exact duplicate order via VA01. Then, run RSNAST00 and both outputs will be processed. So, there does not seem to be any consistancy. Any ideas as to where to start looking at this?

Thanks,

Bryan

[Jelena]

I've never seen this issue with RSNAST00, but I've also never seen it used to process two separate outputs for the same document at the same time. If both outputs have the same type, then I'm not sure if it makes much sense, actually (can you clarify why it's needed?). If these are two output types then this could be resolved by running the program separately for each output.

In a nutshell, this happens with background jobs when load optimizer or some other magic tries to run the whole thing faster and transactions sor of "run into each other", like kids on a slide. One output has not fully finished processing yet but the second one already kicked in. Hence the lock message. With the imediate processing this error is impossible to recreate because a human being can't run the transactions that fast to cause this issue.

[Former Member]

Hi Jelena -

The two order confirmation documents have different destinations.

Example:

The Soldto is #12345

The Shipto is #98765

So based on configuration, after the order is saved, you can see two outputs (VA03), each with the same output type (ZBA3). When processed, one will go to the Soldto and the other with go to the Shipto.

Both documents have status "scheduled with periodic job". When RSNAST00, at 4:00 AM when there are no users on the system, I get a message stating that 1 document was processed while 1 was blocked. I have to run RSNAST00 a second time in order to process the blocked document.

[Shiva_Ram]

Can you try with user exit RSNASTZZ to influence the sorting/selection of print output sequence to avoid object blocking? You may also refer OSS Note 357114 - Sorting of message output is incorrect

My two cents.

Regards,

[Jelena]

It doesn't matter whether there are users in the system. Locking clearly happens in a background job.

Although it is possible that there could be another job (e.g. an ATP check / rescheduling) running at the same time and causing the locking issue, I doubt it is the case since it was noted that consistently one output is getting processed and the other is not. Based on that information, I suspect the background job with RSNAST00 somehow runs in two parallel processes. Hopefully I don't say something stupid, but I believe it's possible at least in some landscapes and it is meant to make the jobs run faster.

When this happens, the first instance of the output (Sold-to) locks the record (it's an exclusive lock for the sales document, so no other transaction for this document may happen) and does some stuff. Meanwhile the second instance (Ship-to) starts processing in parallel and is unable to lock the order because it's already locked by the first instance. Then first instance is completed and lock is released. All this happens very fast, naturally.

I'm not sure what exactly would cause the parallel processing, but you might want to check with the Basis admin if some changes could be made in the job to avoid that (e.g. designate it to run on just one server). Otherwise feel free to send a message to SAP, although I wouldn't expect a solution since usually their response to such issues is "well, just run it once again". But at least you might get an explanation.

P.S. This is not an SD question, perhaps if you check in ABAP or even Basis forum you'd get more intelligent response.

[Former Member]

Hi Bryan,

I guess the error is due the lock object "ËVVBAKE", please check with your technical guy also i am attaching a screen shot for different reasons for locking of the object, might help you.Let me know your response on the same.

Regards

Aadesh

[Former Member]

Hello Aadesh -

I checked with technical team. He is not familiar with this lock object. Is there a wat to debug during the RSNAST00 process to see this object and it's status?

[Former Member]

Hi Bryan,

The lock concept is as follows :-

Simultaneous access by several users to the same data is synchronized in the
SAP System using a lock mechanism. Locks are set and cleared in the dialog
transaction programming by calling function modules that are automatically
generated in the ABAP Dictionary from the definition of lock objects.

The function modules ENQUEUE_OBJECT (set lock) and
DEQUEUE_OBJECT (clear lock) are generated by activating a lock object
OBJECT.

I guess your error is due the locking of the object, i guess the function module DEQUEUE_OBJECT is not executed in your case, debugging would help.

Regards

Aadesh

[Shiva_Ram]

Object is blocked (object key 000<ordernumber>, application V1...)

Is there any message number associated with this message?

Regards,

[Former Member]

Hello Shiva -

Message no. VN036

[Lakshmipathi]

Check whether the following note helps you:-

• Note 871157 - VN036: Print in billing doc. display from archive using VF05

G. Lakshmipathi

[Former Member]

Hello G.

That note has been in PRD for a few years per our BASIS team.

Thanks

[Former Member]

Hi Bryan, Did you find the root cause? Please share, thank you

[Former Member]

No. I have not found out the cause yet. My solution, if you can call it that, is to run the batch job twice. Once to pick up 99% of the output and a second time, 5 minutes later, to pick up the remaining 1%.