Some common troubleshooting advice for when a CA Service Catalog system is failing.
First, a discussion of scope – for a production system to be failing, it must first have been working; this document does not cover installation or initial configuration problems.
In order to investigate the causes of a Service Catalog environment, look in the following locations:
%USM_HOME%\logs is the location of the main Service Catalog logs folder. In there, you will find the following useful information for diagnosing issues:
view.log – the primary log for the Service Catalog application
error.log – additional debugging for database interactions
view\ServiceCatalog.log – this file contains messages from the Tomcat application; it is particularly useful for any problems with web display.
If the integration between PAM and Catalog is failing, it will manifest as requests not progressing (stuck in Submitted/Approved statuses). To perform a test, open the Service Catalog UI and go to Administration > Configuration > CA Process Automation and click the “Test” button.
This makes a SOAP API call to the PAM environment to start an instance of the process “CheckSLCMConnectivity”. This instance then reads the information stored in PAM’s library at “CA SLCM\SLCM_GlobalDataset” to get the connection information back to Catalog, uses it to make a web call to confirm it has started, then closes out. This second web call is what triggers the Catalog UI to display an alert that the test was successful.
If there are communication problems between the two, however, this will return an error. Look in the PAM UI to see if the process instance was created – if the instance is built but fails, then the communication from PAM to Catalog is in error, but if there is no instance then the communication failure is from Catalog to PAM.
If PAM itself is having problems, then the log location on the PAM server is PAM\server\c2o\log – in there are the boot.log for startup issues, c2o.log for the application itself and eiam.javasdk.log for EEM calls. Further information about PAM logging can be found in Article Id 9347.
If browser errors are being seen, then Tomcat caches may be removed. Stop Catalog and Accounting, empty the contents of %USM_HOME%\view\translets but do not delete the folder itself, clear the browser cache and restart. Details are in Article Id 111885.
If Requests are not processing forward but the integration with PAM has been checked as above, then there may be an issue in the JMS shared message queue. Prior to Service Catalog 17.1 this is stored in %USM_HOME%\logs\jms-data but it was then moved to %USM_HOME%\jms-data and the individual queues split out to different files. These files can be removed with Service Catalog stopped if they are corrupt; see Article Id 13588.
If the theming of the Catalog UI is corrupt/missing, then there may be an issue with the filestore. The current location is set in Administration > Configuration > File Store Information > File Store Location – by default it will be %USM_HOME%\filestore but on a production or other clustered environment will typically point to a SAN that is shared across multiple server nodes. If the theming is missing, then this may be set incorrectly, or the SAN may be unavailable. Alternatively, if the environment has been recently upgraded or patched, the updates may not have been copied to the non-default location.
The display rights on Guinodes (individual pages) of the Catalog UI are controlled through EEM. If these have not been correctly updated during the upgrade by the installer, this can be corrected manually – the instructions are in Article Id 105998.
Review the installation logs carefully for any references to jar files that might be missing.
Further troubleshooting recommendations are found in the product documentation.