Skip to Content

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>

To report this post you need to login first.


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

  1. Michal Krawczyk
    Hi Raymond,

    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

    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
    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) ?


      1. Hi, 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.


        1. Michal Krawczyk

          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)


          1. Former Member

            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

            1. Hi Guarav,

              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!

              1. I suggest you should exercise EOIO with care for scenario like IDOC –> XI –> JDBC.

                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.


        2. Former Member
          Hi 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.


          1. Former Member

            Check the IDOC is posted via Function Module EDI_OUTPUT_NEW using parameter ONL_OPTION = ‘O’.
            That did the trick for me.


  2. Former Member
    Hi Raymond,

    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.


Leave a Reply