Professional Documents
Culture Documents
SAP PI Monitoring Activities PDF
SAP PI Monitoring Activities PDF
SAP PI Monitoring Activities PDF
8. Run transaction SM21 (Read System Log) on the XI server to look for error messages around the
time you got the error.
9. Check the all instances of your Production Server are running fine.
To check this, use SM51 transaction. All instances should be in active state
Now we are done with ABAP side Monitoring.
Check the log and Traces file
Check the URL for server monitoring
http://:500/MessagingSystem/monitor/systemStatus.jsp
Ref: from
http://www.saptechnical.com/
http://wiki.sdn.sap.com/wiki/display/XI/Michal+Krawczyk+-+FAQ+blog+-+Wiki
http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/2728
http://wiki.sdn.sap.com/wiki/display/XI/Troubleshooting
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)
2. Memory
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)
RWB:
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)
More inportantly if you have Wily INTROSCOPE in your environment look for trends in
messages, garbage collections, etc.
And more in detail documentation on 'Process Integration PI 7.1' Trobleshooting Guide
https://websmp104.sap-ag.de/operationsNWpi71
-> Process Integration
-> Troubleshooting Guide - SAP NetWeaver PI 7.1
These messages do not get picked up automatically and it is not possible restart them
from using RWB or the transactions like SXI_MONITOR/SXMB_MONI.
Such messages could be processed in the following way:
Send data directly to Integration Engine
Change the status of failed message
This example shows how to solve the problem two error messages are shown and
one of them is solved here.
Step 1: Send data directly to Integration Engine
Go to Component Monitoring in SAP XI Runtime Workbench. Click on the Test
Message tab for the Adapter Engine. Specify the URL of SAP XI Integration engine to
send the message to e.g. http://:/sap/xi/engine?type=entry
When we log in to ABAP stack and hit the transaction SXI_CACHE there you can observe the status will
be in red color and the cache will not be up-to-date and unable to refresh cache. Even though if we
perform the cache refresh the changes are not reflecting since the cache is not working properly.
From IR from menu using cache notifications we can see whether cache is refreshing or not. From that
option also it shows the status as RED color and cache is not up-to-date and cache is not refreshing.
So how to resolve this issue and what might be the problem for displaying the status as red and cache is
not up-to-date.
To resolve this issue logon ABAP stack and check the RFC Destination of
Type H: INTEGRATION_DIRECTORY_HMI in this check whether the path prefix is maintained or not.
If we observe the above screenshot we can identify that path prefix as not maintained anything. So
maintain the path prefix as in the below screen shot and save it.
After performing the above step go to SXI_CACHE and perform cache refresh. Now cache will perform
the refresh and the status will be as below.
admin SAP PI
Sap pi PAG(problem analysis guide)
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
queues 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
MONITOR QRFC_RESTART_ALLOWED to value 1
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
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.
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).
Type of Error
qRFC
SMQ2
RSQIWKEX
tRFC
SM58
RSARFCEX
OTHER errors
SXMB_MONI RSXMB_RESTART_MESSAGES
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 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.
Conclusion
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.