SAP PI Administration: How to do cache refresh in SAP PI

How to do PI cache refresh

We can monitor the runtime cache and perform the PI cache refresh using a transaction SXI_Cache.

Monitoring of XI Runtime cache

The cache should always be in green status to ensure that the relevant Integration Engines have quick access to the contents of the Integration Builder at runtime, the information required is loaded into corresponding caches. Caches also contain the runtime-relevant data from the System Landscape Directory.

The Integration Directory cache is always updated:

  • When a change list is activated in the Integration Directory
  • A change list in the Integration Repository is updated that contains objects (mapping objects or integration processes) that are used in the Integration Directory

The traffic light icon at the top of the screen on the right displays the status of the cache.

  • Red traffic light: The cache is not up-to-date. This means that there are objects in activated Integration Directory change lists that are not yet contained in the cache.
  • Amber traffic light: The cache is currently being updated. This means that we must wait until the cache update is complete.
  • Green traffic light: The cache is up-to-date and can be analyzed.

Updating the Runtime Cache

  • Update Cache: To update the cache, in the menu bar choose XI Runtime Cache – Start Delta Cache Refresh. The missing activated change lists are included in the directory cache.
  • Update Cache Completely: To restructure the cache completely, in the menu bar choose XI Runtime Cache – Start Complete Cache Refresh.
  • Display Cache-Update Errors: If an error occurred while updating the directory cache, a red traffic light is shown. To display information about an error, in the menu bar choose XI Runtime Cache – Display Refresh Error.
  • Display Adapter Engine Cache: To display the cache of the relevant Adapter Engine, in the menu bar choose Goto – AE Cache.

Some times when we performing a delta cache refresh or full refresh we may encounter the below errors.

Couldn’t parse Configuration Data cache update XML string from Directory.

org.xml.sax.SAXParseException: The markup in the document following the root element must be well-formed. at at at

This is because the adapter framework service user PIAF<SID> is locked, to resolve:

  • Unlock the PIAF<SID> user in transaction SU01 if this is a dual stack system
  • If this is a single stack system unlock the user from within User Management which is accessed from the url http://<host>:<port>/useradmin
  • Ensure the password of the user is maintained consistently throughout the system

Based on the note: 1665838 – How to check why a technical PI user gets locked

It is a common issue that a technical PI user gets locked for an unknown reason. When the PI system has many decentral adapter engines that use the same user(s) it is difficult to check where the wrong password has been set.

There are quite a lot of HTTP communications within a PI domain, most of them with special users that should have a specific username and a correct password within the whole PI domain. In case a wrong password remains in the settings even on a single place, after several logon attempts (HTTP requests), the user gets locked in the UME of the central PI installation.

As a rule of thumb, if the user is locked follow the below procedure:

  1. Once you know that the user is locked, execute TCode SM21 for an approximately near period of time.

You will find entries similar to:

19:11:24 DIA 045 400 US 1

User XIAPPLUSER locked due to incorrect logon

If the user that logs the above error is SAPJSF, in most of the cases the affected user (XIAPPLUSER in our example) is locked by a java application. SAPJSF is an internal UME user for Java – ABAP communication.

  1. Search for mass HTTP/1.1 401 Unauthorized http responses in HTTP response log (file /usr/sap/<SID>/<inst#>/j2ee/clsuter/server#/log/system/httpaccess/responses*.trc) around the time when we get the “User Locked” error message in ABAP. In case of a clustered environment, search in responses*.trc files on all server nodes.
  2. If the user is locked by an ABAP application, you may refer to note 495911.
  3. Typically, in at least one responses*.trc file you will find at least one bunch of lines for incoming HTTP requests from one and the same IP, similar to:

Sep 23, 2010 7:11:23 PM – : POST /sld/cimom HTTP/1.1 401 1499 (46)

Sep 23, 2010 7:11:23 PM – : POST /sld/cimom HTTP/1.1 401 1499 (15)

Sep 23, 2010 7:11:23 PM – : POST /sld/cimom HTTP/1.1 401 1499 (24)

Sep 23, 2010 7:11:24 PM – : POST /sld/cimom HTTP/1.1 401 1499 (80)

Sep 23, 2010 7:11:24 PM – : POST /sld/cimom HTTP/1.1 401 1499 (13)

Sep 23, 2010 7:11:24 PM – : POST /sld/cimom HTTP/1.1 401 1499 (13)

Sep 23, 2010 7:11:24 PM – : POST /sld/cimom HTTP/1.1 401 1499 (15)

Sep 23, 2010 7:11:24 PM – : POST /sld/cimom HTTP/1.1 401 1499 (15)

Sep 23, 2010 7:11:24 PM – : POST /sld/cimom HTTP/1.1 401 1499 (14)

Sep 23, 2010 7:11:24 PM – : POST /sld/cimom HTTP/1.1 401 1499 (13)

Sep 23, 2010 7:11:25 PM – : POST /sld/cimom HTTP/1.1 401 1499 (12)

In this case, 11 unsuccessful requests from IP means that the incorrect logon data is provided by IP In this example, check the CIM client settings at host – they contain a wrong password for XIAPPLUSER.

The CIM client settings can be set directly in SLD Data supplier service or can be provided by the CPA Cache service property directory user.

As the allocation of the application and IP that has locked the user is a common issue there is an improvement in Java Server Security tracing already developed. Check note 1493272.

The applications vary within the various service users that are getting locked, but the main point always is to fetch the bunch of HTTP requests that cause the erroneous logon.

You may also like...

1 Response

  1. Raghuchowdary says:

    This is a nice to clear cache and best SAP PI. Refreshing

Leave a Reply

Your email address will not be published. Required fields are marked *