Java memory settings are specific to the Java Virtual Machine (JVM) used by the application server. Use the commands “java –h” and “java –X” to return a full listing of the options available on your system. Ensure that you are calling the same JVM that is used by your application server when issuing these commands.

• -ms –mx as appropriate (usually 1GB of memory is reserved for the heap within the JVM).
• -server mode is recommended for Oracle JVM.
• A common modification is to increase the garbage collector’s maximum permanent generation size to 128MB with the argument: --XX:MaxPermSize=128m.

The Java memory switches governing the minimum and maximum heap size available to the JVM may need to be tuned if Service Catalog encounters “out of memory” errors.

The number of connections for the queue connection factory should be configured based on the work load on the JMS server. The recommended setting for a single Service Catalog instance is 25. There is no hard and fast rule on the number of connections required based on the number of servers in the cluster. Some tuning effort may be required to arrive at the optimal connection settings for the application environment.

You can upgrade the JDK to a later version by following the steps below:

• Edit the script named “setEnv.cmd” on the <APP_HOME>/bin directory to specify the path to the new JDK.
• For customers using the startup scripts, save the revised setEnv.cmd file and then restart the server.
• For customers using the Windows services, stop the windows services, uninstall the window services (using the <APP_HOME>\bin\uninstall*.cmd scripts), and then re-install the window services again (using the <APP_HOME>\bin\install*.cmd scripts).

• For the OLTP database, create a primary tablespace named REQUESTCENTER. Allow for 10 MB per user, with a minimum size of 500 MB, for the tablespace. Your database administrator should choose an extent management strategy that fits well with the best practices of your organization.
• A very rough estimate of database storage required is 500 KB for each requisition completed. This varies greatly with the complexity of the service form, the authorization structure, and the delivery plan.
• Sites with many Service Link tasks will notice significant growth in the database size, attributable to storing Service Link messages. Recent versions of Service Catalog have included increasingly effective compression algorithms for these messages, as well as a means to configure message context. Additional details are available in the Cisco Prime Service Catalog Integration Guide. Database scripts for purging Service Link messages for completed tasks are available as stored procedures in the RequestCenter database and can be executed either as a one-time job or on a recurring basis.

You can optimize performance for Oracle database in the following ways:

• Gather statistics on the OLTP database (both tables and indexes) on a regular basis. This can be automated via Oracle Enterprise Manager (OEM).
• Perform column-level histogram analysis to further optimize the Service Manager indexes.
• Gather statistics on the Service Catalog data marts after the data marts have been refreshed.
• Review table allocation, tablespace fragmentation, and row chaining.
• Grant access to the SELECT_CATALOG_ROLE for monitoring query performance.

Apply settings similar to the following:

Enable snapshots with this command:

ALTER DATABASE <database name> SET READ_COMMITTED_SNAPSHOT ON 

We recommend a SQLServer DBCC Reindex command, especially on volatile Service Catalog tables. The process should be regularly scheduled, typically weekly, at off hours.

The following tables are the most volatile and should be subject to DBCC Reindex.

Cognos maintains the definitions of all reports and queries in a database called the ContentStore. The Cognos KnowledgeBase includes entries on sizing and maintaining the ContentStore. Of particular interest are the formulas published for determining the size required for the ContentStore, based on estimated usage statistics.

A spreadsheet incorporating these formulas is available from the Cisco Technical Assistance Center (TAC). A sample is shown below.

The transactional database consists of a set of relational tables that use a prefix naming convention. The following table is provided as an aid to DBAs or others who need to maintain or tune a production database. The structure and contents of these tables is proprietary to Cisco, which reserves the right to freely change table names or structures from release to release.

Historical Requisition Partitioning feature moves completed requisitions, namely, requisitions that have "Closed", "Canceled", "Delivery Canceled" or "Rejected" status, to historical transaction tables. The use of Historical Requisition Partitioning provides overall application performance improvement as a result of reducing the amount of data in the current transaction tables. The improvement can be seen in the filter and search of tasks, requisitions and external messages in the Service Manager, My Services and Service Link modules. ETL and request workflow processing will also benefit from the smaller population of data in the current transaction tables.

Historical Requisition Partitioning is controlled by the system setting "Enable Historical Requisitions Scheduler" in the Administration module. When it is enabled, requisitions that have been completed for more than 365 days are migrated by a background process to the historical transaction tables. The 365-day retention period is configurable and may be modified based on the specific needs of your organization.

You can execute the migration process of historical requisitions on an ad-hoc basis in the Administration > Utilities page when the scheduler is disabled.

Thus, requisition views in both My Services and Service Manager are separated into "Recent" and "Historical" views. Requisitions migrated to the historical transaction tables can be made accessible on when you select the Enable Historical Requisitions View system setting. These requisitions are displayed under Historical tab on the My Services > Requisitions page, as well as Historical Requisitions view in Service Manager. You cannot view tasks and external messages associated with the historical requisitions through UI, although the data is stored within the Service Catalog database.

Service Catalog provides a transaction purge feature to delete transactions older than a chosen date or those that meet other user-specified criteria. This allows the application administrator to remove test requisitions before deleting test users and sample services. However, through the purge feature, you cannot perform mass data deletion. Also, you must avoid prolonged maintenance phase.

The workflow purge utility removes temporary data from the database related to workflow processing. Those data are no longer used in the product and can be removed to reduce the database size. Executing the purge utility periodically could also provide overall performance improvement.

The workflow purge utility is provided in the form of a stored procedure in the RequestCenter database. The purge utility can require an hour or more to execute if you have a large database. Hence the purge should be done during system down time or a low activity time window. We recommend a practice run on sandbox environment to establish duration of the script execution for your database.

To track the start/end times for the purge, enable the setting for displaying print statements in the SQL tool before you execute the stored procedure.

The Service Link Message Purge Utility removes Service Link messages from the database.

Since these messages can be quite large (depending on the complexity of the service form and content type option used to configure the agent), removing the messages greatly reduces the database size required to hold Service Link-related data. External messages remain unchanged.

Stop the following service and then restart:

• IBM Cognos 10.2.1 – required for all reporting options

This section provides startup and shutdown instructions for the application server, which includes:

• Cisco Prime Service Catalog application
• Cisco Prime Service Catalog Integration Server (Service Link)
• Reporting Server

The following are important files that you may need to see for details on your deployment. Unless specifically stated in this guide or instructed by the Cisco Technical Assistance Center (TAC), all properties files and similar configuration files should be considered read-only. After making changes to any of these property files, you must restart the services.

Service Catalog maintains log files on the application server to track application activities, both expected and unexpected. Logs are managed using a log4j-based framework, an open source (Apache) logging mechanism. By default, logs are configured as “rolling appenders”, with a new log file opened every day. Location of the log files varies according to the application server type, as does the ability to adjust log file contents and configuration.

We recommend that you:

• Rotate logs on a daily basis (this is the default behavior)
• Keep one month of logs “online”
• Back up or delete logs that are older than a company-specified retention period

Service Catalog does not require log files to be maintained. They are useful primarily as troubleshooting tools in case an error arises. There are four types of log entries: E (Error), W (Warning), I (Info), D (Debug), listed in decreasing order of severity.

We recommend against changing the format of the default log files because that is the format the Cisco Technical Assistance Center (TAC) expects. Rather, customers can create their own appenders that suit their needs.

In addition to the system-wide log files, Service Link is configured to have a separate log file for each adapter type. These logs, too, are managed by log4j. By default, Service Link logging is enabled. The adapter-specific log files are written to the ServiceLink\logs directory:

• dbadapter.log
• fileadapter.log
• httpadapter.log
• msadapter.log
• mqadapter.log
• remedyadapter.log
• vmwareadapter.log
• wslisteneradapter.log

With full DEBUG level enabled, logs get very large very quickly, so logging at full debug and trace levels should be enabled only for short periods. System performance will likely slow down significantly, so logging on a Production system should be kept to a minimum, and only for the length of time required to reproduce an issue. For more information, see Logs and Properties.

External dictionaries within the Service Catalog need to be backed by physical tables in the database. You cannot have read-only external dictionaries. All external dictionaries are read-write. Only the application should write to External Dictionaries.

For the application to relate External Dictionaries to the Requisition, a numeric column needs to be available that can be used as the foreign key. This is typically named RequisitionEntryID.

Most site configuration settings are cached in the J2EE system for faster access. To reload any settings that are used by the J2EE application, change any option on the Settings page of the Administration module and click Update. This invalidates the cache and reloads the settings from that page.

This section describes about the application security:

• Retrieve SSL certificates from the LDAP server.
• Ensure LDAP server supports SLDAP connectivity (typically on port 636).

Service Catalog maintains a password-protected key-store that can store many certificates.

We recommend that the web server, or the content switch in front of the web server run SSL, especially, in Extranet-supported environments.

Web Server to Application Server communication does not usually need to be encrypted.

The Reporting modules require scripts that maintain the Service Catalog data mart and produce the standard reports and KPIs available to users.

Service Catalog Extract-Transform-Load (ETL) scripts generated from the Cognos DataManager ETL tool controls the population of the database which supports running prebuilt reports provided by Service Catalog and all nonform based data in the data mart.

Additional command files complete the generation of the framework used by Cognos QueryStudio and Report Studio (Ad-Hoc Reports and Report Designer) to permit ad-hoc reporting on the Service Catalog data mart.

These scripts share the same invocation and logging framework. They are available as Windows .cmd files that reside and run on the Cognos server. They can be scheduled to run via any enterprise scheduler. These scripts log their activities in the <ReportingInstalledDirectory>\logs directory of the Cognos server.

The following script is required to support standard reports and Key Performance Indicators (KPIs).

The following programs are required to support the data marts.

The Escalation Manager is responsible for monitoring if a task exceeds its Operating Level Agreement (OLA). If the OLA is exceeded, and escalations have been configured, the Escalation Manager sends the appropriate notifications after the designated amount of time has elapsed since the task became overdue.

The Escalation Manager is run via the internal scheduler. Schedule settings can be adjusted by editing the newscale.properties file. By default the Escalation Manager is set to run during business hours Monday through Friday.

A schedule setting is essentially a cron expression, which describes the desired schedule in the format “Seconds Minutes Hours Day-of-Month Month Day-of-Week”. For example, the expression “0 0 12 ? * WED” means “every Wednesday at 12:00 pm”.

Service Manager is the module used by task performers to fulfill service requests.

Service Manager allows users to search for tasks or requisitions of interest by specifying a set of conditions to be matched, via the Filter and Search pop-up window. By default, these conditions do not support a Contains operator, for example, the ability to find all task whose name contains a specified string.

This default behavior optimizes performance by increasing the probability that indexed queries can be run against the database. The functionality of performing Contains queries can be supported; however, administrators should be careful in making this configuration change, as response time may not be optimal, especially with a large transactional database. Reverting is not recommended as it will impact Service Manager Custom Views.

To allow Service Manager users to specify Contains queries, edit the newscale.properties file, to add the following property setting:

# Service Manager will use this flag to control Contains Query in Datatable Filter and Search
ContainsQueryInFnS=true

For the changes to take effect for the newscale.properties files, navigate to the Administration > Utilities modules, select “Request Center – Property Files” from the drop down, select “newscale.properties” file and click the “View File” button. Review the file content to make sure it includes your changes, and then click the “Reload” button. Click “OK” button when the reload success message is displayed.

Installation Logs are saved to the <APP_HOME>/logs folder with a mmddyyyyhhmm time-stamp (for example, 010720111126) each time the Installer is invoked.

Key installation logs are listed below.

Installation settings are recorded in the RequestCenter/etc folder. Preserve that folder so that installation settings are stored for future invocations of the Service Catalog Installer.

The settings are available in the file setup_options.txt.

A single clustered installation of Cisco Prime Service Catalog requires multicast to communicate within the cluster. Each node has to be on the same subnet or have multicast routing enabled across the subnets on the switches. You may also have to enable multicasting in the network interface configuration of the host servers.

Service Catalog uses multiple multicast addresses that have to be unique.

The system allows for multiple LDAP directory integrations. A group of two or more LDAP sources becomes one LDAP system through referrals. Referrals are supported for searches only, not binding. For detailed information on configuring directory integrations, see the Cisco Prime Service Catalog Integration Guide .

Directory Integration allows integration architects to connect Service Catalog to an LDAP data source and map attributes in that data source to corresponding fields in the Person profile. The integration allows designers to designate which events should trigger an LDAP lookup, and whether that lookup should also cause a refresh of the Person profile in Service Catalog. Events that can trigger an LDAP lookup include:

• Authentication after login, either via the Service Catalog screen or Single Sign-On
• Person Search for Order On Behalf
• Person Search for form data in a Person-type field
• Lookup of Person information for the managers of a person previously chosen via Order on Behalf or Person Search

In addition to these preconfigured events and behavior, Directory Integration provides an API to allow programmers to implement custom directory interfaces to add new search capabilities or refine the search logic.

Single Sign-On functionality is provided as part of Directory Integration. If you experience any problems with Single Sign-On, begin troubleshooting by checking the following items:

• Review any related changes to your environment such as LDAP or Junction/SiteMinder agent configurations.
• Check if the Service Catalog is still accessible through the Administrative override
• Restart the Service Catalog service.

ISF is a JavaScript API that integrates with Cisco Prime Service Catalog service forms. ISF allows the forms to dynamically alter their contents or behavior based on the current context, including user credentials; data previously entered on the form; or the life cycle of the displayed requisition. For more information on ISF, see the Cisco Prime Service Catalog Designer Guide .

ISF supports the use of JavaScript libraries, stored on the application or web server, to supplement JavaScript code stored in the Service Catalog repository. If such libraries are used, they are treated as customizations when upgrading or migrating a Service Catalog site.

The data retrieval rules available within active form components allow the application to retrieve data from external relational databases or from the application database, for use in service forms. Such data can be used to prefill form fields with default values; to produce drop-down lists; and to provide dynamically populated drill downs to detailed information. User data entry could also be validated against the external data.

For a rule to access an external database, a corresponding JEE datasource must be created. Instructions on creating the datasource are given in the Cisco Prime Service Catalog Installation and Upgrade Guide. Any such datasources are treated as customizations when upgrading or migrating the Service Catalog site.

Service Link, also known as the Integration Server, or ISEE (Integration Server Enterprise Edition), allows Service Catalog to send synchronous or asynchronous requests to other systems via XML messages. Tasks that are configured in Service Designer as “external” are handled by Service Link.

Service Link uses JMS queues as an underlying technology, so disruption to JMS configuration may disrupt Service Link operation. Most Service Link troubleshooting can be done through the Service Link module which provides the ability to drill-down to individual messages sent or received and the tasks responsible for sending or receiving those messages.

A Service Catalog implementation typically consists of multiple sites, each of which plays a different role:

The Catalog Deployer module provides configuration management for metadata (service definitions) and organizational data (people, organizations, and related entities) which is stored in the repository. For more information, see Cisco Prime Service Catalog Designer Guide for Catalog Deployer documentation.

You can copy Service Catalog OLTP database from one site to another during deployment, for instance:

• When initially installing a test or production site, the complete development site may be copied to the new environments.
• After production has been in operation for a time, all of the user activity should be copied to a test environment, to allow realistic performance or volume studies.

Perform the following procedures to copy a Service Catalog OLTP database from one site to another.

Enabling SSL for Service Link turns on the secure port, but it does not turn off the nonsecure port for Service Link. If you choose not to turn off the nonsecure port, external systems can still communicate with Service Link via an http URL. If you decide to turn off the nonsecure port, all communications with the Service Link service must use the https URL.

It is possible to use both secure and nonsecure port for the Service Link service and control the access to the nonsecure port via another mechanism, such as a firewall system.

For example, in a Two-JBoss-Server topology, the Service Catalog application is also a “client” of the Service Link service (which runs on a separate JBoss server). At runtime, Service Catalog needs to connect to the Service Link service via the URL http://<SL_servername >:6080. If the nonsecure port 6080 is turned off for the Service Link service, then Service Catalog must be configured to connect to Service Link via an https address, that is, https://<SL_servername >:6443.

So, one possible scenario is that you turn on both nonsecure port 6080 and secure port 6443 for the Service Link service. Service Catalog can still connect to Service Link via http://<SL_servername >:6080, while other external systems must only communicate with Service Link via https://<SL_servername >:6443. You configure your firewall system to deny access to port 6080 from all external systems.

This section does NOT describe how to turn off a nonsecure port for the application server or how to configure a firewall system to deny access to a nonsecure port number. Please contact your system administrator, or the vendor of your application server product to obtain the information you need.

If Service Link is deployed in a separate application server from Service Catalog (as in the case of a Two-JBoss-Server topology), then to enable SSL for Service Link, you configure the certificate and secure port number only for the application server where Service Link is running.

It is assumed that you have procured a digital certificate that can be used to secure the Service Link service. This certificate can either be self-signed or obtained through a third-party Certificate Authority like VeriSign. In either case, your digital certificate must be imported into a java keystore (that is, a jks file) that can be accessed by the application server. Furthermore, the signer certificate (aka the public key of your certificate) must be exported into a file in “Base64-encoded ASCII” format, so that it can be given to the external systems that want to communicate with Service Link service in SSL mode.

Note

This document does not describe how to create a keystore file, and how to request a certificate for your web server or application server. The instructions in this section assume that you have already created a keystore file that contains the digital certificate to be used to enable SSL for the application server where Service Link is running. For ease of documentation, assume that your keystore file is named “slkeystore.jks”. It contains a certificate under the alias called “servicelink”. The password to open this keystore file is “slpassword”.

Also assume that the signer certificate has been exported in “Base64-encoded ASCII” format into a file named “slsigner.cer”. A “Base64-encoded ASCII” format is similar to the following example:

-----BEGIN CERTIFICATE-----
MIICPDCCAaUCBE17w1cwDQYJKoZIhvcNAQEEBQAwZTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB
MRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1NjYWxlMQswCQYDVQQLEwJRQTEVMBMG
A1UEAxMMS2hhbmcgTmd1eWVuMB4XDTExMDMxMjE5MDI0N1oXDTIxMDMwOTE5MDI0N1owZTELMAkG
A1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1Nj
YWxlMQswCQYDVQQLEwJRQTEVMBMGA1UEAxMMS2hhbmcgTmd1eWVuMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDhTxg2RwarD6Wn4iqYeOOk3ykfXzZiDArf/X63omXquTmN0Up+mg6oJmPAfqJA
l7k4+Dn7dfVtAc4h8qra7PBeBU48zrzRqZd6VAK07rz++CilQto64mHXYVomb5vWPGeKA41j9vlv
ENj/tE/6++IqbwnxAqeZtY3EvEM7dcCWDwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAAaqCnfEAovy
Uf2S+oAXYDo5N387a035APsz5iiUM5oiKR/KW3oRz/v0P0I/o3n312kDIJ01111pl6qpZRtPEsr1
b00Tu1cXfPmizEtz0ole606qDS+DzkS1+YYz2mLL2Zq40d1EPsMolyqyUmyq3GHaEnuhWemcv2aA
wGFgbQYd
-----END CERTIFICATE-----

The subsequent sections contain instructions for installing the certificate file and configuring SSL for each type of application server.

Before following the application server-specific instructions, you must complete the following step:

Note	If the signer of the external web server certificate is a well-known Certificate Authority like VeriSign or Thawte, then most likely, you can skip this step since Sun JDK already recognizes CA signers.

• Obtain the signer certificate of the external web server in a file. To do this, you can contact the system administrator who manages the external web server, and ask him/her to export the signer certificate (the public key) of the digital certificate used to secure that web server. The signer certificate must be exported in the “Base64-encoded ASCII” format. The following is an example of what a Base64-encoded signer certificate looks like:

-----BEGIN CERTIFICATE-----
MIICPDCCAaUCBE17w1cwDQYJKoZIhvcNAQEEBQAwZTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB
MRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1NjYWxlMQswCQYDVQQLEwJRQTEVMBMG
A1UEAxMMS2hhbmcgTmd1eWVuMB4XDTExMDMxMjE5MDI0N1oXDTIxMDMwOTE5MDI0N1owZTELMAkG
A1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1Nj
YWxlMQswCQYDVQQLEwJRQTEVMBMGA1UEAxMMS2hhbmcgTmd1eWVuMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDhTxg2RwarD6Wn4iqYeOOk3ykfXzZiDArf/X63omXquTmN0Up+mg6oJmPAfqJA
l7k4+Dn7dfVtAc4h8qra7PBeBU48zrzRqZd6VAK07rz++CilQto64mHXYVomb5vWPGeKA41j9vlv
ENj/tE/6++IqbwnxAqeZtY3EvEM7dcCWDwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAAaqCnfEAovy
Uf2S+oAXYDo5N387a035APsz5iiUM5oiKR/KW3oRz/v0P0I/o3n312kDIJ01111pl6qpZRtPEsr1
b00Tu1cXfPmizEtz0ole606qDS+DzkS1+YYz2mLL2Zq40d1EPsMolyqyUmyq3GHaEnuhWemcv2aA
wGFgbQYd
-----END CERTIFICATE-----

The instructions for importing the signer certificate depend on the application server (Configuring JBoss 7.1.1, or Troubleshooting) that Service Link is running on.

After you order the application template, the orchestration component provides an option to track the template provisioning progress in Comments and History, under My Stuff.

If the (built-in) Cloud orchestration service is restarted when Prime Service Catalog is running, it reconnects to Prime Service Catalog, discovers AMQP exchanges, and resumes monitoring of AMQP messages.

Whereas, if Prime Service Catalog is restarted when Cloud orchestration service is running, the Cloud orchestration service reconnects to Prime Service Catalog when it resumes execution.

When an order (for the application template) is submitted, the Cloud orchestration engine (Heat Engine) status is checked before the engine starts provisioning the application template:

If the Cloud orchestration engine or the Cloud orchestration engine API service is down, the Cloud orchestration service cancels the requisition in Prime Service Catalog and logs in Comments for that requisition: Heat Engine service is down. Details: <More information on the service status>.

Note	Cloud orchestration engine is not fault tolerant: If it goes down when an infrastructure template is being provisioned, the provisioning is halted and cannot be recovered when the engine is restarted at a later point.

Restarting Cloud Orchestration Engine and Orchestration services

sudo service openstack-keystone restart
sudo service openstack-heat-api restart
sudo service openstack-heat-api-cfn restart
sudo service openstack-heat-engine restart
sudo service amqp-service restart
sudo service psc-orchestration restart 

Log Files

The following traces are commonly monitored:

You may want to limit outbound email during service design testing or in nonproduction environments.

By limiting outbound email capabilities, you can limit or prevent the sending of email to actual performers or customers on whose behalf services are ordered.

Changing all email templates to have “fake addresses” in a development environment is not really an option. Firstly, it would be very time consuming. More important, much of the testing is invalidated when the template addresses are changed back—you would still need to ascertain that the correct people are receiving the appropriate emails.

If templates use only namespace variables and users in the nonproduction environment are refreshed via directory integration, you could change the LDAP mapping to give everyone the same email address or a similar fake address, for example:

User@<company>.com, or

reqcentertest@<company>.com

by using a mapping similar to:

expr:#cn#=(cannotmatch)?(neverthis):requestcenter@<company>.com

However, this approach also does not allow you to adequately test the accuracy of email delivery.

A more robust solution is to use a dedicated SMTP (email) server for the development instance and any other instances where emails should not be distributed outside the box. You can set up an SMTP server that routes ALL emails (whether fake or correct) to a standard mailbox (for example, rctestmailbox@company.com) for the development and test servers. This way, you do not have to change Service Catalog configuration in any way, and emails could be tested very easily. The project team just needs to be able to open that test mailbox.

This requires users to configure a separate test SMTP server that overrides the recipients to always forward to the test email box. Production would need to point to the production SMTP server, of course.

If you use any of these techniques, add the To/Cc addressees in the HTML body of the email templates surrounded by <!-- Comment --> tags so that testers may validate the namespace expression and other logic for these fields.

It is useful to document the systems in your environment by using a matrix like the one provided in the Sample Environment Matrix.

Cisco publishes a support matrix detailing the software on which each version of Service Catalog is certified. The Cisco Technical Assistance Center (TAC) will always have the most current version of this matrix, adjusted for point releases and Service Packs.

You can inform the Cisco Technical Assistance Center (TAC) before performing any system maintenance tasks that may affect:

• Server operating system patches/upgrades
• Database server patches/upgrades
• Service Catalog application server patches or upgrades – Validate the update is supported by Cisco first!
• LDAP Directory tree structure changes
• Single Sign-On system upgrades

This section describes the configuration steps to enable the adapter log files for ServiceLink. These configuration steps must be performed manually by the user after the ServiceLink WAR is deployed.

Note	This section is not applicable for JBoss, since the Service Catalog Installer automatically configures the ServiceLink adapter log files at installation time.

Error logs for Service Catalog and its related components are in the following locations:

If you have configured the support utilities in Administration module to enable GUI access to the application log files, you can also view and download the above log files from there.

The following error conditions are presented according to the error condition or its related error message.

Some error conditions cause the same system behavior although the error itself may stem from one of several different error conditions within the system. For example, if you cannot connect to the LDAP server, several error conditions below may apply. It is important to match the error message to the error you are experiencing.

All errors are written to the Service Catalog server log file, whose behavior and location are described earlier.

It is a standard practice of the Universal Development Methodology (UDM) to complete a column in this matrix for each site in an implementation, as the site comes online. Cisco Advanced Services deliverables typically include a soft copy of this matrix, which administrators should keep up to date.