Skip to Content
0

IDOC with inbound queue booking in wrong order

Dec 18, 2016 at 12:35 AM

159

avatar image
Former Member

Hello guys,

i can't believe that this is happening, but i sorted out, that a special sort of idoc in our system gets simply booked in wrong order and doesn't care a sh*t of queue using.

No workflow is defined, an external system is pushing messages in, all goes well in right order in the RFC-Inbound queue and even the idoc numeration goes right. But the system is just booking in wrong order and it even seems that it is booking in parallel LUW's.

There are just three letters i have for this crap: WTF ???

The messages are getting in for sales orders, sometimes 3 messages per second for the same order, that's all that is special about this message, it's just 1 segment per idoc with about 20 fields, nothing spectacular at all.

As i'm used to other systems (non SAP), that's not a number that would bother me. SAP has to handle the right order of booking.

The customer i am programming for is sitting in my neck and it drives me crazy as i have no chance to change something on this stupid behavior.

WE20, WE21 and SM59 are checked multiple times, and according to EDIDS-table and SMQR the queue is properly working, it's just the last way to the finish line that totally goes wrong.

I even implemented an own logging that measures idoc function module entry and leaving

Here is an example of this logging from yesterday, SAP queue failing at it's best, all 4 IDOC's are in parallel progress and even booked in wrong order

Timestamp Entry               Timestamp leaving             Docnum      last part of transaction id from RFC-queue
20.161.216.132.813,6951200    20.161.216.132.815,1958030    29108903    EBEC72E7
20.161.216.132.814,3118650    20.161.216.132.815,1748620    29108905    EBED72EB
20.161.216.132.815,2070750    20.161.216.132.815,3978740    29108906    EBEE72ED
20.161.216.132.815,2152670    20.161.216.132.815,4114670    29108904    EBED72E9

As can be seen on the TID, the 4 IDOC numbers are generated properly, as all 4 docs are processed in the same rfc process and 29108903 has the least timestamp (time EBEC and counter 72E7) and 29108906 has greatest time and counter.

The function module for booking is not using update task, background task, no messages, no wait, as i have erased all possibilities to do an implicit commit during process which i thought could force the parallel processing as the job sends its "finishing" too early.

Please bring some light in this painful process, i have no energy anymore to read the 75404312421231st post about standard inbound queue.

I even think the queue processing would be fine if it would not be just "unpacking" the rfc luw and let the idoc process do what it wants, it should rather be "unpacking", processing, commit, next package but that's propably not the way it is handled right now.

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

avatar image
Former Member Dec 22, 2016 at 01:34 PM
0

yeah, thanks SAP for that super cool message handling.

You have to additionally activate an idoc Queue under WE20 -> Choose your Partner number -> Inbound Parameter -> Choose your message type -> Options

Fill in rule Name "MESTYP_OF_CONTROLRECORD", function gets then Auto filled with "IDOC_QUEUE_INB_MESTYP"

Now finally SAP catches a brick and get the Messages in right order.

The tab Strip that is showing These Options is Buggy, it does no proper refresh after changing message type, you have to leave / enter we20 for each message type to properly set it.

If you are as tired right now as i am, you could hardly insert the same in table EDP21OPTIONS, just fill in Partner number, Partner type and message type, set PARID = QURULE and value = "MESTYP_OF_CONTROLRECORD".

don't know where i can trace the idoc Queue, hopefully it will send Errors into bd87 as normal idoc processing, But finally this crappy parallel processing due to RFC queueing is over.

Many thanks to everybody that was employed in the development of the wonderful Queue processing in SAP, you did a great work *ironic off*

What were you thinking that parallel processing is possible even with RFC queueing ? It does make 0 sense, why would anybody slow down the message Input into an rfc Queue and then let them book parallel ?

Share
10 |10000 characters needed characters left characters exceeded