You are on page 1of 10

SAP PI Monitoring activities

Activities for Production Support and Maintenance projects in SAP PI/XI
While working in a Production Support and Maintenance project, we have to perform a series of day to day activities as a responsibility of an SAP PI / XI consultant. Here, I would like to list a series of steps that may be useful to monitor the PI / XI Production server. J2EE Engine side monitoring: 1. Enter the URL for all the instances of your Production Server http://:500/rep/start/index.jsp Make sure that these links are responding. 2. Go to Runtime Workbench (RWB) using URLhttp://:500/rwb 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. Once done with all of the above activities means we are done with J2EE Engine side Monitoring. ABAP side monitoring: 1. Use SXMB_MONI. Transaction to monitor the messages which are processed through the entire XI pipeline that is Integration Server. 2. Use SXMB_MONI_BPE Transaction to monitor the messages which are processed by BPE (Business Process Engine). 3. Use SM37 to check the Job status. 4. Use SMQR Transaction for monitoring the XI Run Time queues (I/B, O/B Queues). 5. Use SMQ1 Transaction for monitoring the XI Run Time queues (O/B Queues). 6. Use SMQ2 Transaction for monitoring the XI Run Time queues (I/B Queues). 7. Use SLDCHECK to check SLD Connection. If there are any red entries then report it to SAP Basis Team.

Tcode: ST06 1. garbage collections. All instances should be in active state Now we are done with ABAP side Monitoring.8. 4.1' Trobleshooting Guide . And more in detail documentation on 'Process Integration PI 7. 9. Job Overview 3. Check the all instances of your Production Server are running fine. Tcode: SM66 (no long running DIA) 6. To check Persistence Layer Analysis (Observe growth day to day.hit ratios) 8. no sudden jumps). Process XML messages – Standard and Process (check for message failures. Tcode: ST04 (Overview . 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. Tcode: SMQ2. etc. SMQ1 (check for blocking) http://wiki.jsp Ref: from http://www. Memory http://wiki. Tcode: SMICM (for each server: look for Current/Peak/Maximum values and make its not Peak is not hitting MAX) RWB: 1.sdn. ST22 (look for unusual errors) 7.saptechnical. CPU (no overloads) http://www. HTTP) 10. Response times. Run transaction SM21 (Read System Log) on the XI server to look for error messages around the time you got the 1. determine if ABAP or Java related) 2. Message Monitoring – Database (overview) -Integration Engine and Adapter engine (Look for unusual errors) 2. Tcode: ST03 (Workload overview.sdn. use SM51 transaction. Tcode: SM21. special attention on  Check the log and Traces file  Check the URL for server monitoring http://:500/MessagingSystem/monitor/systemStatus.

This article explains how to deal with such Specify the URL of SAP XI Integration engine to send the message to e. in some -> Process Integration -> Troubleshooting Guide .https://websmp104. 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. It may not be possible to restart them from using RWB or the transactions like SXI_MONITOR/SXMB_MONI. 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. Generally. Click on the Test Message tab for the Adapter Engine. http://:/sap/xi/engine?type=entry . (Transactions – SXI_MONITOR/SXMB_MONI). However.1 XI/PI: Dealing with Errors on the Outbound side Sometimes the link between SAP XI and the target system (say ERP) goes down and messages fail on the outbound side. it may be possible that SAP XI server could not finish conversation with ERP. Main status of messages is “Processed successfully” – but there is an error in the outbound side as shown below.SAP NetWeaver PI 7. Step 1: Send data directly to Integration Engine Go to Component Monitoring in SAP XI Runtime Workbench.g. messages are picked up and sent via SAP XI when the link returns.

Specify the header Information. Step 2: Change the status of failed message Call the transaction SWWL. Copy payload of the message using SXI_MONITOR/SXMB_MONI and paste it into Payload area in RWB. Send the message using Send Message button. .

Delete appropriate work items. . Check that the messages are complete in SXI_MONITOR/SXMB_MONI.

In these ways we can reprocess the messages failed on the outbound side. 1. information collected from Problem with Cache Refresh When 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. In ID from Menu ClearEnvironmentSLD Data Cache. then they can still be traced via outbound queues or SM58 logs and restarted. If the messages do not participate in BPM process. . In IR from MenuEnvironmentClear SLD Data cache. 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. Choose the appropriate line item and click on Restart workflow button. From PI home page under administration we have the cache overview. We have different options available to perform the cache refresh. Select Continue Process Following Error under Business Process Engine -> Monitoring and Execute (F8). Update the selection criteria as required and Execute (F8). Even though if we perform the cache refresh the changes are not reflecting since the cache is not working properly.Another simpler way to accomplish this is to use transaction SXMB_MONI_BPE . 2.

From IR from menu using cache notifications we can see whether cache is refreshing or not. 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. From that option also it shows the status as RED color and cache is not up-to-date and cache is not refreshing. information collected from archiving and deleting jobs in SAP PI . 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. 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. So maintain the path prefix as in the below screen shot and save it.

wrong or missing configuration settings. I. schedule the report RSQIWKEX to run periodically. Manual Resend of messages: Use transaction SMQR or SMQ2 to reset the status of queues. the queues are set to SYSFAIL status and all the messages in the inbound queue are stuck (not processed). make sure to set following IS configuration parameter MONITOR QRFC_RESTART_ALLOWED to value 1 For automatic qRfc failure recovery. What is required is a way to be able to automatically resend messages that error out. schedule the report RSARFCEX for periodic execution. exceptions that weren't handled or lack of disk space for processing messages. As you can see in the following figure. c) Other Errors All the errors generated and captured in Integration engine can be viewed using transaction SXMB_MONI. b) tRFC Errors Like qRFC errors one can either manually or automatically initiated processing of messages hanged tRFC calls. we can reset a queue’s status and trigger processing of messages. start hanging tRFC calls under the Edit menu by choosing Execute LUWs. Integration Engine II. These errors can be categorized as those generated in I. But would it be fun to restart many messages manually. Adapter Engine. Errors in Integration Engine a) qRFC Errors Often in asynchronous scenarios where inbound queues are used. For automatic tRfC failure recover. If necessary. Thankfully there are many ways of doing this in XI.admin SAP PI Sap pi PAG(problem analysis guide) Messages in XI can fail due to many reasons. Depending on the status of XI processing queues. the queue has been marked with a status sysfail. . This report enables automatically resets the queues. Manual Resend of messages: Use transaction SM58 and check through the list. Message that were sent asynchronously and had failed due transient system/configuration failures can be manually restarted in SXMB_MONI. To be able to initiate processing of messages stuck in the queue. Most of the common failures are due to connection failure to end systems.

up to 990 times). If you don't see the DELETION category . . RSXMB_RESTART_MESSAGES tries to restart a failed message 800 times by default. the message is flagged as checked in Integration Engine. you must run the report RSXMB_CREATE_CONF_ENTRIES3 to generate the configuration parameter. This value can be maintained in SXMB_ADM-> specific configuration 'DELETION' 'MAX_VERSION' 'BATCH_RETRY' . So if there is a message that failed due to genuine reasons. Since there is no control on the retry period .Option 1 IS_Retry A batch job( internal in XI) is automatically scheduled to reprocess the entry after 2 minutes. 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. Errors in Adapter Engine Till now we have seen how to resubmit/restart message that failed in Integration Engine. It is recommend by SAP to reduce the retry count to 20 restarts. Finally here is the table that describes ways to handle resubmit of errors in Integration Engine Type of Error qRFC tRFC OTHER errors Manual Start Automatic Start SMQ2 SM58 RSQIWKEX RSARFCEX SXMB_MONI RSXMB_RESTART_MESSAGES II. from the monitor. The status of the message in Adapter engine does not effect the processed state in Integration Engine. (You can always manually restart a message. The other option is to do Mass Restart by scheduling the report RSXMB_RESTART_MESSAGES at a predetermined retry period like 1hr. IS configuration parameter TUNING IS_RETRY_LIMIT). 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 . One a message makes it from Integration Engine to Adapter Engine. Now if this message was asynchronous. If the maximum number of retries was reached (10 by default. a communication error then causes a SYSFAIL status for a queue. There is a catch here. a high retry count could cause excessive load on XI. we may want to limit the number of retries.

This count can be changed inVisual Admin->server->services-> SAP XI Adapter: XI. For these configuration changes to be picked up. by default its set to 3 times. 5 minutes apart. especially if the errors were due to system outage or system memory exceptions. . In scenarios where XI was trying to send the message to an end system that was down for maintenance. What would be nice is to able to tune the retries like IS_Retry which is available for Integration engine. you would want XI to resubmit the message automatically without human intervention. Here change the number Retries parameter from 3 to 10 and change the retry retryInterval to around 10minutes. One can Manually resend the error messages by using the RESEND button in RWB. restart SAP XI Adapter: XI. XI tries 3 times before changing the status of the message to System Error. but when they occur we should be able to restart or resend the messages in a way that requires minimal human intervention. We can achieve this by changing the retry count used by the Adapter Engine. In this weblog I have tried to list out the most commonly occurring errors and the many ways of restarting these messages.As shown in the above figures a message is initially put into waiting status. Conclusion Error in XI are inevitable.