restart falied xi messages[1]

8/3/2019 Restart Falied Xi Messages[1]

http://slidepdf.com/reader/full/restart-falied-xi-messages1 1/5

XI : How to Re-Process failed XI Messages AutomaticallyNaveen Pandrangi Business Card Company: Valero Energy CorporationPosted on Nov. 29, 2005 10:53 AM in SAP Exchange Infrastructure (XI), Service-Oriented Architecture

Messages in XI can fail due to many reasons. Most of the common failures are due to connection failure to end systems, wrongor missing configuration settings, exceptions that weren't handled or lack of disk space for processing messages. These errorscan be categorized as those generated in

I. Integration EngineII. Adapter Engine.

I. Errors in I ntegration Engine

a) qRFC Errors Often in asynchronous scenarios where inbound queues are used, the queues are set to SYSFAIL status and all the messagesin 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 followingfigure, 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 parameterMONITOR QRFC_RESTART_ALLOWED to value 1

For automatic qRfc failure recovery, schedule the report RSQIWKEX to run periodically. This report enables automatically resetsthe 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 weresent 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 messagesthat error out. Thankfully there are many ways of doing this in XI.

Option 1IS_Retry 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 themaximum number of retries is reached. Since there is no control on the retry period , a high retry count could cause excessiveload on XI. The other option is to do Mass Restart by scheduling the report RSXMB_RESTART_MESSAGES at a predeterminedretry 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 bySAP 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 theDELETION 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 fromIntegration 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 bydefault try to restart the message 3 times at intervals of 5 minutes before the status of the message is changed fromWaiting 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 themessage to System Error. One can Manually resend the error messages by using the RESEND button in RWB. In scenarioswhere XI was trying to send the message to an end system that was down for maintenance, you would want XI to resubmit themessage automatically without human intervention. What would be nice is to able to tune the retries like IS_Retry which isavailable 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 theseconfiguration changes to be picked up, restart SAP XI Adapter: XI.

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

Naveen Pandrangi is a Lead SAP Specialist for Valero Energy Corporation

Variable time data for programs RSQIWKEX and RSQOWKEX SAP Note Number: 1259511

Symptom These corrections enable you to enter variable time data.

Other terms RFC, qRFC, RSQIWKEX, RSQOWKEX

Reason and Prerequisites In the programs RSQIWKEX and RSQOWKEX, the time was fixed (20 minutes) and you could not enter another time when you

called the report.

Solution By implementing these corrections, the applications can define another time.

Header Data Release Status Released for Customer

Released on 27.10.2008

Priority Correction with low priority



Category Program error

Primary Component BC-MID-RFC RFC

Release

Soft. Component Release Track From Release To Release And Successors

SAP_BASIS 60 620 640



Correction Instructions CorrectionInstruction

Valid from Valid to Installation Soft. Component ID

Ref. Correction Modification Status Last Changed on

0000697265 620 711 0120031469 SAP_BASIS 41

Y7CK024523 Released 26.10.2008 11:30:31

Support Packages Add toBasket

Software Component Release Package Name Download

SAP_BASIS 620 SAPKB62066






Related notes No related notes available

Attributes No attributes available

Attachments No attachments available

Reason - Side Effects SAP Notes / Patches corrected by this Note

restart falied xi messages[1]

Documents