XI Problem Analysis Scenarios

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.

ScopeComponent: XI 3.0, Validity: ≥ XI 3.0, SP1

Used Tools: SXMB_MONI, Performance Header Display, Visual Administrator, Jarm Statistics

Verification of SymptomsStart 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

document.doc Page 1 of 53

http://help.sap.com/saphelp_nw04s/helpdata/en/42/e7bb8f7c9d3ee0e10000000a1553f6/frameset.htm

Analysis Overview


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.


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.


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.


Sending an IDoc through XI Failed

Problem DescriptionAn 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: Error analysis

NetWeaver Component: XI 3.0

Validity: ≥ XI 3.0, SP6

Possible Error CausesFaulty 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


http://help.sap.com/saphelp_nw04s/helpdata/en/6a/e6194119d8f323e10000000a155106/frameset.htm

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.


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: IDOC_INBOUND_ASYNCHRONOUS

Target System: <destination>

Date: 03.01.2004

Time: 14:02:22

Status Text: 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


http://help.sap.com/saphelp_nw04s/helpdata/en/6f/1bd5baa85b11d6b28500508b5d5211/content.htm

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


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 processingNo 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 errorIf 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


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 errorSee problem analysis scenario Mapping Fails for a Certain Message Type.

4.2.1.4 Problem with cache updateReload cache, see problem analysis scenario Mapping Fails for a Certain Message Type.


http://help.sap.com/saphelp_nw04s/helpdata/en/29/e0194120ddf223e10000000a155106/content.htm



Sample communication error

4.2.1.5 Outbound AdapterHere, 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 problemPossible 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


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 InformationIDoc Interface


http://help.sap.com/saphelp_nw04s/helpdata/en/6f/1bd5baa85b11d6b28500508b5d5211/content.htm

http://help.sap.com/saphelp_nw04s/helpdata/en/49/e3fb40ef74f823e10000000a155106/content.htm

Message Failed on the Adapter Engine

Problem DescriptionAn 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


http://help.sap.com/saphelp_nw04s/helpdata/en/49/e3fb40ef74f823e10000000a155106/frameset.htm

Scenario Type: Error analysis


Validity: ≥ XI 3.0, SP4 (FP)

Decision Roadmap

Prerequisites

Main Tools

Visual AdministratorMessage 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 Engine’s 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>/<PROTOCOL>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.


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.


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.


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 Administrator’s 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.


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 server’s 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 Administrator’s 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).


Log Configurator


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 Viewer’s 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 InformationAdapter Engine


http://help.sap.com/saphelp_nw04s/helpdata/en/8f/d906d01f77fa40a4c84683c3f8326f/frameset.htm

Mapping Fails for a Certain Message Type

Problem DescriptionThe receiver application does not work properly due to incorrect data. Mapping is used during the message flow.Scenario Type: Error analysis


Validity: ≥ XI 3.0, SP1

Decision Roadmap

Prerequisites

Main Tools

TransactionsSXMB_MONI

SXMB_ADMIN

SXI_CACHE

SICF

SUIM

SU01

SM59

SM58

PFCG

Integration Builder: Design/ConfigurationRuntime WorkbenchExchange ProfileVisual Administrator

Analysis

The following figure gives you an overview of the analysis process:


http://help.sap.com/saphelp_nw04s/helpdata/en/29/e0194120ddf223e10000000a155106/frameset.htm

1. Check receiver data...

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


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).


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_PLSRV3-ENTER_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.


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


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.


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.


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).


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.


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).


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).


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).


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.


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.


Double-click on the status to display more details.

4. Entries present


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.


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).


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.


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.


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 User role

Directory SAP_XI_ID_SERV_USER

Integration Server SAP_XI_IS_SERV_USER

Repository SAP_XI_IR_SERV_USER

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


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


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


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:


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:


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:


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


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.


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).


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.


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.


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


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.


Documents

XI Problem Analysis Scenarios