Components won't be refreshed as ServiceCenter isn't available in the Controller Node
Certified

Components won't be refreshed as ServiceCenter isn't available in the Controller Node
Certified

  
In some situations when publishing the running version of a solution you will get the following warning in the Refresh References step:

"Components won't be refreshed as Service Center isn't available in the Controller Node."

People are often baffled by this warning and want to know why it's there and what does Service Center on the Controller node have to do with refreshing references. This post serves to shed some light on this issue.

This all has to do with how references are refreshed during a solution publish, so... how are they refreshed?

Step 1) The Service Center publishing the solution contacts Deployment Controller Service to refresh the references
Step 2) Deployment Controller Service calls local Service Studio to refresh references
Step 3) This is done against 127.0.0.1 on the Controller machine

The last step is the reason Service Center needs to be installed in the Deployment Controller machine for this functionality to work, since Service Studio talks with the Platform to refresh references via Service Center Web Services. If Service Center is not deployed on the Deployment Controller, Service Studio will not be able to contact those web services.

So, when can this happen?

1) When you have a Deployment Controller only node. Obviously if there is no eSpace  deployed on the Controller, Service Center will also not be deployed there
2) When you have ServiceCenter in a Zone which does not include the Deployment Controller node.

Please note that in a Java installation you might also get this warning, but since Service Studio is a Windows only application, it currently isn't supported to refresh references and upgrade eSpaces automatically on a Java installation even if you don't get this warning.

If you have further questions regarding this matter, feel free to ask them in this thread.

Best regards,
Ricardo Silva
Hi Ricardo,

Thank you for this post. It is exactly what I was looking for! My scenario is the one you described in 1) except I do have Service Center installed on the Controller only node   Why is it then that I still get that message on every LifeTime deploy?

Thanks,
Pedro
HI,

If you read carefully the post those 2 scenarios are the ones where it will not work.
There are no automatic refreshes on "Controller Only nodes".

Still, I don't see why lifetime should be trying to do refeshes anyway (Since they only supposed to happen when publish the "Current Version" of a solution directly in Service Center and lifetime doesn't allow staging of broken referenced modules),


Regards,
João Rosado
Hi João, thanks for the reply.

Actually I got confused with having Service Center running on a Controller Node!!?

Today, during a revision patch I finally noticed my mistake because whenever I tried to publish SystemComponents.osp I got a message saying "Version Mismatch. Service Center was not upgraded to Platform Server 9.0.0.19. Please contact your Service Center administrator to run 'SCInstall.bat' "

I then checked Service Center on my browser and there it was: the latest version 9.0.0.19   So, what could be wrong?

I then tried to do the installation again through Configuration Tool. All good. But then the same message again showed up whenever I tried to publish SystemComponents.osp  ...same with running SCInstall.bat through the command line.

So what was the problem? Recalling my initial server installation, I somehow forgot that Deployment Service should have been toggled off. And I had some eSpaces published there since IIS virtual directories were mapped. So...could it be that I really had an old Service Center version running loose in my Deployment Controller??? Indeed. After proceeding with System Components installation on a frontend-server everything went smooth. Mind you: installation checklist even mentions this step should be done on a Frontend-Server! Doh!! RTFM!!!

An idea that occurred to me would be to have a Version.txt file placed in Service Center directory, just like Platform Server and Development Environment directories. As mentioned above, the platform version posted in Service Center's sidebar didn't help to debug this issue at all...

I hope this troubleshooting episode can help you in the future, folks. Cheers!