Skip to Content

Messages in XI can fail due to many reasons. Most of the common failures are due to connection failure to end systems, wrong or missing configuration settings, exceptions that weren’t handled or lack of disk space for processing messages. These errors can be categorized as  those generated in 
                    I.  Integration Engine
                    II. Adapter Engine.

I. Errors in Integration Engine

a)  qRFC Errors
Often in asynchronous scenarios where inbound queues are used, the queues are set to SYSFAIL status and all the messages in the inbound queue are stuck (not processed).  Depending on the status of XI processing queues, we can  reset a queue’s status and trigger processing of messages.

Manual Resend of messages:  Use transaction SMQR or SMQ2 to reset the status of queues. As you can see in the following figure, the queue has been marked with a status sysfail.


To be able to initiate processing of messages stuck in the queue, make sure to set following IS configuration parameter


For automatic qRfc failure recovery, schedule the report RSQIWKEX to run periodically. This report enables automatically resets the queues.

b) tRFC Errors
Like qRFC errors one can either manually or automatically initiated processing of messages hanged tRFC calls.
Manual Resend of messages:Use transaction SM58 and check through the list. If necessary, start hanging tRFC calls
under the Edit menu by choosing Execute LUWs.
For automatic tRfC failure recover, schedule the report RSARFCEX for periodic execution.

c) Other Errors
All the errors generated and captured in Integration engine can be viewed using transaction SXMB_MONI. Message that were sent asynchronously and had failed due transient system/configuration failures can be manually restarted in SXMB_MONI.


But would it be fun to restart many messages manually. What is required is a way to be able to automatically resend messages that error out. Thankfully there are many ways of doing this in XI.

Option 1
A batch job( internal in XI) is automatically scheduled to reprocess the entry after 2 minutes.
If the maximum number of retries was reached (10 by default; IS configuration parameter
TUNING IS_RETRY_LIMIT), a communication error then causes a SYSFAIL status for a queue.

Option 2 The problem with setting IS_RETRY is that every message with a failure status will be retried every 2minitues till the maximum number of retries is reached. Since there is no control on the retry period , a high retry count could cause excessive load on XI. The other option is to do Mass Restart  by scheduling the report RSXMB_RESTART_MESSAGES at a predetermined retry period like 1hr. There is a catch here, RSXMB_RESTART_MESSAGES tries to restart a failed message 800 times by default. So if there is a message that failed due to genuine reasons, we may want to limit the number of retries. It is recommend by SAP to reduce the retry count to 20 restarts. (You can always manually restart a message, from the monitor, up to 990 times).

This value can be maintained in SXMB_ADM-> specific configuration ‘DELETION’  ‘MAX_VERSION’    ‘BATCH_RETRY’ . If you don’t see the DELETION category , you must run the report RSXMB_CREATE_CONF_ENTRIES3 to generate the configuration parameter.

Finally here is the table that describes ways to handle resubmit of errors in Integration Engine

Type of Error

Manual Start

Automatic Start







OTHER errors



II. Errors in Adapter Engine
Till now we have seen how to resubmit/restart message that failed in Integration Engine.  One a message makes it from Integration Engine to Adapter Engine, the message is flagged as checked in Integration Engine. The status of the message in Adapter engine does not effect the processed state in Integration Engine. Now if this message was asynchronous, XI will by default try to restart the message 3 times at intervals of 5 minutes before the status of the message is changed from Waiting to System Error .




As shown in the above figures a message is initially put into waiting status, XI tries 3 times before changing the status of the message to System Error. One can Manually resend the error messages by using the RESEND button in RWB. In scenarios where XI was trying to send the message to an end system that was down for maintenance, you would want XI to resubmit the message automatically without human intervention. What would be nice is to able to tune the retries like IS_Retry which is available for Integration engine.
We can achieve this by changing the retry count used by the Adapter Engine, by default its set to 3 times, 5 minutes apart. This count can be changed in Visual Admin->server->services-> SAP XI Adapter: XI.
Here  change the number Retries parameter from 3 to 10 and change the retry retryInterval to around 10minutes. For these configuration changes to be picked up, restart SAP XI Adapter: XI.

Error in XI are inevitable, but when they occur we should be able to restart or resend the messages in a way that requires minimal human intervention, especially if the errors were due to system outage or system memory exceptions. In this weblog I have tried to list out the most commonly occurring errors and the many ways of  restarting these messages.

To report this post you need to login first.


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

  1. Sriram Vasudevan
    U have done a good job of documenting the various options for restarting msgs in XI..Appreciate your effort in putting these options together..More blogs like these pls..

    Sriram V.

      1. Dhanya Nair
        Hi Naveen
        Is there any way to restart the messages failed in Adapter engine. I feel the report RSXMB_RESTART_MESSAGES only takes care of IE failed messages.

        Plz guide.

      2. Dhanya Nair
        Hi Naveen
        Is there any way to restart the messages failed in Adapter engine. I feel the report RSXMB_RESTART_MESSAGES only takes care of IE failed messages.

        Plz guide.

  2. Kirk.A. Miller
    Thanks for the suggestions on resending failed XI messages.  This is extremely helpful and provides the answers my client was looking for.  Great blog!
  3. Andrzej Burakowski
    Your blog was very helpful for me, but do you know, if there is any other way to restart automatically the fail message in the adapter (RTW)?
    I memorize in a table the times, when particular business systems are expected to be out of order. There is no purpose to resend the message from the adapter if the receiver doesn’t work. But I cannot select the messages in adapter by setting the system configuration. Therefor I need a report or a fuction.
  4. naveen chitluri

    If there is an AE error and the message is synchronous. How many times does it try and with what intervals.

    I am looking for sth, to reprocess all the error messages, sth like SELECT ALL> RESEND should resend all the messages.


    1. Hi,

      Xi will retry only message of QOS type asynchronous. If a sychronous message fails, the error will propogated back to the call initiater.


  5. Kalyan Veerapaneni

    It helps a lot knowing how to handle the unsuccessful messages. I have a question regarding the status of the failed messages ( after the no.of retries reached). I think those messages will be deleted from the XI, is it correct?

    Can we write these old messages to any temp queue and when we know that the problem with the other end is corrected, can we resend them?

    Please clarify.


    1. Hi,

      >>I think those messages will be deleted from the >>XI, is it correct?
      There messages will not be deleted, unless you have an archival job running that archives the messages.

      >>Can we write these old messages to any temp >>queue and when we know that the problem with >>the other end is corrected, can we resend them?
      No, you cannot put them into a fail queue. I think you are familliar with MQSeries, where failed messages can be put into a Fail queue. In XI this is not possible. But failed messages can be manually restated at any time.


      1. Hi,

        good blog, just a small correction to the previous comment:
        >>I think those messages will be deleted from the >>XI, is it correct?
        >There messages will not be deleted, unless you >have an archival job running that archives the >messages.
        Actually messages will only be deleted or archived (depending on what is configured) when they have reached a final state, due to the fact that XI supports guaranteed delivery. A final state is only reached when a message is cancelled or successfully processed.


  6. Vijayakanth Vangala
    If we set the number of retries to 10 and the delivery fails all ten times due to a error in the program of the target system, the message goes into system Error. At this point I correct the program and try to resend the message but it does’t resend, some times it gives a message saying that the “messages in this status cannot be resent”.

    How to get over this problem?


  7. can to help me out from this problem….
    Inbound qRFC problem recorded in the QTABLE:XI Error NO_RECEIVER_CASE_ASYNC.RCVR_DETERMINATION
  8. S. Gokhan Topcu
    “IS_Retry A batch job( internal in XI) is automatically scheduled to reprocess the entry after 2 minutes.”

    I could not find a IE configuration parameter like this, nor a scheduled job or a report. Could you clarify what this is? In the default settings, does PI automatically restart any messages with temporary errors? Thank you.

  9. Tarun Bakshi
    Naveen, Nice blog !

    I have one question on Inbound queue processing:
    It is an Asynchronous Inbound scenario from PI to ECC.
    The queue is correctly passed on from PI to ECC with status READY. However I have to manually go to SMQ2 to process the QUEUE.
    The queue name in my name is dynamic and start with XBQR……. followed by PO number
    I checked in sxmb_adm and the queue are registered and activated.
    What do I need to do to make sure the queues are automatically processed.
    I understand from your blod I have to schedule “RSQIWKEX” to reprocess the errored queues but how about running it automatic the first time.
    Please let me know.



Leave a Reply