Automatic resend of the wrong Xi message

Messages in Xi can fail due to parse 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

In inbound queuesSysfailStatus data. When this error occurs, the entire queue cannot be processed. You can manually trigger the queue to re-process the data using t-code: smqr or smq2,

You can set the following parameters to enable automatic resend of message queue.
Monitor qrfc_restart_allowed to value 1

You can also customize a job.Report rsqiwkex for periodic running.

B)Trfc errors
Like qrfc errors one can either manually or automatically initiated processing of messages hanged trfc CILS.
Manual resend of messages:Use transaction sm58 and check through the list. If necessary, start hanging trfc CILS
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 failed and had failed due transient system/configuration failures can be manually restarted in sxmb_moni.

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

Option 1
Is_retryA 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 2The problem with setting is_retry is that every message with a failure status will be retried every 2 minitues till the maximum number of retries is reached. since there is no control on the retry period, a high retry count cocould 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
Qrfc	Smq2	Rsqiwkex
Trfc	Sm58	Rsarfcex
Other errors	Sxmb_moni	Rsxmb_restart_messages

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 message3 timesAt intervals5 minutesBefore the status of the message is changed fromWaitingToSystem 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 wowould want XI to resubmit the message automatically without human intervention. what wocould 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.

Conclusion
Error in Xi are inevitable, but when they occur we shoshould 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 following ways of restarting these messages.