This chapter covers the following topics:
The following tables lists common issues in using the SDK Integrated Test Utility and recommended actions for resolving these issues.
| Common Issues | Recommended Action |
|---|---|
| SDK Test Utility does not start. | Check JDK path and SDK_JRE_HOME and SDK_JRE. environment variable in sdkenv.cmd. Make sure no spaces are in the PATH or CLASSPATH environment variable. |
| Oracle Telephony Adapter Server does not start. | Refer to Oracle Telephony Adapter Server Startup Sequence for more details. |
| Verification Tool does not start. | Check Verification Tool configuration. Make sure Oracle Telephony Adapter Server is running before Verification Tool. |
The Verification Tool is a development tool to automate Oracle Telephony Adapter SDK API testing. The Verification Tool's main use is to run SDK adapter test cases and to generate outputs easily. The scripts and solution files are written for a limited set of switches and middlewares. The supplied solution files do not cover all possible valid outcomes. Therefore, an adapter that passes all verifications might not necessarily work properly when integrated with Oracle Interaction Center. Likewise, an adapter that fails to pass some verifications might not necessarily work when integrated with Oracle Interaction Center.
Note: The Verification Tool is not a certification tool. Do not use the Verification Tool as the final check for Adapter implementation or for live customer diagnostics. Adapter developers should always run and test their implementations fully integrated with Interaction Center before going into production. Support should always use Oracle Telephony Adapter Server logging as the diagnostic tool.
Oracle Telephony Adapter Server logs runtime and diagnostics information into a log file. You can configure the content and the level of details logged in the file. This section describes how to configure and access Oracle Telephony Adapter Server logs.
Every time Oracle Telephony Adapter Server starts, it creates a log file in the directory <ICSM_TOP>/admin/scripts/<SERVER_NAME>, in which ICSM_TOP is the path where Interaction Center Server Manager is installed, and SERVER_NAME is the server name of Oracle Telephony Adapter Server that is defined in the Interaction Center Server Manager HTML Administration.
The Oracle Telephony Adapter Server log file has the naming convention
<OTAS_server_name>mmddyyyy_hhMMss.log
where " mmddyyyy" is the date when the log file is created, and "hhMMss" is the time when the log file is created.
Use the following procedure to view and download Oracle Telephony Adapter Server log files by way of the Interaction Center Server Manager HTML Administration.
HTML Login URL
Interaction Center Server Manager
Create a user in Interaction Center Server Manager HTML Administration.
Log in to the Interaction Center Server Manager HTML Admin.
Locate the Server Group / Node where the target Oracle Telephony Adapter Server is running.
Select OTAS.
Go to Server Details > Advanced.
The Advanced page opens.
View and download any of the listed log files.
Note: You can view log files when Interaction Center Server Manager is running on the target node. When running Oracle Telephony Adapter Server by using the SDK Integrated Test Utility, the Oracle Telephony Adapter Server log file is in the directory that is specified in the SDK test utility.
You can also access Oracle Telephony Adapter Server log files locally on the node where Oracle Telephony Adapter Server runs.
Use the following procedure to configure Oracle Telephony Adapter Server to log different levels of detail.
HTML Login URL
Interaction Center Server Manager
Create a user in Interaction Center Server Manager HTML Administration.
Locate the Server Group / Node where the target Oracle Telephony Adapter Server is running.
Select ICSM.
Go to Server Details > Server Parameter page.
Edit the Trace Level Parameter.
Oracle Telephony Adapter Server classifies different log entries into modules and levels of details. You can configure Oracle Telephony Adapter Server to log all modules with a specific level of details or log only specific modules with a specific level of details. Each log entry has the following format:
[timestamp] - [module: level] - message
For example,
[Fri Jul 19 12:18:05 PDT 2002] - [adapter:verbose] - SampleTeleDeviceFactory.createTelesetDevice(7001, 8001, 9001);
A message could span multiple lines, as in the following example.
[Fri Jul 19 12:18:06 PDT 2002] - [device:info] - [API]
device = TelesetDevice[7001,8001,9001]
object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1ece00
method = loginAgent
acdAgentId = 7001
acdAgentPassword = 8001
acdQueue = 9001
Log Detail Levels
The following table lists the level of details that are supported by Oracle Telephony Adapter Server, in the order of descending severity.
| Level | Meaning |
|---|---|
| fatal | Fatal and unrecoverable error, Oracle Telephony Adapter Server will shutdown |
| error | Major error, affects some Oracle Telephony Adapter Server functions |
| warning | Minor error, does not affect functionality |
| info | Informational only, for diagnostics purpose |
| verbose | Extended diagnostics information, use only when instructed by development |
The following table lists the log modules that are defined in Oracle Telephony Adapter Server.
:
| Module | Meaning |
|---|---|
| otas | Generic Oracle Telephony Adapter Server messages |
| comm | Communication layer messages |
| db | Database access layer messages |
| adapter | Messages generated by Telephony Adapter |
| device | Telephony API and Events diagnostics messages |
Trace Level Format
By default, all modules are set to error level, so that logging includes only messages that are tagged at the error level or a higher level (error + fatal). Users can change the level by using the Trace Level server parameter.
The Trace Level server parameter uses the following format. Users can globally set the level for all modules or set the level individually.
<level> or
<module_1>=<level_1>,<module_2>=<level_2>,...
The following table lists and describes trace levels.
| Trace Level | Description |
|---|---|
| (Default) Log error and fatal level messages for all modules | |
| fatal | Log only fatal level messages for all modules |
| error | Log error and fatal level messages for all modules |
| warning | Log warning, error and fatal level messages for all modules |
| info | Log informational, warning, error and fatal level messages for all modules |
| device=info |
|
| device=info,adapter=verbose,otas=warning |
|
Common and Recommended Usage
info: Turn on everything from fatal to informational messages for all modules.
device=info: For tracing Adapter API and Events while filtering out informational messages from other modules.
device=info,adapter=verbose: For tracing Adapter API and Events and any internal messages generated by Adapter.
General Guidelines in Interpreting Oracle Telephony Adapter Server Logs
Info and verbose messages are not serious, even for an exception trace.
Oracle Telephony Adapter Server Log Header
The Oracle Telephony Adapter Server Log Header contains information about the release and build number and startup sequence information. This information is very useful in determining the release, patch level and adapter configuration at a particular site. The Oracle Telephony Adapter Server Log Header contains the following.
Note: The following example shows the default logging configuration. If the log level is set to a higher error level, then the log displays more entries than those shown here.
Server Wrapper Build and Release Information indicates the version of Interaction Center Server Manager.
[Tue Jul 23 14:37:15 PDT 2002] -
***************************************
Server Wrapper - Release 11.5.8
Build 219 on Mon Jul 15 15:54:52 PDT 2002
(c) Copyright 2002 Oracle. All rights reserved.
***************************************
Oracle Telephony Adapter Server Build and Release Information indicates the version of Oracle Telephony Adapter Server.
[Tue Jul 23 14:37:17 PDT 2002] -
***************************************
Oracle Telephony Adapter Server - Release 11.5.8
Build 2547 on Thu Jul 18 18:36:26 PDT 2002
(c) Copyright 2002 Oracle. All rights reserved.
***************************************
Startup Sequence Information shows users which steps Oracle Telephony Adapter Server has gone through in startup. If there is an error in a particular step, then an error is logged and Oracle Telephony Adapter Server will not start. Adapter information is logged in this step:
[Tue Jul 23 14:37:18 PDT 2002] - Database Layer started
[Tue Jul 23 14:37:18 PDT 2002] - Socket Layer started
[Tue Jul 23 14:37:18 PDT 2002] - Adapter Layer started
The final status indicates that Oracle Telephony Adapter Server has been started successfully:
[Tue Jul 23 14:37:18 PDT 2002] - Oracle Telephony Adapter Server [xxx_otas] started.
Oracle Telephony Adapter Server starts in the following sequence:
Database Layer: Establish connection to database and load configurations
Socket Layer: Create server TCP/IP socket for communication
Adapter Layer: Load and Initialize Adapter
If any part of the phase fails, then a fatal error is logged and Oracle Telephony Adapter Server shuts down.
The database layer phase establishes the database connection. Oracle Telephony Adapter Server executes this phase in the following order:
Load dbc file (passed by Interaction Center Server Manager).
Create database connection.
Load Server Configurations.
Load Middleware Configurations.
Update Server Status.
If any of the above procedures fail, Oracle Telephony Adapter Server logs the following:
[Tue Jul 23 15:33:04 PDT 2002] - Database Layer starting FAILED
[Tue Jul 23 15:33:04 PDT 2002] - [otas:fatal] - Nested Exception :
< exception stack trace based on different errors >
The following table lists possible reasons for failure and describes recommended actions.
| Reason | Recommended Action |
|---|---|
| dbc file does not exist (should not happen in general if Interaction Center Server Manager is running) | Check DBC file integrity |
| dbc file error (should not usually happen when Interaction Center Server Manager is running) | Check DBC file integrity |
| database unavailable | Contact Database Administrator |
| server configuration error | Check Server Configuration in Interaction Center Server Manager HTML Admin |
| middleware configuration error (missing Middleware Configuration Name in Server Parameter) | Check Server Configuration in Interaction Center Server Manager HTML Admin and Middleware Configuration in Call Center HTML Admin |
If the database layer phase succeeds, Oracle Telephony Adapter Server logs the following message:
[Tue Jul 23 15:33:04 PDT 2002] - Database Layer started
The socket layer phase creates a TCP/IP server socket. Oracle Telephony Adapter Server executes this phase in the following order.
Get the local IP address.
Create a server socket.
Update database with the port information.
If any of the step above fails, then Oracle Telephony Adapter Server logs the following message:
[Tue Jul 23 15:33:04 PDT 2002] - Socket Layer starting FAILED
[Tue Jul 23 15:33:04 PDT 2002] - [otas:fatal] - Nested Exception :
< exception stack trace based on different errors >
The following table lists possible reasons for failure and describes recommended actions.
| Reason | Recommended Action |
|---|---|
| Network error | Contact Network Administrator |
| Unable to create server socket (address in use) | Check if -svr_port is used, contact network administrator if necessary |
| Unable to update database records | Contact Database Administrator |
If the socket layer phase succeeds, Oracle Telephony Adapter Server logs the following message:
[Tue Jul 23 15:33:04 PDT 2002] - Socket Layer started
In the adapter layer phase, Oracle Telephony Adapter Server loads and initializes the Adapter in the following order:
Get Middleware Type and PBX Type from Middleware Configuration.
Derive the TeleDeviceFactory Java class name to be loaded.
Load the TeleDeviceFactory Java class.
Initialize the Adapter by invoking init() method.
If any of the above procedures fails, then Oracle Telephony Adapter Server logs the following message:
[Tue Jul 23 15:33:04 PDT 2002] - Adapter Layer starting FAILED
[Tue Jul 23 15:33:04 PDT 2002] - [otas:fatal] - Nested Exception :
< exception stack trace based on different errors >
The following table lists possible reasons for failure and describes recommended actions.
| Reason | Recommended Action |
|---|---|
| Wrong Middleware Configuration | Check Middleware Configuration |
| Unable to derive TeleDeviceFactory Java class name from Middleware Configuration | Check Middleware Configuration |
| Unable to load the TeleDeviceFactory Java class (class does not exist in clasps) | Check if adapter jar file exists in 3rdParty directory |
| Unable to instantiate the TeleDeviceFactory Java class (no default constructor) | Fix adapter source code |
| Unable to instantiate the TeleDeviceFactory Java class (constructor not public) | Fix adapter source code |
| TeleDeviceFactory Java class throws TeleDeviceException on init() (Runtime error checked by Adapter) | Check Middleware Configuration, Check Adapter Log, Consult Adapter Developer |
| Unable to load 3rd Party Java classes or libraries (NoClassDefFoundError) | Check if the 3rd Party libraries is placed in the 3rdParty directory |
If the adapter layer phase succeeds, Oracle Telephony Adapter Server logs the following message:
[Tue Jul 23 15:33:04 PDT 2002] - Adapter Layer started
In the Adapter Phase, Oracle Telephony Adapter Server logs additional information about the type of adapter that is being configured, as shown in the following example.
[Tue Jul 23 15:21:00 PDT 2002] -
Middleware type = ICC_CUSTOM_ADAPTER
PBX Type = null
TeleDeviceFactory Class = oracle.apps.cct.sdk.sample.SampleTeleDeviceFactory
[Tue Jul 23 15:21:00 PDT 2002] -
Integration Level = <Advanced or Standard>
Based on the Middleware type and PBX type, users can determine whether the Oracle Telephony Adapter Server is running a custom adapter or an adapter that Oracle developed.
The following table lists and describes possible middleware types.
| Middleware Type in Log File | Description |
|---|---|
| ICC_CUSTOM_ADAPTER | Custom Java Adapter |
| ICC_CUSTOM_C_ADAPTER | Custom C Adapter |
| ICC_CTC_ADAPTER (In-house) | Adapter for CT Connect |
| ICC_ASPECT_ADAPTER (In-house) | Adapter for Aspect |
| ICC_ICM_ADAPTER (In-house) | Adapter for Cisco ICM |
The following table lists and describes possible PBX types (PBX types are applicable only to in-house adapters).
| PBX Type in Log File | Description |
|---|---|
| A | LUCENT_DEFINITY |
| C | ALCATEL_4400 |
| E | ERICSSON_MD110 |
| M | NORTEL_MERIDIAN |
| P | ASPECT |
| R | ROCKWELL_SPECTRUM |
| S | SIEMENS_HICOM |
| X | NORTEL_DMS100 |
| Z | CALLMANAGER |
Note: A value defined here does not indicate that switch certification is available for the platform. Please consult the Switch Certification support matrix for details.
If Oracle Telephony Adapter Server starts successfully, then it logs the following message:
[Tue Jul 23 14:37:18 PDT 2002] - Oracle Telephony Adapter Server [ <otas_server_name> ] started.
Oracle Telephony Adapter Server logs all API invoked, Events sent, and Exceptions thrown by the Adapter at the info level of the device module. To enable this feature, set Trace Level to one of the following:
info
device=info
Oracle recommends that you use device=info so that log entries of other modules will not show.
SDK API and Event traces are useful for diagnosing Adapter behavior. When they are used in conjunction with the call event flow specification of the Telephony SDK, users will be able to determine if the Adapter is working properly.
SDK API Traces are Adapter methods, such as makeCall, that Interaction Center Servers invoke. Oracle Telephony Adapter Server logs the device, the method that is invoked and the parameters that are passed to that method.
SDK API Traces have the following format:
[<timestamp>] - [device:info] - [API]
device = TelesetDevice[<extension1,extension2,extension3>] or RoutePointDevice[<extension>]
object = <teledevice object>
method = <method name>
<parameter1 = value1 >
<parameter2 = value2 >
...
Example Log Entry
[Wed Jul 24 16:45:48 PDT 2002] - [device:info] - [API]
device = TelesetDevice[7001,8001,9001]
object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1ed043
method = blindTransfer
mediaItemId = 7001
ineIndex = 8001
destinationNumber = 9001
SDK Exception Traces are TeleDeviceExceptions that the Adapter throws. The log records both the device that throws the exception and the exception details.
SDK Exception Traces have the following format:
[<timestamp>] - [device:info] - [EXCEPTION]
device = TelesetDevice[<extension1,extension2,extension3>] or RoutePointDevice[<extension>]
exception : <exception details>
Example Log Entry
[Wed Jul 24 16:45:48 PDT 2002] - [device:info] - [EXCEPTION]
device = TelesetDevice[7001,8001,9001]
exception : TeleDeviceException:ERROR_CODE_FUNCTION_NOT_SUPPORTED;blindTransfer NOT IMPLEMENTED
SDK Event Traces are events that the Adapter sends. The log records both the device that sends the event and the event details.
SDK Event Traces have the following format:
[<timestamp>] - [device:info] - [EVENT]
device = TelesetDevice[<extension1,extension2,extension3>] or RoutePointDevice[<extension>]
object = <teledevice object>
event = <event name>
<parameter1 = value1 >
<parameter2 = value2 >
...
Example Log Entry
[Wed Jul 24 17:41:39 PDT 2002] - [device:info] - [EVENT]
device = TelesetDevice[7002,8002,9002]
object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1eca40
event = beginCallEvent
mediaItemId = 7002
mediaItemIdComplete = true
ineIndex = 1
ani = 7001
dnis = 8002
data = {MI=7002}
dataComplete = true
[Wed Jul 24 17:41:24 PDT 2002] - [device:info] - [API]
createTelesetDevice
extension1 = 7001
extension2 = 8001
extension3 = 9001
[Wed Jul 24 17:45:08 PDT 2002] - [device:info] - [API]
destroyTeleDevice
device = T:7001
The following table lists the complete SDK API and Event traces for a simple internal call scenario in which A calls B, B answers, and A hangs up.
| Sequence | Notes | TelesetDevice A: TelesetDevice[7001,8001,9001] | TelesetDevice B: TelesetDevice[7002,8002,9002] |
|---|---|---|---|
| 1 | A calls B on 8002 using line 0 | [Wed Jul 24 17:41:39 PDT 2002] - [device:info] - [API]device = TelesetDevice[7001,8001,9001]object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1ec457method = makeCallmediaItemId = 7002lineIndex = 0destinationNumber = 8002 | |
| 2 | B sends beginCallEvent on line 1 | [Wed Jul 24 17:41:39 PDT 2002] - [device:info] - [EVENT]device = TelesetDevice[7002,8002,9002] object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1eca40 event = beginCallEventmediaItemId = 7002 mediaItemIdComplete = true lineIndex = 1ani = 7001 dnis = 8002 data = {MI=7002}dataComplete = true | |
| 3* | B sends callRingingEvent on line 1 | [Wed Jul 24 17:41:39 PDT 2002] - [device:info] - [EVENT]device = TelesetDevice[7002,8002,9002] object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1eca40 event = callRingingEventlineIndex = 1 | |
| 4 | A sends beginCallEvent on line 0 | [Wed Jul 24 17:41:39 PDT 2002] - [device:info] - [EVENT] device = TelesetDevice[7001,8001,9001] object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1ec457 event = beginCallEvent mediaItemId = 7002 mediaItemIdComplete = true lineIndex = 0 ani = 7001 dnis = 8002 data = {MI=7002} dataComplete = true | |
| 5* | A sends callDialingEvent on line 0 | [Wed Jul 24 17:41:39 PDT 2002] - [device:info] - [EVENT] device = TelesetDevice[7001,8001,9001]object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1ec457event = callDialingEventlineIndex = 0 | |
| 6 | B answers call on line 1 | [Wed Jul 24 17:41:56 PDT 2002] - [device:info] - [API]device = TelesetDevice[7002,8002,9002] object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1eca40method = answerCalllineIndex = 1 | |
| 7* | B sends callEstablishedEvent on line 1 | [Wed Jul 24 17:41:56 PDT 2002] - [device:info] - [EVENT]device = TelesetDevice[7002,8002,9002]object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1eca40event = callEstablishedEventlineIndex = 1 | |
| 8* | A sends callEstablishedEvent on line 0 | [Wed Jul 24 17:41:56 PDT 2002] - [device:info] - [EVENT]device = TelesetDevice[7001,8001,9001]object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1ec457event = callEstablishedEventlineIndex = 0 | |
| 9 | A releases call on line 0 | [Wed Jul 24 17:42:03 PDT 2002] - [device:info] - [API] device = TelesetDevice[7001,8001,9001] object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1ec457 method = releaseCall lineIndex = 0 | |
| 10* | A sends callReleasedEvent on line 0 | [Wed Jul 24 17:42:03 PDT 2002] - [device:info] - [EVENT] device = TelesetDevice[7001,8001,9001] object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1ec457 event = callReleasedEvent lineIndex = 0 | |
| 11* | B sends callReleasedEvent on line 1 | [Wed Jul 24 17:42:03 PDT 2002] - [device:info] - [EVENT] device = TelesetDevice[7002,8002,9002] object = oracle.apps.cct.sdk.sample.SampleTelesetDevice@1eca40 event = callReleasedEvent lineIndex = 1 |
*The following sequences can be of any order: 3 and 5, 7 and 8, 10 and 11.
For inbound calls that reach the realm of monitored devices for the first time, the adapter should fire a beginCallEvent with the following attributes:
mediaItemId should be left blank.
mediaItemIdComplete should be set to true.
For implementing Oracle Advanced Inbound in enhanced passive mode only - A two-second delay is required to keep inbound calls at the route point before the calls are routed to agents. This delay is necessary to allow time for Oracle to assign a mediaItemId to an inbound call and notify the RoutePointDevice in the assignMediaItemId method. You may implement this delay by adding a wait step in the call processing script of the PBX/ACD or CTI middleware.
The adapter must keep track of the mediaItemId assigned by Oracle for each call and pass the same mediaItemId in all events for the entire life cycle of the call, including transferred and conferenced calls.
RoutePointDevice should not fire duplicated beginCallEvent and callQueueEvent for the same inbound call.
The following table describes a sample trace scenario for a simple inbound call for implementing Oracle Advanced Inbound Telephony in enhanced passive mode.
| Sequence | Description | Events |
|---|---|---|
| 1 | An inbound call arrives at a route point. |
.
[Fri Jun 25 14:39:42 PDT 2004] - [device:info] - [EVENT]
device = RoutePointDevice[7710]
object =
oracle.apps.cct.sdk.sample.advanced.SampleRoutePointDevice@15575e0
event = beginCallEvent
mediaItemId =
mediaItemIdComplete = true
callId = 61696
ani = 6501112222
dnis = 7710
data = {AccountCode=12345}
dataComplete = true
.
. [Fri Jun 25 14:39:42 PDT 2004] - [device:info] - [EVENT] device = RoutePointDevice[7710] object = oracle.apps.cct.sdk.sample.advanced.SampleRoutePointDevice@15575e0 event = callQueuedEvent callId = 61696 . |
| 2 | Oracle assigns a mediaItemId to the call. |
.
[Fri Jun 25 14:39:42 PDT 2004] - [device:info] - [API]
device = RoutePointDevice[7710]
object = oracle.apps.cct.ccc.commonLayer.RoutePointDeviceImpl@15575e0
method = assignMediaItemId
mediaItemId = {MI-11380760;}
callId = 61696
.
.[Fri Jun 25 14:39:42 PDT 2004] - [device:info] - [EVENT]
device = RoutePointDevice[7710]
object =
oracle.apps.cct.sdk.sample.advanced.SampleRoutePointDevice@15575e0
event = updateMediaItemIdEvent
callId = 61696
mediaItemId = {MI-11380760;}
. |
| 3 | The call is routed to an agent. |
.[Fri Jun 25 14:39:46 PDT 2004] - [device:info] - [EVENT] device = RoutePointDevice[7710] object = oracle.apps.cct.sdk.sample.advanced.SampleRoutePointDevice@15575e0 event = callDivertedEvent callId = 61696 . .
[Fri Jun 25 14:39:46 PDT 2004] - [device:info] - [log.thread:Thread-18]
- [EVENT]
device = TelesetDevice[7001,8001,9001]
object =
oracle.apps.cct.sdk.sample.advanced.SampleTelesetDevice@6e4365
event = beginCallEvent
mediaItemId = {MI-11380760;}
mediaItemIdComplete = true
lineIndex = 0
ani = 6501112222
dnis = 7710
data = null
dataComplete = true
.
. [Fri Jun 25 14:39:46 PDT 2004] - [device:info] - [log.thread:Thread-18] - [EVENT] device = TelesetDevice[7001,8001,9001] object = oracle.apps.cct.sdk.sample.advanced.SampleTelesetDevice@6e4365 event = callRingingEvent lineIndex = 0 . |
| 4 | The agent answers the call. |
. [Fri Jun 25 14:40:00 PDT 2004] - [device:info] - [log.thread:Thread-18] - [EVENT] device = TelesetDevice[7001,8001,9001] object = oracle.apps.cct.sdk.sample.advanced.SampleTelesetDevice@6e4365 event = callEstablishedEvent lineIndex = 0 . |
| 5 | The call is released. |
. [Fri Jun 25 14:43:35 PDT 2004] - [device:info] - [log.thread:Thread-18] - [EVENT] device = TelesetDevice[7001,8001,9001] object = oracle.apps.cct.sdk.sample.advanced.SampleTelesetDevice@6e4365 event = callReleasedEvent lineIndex = 0 |
When the underlying connection between Oracle Telephony Adapter Server and the CTI middleware or switch is interrupted, you can expect the following behavior from the soft phone.
When the connection terminates, the soft phone displays an appropriate message, such as "Connection to telephony services is lost," and the soft phone buttons become disabled.
When the connection is reestablished, the soft phone displays an appropriate message such as "Connection to telephony services is restored," and the soft phone buttons are enabled. The soft phone does not reconnect with the physical telephone. The agent must complete any active calls manually by using the physical telephone.
If the expected messages do not appear, you can implement the custom adapter to trigger the appropriate soft phone behavior by doing the following:
When a node goes down, throw a TeleDeviceException passing SWITCH_CONNECTION_LOST as the ErrorCode.
When a node recovers or when the device is reconnected to another node, throw a TeleDeviceException passing SWITCH_RECONNECT_SUCCESS as the ErrorCode.
The following table lists common adapter errors that adapter implementers sometimes make, and the symptoms of those errors.
| Adapter Error | Observed Symptom |
|---|---|
| SDK method not implemented | Softphone functions do not work. |
| SDK call events not properly implemented | Softphone out of synchronization. |
| RoutePoint Events not properly implemented |
|
| Media Item ID not properly propagated | |
| Memory not properly managed in C/C++ implementation | Oracle Telephony Adapter Server crashes. |
Unable to compile Sample code.
Incompatible versions of Microsoft Visual Studio can cause problems when making a build by using the workspace file. To correct this issue, build the SampleAdapter.dll using the workspace (.dsw) file in the directory \oracle\apps\cct\c\sample.
Use the following procedure to build the SampleAdapter.dll.
Add only the following source files to the project.
TeleDeviceFactory.c
RoutePointDevice.c
TelesetDevice.c
In Project Settings > Resource tab, add the following directory in the 'Additional resource include directories' field ../include, or the whole path to the include directory, such as D:\sdk\oracle\apps\cct\c\include.