SICF calls wrong host

[roger_beach]

We have a system we are using for our portal upgrade project HQ3.  Our production system is HP1.  Recently to be sure we have everything in sync, we refreshed HQ3 with a copy of HP1.

Now if I test a web dynpro abap application from SE80, I can see the correct URL in the application and it launches fine when you right click and select test.

However, if I go to that same application in SICF and right click and choose test, I get a logon screen prompting for credentials for HP1.

Is there somewhere I can check the configuration to see why it is going to HP1 when tested from HQ3?

I looked in SMICM and SICF but could not find anything.

Looking at the icm/host_name_full parameter in RZ10 looks good.

[former_member197475 · Accepted solution]

Hi Roger,

Though you copied your config, your Portal System object details should be changed manually from Portal Content Admin.

Please ask your portal consultant, to change the system object to point to your HQ3 new system.

BR,

RAM.

[roger_beach · Accepted solution]

Ram,

I appreciate your reply.  I should have specified, we only copied the backend system.  The portal system was not refreshed from our production system.

Given that information, is your answer still relevant?  What we have noted is that if we take a URL not using the vanity url but the direct host:port/wda application and paste it in a browser, even though the host:port is for HQ3, it is going to HP1.

[roger_beach · Accepted solution]

Ram,

Just to follow up.  I'm lucky enough to work with who had researched the answer.

Apparently when copying from HP1 that meant everything on the backend, including Client 000 so the entry in HTTPURLLOC in client 000 was incorrect and still pointing to HP1.

Sudarshan found the following article which contained the helpful hint:

HTTPURLLOC in Client/Mandant 000
Usually the HTTPURLLOC table is only configured for the one specific client where the information is required. However, there is one additional case where this is not sufficient. When a special logon application, for example in 620 the BSP SYSTEM application or from 640 the ICF SYSTEM logon, is used, then the first part of the logon runs without any user of client information. This information only becomes avialable after a successful logon. Up to that point, all requests are processed in client 000! Thus, when any of these logon applications are used, and no access point information is available, the HTTPURLLOC table must also have entries in client 000 for the switch onto HTTPS to work.

http://wiki.scn.sap.com/wiki/display/BSP/Using+Proxies