Activities for Production Support and Maintenance projects in SAP PI/XI
and perform the following:
a) Click on Component Monitoring and then click on display and then to Monitor your Adapter engine click on Adapter Engine.
b) In Adapter Engine Monitoring, monitor the adapter with errors.
c) After doing this monitoring activity click on Message Monitoring.
d) To do this click on Message Monitoring Tab.
e) Now choose free entry from start/end date combo Box and then choose the status of messages that were processed by Adapter engine.
f) Check the messages for To be delivered state.
g) Check the messages for Delivering state.
h) Check the messages for All containing error state.
i) Use filter in this monitor page if needed.
To check this, use SM51 transaction. All instances should be in active state
Ref: from http://www.saptechnical.com/
1. Process XML messages – Standard and Process (check for message failures, determine if ABAP or Java related)
2. Job Overview
3. Persistence Layer Analysis (Observe growth day to day, no sudden jumps).
4. Tcode: SMQ2, SMQ1 (check for blocking)
5. Tcode: SM66 (no long running DIA)
6. Tcode: SM21, ST22 (look for unusual errors)
7. Tcode: ST04 (Overview - hit ratios)
8. Tcode: ST06
1. CPU (no overloads)
9. Tcode: ST03 (Workload overview. Response times, special attention on DIA, HTTP)
10. Tcode: SMICM (for each server: look for Current/Peak/Maximum values and make its not Peak is not hitting MAX)
1. Message Monitoring – Database (overview) -Integration Engine and Adapter engine (Look for unusual errors)
2. Performance Monitoring – last 7 days/Daily (look for volume jumps)
And more in detail documentation on 'Process Integration PI 7.1' Trobleshooting Guide
-> Process Integration
-> Troubleshooting Guide - SAP NetWeaver PI 7.1
XI/PI: Dealing with Errors on the Outbound side
- Send data directly to Integration Engine
- Change the status of failed message
Problem with Cache RefreshWhen we perform any changes to our design objects and configuration objects which were created in our IR and ID and if the changes were not reflected to that objects, at that time every one mind would point to perform the cache refresh. We have different options available to perform the cache refresh.
- In IR from MenuàEnvironmentàClear SLD Data cache.
- In ID from Menu ClearàEnvironmentàSLD Data Cache.
I. Integration Engine
II. Adapter Engine.
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.
MONITOR QRFC_RESTART_ALLOWED to value 1
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.
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.
IS_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.
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.
Type of Error
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 .
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 inVisual 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.