Performance Analysis with Single Message

Problem Description
Processing of an XI message takes long in specific pipeline step.

Example Scenario

During a GoingLive Optimization Session for an SRM scenario, an invoice is send from an SUS System to an MM backend via XI as a pre-production test. A standard SAP scenario SUS2MM is used for the interface. The total response time of the business process is more 2,3sec, which is not acceptable for the customer, since the business process is time-critical and has a high volume.

Scope
Component: XI 3.0, Validity: XI 3.0, SP1 Used Tools: SXMB_MONI, Performance Header Display, Visual Administrator, Jarm Statistics

Verification of Symptoms
Start SXMB_MONI, select the particular XI message and go to the performance header. Pipeline step PLSRV_MAPPING_REQUEST is longest pipeline service.

Possible Error Causes

Bad mapping algorithms

118381127.doc

Page 1 of 53

Analysis Overview

118381127.doc

Page 2 of 53

Analysis Details
In a pre-production system a single message of a specific type can be tested by sending it separately and looking at the response time within XI. Message monitoring (SXMB_MONI) Log on to the integration server and call transaction SXMB_MONI: Monitor for processed XML messages. A selection for the messages in status Processed Successfully during the last hour is done.

118381127.doc

Page 3 of 53

In the list of messages displayed, you can identify your message e.g. by the sender, receiver or time stamp. Select it with double-click and you can take a look at the message content.

Performance Header Choose the latest Performance Header from the tree on the left hand side and take a look at the soap header on the upper window on the other side.

By comparing the time stamps given in the format <YYYYMMDDHHMMSS.msec> for all pipeline steps, one can find the step with the longest time.

In this example the mapping step takes most of the time. You have to know the overall Xi architecture now, to find the next analysis step. The Mapping Request is the only step that is processed within the Java part of the WebAS. Therefore any further analysis has to be down with java monitoring tool.

118381127.doc

Page 4 of 53

Performance monitoring in the J2EE Engine Launch the J2EE Visual Administrator by executing the go.bat in path <>. You will see the cluster configuration in the tree on the left hand side.

Choose the relevant server node. Then expand Services and choose Application tracing and the tabulator JARM. To display any data, you always have to click on the refresh icon.

118381127.doc

Page 5 of 53

Sending an IDoc through XI Failed

Problem Description
An application sent an IDOC through XI. The respective message did not arrive at the receiver system. Example Scenario

Example Scenario

An application sent a message through XI. The message was sent as an IDoc and the IDoc number is known. The message should have been transformed on the Integration Server into an XI message, sent to the file adapter and stored on the file system from which a non-SAP application picks it up.
Scenario Type: NetWeaver Component: Validity: Error analysis XI 3.0 XI 3.0, SP6

Possible Error Causes

Faulty configuration in XI Directory, such as incorrect routing Faulty technical configuration of XI, such as the IDOC adapter is not properly configured Problems in underlying technologies, such as the file system is full

Decision Roadmap
Prerequisites Main Tools XI Runtime Workbench Transactions:
IDX1 IDX5 SXMB_MONI SM58 SM21

118381127.doc

Page 6 of 53

Analysis For an overview of analysis steps see the flow chart.

Flow Chart
...

1.

Gather information about the failed IDoc/message

In this step you need to get the relevant information to trace the document through XI, that is, to find out the path the failed document took from sender to receiver. Let us assume that the initial information includes the sending system SID, the time the IDoc was sent, and the sending message type.
2. Find the location of the failure

Try to find out in which XI component the error occurred. Candidate components depend on the scenario used. The standard scenario involves a sender system, the integration server (IS) and a receiver system. Basically, there are two ways to find out in which system the error occurred: Use the end-to-end monitoring, or search through the systems step-by-step beginning with the sender, then the IS and finally the receiver system using the individual monitoring tools.

118381127.doc

Page 7 of 53

Here we describe the individual monitoring (step-by-step approach), in other words, we successively inspect the component-based monitoring tools from sender through integration server, adapter engines to the receiver. The analysis starts with the sender system and proceeds towards the receiver. In the scenario described here, this process begins with checking the IDoc status in the sender.
3. Check the IDoc status on the sender

Call transaction WE05, either set an appropriate time frame or enter the IDoc number to see if the IDoc was sent. After you make a selection you see the following screen. Here you can see that there were a couple of IDocs that have not successfully been passed to the TRFC handling. In such cases, see the IDoc Interface documentation for further analysis. If transaction WE05 says that the IDoc handling was successfully passed to TRFC (status 03), look in transaction SM58 of the sender for errors of function block IDOC_INBOUND_ASYNCHRONOUS. For instance, you may find here the following entries:
Function Module: Target System: Date: Time: Status Text: IDOC_INBOUND_ASYNCHRONOUS <destination> 03.01.2004 14:02:22 Transaction IDX1: Port <port>, Client <client>, RFC destination contains errors

The following are possible error causes on the receiver:

1. Port/client not assigned to an RFC destination.

Call transaction IDX1 and check that an RFC destination is maintained for the port <port> and the client <client>. For IDocs that are sent from SAP systems, the port is assembled from the prefix SAP and the SID of the SAP system. Check whether the RFC destination has been entered correctly.
1. The RFC destination contains errors (for example, the user does not have required authorizations). Use transaction SM59 to check the RFC destination.

Initial screen of transaction WE05

118381127.doc

Page 8 of 53

Transaction WE05 search results

Errors caused by wrong IDOC configuration on IS

If the IDoc adapter is not properly configured on the integration server, these errors become visible on the sender system. Check transaction SM58 for failed IDoc function blocks. In case of authentication or authorization errors, you may also find information in the system log (transaction SM21). Possible errors:
1. Destination for reading meta data not defined in IDX1 2. Reading of IDOC meta data by IS failed due to authentication, authorization or other technical problems 4 Check XI Message on Integration Server

If the IDoc arrived at the IS, it is transformed into an XI message. Hence failures are always visible in the message monitor. The message monitor can be accessed through SAP GUI (transaction SXMB_MONI) or Web browser (XI Runtime Workbench). If you know already that the integration server is the location where the message failed (by having used the end-to-end monitoring for locating the error-causing system) you may skip section 4.1.

Port definitions

4.1

Determine whether the error occurred on IS

Check IDoc in IDX5 Log on to the XI system and check the inbound queue to see if the IDoc was received. For this purpose, use transaction IDX5. You must enter the time frame of when the IDoc was sent. In the figure below you can see the output of transaction IDX5.

Transaction IDX5

118381127.doc

Page 9 of 53

MessageIDis the GUID of the XI system for this particular IDoc. The IDoc number is the IDoc number as stored by the Integration Server. Transaction ID is the transaction ID which is used in the sending process of the IDoc. Check associated message in SXMB_MONI When you double click the entry in IDX5, you come to SXMB_MONI where you see details of the faulty message. See section 4.2 for how to proceed further.
4.2 Find error cause

Open the detail view of the faulty message. There are different ways to display the detail message view:
1. Navigate directly from end-to-end monitoring 1. Navigate through the message list, then select the faulty message. In the detail view, inspect the error header of the message.

In the example above, you can see an error code (OUTBOUND_BINDING_NOT_FOUND), with explanatory text: No receiver agreement found for sender INLD50033057,PIP0C2_R0102_Responder and receiver U6X,PIP0C2_R0102_Initiator,http://sap.com/xi/RosettaNet /PIP0C2_R0102,AsynchronousTestConfirmationAction So when there are errors in the Integration Engine, this information can help you to find problems. Typical error categories are sketched in the subsequent chapters.

Message details on the Integration Engine

4.2.1 Configuration Error 4.2.1.1 Error in inbound processing

No business systems are defined in the SLD for the sending system ID and client. As a consequence, the transformation of the IDoc to the XI message failed.

4.2.1.2 Routing error

If the receiver of a message cannot be determined, this may have two causes:

The definitions in the XI directory are inconsistent or incomplete. Example: For a given set of message header information, no receiver determination has been defined. Then this message cannot be delivered. This

118381127.doc

Page 10 of 53

is also the case if the physical address information is undefined or wrong (wrong URL, wrong user). The technical base configuration is wrong. Example: The target business system used in a receiver determination is not defined in the SLD, or the user for logging on to the target system does not have the required authorizations.
You find the receiver determined by the Integration Server in the element <SAP:RECEIVER> of the main header. The addressing information is computed in the pipeline step Technical Routing and entered in the header OutboundBinding. The following are typical routing error situations:

1. No outbound binding found. Correction: Define an outbound binding for this message in the XI directory. Restart the message. 2. No receiver agreement found. Correction: Define receiver agreement in the XI directory. Restart the message. 3. Wrong physical address. After successful execution of the pipeline step Technical Routing, the message header OutboundBinding specifies the technical address in the element ChannelAttributes. The physical address may be specified by means of an SM59 destination, or by defining the target URL directly in the header. In the former case, open transaction SM59 and check the destination specified. In the latter case, check whether the attributes in the header define a valid target address.

Receiver determination

4.2.1.3 Mapping error

See problem analysis scenario Mapping Fails for a Certain Message Type.

4.2.1.4 Problem with cache update

Reload cache, see problem analysis scenario Mapping Fails for a Certain Message Type.

118381127.doc

Page 11 of 53

Sample communication error

4.2.1.5 Outbound Adapter

Here, the relevant pipeline step in the message monitor is call adapter. A number of HTTP communication errors may occur. See the HTTP documentation on error codes for further analysis of the problem cause. Depending on the specific error code, you may have to check the address that has been determined in the pipeline step Technical Routing and can be found in the outbound binding. Check whether the address points to the intended receiver (in our scenario, the intended receiver is the adapter engine) and that the authentication data are valid. If the outbound binding refers to a SM59 destination, you can test the connection by means of transaction SM59. In the case of authentication or authorization errors (HTTP error codes 401, 403), make sure that the user and password are defined on the receiver (on the adapter engine), and that the user has the proper role (the user needs to have the role SAP_XI_IS_SERV_USER_MAIN).

4.2.1.6 Low-level technical problem

Possible error causes are: Wrong message format, code page not available. In this case you have to analyze further with technical experts.

4.2.2 Check integration server queues whether message is stalled If the message that has not yet been delivered is not in error state, the problem cause is probably that the message is blocked in the QRFC queues of the Integration Engine. Check queue status Call the Integration Server and call transaction SMQR in the sender and receiver Integration Engine in the corresponding system client. Check the status of the scheduler and the status of the XBQ* and XBT* queues:
1. Inbound qQueues

118381127.doc

Page 12 of 53

XBTI* (ExactlyOnce) XBQI* (ExactlyOnceInOrder) 1. Outbound queues XBTO* (ExactlyOnce) XBQO* (ExactlyOnceInOrder) 1. Acknowledgment queues XBTB* (ExactlyOnce) XBQB* (ExactlyOnceInOrder) 1. Large message queue XBTL* (ExactlyOnce)

If the scheduler has the status Waiting, it is waiting for free work processes. This is why delays occur when XML messages are processed. If not all necessary queues are registered, you can search for queues with the name prefix above using transaction SMQ2. Use transaction SXMB_ADM to register the queues in this case. Check queue configuration For a complete analysis, make sure that the queues of the integration server are registered. To do this start the transaction for the Integration Engine administration (SXMB_ADM) and select the function manage queues.
5 Check Message on Adapter Engine

See problem analysis scenario Message Failed on the Adapter Engine.

Additional Information
IDoc Interface

118381127.doc

Page 13 of 53

Message Failed on the Adapter Engine

Problem Description
An XML message is successfully sent from the XI Integration Server (IS) to an XI Adapter Engine (AE). The delivery semantic is exactly once (EO). The payload of the message could be an IDoc or any other payload. The problem occurs on the Adapter Engine, which means that the message was successfully delivered from IS point of view. The XML Message Monitor shows the processed successfully flag, as shown below.

Monitor for processed XML messages

When the XML message has successfully arrived at the Adapter Framework, the messaging system processes the message and passes it to the file adapter. The file adapter writes the XML message to the file system, as shown below.

Example Scenario Scenario Type: Error analysis

118381127.doc

Page 14 of 53

NetWeaver Component: Validity:

XI 3.0 XI 3.0, SP4 (FP)

Decision Roadmap
Prerequisites Main Tools Visual Administrator Message Display Tool (MDT) Basics If the XML message was successfully delivered to the Adapter Engine, it can be monitored with the Message Display Tool (MDT). This can either be started directly via the URL http://<Host>:<PORT>/mdt/index.jsp or from the Runtime Workbench. The Adapter Engines Messaging System (MS) receives the message, processes it and forwards it to the receiver (that is, the file adapter). While the MS processes the message, it passes several statuses:
TO_BE_DELIVERED: The state of message when it is initially handed over to the Messaging System. DELIVERING: The state of message when it has popped out of the MS queuing system and is in the process of being transmitted across the wire or delivered to an application. DELIVERED: The state of message when it has successfully reached its intended recipient. HOLDING: The state of an EOIO message that cannot be delivered until its predecessors have been delivered. NON_DELIVERED: The state assigned to a message when all attempts (retries) to deliver the message to its recipient have failed. FAILED: The state assigned to a message when an administrator decides to abort sending the message, or when a message could not be delivered due to a fatal exception that cannot be repaired. WAITING: The state of a message that has been attempted to be sent at least once, failed, and is currently waiting for another attempt.

In this scenario you should see only the statuses WAITING, DELIVERING, NON_DELIVERED or DELIVERED. Statuses such as HOLDING or FAILED usually happen only for delivery semantics EOIO (exactly once in order) or BE (best effort). TO_BE_DELIVERED occurs while the message is put into the Messaging System receive queue. This is done via the Messaging System receive servlet: http://<Host>:<PORT>/MessagingSystem/receive/<CONNECTION>/<PROTO COL> The MS returns HTTP 200 to the Integration Server only if this was executed successfully. In this example scenario, status TO_BE_DELIVERED should not appear since we assume that the IS has called the servlet successfully.

118381127.doc

Page 15 of 53

The status is updated from TO_BE_DELIVERED to DELIVERING when the message has popped out of the receive queue and the event handler lookup was successful, so there is a small gap where TO_BE_DELIVERED could remain in the message monitor, although it was delivered from IS successfully, however, this is out of scope here.

The other four statuses appear in the following order:

1. Message status DELIVERING When the message pops out of the MS queuing system and the lookup of the event handler was successful, it gets the status DELIVERING. This status is kept while the message is transmitted across the wire or delivered to an application. Usually this is a small time period and you should not see it. In cases where an HTTP response takes a long time, for example, this status could be visible. 1. Message status WAITING When the fist attempt to deliver the message has failed (a recoverable exception arose), the message is usually rescheduled and the status is updated to WAITING. As long as the message is in this status, the MS retries to deliver the message according to the configured retry settings (default 3 retries). 1. Message status NON_DELIVERED If all retries were unsuccessful, the message gets this status. From this status it is possible to restart message processing. 1. Message status DELIVERED This is the final status if the message has been delivered successfully.

Analysis The Message Display Tool is the central tool for monitoring XML messages on the Adapter Engine. As explained above it can be started directly by an URL or via the Runtime Workbench.

118381127.doc

Page 16 of 53

Message Display Tool

It shows all messages that have been processed on the Adapter Engine. With the extended filter criteria you can select for asynchronous inbound messages from a special partner, for example, for a time interval or for a message ID. As explained above, messages in error situations have the status NON_DELIVERED. In error situations perform the following steps: 1. Read the message details, which are also called the Audit Log, from the Message Display Tool. The audit log contains information about the executed processing steps in the Adapter Engine. Often it shows details about the error. You can also access the XML message down to its message bytes and check if all partners and so on are set as expected. The figure below shows an example.
...

118381127.doc

Page 17 of 53

Message Details (Audit Log)

2. If you do not find information about the error in the XML message audit log, check the application log file. This log file is accessed with the Visual Administrators LogViewer service. Browse to the server node and open the file .\log\applications.log. The application log contains information for system administrators. Try to find an error message using the time stamp of the message or the message ID. An example is shown below. Error messages are colored in red. Sometimes it is useful to customize the columns that are displayed.

118381127.doc

Page 18 of 53

Log Viewer

3. If you do not find an error in the log file or the error message does not explain the problem sufficiently, access the defaultTrace. The default trace file contains detailed messages for developers. Try to find more detailed information of the error. Extract the relevant trace information, for example using the time stamp or the message ID.
If there are several cluster nodes, you have to search in the trace files of all servers (for example, if you are searching for a message ID). The default trace is written cyclically. The old trace files are zipped and copied to the servers archive folder (./log/archive). Therefore, trace information can be found there if the problem occurred in the past. This is done for all server nodes.

4. If this does not explain the problem in more detail, increase the trace level and reproduce the problem. Go to the Visual Administrators Log Configurator service and increase the severity of the location com.sap.aii.af.ra.ms to DEBUG. Propagate the severity to the subtree and save your settings. Increase the severity also for other locations according to your scenario, such as com.sap.aii.adapter.file if the file adapter is involved. If you are not sure which components are involved, increase the severity of the XI parent location com.sap.aii. Then restart message processing using the message display tool. Mark the message and select repeat (see the figure below).

118381127.doc

Page 19 of 53

Log Configurator

118381127.doc

Page 20 of 53

Restart Message Processing

After that you should find detailed error and debug messages. Access the trace file and search for traces with severity ERROR, WARNING or stack traces. Use the Log Viewers search function. Pay attention to the correct value in the in column box when you search.
Do not forget to reset the severity to ERROR again. Use the parent location com.sap.aii again and copy the ERROR severity to the subtree. Save the setting. A DEBUG trace level can slow the system down.

Additional Information
Adapter Engine

118381127.doc

Page 21 of 53

Mapping Fails for a Certain Message Type

Problem Description
The receiver application does not work properly due to incorrect data. Mapping is used during the message flow.
Scenario Type: NetWeaver Component: Validity: Error analysis XI 3.0 XI 3.0, SP1

Decision Roadmap
Prerequisites Main Tools Transactions
SXMB_MONI SXMB_ADMIN SXI_CACHE SICF SUIM SU01 SM59 SM58 PFCG

Integration Builder: Design/Configuration Runtime Workbench Exchange Profile Visual Administrator Analysis The following figure gives you an overview of the analysis process:

118381127.doc

Page 22 of 53

1.
...

Check receiver data

5. 6. 7. 8. 9.

Log on to the receiver system and call monitoring transaction SXMB_MONI. Choose Technical Monitor for Processed XML messages. Define the selection criteria as appropriate to reduce the list of messages. Double-click the first column of the problematic message to display the details. Check the received application data. Is the content as expected?

118381127.doc

Page 23 of 53

2.

Is an interface mapping executed on the Integration Server (IS)

1.Log on to the Integration Server system and call monitoring transaction SXMB_MONI. 10. Choose Technical Monitor for Processed XML messages. 11. Define the selection criteria as appropriate to reduce the list of messages. 12. Double-click the first column of the problematic message to display the details. 13. Check whether an interface mapping has been executed:
There are two ways to do this

1. Compare the payload before and after the mapping step (use the buttons Window 1 and Window 2).

118381127.doc

Page 24 of 53

2. Check the trace of the mapping step. Three different outputs might occur. You can find the entry by searching (CTRL-F in the window) for the text CL_MAPPING_XMS_PLSRV3ENTER_PLSRV. The relevant entry is contained in the next Trace tag. 1. No interface mapping is necessary. In this case, the trace contains the message: Es ist kein Mapping notwendig.

118381127.doc

Page 25 of 53

1. An interface mapping is executed. In this case the trace contains the key information (name and namespace) of the executed interface mapping.

118381127.doc

Page 26 of 53

1. An interface mapping is necessary but is not available in the cache. In this case, the trace would contain the following entry: Interface Mapping XY is not present in the runtime cache.
3. Should an interface mapping have been executed according to the configuration

If you have analyzed the trace as described in section 2 with the result that an interface mapping is necessary but not executed, the answer is clear yes. Otherwise you have to perform the following steps to get the information: From the details of the message, you can access the information about the sender and receiver.

118381127.doc

Page 27 of 53

1.Log on to the Integration Directory. 14. Use the navigation tree on the Objects tab or the query to get the interface determination used for the message.

118381127.doc

Page 28 of 53

15. Open the interface determination (with a double-click) and check whether an interface mapping is defined.

4.

Check used interface mapping version

1.Open the interface determination in the Integration Directory (see section 3, for example).

16. Start the Integration Repository and open the interface mapping referenced by the interface determination (name, namespace and software component version are given).

118381127.doc

Page 29 of 53

When you try to open the interface determination, an exception dialog may be displayed stating that the communication to the REPOSITORY is interrupted. After you close this dialog, the object editor does not show the name of the software component version but only a GUID. In this case, you can go on with number 8 in the flow chart, performing a check of the communication between Integration Repository, Integration Directory and Integration Server. You could also continue but then have to use the query in the Integration Repository to find the interface mapping. Start the query in the Integration Repository and choose Interface Mapping as the object type, and All Software Component Versions as the context, and specify the name and namespace as attributes. If the result contains more than one object - that is, with different software component versions - you have to check their GUIDs (open them from the navigation tree and check the entry on the Key tab see below).

17. Use the navigation tree starting with the software component (version), selecting the namespace. If the namespace is not visible, open the Basis Objects node. Look at the namespaces listed there. This Basis Objects node contains the namespaces of the software component versions the actual one is based on. 18. From the correct namespace, navigate to Mapping Objects Interface Mappings. The interface mapping should be present there. 19. To check the version, open the software component object from the navigation tree and choose the Key tab. Look at the entry GUID.

20. Compare the information about the name, namespace and GUID of the software component version with that used by the Integration Server. Start transaction SXI_CACHE. From the navigation tree, select the interface determination and double-click on it. 118381127.doc Page 30 of 53

21. Compare the version ID field with the software component version of the Repository and map Name/map Namespace field with the information stored in the Directory. Any difference indicates that the cache is not up-to-date and, therefore, that there is an incorrect version of the interface mapping.
5. Check used mapping program version

1.Open the interface mapping in the Repository (see section 4).

Make sure that the object is in status Active (see status information in the right corner of the editor or use the I-button). If it is in status Being processed, you are dealing with a version that is part of your change list but not active, that is, not relevant for the cache (the same holds for the mapping itself).

22. Navigate to the mapping program(s) (by double-clicking them).

118381127.doc

Page 31 of 53

Different types of mappings are possible.

23. Open the Mapping Program with a double-click.

24. In the new editor, choose the I button to display the date of the last change (Changed on).

118381127.doc

Page 32 of 53

25. To check the version of the mapping used on the Integration Server, start the Runtime Workbench and choose Cache-Monitoring. As the cache type, choose Search Mapping Programs and fill in the search criteria for the software component version and the mapping program name (we recommend you use the input help as the mapping program name has a special syntax).

118381127.doc

Page 33 of 53

26. Compare the two Changed on dates in other words, check whether the cache was updated after the last time the mapping changed. If this is not the case, the cache is not the correct version.
6. Check cache notification status

The starting point is that the cache on the Integration Server is not up to date. An interface determination, interface mapping or mapping program is missing or not present in the correct version. For the upcoming analysis it is helpful if information about the user who submitted the relevant objects and when this was done is available. You can find some hints by opening the relevant objects in the Integration Directory/Repository and clicking on the I pushbutton. This displays information about the last changes. The object ID is also of interest. 1.Start the Integration Repository. 27. Choose Environment Cache notification. 28. Look at the entries for the relevant user and date.

If the notification failed (indicated by the icon), there is a problem with the Repository -> Directory communication.

29. If all seems to be OK in the Repository, start the Integration Directory. 30. Choose Environment Cache notification. 31. Look at the entries for the relevant cache instance, user and date.

118381127.doc

Page 34 of 53

32. Check the notification status: green is OK, red indicates an error situation. In this case, the communication Directory -> Integration Server does not work properly.
7. Check cache update status

1.Perform the steps as described in section 6. 33. In this case, check the Cache update column. Green is OK, red indicates an error situation. In the case of an error, you have to switch to the Problems tab. 3. No entries
If there are no entries in the list, the communication between the Integration Server and the Directory may have failed. Start transaction SXI_CACHE on the Integration Server and look at the status.

118381127.doc

Page 35 of 53

Double-click on the status to display more details.

4. Entries present

118381127.doc

Page 36 of 53

The list displays all objects that could not be updated. Search for the interface determination, interface mapping, or mapping program that caused the problem on the Integration Server (wrong version/not present) by its object ID (this can be found in the trace on the Integration Server or using the I pushbutton in the Repository/Directory). Double-clicking on the entry displays the error message that has to be analyzed (and should also be present in the logs). In both cases, the update may have failed due to connection problems between the Integration Server and the Directory or the Directory and the Repository. If there is no information in the Directory or on the Integration Server, you have to investigate the XI logs. 8. Check Directory->Integration Server and Repository-> Directory communication

Check Directory->Integration Server communication:

The notification of the cache on the Integration Server may have failed due to connection problems caused because the HTTP service is not running on the Integration Server. 1.Start transaction SICF. 34. Choose default_host sap bc ping (connection test) and choose Test service in the context menu of the entry.

118381127.doc

Page 37 of 53

A browser should be started requesting a logon (you may have to close all browsers). If this does not happen, this could be caused by a problem with the http service and has to be analyzed.

35. For the logon use the Directory service user (see section Check service user name and password). If the user and password are correct, a HTML page is returned containing the following message: Server erfolgreich erreicht. If you get an authorization error, you have to check the user and password for the HTTP connection. Perform the check of the user name and password for the Directory service user by retyping the values as described in section Check service user name and password. 36. Repeat the connection test in transaction SICF and check if it works now.
Check Repository->Directory communication:

For Mapping objects edited in the Integration Repository, the initial notification is started from the Integration Repository. Therefore the Repository -> Directory communication must also be checked. 1.Start a Web browser and type in the following URL: http://<hostname>:<port>/dir/hmidiag/ext?method=info
(hostname and port could, for example, be extracted from the Exchange Infrastructure start page).

37. A logon request should come up. If this is not the case, the Repository (or possibly the whole J2EE) is not running and has to be started. Perform the steps as described in section Check Http-Service and status of the applications of the appendix.
If the logon pop-up appears, use the Integration Repository Service user to log on (see section Check service user name and password).

118381127.doc

Page 38 of 53

If the user and password are correct in both cases, a HTML page is returned containing information about the HMI service.

If you get an authorization error, you have to check the user and password for the HTTP connection.

38. You check the user name and password for the Integration Repository service user by retyping the values as described in section Check service user name and password.
9. Check Integration Server -> Directory and Directory -> Repository communication

The update of the cache on the Integration Server may have failed due to connection problems when trying to reach the Directory and/or the Repository and/or the Java stack of the Integration Server (Mapping Runtime). First check whether the Directory/Repository/mapping runtime is running (and the HTTP service). Start a Web browser and type in the following URL:
1. Directory: http://<hostname>:<port>/dir/hmidiag/ext?method=info 2. Repository: http://<hostname>:<port>/rep/hmidiag/ext?method=info 3. Mapping Runtime: http://<hostname>:<port>/run/hmidiag/ext?method=info (hostname and port could be extracted from the Exchange Infrastructure start page, for example).

A logon request should appear. If this is not the case, the Directory/Repository/mapping runtime (or possibly the whole J2EE) is not running and has to be started. Perform the steps as described in section Check Http-Service and status of the applications of the appendix. 118381127.doc Page 39 of 53

If the logon pop-up appears:

1. For the Directory URL use the Integration Server service user 2. For the Repository URL use the Directory Service user 3. For the Mapping Runtime URL use the Directory Service user

to log on (see section Check service user name and password of the appendix). If the user and password are correct in all cases, a HTML page is returned containing information about the HMI service.

If you get an authorization error, you have to the check user and password for the HTTP connection. Check the user name and password for the Integration Server service user/Directory service user by retyping the values as described in section Check service user name and password of the appendix. Repeat the connection test with the URLs.
10. Retry the cache update and resend the message

1.To start a new cache update you have to open the problematic interface determination, interface mapping and/or mapping program in the Directory/Repository. 39. Change to edit mode and save the same version, that is, with no changes of the content (to activate the save pushbutton just add and remove a blank in the short description). 40. Submit the object and resend your message if the cache update has been made. If you think that not more than one object is affected by the cache notification/update problems, try a full cache refresh (this will take a while!). 1.Start transaction SXI_CACHE.

118381127.doc

Page 40 of 53

41. From the context menu XI Runtime Cache choose Start Complete Cache Refresh. 42. Call transaction SM58 to check the status of the refresh process.
The cache update is finished if no entry for function module SAI_CACHE3_REFRESH_BACKROUND is present.

11.

Analyze XI logs

1.Start the Visual Administrator or the Log Viewer. 43. Choose Applications com.sap.xi xi.log.

Additional information:
1. Check service user name and password Different connections are important for the cache refresh. The applications involved are: Directory, Repository and Integration Server. For each of them there is a service user with a special user role:
Applications and user roles Application Directory Integration Server Repository User role SAP_XI_ID_SERV_USER SAP_XI_IS_SERV_USER SAP_XI_IR_SERV_USER

The following figure gives a short overview according to the communication for notification/update:

118381127.doc

Page 41 of 53

The information about the user and password is read from the exchange profile in the case of the Directory and Repository. The Integration Server uses a SM59 destination (INTEGRATION_DIRECTORY_HMI). 1.First you have to get the name of the user who is in the required role. For the Directory/Repository, you have to call transaction SUIM in the SAP system that is used for the user management (the default should be the client of the Integration Server). If you are not sure, you can check it in the Visual Administrator. Choose Server Service UME Provider and look at the properties: 1. ume.r3.connection.master.client 1. ume.r3.connection.master.ashost

118381127.doc

Page 42 of 53

44. In transaction SUIM, choose User Information System User User by Complex Selection Criteria By Role.

118381127.doc

Page 43 of 53

45. Type in the service user role: SAP_XI_ID_SERV_USER/SAP_XI_IS_SERV_USER/ SAP_XI_IR_SERV_USER

A list of user name(s) is displayed (the name is probably XIDIRUSER/XIISUSER/XIREPUSER).

46. Call transaction SU01 to check whether the user is locked. The Logon Data tab displays the information about the lock status:

47. You can unlock the user on the initial screen by choosing Lock/unlock. You also have to check whether the service user has the correct user type: SERVICE (not Dialog)! 48. Check whether the profiles for the user have been generated. Choose the Profiles tab:

118381127.doc

Page 44 of 53

49. If the profile for the role is not generated, you have to call transaction PFCG. Select the corresponding role SAP_XI_ID_SERV_USER/ SAP_XI_IS_SERV_USER/ SAP_XI_IR_SERV_USER and display the definition. Choose tab Authorizations and check the status of the profile generation:

118381127.doc

Page 45 of 53

50. If the generation is incomplete, change to edit mode and delete it first. To generate the profile, choose Display Authorization Data on the same tab. Then choose the red/white ball icon and start the generation:

118381127.doc

Page 46 of 53

51. As final step after the successful generation, choose the User tab (on the previous screen) and perform a User comparison.

118381127.doc

Page 47 of 53

At this point, the user name for the service users should be clear and the users should not be locked. In addition the role profiles should be generated successfully. Now you have to check the caller side entries: Exchange Profile and SM59 destination. Exchange Profile:

1.Go to the start page of the Exchange Infrastructure and click on the Administration link in the navigation area. 52. You have to log on with an XI administrator user. Choose Administration of Properties Exchange Profile. 53. Navigate to IntegrationBuilder IntegrationBuilder.Directory com.sap.aii.Directory.serviceuser.name and .pwd or IntegrationBuilder IntegrationBuilder.Repository com.sap.aii.Repository.serviceuser.name and .pwd 54. Check the name of the service user and retype the password that is stored in the SAP user management (if you are not sure about the password, retype it also in transaction SU01). Afterwards choose Save.

118381127.doc

Page 48 of 53

55. Change back to the XI administration pages and choose Administration of Properties AII Properties and choose the Refresh button in the content area (this reads the properties from the Exchange Profile).

118381127.doc

Page 49 of 53

SM59 destination:

1.Call transaction SM59. 56. Choose RFC Destinations HTTP connections to ABAP system INTEGRATION_DIRECTORY_HMI. 57. From the context menu, choose Change.

118381127.doc

Page 50 of 53

58. On the Technical Settings tab you can check the target host and port (they have to correspond to the ones of the Directory check this, for example, on the start page URL of the Exchange Infrastructure). 59. Switch to the Logon/Security tab. Here you can see the name of the user and the password. Check the name of the Integration Server service user and retype the password that is stored in the SAP user management (if you are not sure about the password, retype it also in transaction SU01). 60. Afterwards choose Test Connection.
A HTTP return code 500 (Internal Server Error) is OK. If you have retyped the passwords and you are not sure if you have changed them by this action, follow Note 721548 to adjust other destinations that are relevant.

2. Configuration of the trace level for transaction SXMB_MONI 1.Call transaction SXMB_ADMIN. 61. Choose Configuration Configuration Data (Integration Engine). 62. Choose RUNTIME for the category and then choose Specific Configuration.

118381127.doc

Page 51 of 53

63. Set parameter LOGGING to value 1 and parameter TRACE_LEVEL to value 3.

118381127.doc

Page 52 of 53

3. Check the HTTP Service and status of the applications To check if the HTTP service and the applications are running, perform the following steps: 1.Start the Visual Administrator and check whether Server Services HTTP Provider is running. If not, start it using the context menu. 64. Choose the Cluster tab and then choose Server Services Deploy. 5. On the Runtime tab, choose Application at the bottom of the right window and check the status of sap.com/com.sap.xi.directory, sap.com/com.sap.xi.repository and sap.com/com.sap.xi.services. 6. If the application is not running, highlight it and start it by selecting Start Application on the right hand side.

118381127.doc

Page 53 of 53