PI Archives » Musings of an IT Implementor

Fixing SAP PI Open Channel Monitoring with Host FQDN

In some SAP landscapes, DNS is extremely complex and can result in problems with hostname resolution unless the host has the domain name appended.

In this post I show an issue with SAP PI 7.1 channel monitoring, which is resolved by using the fully qualified hostname.
Finding how to get that fully qualified hostname set, took some crazy tracing ideas which I won’t go into (they are crazy but it worked).

The Problem

From within the SAP PI Integration Builder, you open a communication channel object and then from the menu select “Communication Channel -> Open Channel Monitoring“:

The channel monitoring web page is opened in your default web browser of the PC where you are running the Integration Builder.
Except the web page is opened with just the hostname of the adapter host. Due to the DNS configuration, you need it to use the fully qualified domain name instead.

Where does the Hostname Come from?

In this specific case, the adapter hostname is actually determined from the System Landscape Directory (SLD) that the Integration Builder uses.
This SLD is usually the SAP PI local SLD, but it could be a central PI SLD or even the central landscape SLD.
You can check in the PI Exchange Profile/Aii Properties for the SLD host.

Fixing the Issue

To fix this issue, you will need to adjust the SLD. Before we adjust the SLD, I need to explain that in a PI system, certain data in the SLD is updated at system start up (application start up) and this information is documented in SAP note 1435392:

During start up, certain data in the SLD could be reset from the source, which is usually the Exchange Profile/Aii properties.
In this specific case, the SLD data does not seem to be influenced by the adapter start or system start. So I have to conclude that it is set by the CTC during installation only.

Log into the Administration page of the SLD and go to the “CIM Instances” section:

Filter for class “HTTP Service Port” and add a text filter for “SOAP“:

You should see your adapter (the one where you are trying to get to the channel monitoring page), select it:

Select the “Properties” tab:

Change the “SecureURL” and “URL” properties to have the required FQDN and then click save:

Once saved, you can log out of the SLD administration page.

Then, back in the SAP PI Integration Builder, you need to clear the SLD Cache, select “Environment -> Clear SLD Data Cache“:

Finally, retry the “Open Channel Monitoring” and you should now see the fully qualified domain name being used.

Something you will notice, is that there are a lot of instances of class “HTTP Service Port” in the SLD.
You may find you can fix some other hostname related issues, but remember the key point about where certain data gets updated; because you may also need to ensure that the Exchange Profile/Aii properties are also updated.

You may also be interested in:

SAP PI URLs – Wiki Link

Here’s a great SDN Wiki Link for all SAP PI URLs:

https://wiki.sdn.sap.com/wiki/display/XI/Important+URLs,+Transaction+Codes,+ABAP+Reports+in+Process+Integration+7.1

SAP PI Integration Builder Unable to Launch and Verify Fail

When starting the Integration Builder or any other Java based application for SAP PI, you get a Java error displayed on your PC for the aii_bdir_client.jar stating that it was “Unable to launch the application” or verify the Java signature.

This problem is caused by the expiration of the self-signed Java certificates that certify the server where the Java classes are deployed from for the Java Web Start functionality.

To fix the issue:

– From the main SAP PI Web Screen (https://<server>:50##00/rep), select “Administration” in the top right.
– Log in with your PISUPER user.
– Then on the left-hand side, select “Java Web Start Administration”.
– On the right click the “Re-initialization and force signing” button.

– Select the “Directory” tab on the left-hand side.
– Then on the left-hand side, select “Java Web Start Administration”.
– On the right click the “Re-initialization and force signing” button.

– Close Internet Explorer.

When you next try accessing the Integration Builder (or other Java Apps), you will be presented with a holding screen whilst the Java server collects and re-signs all the required Java classes.

It usually takes around 5-10 minutes to complete.
After completion, the Java apps should work as before.

SAP PI 7.0 JDBC Connectivity Issues

The following SAP Notes contain useful information about fixes in the SAP PI Adapter Framework Core (SAPXIAFC) and Adapter Framework (SAPXIAF) components.

The notes were found whilst searching for component: BC-XI-CON-JDB (JDBC Adapter).

SAP Note 1483974 – File and JDBC sender adapter’s retry not working after error
SAP Note 1510659 – Improvement in Locking, Logging and Monitoring in JDBC
SAP Note 1083488 – XI FTP/JDBC sender channel stop polling indefinitely(04/04S)
SAP Note 1398891 – XI/PI Adapter for Oracle: Overcoming DB Connection Issues

I was seeing a constant problem whereby the JDBC Adapter would not restart after the destination database system went down for backup or had a failure, or was not started at the time that the SAP PI system was started up.

The SAP note 1483974 was interesting as it highlighted the use of the Scheduler, which I didn’t know existed.

HowTo: Cancel Large Message Stuck in SAP PI/XI Queue

Scenario: You have a large message that is stuck in the INBOUND (XBTS*) queue of an integration server (maybe an ABAP proxy).
(This solution is based on SAP note 688147).

The message is visible in transaction SMQ2 (inbound queue) for a few hours/days/months:

and it’s consuming significant resources, visible in SM50:

You may also be blowing the ICM http buffer, visible in the SMICM log file:

But, you can’t cancel the message in SXMB_MONI, as it is still scheduled on the QUEUE (“still scheduled in queue XBTS*”):

SAP notes state that you should NEVER delete messages directly from SMQ1 or SMQ2 as this leaves the messaging system in an inconsistent state.

What to do? What to do?

Instead, in this exceptional case, you can delete the message in SMQ2. This will prevent it retrying.
Once you’ve done this, you can then use report RSXMB_CHECK_MSG_QUEUE to restore the messaging system integrity by resetting the original message status to cancel it.

Delete the entry from the queue:

Now execute the report RSXMB_CHECK_MSG_QUEUE:

Ensure that you enter the specific message ID, then enter the PIPELINE ID (same as that shown in column PIPELINE in SXMB_MONI), select all status to search for and then select TEST RUN: