Skip to Content
Author's profile photo Stefan Grube

How to deal with stuck EOIO messages in the XI 3.0 Adapter Framework

Asynchronous message can be delivered with a guaranteed order. For this purpose you set the quality of service of the messages to exactly once in order (EOIO) and provide a queue name. All messages are delivered in the same sequence that they were sent from the sender system. For that reason a sequential number is assigned to the message.

When a message runs on an error during the processing, all other messages in the same queue will not be processed until the error is fixed or the erroneous message is cancelled from processing.

The status of the messages in the message monitoring of the adapter framework is Holding.


If you want to fix the problem it is necessary to find the message which blocks the queue. If there are a huge number of messages in your system you search for the lowest sequential number in the queue.

If you know the name of the queue that is stuck, you can add the queue name as additional filter criteria. Click on Show Additional Criteria:  


Enter the queue name to the field Conversation ID and set the parameter Quality of Service to Exactly Once in Order:


To be able to see the sequential numbers in the message monitor, you configure the table columns:


Add Conversation Id (that is the queue name) and Sequential Number to the table columns:


Scroll the window right to see the new columns. Sort the sequential number ascending (the upper triangle):


Now the erroneous message is the first message in the display. You can look at the error reason, try to fix the problem and resend or cancel the message to release the queue.


After you have resent or cancelled the message all other message will be processed immediately. You have of course to make sure, that the next message in sequence does not run on error too.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Giuliano Bellù
      Giuliano Bellù
      It'll be very helpful. Byez!
      Author's profile photo Michal Krawczyk
      Michal Krawczyk
      >>>>It'll be very helpful.

      agree 🙂
      proper way of handlling a quite unpleasant error


      Author's profile photo Rajesh PS
      Rajesh PS

      Michal Krawczyk PAOLO TEGON 

      I'm facing similar issues wherein QRFC queues are getting stucked in SMQ2 inbound queues of SAP S4H and it should be processed in EOIO sequential quality of service and ideally no abrupt data loss of cancelling or deletion of message.


      Requesting you to kindly provide some inputs around the custom program in elucidate or other ways to resolve this.

      Thanks in advance!


      Author's profile photo Former Member
      Former Member
      Pretty nice! But what about IDOCs?

      Just a word (well better a TCODE): WEINBQUEUE (to be run on the target application system).


      David R.

      Author's profile photo PAOLO TEGON
      Hi Stefan,

      but instead of cancelling the message that blocks the queue, looking for the lowest sequential number in the queue, I think it could be better following this steps:

      1) TCODE SMQ2 then select your queue
      2) In the selected queue you can see all the messages in the queue. Then delete the first one (the message in the error status)
      3) select again the queue and unlock it

      What do you think?

      Best Regards,

      Author's profile photo Stefan Grube
      Stefan Grube
      Blog Post Author
      Hi Paolo,

      The message queues of the Adapter Framework are different from the queues of the Integration Server. Therefore you cannot see the queue entries of the Adapter Framework with SMQ2.

      In my example, the messages have passed the Integration Server without error and run into error, when the Adapter Framework tries to post the message to the application system.


      Author's profile photo Santhana Michael
      Santhana Michael
      Hi Stefan,

      You are right. I am facing a similar situation but I am not able to cancel or resend the messages.

      Do you know why this would be the case, Is there anything else I can do.
      Please advise.


      Author's profile photo Former Member
      Former Member
      Great blog......


      Author's profile photo Former Member
      Former Member
        I happened to see your blog on EOIO queue administration and had a related question -

      After I locate the first erroneous message ( status : System error )  in a particular queue that is blocking the whole queueand & cancel it , I am expecting the next message that is in "holding" status to be picked up and processed automatically. However, I see that this is not happening - i.e I have to manually select all the remaining messages in the "holding" status and resend them. Is this the expected behaviour of the AF processing "holding" status messages . We are on XI 3.0 SP 13.

      Thanks for your time in advance.

      Author's profile photo Former Member
      Former Member
      Hi Stefan,

      It is fantastic blog which gives lots of information.
      I would like to know that in case of File to IDOC scenario, messages will stuck in Adapter framework.

      Thank you for spending your valuable time.



      Author's profile photo Stefan Grube
      Stefan Grube
      Blog Post Author
      Hi Piyush,

      As the IDOC adapter is coded in ABAP and therefore not part of the adapter framework, this Blog is not applicable for problems with the IDOC adapter.

      Describe your problem in the SDN forum.


      Author's profile photo Former Member
      Former Member
      Excellent blog which helped me better my knowledge.But have one question.The very reason why we use EOIO is to maintain the sequence of messages.By cancelling the blocked message are we not forcing others to post to the application system, in which case are we not missing the sequence defeating the whole purpose of EOIO?
      Appreciate your answer.
      Author's profile photo Mallikarjuna Rao Malisetti
      Mallikarjuna Rao Malisetti
        I faces situation where  EO messages got struck in the adapter engine. Is ther any way to deal with this.


      Author's profile photo Sudheer Jallipalli
      Sudheer Jallipalli
      During the migration process problems have been reported for this blog. The blog content may look corrupt due to not supported HTML code on this platform. Please adjust the blog content manually before moving it to an official community.
      Author's profile photo Sudheer Jallipalli
      Sudheer Jallipalli
      Hi Stefan,
      How do I process messages with status = "Holding" from the RWB-Message Monitoring - Adapter Engine?

      I did a quick scan for records with errors in the same queue (ConversationID), but could not find any.

      I tried to cancel the one with the smallest sequential number, but I got the error - "Unable to cancel 1 of 1 messages; update the status"

      Please help.

      Author's profile photo Former Member
      Former Member
      Dear Stephan

      We have a File to RFC scenario which sends Return documents from
      supermarkety outlet to the warehouse. Following are the interface

      The messages are successfully delivered from IE to AE and its shows
      successfully processed flag in / chequered flag in SXMB_MONI. No
      messages are stuck in IE queue (SMQ2). But the message is stuck in AE
      with status "Delivering". I can not resend or cancel the message coz
      the status is "delivering".

      This has become an operational problem where messages were not getting
      transferred from SAP to Warehouse system (3rd party system).

      Only workaround which we have done is to restart the Java stack which is not going to be the solution in going forward.

      though there are severel messages transfered after the restart it does not show in message monitoring->
      Adapter engine ..?

      wher are theese messages reside?? how can i see all the blocked messgaes ?/



      Author's profile photo Bruce Hartley
      Bruce Hartley


      Thank you for this writeup - this just saved me a lot of time when this happened a few weeks after I had set up an EOIO queue to serialize IDOC's to a remote application.  And I can say the the queue is working - all too well.

      Buddhike Perera brings up a good point - why aren't thse in SMQ2?  In my case it's a remote application that the message got delivered to and something in the data was bad that it didn't like and it decided to throw an error on it, which then in turn held everything else up.  But having to use RWB to find these was a real pain, there should be a transaction that can show this and due to the fact the users want more EOIO queues, I may develop one.

      To anyone else wanting to do this, you don't need to go as far in RWB as Stefan did, all I did was look for things on hold and narrowed the date range down to find the date things started going on hold, then looked for an error on that day - and that found it quickly.  It may be that worked in my case because I had everything going to one destination which made for an easy filter.  Also limiting the status to what I was looking for helped a lot.