cancel
Showing results for 
Search instead for 
Did you mean: 

SICF calls wrong host

roger_beach
Participant
0 Kudos
1,210

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.

Accepted Solutions (1)

Accepted Solutions (1)

former_member197475
Active Contributor
0 Kudos

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
Participant
0 Kudos

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
Participant

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

Answers (0)