No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Unable to acces records saved in Database Fault Occured in IPCC system when checking in agent clients

Publication Date:  2015-06-17 Views:  59 Downloads:  0
Issue Description

                Fault symptom:

    

In the Call Center system, agents correspond to the main entrance between the Caller and the system. The IPCC system is basically made of UAP (Universal Access platform) CTI, Web, report, file and databases servers. Each of these components comprises the IPCC system but cannot function alone; there are one or many communication interfaces between these components. Each of the components needs another for a good performance of the system. As far as this is concerned, the CTI server which includes the agent management and agent clients should communicate with the Database servers.

It might happen that the client agent needs to check the recorded calls in the system but did this unsuccessfully (receive an error dialog box) because of a lack of communication between the CTI server and the database servers. This contribution case is to bring the answer to this specific of issue.

Version information: V300R005C50

Oracle :

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production

UAP3300 :

V100R002C06SPC300

CTI :

V300R005C50

               Networking overview and topology


Alarm Information

The issue we describe here can occur frequently when the communication between the CTI server and the database server is not possible, for example, agent client is unable to query the records of the system; the error message “Failed to get audio file” always appears. The picture below is more explicit:

Reasons of this communication failure might be many but, let us describe below the most common ones:

·         One or two of the servers is powered off : in this case power on the off server first

·          One or both servers could be physically disconnected from the network: verify that all the servers of IPCC system are well connected and reachable.

·         Some routes might be deleted in one or both servers: this is a logical configuration; kindly check the Low Level Design (LLD) of your system and apply the routes configurations as they are specified in the LLD.

·         Once you are sure that both CTI servers and database servers are reachable in the network but some operations in the agent client which requires the communication with the database are not possible, it is important to check the issue inside the system. This document will help to provide some core solutions.

Handling Process

                   1.     Verify the Database installation

1.1.         Checking the Listener Status

Procedure

1.     Log in to the node 1 or node 2 as the oracle user.

2.     Right-click in the blank area on the desktop and choose Open in Terminal from the displayed shortcut menu.

The Terminal window is displayed.

3.     Run the lsnrctl status command to check the listener status.

·           If information similar to the following is displayed on the node 2, the listener is running properly:

·           If information similar to the following is displayed on the node 2, the listener is running properly:

1.2.        Checking the status of Oracle Instances

Procedure

1.     Log in to the node 1 or node 2 as the oracle user.

2.     Right-click in the blank area on the desktop and choose Open in Terminal from the displayed shortcut menu.

The Terminal window is displayed.

3.     Run the sqlplus / as sysdba command to connect to the Oracle database.

If information similar to the following is displayed on both nodes, the database is connected:

  1. Run the select INSTANCE_NAME, STATUS from v$instance; command to view the status of the Oracle database instance.

·         If information similar to the following is displayed on the node 1, the Oracle database instance is in normal state:

·           If information similar to the following is displayed on the node 2, the Oracle database instance is in normal state:

If the various steps described above are all successful and the Agent Client is still unable to Access the Database, follow the process below:

2.      Verify the ApLogic installation and configuration status

2.1.         Verifying ApLogic Installation

Prerequisites

  • The ApLogic has been installed.
  • Core services have been started and are running properly.

Context

The ApLogic and DtProxy are database access agents, and they support multiple instances on the same computer. The instances are identified by ProgID. Before starting an ApLogic, you must specify ProgID of the ApLogic.

A ProgID can be 12 or ranges from 201 to 298.

Procedure

  1. Click the Maintain Terminal tab in the MainAst operation window.
  2. Expand the device where the ApLogic has been installed in the navigation tree on the left.
  3. Double-click ManagingCTIplatform>StartCTIplatform under the device to start the Monitor Daemon Server (MDS).

The MainAst sends an mds command to the computer where the ApLogic is installed to start the MDS. Then the MDS starts the ICDComm process.

In normal cases, the value of Connection status is CONNECTED for the ApLogic if you click Refresh in the MDS monitoring console dialog box.

 

  1. Double-click Managing CTI platform > Managing processes through the mdscmd under the device. Add the ApLogic to the monitoring list of the MDSCMD Manager, and verify that the ApLogic can be started by the MDS
    1. Click Add in the MDS monitoring console dialog box.
    2. Select aplogic from the Process Name drop-down list box and the internal process ID such as 12 of the ApLogic from the Port drop-down list box in the Input Device Info dialog box, and click OK.

In normal cases, the value of Connection status is CONNECTED for the ApLogic if you click Refresh in the MDS monitoring console dialog box.

  1. Double-click Maintain ApLogic > Configuring ApLogic under the device and check the manager IP address setting.

In normal cases, a manager IP address contains the IP addresses of the active and standby Call Center Server (CCS).

2.2.         Verifying ApLogic configuration

Follow the first part of the step above to check the data source configuration in the ApLogic. Normally, the data sources (Databases nodes) are supposed to be connected to the ApLogic; the following displays the key reason of the data source access issue from CTI to both data sources:

 

Reason of he issue : ApLogic ‘s data sources are disconnected

Root Cause

The CTI server use login/password credentials to allow data source connection to the ApLogic. These credentials should normally be set for one or more of these users for connection:

Icd, gaea ,wecc

The password credential is normally set with an expiration date. Thus, if the Database server is reachable and can also access the CTI server (i.e. the CTI server is reachable), the root cause of the issue is that the password of the tnsname (username) used by the ApLogic (CTI) to connect Data source is expired. Connect to the Oracle database system as oracle user and check by following the steps below:

·         Run the sqlplus / as sysdba command to connect to the Oracle database

·         Check the expired time of all users, check if the necessary user password has been expired (especially user icd,gaea,wecc).

 

SELECT USERNAME, EXPIRY_DATE FROM DBA_USERS;

If the issue is the expiration date, normally the expiry_date should be less than the current date.

Solution

The root raison of the ApLogic data source connection issue is the password expiration date. Normally, if you extend the expiration date especially for wecc, icd, was or gaea users, this issue should be solved. You can extend the expiration date to a fixed date or extend this to an infinite date. Follow the steps below to extend the password of wecc, icd, was and gaea users to an infinite date:

·         To modify the password expired time as unlimited, type the following sql query:

ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

·         Set password so that it can be used more than once.

ALTER PROFILE DEFAULT LIMIT PASSWORD_REUSE_TIME UNLIMITED;

·         Change the password to original password and unlock it

 

Notice: <OLD PASSWORD> is a parameter; it corresponds to the original password of the user.

     //for gaea user:

ALTER USER GAEA IDENTIFIED BY <OLD PASSWORD>;

ALTER USER GAEA ACCOUNT UNLOCK;

                // for icd user

ALTER USER ICD IDENTIFIED BY <OLD PASSWORD>;

ALTER USER ICD ACCOUNT UNLOCK;

        // for was user

ALTER USER WAS IDENTIFIED BY <OLD PASSWORD>;

ALTER USER WAS ACCOUNT UNLOCK;

 // for wecc user

ALTER USER WECC IDENTIFIED BY <OLD PASSWORD>;

ALTER USER WECC ACCOUNT UNLOCK;

 

After correct the password to original one and modify the expiration date, there should be no error when query record on agent client.

Suggestions

In version V300R005C50 of CTI Server, there is some key features which can help you check if the calls are recorded and kept in the database. Follow the line below to know more about them:

·         Connect to the database as oracle

su - oracle

·         Access the database with sqlplus as  icd user by just typing sqlplus, the system will ask you the username, type icd and then,  the icd password.

sqlplus

username: icd

password:

·         Type the query:

 SELECT TABLE_NAME FROM USER_TABLES;

This query will make you notice that the icd user has Twelve (12) trecordinfo tables, i.e. each per month. Then, trecordinfo1 is for January records, trecordinfo2 (February records)…trecordinfo6 (June records).

  • To check the records done during the month of June, just type the query:

SELECT CALLID, BEGINTIME, ENDTIME, FILENAME FROM TRECORDINFO6;

Notice that this feats exactly with the calls made the 05th of June 2015. This means that the IPCC really record the calls. Recheck the record management by specifying all the day duration and you will get the output below.

cid:image032.png@01D0A218.E5E10AB0

 

END