- If you are stupid enough to setup the SAP/XI server on Windows (particularly 32-bit) OS (and/or be responsible for it), make sure that the kernel has enough resources to handle the zillion connections required for XI operation. You will NEED to keep the Memory / Free System Page Table Entries (PTEs) at least 20.000. You can monitor this with "perfmon.msc". If this number drops well below 20k, you will experience sever problems: dropped connections, internal time-outs and plenty of HTTP errors (401, 503, etc). Anyway, check the boot.ini switches /USERVA, /3GB, /PAE and set them following Microsoft rules.
- Bare in mind that XI requires plenty of power and resources. It starts several virtual machine instances (both ABAP and JAVA/J2EE) and handles heavy network load. These need plenty of memory and a good OS kernel. When setting up an XI server, these things should be taken into account.
- XI Administration: SXMB_ADM. Manages every aspect of XI operation from the R/3 end, including queues, archiving and deletion, as well as various system-wide definitions.
- ICM Monitor: SMICM. Supreme overlord for Java maintenance from the R/3 end. Permits J2EE restarts (Check "Administration" menu) and offers useful Java monitor stats.
- Queue monitors: SMQ2, SMQ1, SMQ3. If any message is stuck in the way in or out of the XI switch, you'll find it here. Watch particularly for SMQ2. If you are unlucky to find out that a certain queue is stuck (the top message failed to get processed), select the message and press SHIFT+F6 (Save LUW). This will send it at the end of another queue, permitting processing of the next messages. Note: XBTI* are queues for incoming messages, XBTO* are queues for outgoing messages.
- Message monitor: SXMB_MONI. Find recent messages with errors (inbound or outbound) and generally anything that goes through XI. Perhaps the most useful transaction, but with rather limited search criteria options :-(
- Business Process Engine monitors: SXMB_MONI_BPE. A useful list of monitoring tasks for the status of the XI Processing Engine.
- BPE Errors: SWF_XI_SWI2_DIAG. A sub-section of BPE monitors for latest errors.
- Outgoing RFC monitor: SM58. Find out if another R/3 system has problems processing the messages that XI sent.
- Local RFC Monitor: SWF_XI_SWU2. Monitor the XI ABAP processing status.
- Hardcore message monitoring/retrieval: SE16. For hardcore problems, you can always resort to the tables, that XI uses to store (persist) transferred messages. Look into tables: SXMSPMAST (master table), SXMSPERROR/SXMSPERRO2 (error message info), SXMSPVERS, and some other. NOTE: XI_AF_* tables, that exist in the SAP XI DB (part of the J2EE adapter framework), are NOT managed by R/3 and do NOT exist in the ABAP workbench.
- IDoc monitoring: IDX5. Useful for finding the status of certain R/3 objects (materials, sales/purchase orders, etc) that seem to be lost in the XI way. You need the IDoc number, the Message GUID, or a combination of time-date and IDoc type. Extremely useful when checking with other modules/systems and SAP users.
- TCP/IP listeners: SMMS. See where the XI engine listens for incoming client connections in the TCP/IP level. Quite useful in conjunction with netstat, telnet, wireshark/ethereal and other networking tools.
- Monitor Communication Channel status: Check channels for hidden errors (e.g. "why my file does not get parsed from XI?"); start/stop channel service (common solution for old XI systems); monitor produced/consumed messages.
Access from: Component Monitoring / Adapter Engine / Communication Channle Monitoring.
URL: http://<server_ip>:<adm_port>/rwb/index.jsp - Monitor Messages: Just like SXMB_MONI, but this is more reliable, in some cases.
Access from: Message Monitoring. - Check user locks: Remove stale locks from missed connections, etc. in Repository/Directory.
Access From: XI Tools / Administration / Repository / Lock Overview
URL: http://<server_ip
>:<adm_port>/rep/support/public/LockAdminService
All XI messages follow the SOAP/XML scheme. When a specific problem is found with a message, it is always good practice to look into its Trace section, apart from the Error section. Most likely, the trace contains a Java stack trace, from which, the top entry is of interest.