Content server issue SICF

[Former Member]

Hi guys,

i am facing an issue with the TCODE SICF. when i follow the path default_host/bc/content server and when we double click the content server there is a Logon data tab. now when we give the client ,user name and password details it gets saved in a request. now when i release the same request into the QAS server the same details does not get saved in SICF. instead the service gets disconnected. is there anyway that the details can be saved in the QAS and PROD servers without the request being generated in these servers.right answers will be aptly rewarded with points.

[WolfgangJanzen]

I'm not sure what you mean with "save in a request". Is that a "transport request"?

Well, since the logon data entered in an ICF service is always referring to a local account (type "SERVICE user") it does not make sense to transport that data - in the target system the user might not exist or at least will have a different password. So, after transporting the ICF service you need to assign the (local) logon data, again.

For security reasons, any newly imported ICF services are deactivated (like after installation) - since it is not clear whether they are really required and thus need to be active. I'm not sure whether this is also the case if the service used to be activated before and was only updated by importing the transport request.

Regards, Wolfgang

[Former Member]

Hi Wolfgang., Yes ur right it gets saved in a transport request. the fact is that when i release the request from DEV server the same username and password is present in the QAS and the PROD servers. so based on that assumption i was working on it. but when i release the request the details r not present in the QAS server. even after importing the request when i try to assign the local logon data it says that changes to repository and cross client information error is generated. so i am forced to create a transport request by opening the client to save the changes.

[WolfgangJanzen]

Well, I'm afraid that this is a bug.

For the reasons explained such data always has to be assigned locally - and should never be transported (actually: it <u>is</u> not transported, as you've reported); thus it is not appropriete to request a transport request (to be created) for such customizing activity. This customizing object might be wrongly classified (as "transport relevant").

I'd suggest to submit a bug report to SAP (assigning component BC-MID-ICF).

You might refer to this SDN forum thread (providing the URL: )

Cheers, Wolfgang