Smart UI shows blank page

Hi guys,

we installed a new empty Content Server 16.2 for xECM and updated to 16.2.1.

When trying to switch to Smart UI we get an empty page. Developer tools in IE or Mozilla are showing to following message:

{exception} Load timeout for modules: csui-ext!csui/utils/contexts/perspective/perspective.context,csui-ext!csui/pages/start/perspective.routing,csui-ext!csui/utils/commands,csui/temporary/cop/commands/open.mailstore http://requirejs.org/docs/errors.html#timeout

Any ideas on what went wrong or how this can be fixed?

Thanks
Gregor

screen1.png

Find more posts tagged with

Comments

Ferdinand Prantl

This error usually means, that a functionality (JavaScript module) has been accessed, which has not been deployed.

Can you see any script loading failures on the console? They would be reported as 404 responses for URLs like ".*.js?v=*".

Did you upgrade both CS core and xECM module?

Could you try loading Smart UI in a Private/Incognito browser window? Browser cache should be invalidated by using a new value for the "v" parameter, but if I were desperate, I would test in a clean environment as well...

Gregor Höfert

Hi, I attached the output from the console view of a private browser window. You can see the timeout messages.

We used the cluster manager to upgrade to CS 16.2.1 core. For xECM I see latest patch pat162000080.

Is there a posssibilty to register the modules again?

Thanks in advance!

screen2.png

Gregor Höfert

I now copied csui folder from another instance, where Smart UI is working fine. After that I cleaned up Tomcat working dir, all broswer settings, cache and restarted the services.

Now it's working fine.

Ferdinand Prantl

You have applied the complete 16.2.1 update.

The error comes from the very first (JavaScript) module loading request. The list of the modules on the screenshot is not complete, but there are quire a few of them there. If this request fails, Smart UI tries to drop all optional modules, when it happens, and load just the core modules again. If it works, the customer can use the core functionality, at least. The core functionality is tested together and should always work. However, this second request failed in your case too.

I suspect, that the bundle indexes did not correspond with the bundle content. (JavaScript modules are deployed in module bundles and every bundle supplies a list of module names inside it - a bundle index.) Bundle indexes are loaded dynamically by "{CGI URL}/app/config" and module bundles are static assets in the support directory.

I do not know, what lead to inconsistency in your environment. I would do the same steps, which you did to fix it, in this order:

Check, that you really connect to the server, which you are testing to avoid being mislead by network configuration problems.
Clean up browser cache, or use the private/incognito window. The server is supposed to use a different value for the "cache-busting" URL parameter for static assets. It if fails, this step will help.
Clean up Tomcat working directory and restart Tomcat. Updated files are supposed to have newer modification date attribute. If the server does not reload the patched files, when serving new requests, this step will help.
Unpack the patch again and optionally perform steps 2 and 3 again. The Cluster Patch Manager is supposed to report an error, when the patch unpacking fails. If it does not happen, this step will help.