sxmb_ifr from business systems with PI 7.3

[monika_eggers]

Short version: When connected to PI 7.3 instead of 7.1 running sxmb_ifr in a connected business system (but not PI itself) uses the simple host name instead of the fully qualified host name and goes to /rep instead of /dir.

Long version:

We are upgrading PI from 7.1 to 7.31. Currently we have two mostly identical landscapes, one still with the PI 7.1, the other with the PI 7.31 (i.e. copies of the same business systems connected).

PI 7.1 and 7.3 are the same regarding that

/dir (i.e. http://hostname.subdomain.company.corp:50000/dir) leads to the page with the four things, on the left ESR and SLD, on the right Integration Directory and Configuration and Monitoring

/rep (i.e. http://hostname.subdomain.company.corp:50000/rep) leads to the page with only the two things on the left, ESR and SLD (and a link "Process Integration Tools" that leads to /dir at the bottom, which is often overlooked)

Here's a difference that gives us a problem:

7.1

Run sxmb_ifr in PI 7.1

=> leads to /dir (the page with all four things)

=> uses the fully qualified host name, i.e. http://hostname.subdomain.company.corp:50000/dir

==> Good.

Run sxmb_ifr in a business system connected to PI 7.1

=> also leads to /dir

=> also uses the fully qualified host name, i.e. http://hostname.subdomain.company.corp:50000/dir

==> Good.

7.3

Run sxmb_ifr in PI 7.1

=> still leads to /dir

=> uses the fully qualified host name, i.e. http://hostname.subdomain.company.corp:50000/dir

==> Good.

Run sxmb_ifr in a business system connected to PI 7.1

=> now leads to /rep

=> only uses the simple host name, i.e. http://hostname:50000/rep

==> Bad.

That it goes to /rep is just a nuisance - people overlook the link that leads them to /dir at the bottom, they panic and think that they cannot access the Integration Builder or monitoring anymore, suspect authorization problems with their user and such. I think that this is either a bug or an intentional change in 7.3, but an ill-advised change. There are not a lot of reasons someone running sxmb_ifr in a business system would want to go into the SLD or ESR, most often they want to check out why a message is not going through, thus they first check the monitoring and then if there is an error in the configuration (e.g. receiver agreement).

But that it uses the simple host name instead of the fully qualified host name is a serious problem. People who (whose computers) are located in various subdomains access these systems, so it doesn't work for those who are not in the same subdomain as the server. I have found a lot of posts regarding sxmb_ifr opening an URL with only the simple host name - but they all refer to sxmb_ifr being run in PI, to PI 7.0/7.1, and they were all solved by replacing hostname with hostname.subdomain.company.corp in the Exchange Profile - I have checked the Exchange Profile, there are no occurrences of the simple host name, it is always fully qualified. So with NW 7.3 the URL seems to be determined in some other way and not from the Exchange Profile. Maybe from some destination or setting in the individual business systems. I have tried changing some destinations that use the simple host name (the one used in sxmb_adm), but it didn't help.

Any suggestions where exactly this comes from?

[jensfieger · Accepted solution]

Hi Monika,

please check KBA 1600185 - PI transaction SXMB_IFR opens the wrong URL.

Have you maintained the RFC connection SAP_PROXY_ESR in your backend systems? It seems that probably the URL from the RFC destination is used instead of the exchange profile URL.

Best regards,

Jens

[monika_eggers · Accepted solution]

Yes, that's it! After the upgrade to 7.31 sproxy started only showing local data, so we added destination SAP_PROXY_ESR to the systems.

I have just put the fully qualified domain names into the SAP_PROXY_ESR destinations and now sxmb_ifr uses that, so our main problem is solved.

And I guess for the annoyance of /rep vs. /dir there is no solution - it's not possible to put in /rep as the path prefix, because then sproxy will show an "error with repository query" (it does show non-local data, though).