IDocs arriving at XI are by default processed in Exact Once (EO) mode. However, you may have a business case where certain IDoc type must be strictly processed in the order which they are sent out from the Application System. This post shares with you simple steps to serialize your IDocs fed to XI, i.e., in Exact Once In Order (EOIO) fashion.
h4. Configuration steps in XI (Optional)
From my experience, the steps in the section are not necessary if your Application System is based on WAS 6.40 and above.
Assume you have already configured IDoc port type (IDX1) and RFC destination for your application system (SM59). That is, your EO IDoc works.
In SE16, enter Table name IDXQUEUE and create a new table entry. Supply the parameters: PORT, CLIENT, MESTYP and QUEUEID for each of the IDoc message type that you want to serialize using the IDoc adapter. Save each entry.
h4. Configuration steps in Application System
From CRM, basically you need to enable queue processing mode for this IDoc type, and specify which XI queue will handle the messages. Some simple coding is required.
First, create a function module, e.g., IDOC_QUEUE_BP, which is basically used to indicate QueueID for this IDoc type (SE37).
- Export parameter: NAME of type CHAR16
- Tables: DATA of type EDID4
In the body of source code, simply specify the QueueID with one line of code. Note that it must match with the QueueID specified in IDXQUEUE table in your XI system.
Michal’s book on The specified item was not found.</p>
what you presented is only a partial EOIO
as when you send IDOCs from R3
you cannot use IDXQUEUE for real EOIO,
you need to use the same technique
as you mentioned for the inbound
why?
as if you send IDOCs from R3 using IDXQUEUE
if XI will not be available after the restart,
IDOCs from R3 can/may/will go to XI
in ANY order (IDXQUEUE will only work
when they reach the XI)
you can see the complete EOIO approach in my book:
Mastering IDoc Business Scenarios with SAP XI
The specified item was not found.
so… 🙂
maybe just mention that in your weblog
that:
to use queues in IDOCs you need at least WAS 6.40
and if you don’t have that in the outbound side
you can use your technique to simulate it (during the IDOC sending from R3) ?
Regards,
michal
maybe it’s also worth to mention transactions:
WEINBQUEUE and WEOUTQUEUE
(monitoring IDOCs in queues in SAP Application systems)
REgards,
michal
Thank you for your prompt feedback!
In my implementation, I observed that, by configuring IDXQUEUE alone, IDocs arriving at XI still appear as EO mode by default.
Therefore I need to enforce EOIO mode from Application System side by enabling Queue Processing (ALE serialization). In fact, after that, even without having IDXQUEUE, I can get my inbound queues in SMQ2. 🙂 This is probably because I was using systems above WAS6.40.
By your reading your post, I am sure I can obtain a more complete picture from it.
Cheers!
Raymond
if you apply – “queue processing” mode
in the IDOC receiver adapter
IDOCs will be posted one by one
(of course it only works with 6.40)
Regards,
michal
For calrification, Is it like above step XI Queue and Rule configuration on Application server needs to done only in case of WAS 6.20.
In case of WAS 6.40 only checking “Queue Processing” mode in communication channel is enough. No need to configure XI Queue and Rule configuration on R/3 Side?
Gaurav Jain
From my observation, Rule name for queue processing is however a compulsory field. I am refering to CRM5.0 based on WAS 7.0. Hope this helps!
Kind rgds!
Raymond
You may want to suppress IDoc acknowledge (SE38 report IDX_NOALE) for EOIO. I was getting lots of messages in “Holding” status because first message was waiting for acknowledgement and therefore blocked the entire JDBC queue.
BR
Raymond
I am not able to see the Queue through SMQ1 but I am with WEOUTQUEUE.
Secondly my IDOCs are getting stuck in status of 30 and only go out of R3 if I run RSEOUT00 program or if I activate the queue. They are not going out automatically like they used to before I checked the Queue Processing option in WE20.
Thanks,
Roneil
Check the IDOC is posted via Function Module EDI_OUTPUT_NEW using parameter ONL_OPTION = ‘O’.
That did the trick for me.
Greetings,
Frank
The TABNAM element is not populated on HR IDOCS when you add Queue Processing in WE20.
There is an OSS Note to fix this
https://service.sap.com/sap/support/notes/1057573
We have a requirement where we need to send IDoc’s in sequence from SAP ECC to SAP PI( Should Receive in sequence) .
We tried the same scenario refeing to this blog and the MICHAL Book ,to do the sequencing through IDOC Serialization but the Idoc are not reached to SAP PI (MONITOR) in the Same Sequence.