Guest

Cisco Unified Contact Center Express

Cisco Unified Contact Center Express 5.0/7.0: "Error While Handling The Input Request" Error Message

Cisco - Cisco Unified Contact Center Express 5.0/7.0: "Error While Handling The Input Request" Error Message

Document ID: 110303

Updated: Jun 23, 2010

   Print

Introduction

When you try to change the Cisco Unified Contact Center Express (UCCX) configuration with the the UCCX AppAdmin page, the Error while handling the input request error message is received in the browser window.

This document provides information on this error message and the solution in order to resolve the issue.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

  • Cisco Customer Response Solution (CRS)

  • Cisco Unified Contact Center Express (UCCX)

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco Customer Response Solution (CRS) 4.5(x)

  • Cisco Unified Contact Center Express (UCCX) 5.0(x) and 7.0(x)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Problem

When you try to add an Application or a Resource Manager-Contact Manager (RMCM) Resource Group, or upload scripts/prompts or create a new Unified CM Telephony trigger with the UCCX AppAdmin page, one of these error messages is received in the browser window:

  • This screenshot displays this error message:

    Error while handling the input request

    uccx-5-7-error-01.gif

  • Or, this error message appears:

    The page can not be displayed

This error occurs when a backup or patch operation on UCCX has not been completed successfully. When a backup or patch operation is performed, there are several flags that are temporarily modified to show that a backup/restore or a patch operation occurs. When these flags indicate an operation occurs, then no modifications are allowed from UCCX AppAdmin. Sometimes, these flags get stuck and the issue mentioned in this section occurs.

Solution 1

You need to clear these flags from the archive configuration in the CET (cet.bat) tool in order to resolve this issue. Complete these steps:

  1. This is an example screenshot of these flags that are set in the CET tool:

    uccx-5-7-error-02.gif

    . Complete these steps in order to clear these flags:

    1. On the UCCX server, go to C:\Program Files\wfavvid and double-click on the cet.bat file.

    2. Click No at the warning about the use of this tool.

    3. In the left-hand pane, double-click on this Configuration Object Type: com.cisco.crs.cluster.config.ClusterSpecificConfig.

    4. In the right-hand pane, double-click on the row returned for your node.

    5. In the new window, click the com.cisco.crs.cluster.config.ClusterSpecificConfig tab.

    6. Click the Archive tab.

    7. Remove the contents for these fields and leave only double quotes:

      • Archive ID

      • Archive Request Info

      • Archive User Info

    8. For Archive Time, remove the entry and leave that field empty.

    9. Under the Archive Clients section, delete the null field and the IP address and leave only the double quotes for IP.

    10. Click OK in order for the changes to take effect.

      This is an example screenshot of cleared archive flags:

      uccx-5-7-error-03.gif

  2. Next, while in the CET tool, double-click on this Configuration Object Type: com.cisco.crs.cluster.config.LockConfig and complete these steps:

    1. In the right-hand pane, double-click on the row returned for your node

    2. In the new window, click the com.cisco.crs.cluster.config.LockConfig tab.

    3. Remove the contents for these fields and leave only double quotes:

      • Lock Owner

      • Lock Usage

      • Lock User Info

    4. Click OK in order for the changes to take effect.

    5. Close the CET tool.

      This is an example screenshot of cleared Lock entries:

      uccx-5-7-error-04.gif

  3. You should now be able to make necessary changes in the Appadmin.

Solution 2

If you are receive the Error while handling the input request.com.cisco.app.ApplicationException: can not acquire ClusterMutex com.cisco.config.ConfigException: Store config record - error: config request timed out error message, go to CET and clear the mutex locks in Cluster specific and lock configuration as mentioned in IPCC: Troubleshoot Mutex Lock Errors.

Solution 3

Complete these steps in order to resolve this issue:

  1. Choose Program Files > wfavvid > ClusterData > default > com.cisco.crs.cluster.config.LockConfig on the CRS server.

  2. Rename the .default.xml file to .default.xml.old. For example, change 1.1258891010.default.xml to 1.1258891010.default.xml.old.

  3. From the Windows Menu, choose Start > Programs > Administrative Tools > Services and restart the service Cisco Unified CCX Node Manager.

Problem

The UCCX appadmin administration console page shows an error when you try to log in. This is the error message:

error while handling the input request.
java.lang.runtimeException:  Failed to get cluster config.

Solution

Complete these steps in order to resolve this issue:

  1. Delete the Appadmin folder on the primary server at the location, C:\Program Files\wfavvid\tomcat_appadmin\webapps.

  2. Restart the Cisco Unified CCX Node Manager service on the Primary Node from the Windows Service tool Services.msc.

  3. Wait for at least 5-7 minutes and make sure that all the services have started, which includes the Node manager, and that they are up and running.

  4. Check the C:\Program Files\wfavvid\tomcat_appadmin\webapps folder again, and see whether the Appadmin folder has been re-created.

  5. Try to login into the AppAdmin that the issue is resolved on the primary server.

  6. On the Second Server also restart the Node Manager. This failovers back to the primary server again.

Related Information

Updated: Jun 23, 2010
Document ID: 110303