Cisco Cisco Computer Telephony Integration Option 9.0 Developer's Guide
4-5
CTI OS Developer’s Guide for Cisco Unified Contact Center Enterprise
Release 8.5(3)
Chapter 4 Building Your Application
Testing CTI Applications
The main decision point in choosing which API to use depends on your workstation operating system,
your existing applications, and the language skills of your developers.
your existing applications, and the language skills of your developers.
•
ActiveX Controls. The CTI OS ActiveX controls are the appropriate choice for creating a rapid
“drag-and-drop” integration of CTI and third-party call control with an existing desktop application.
The CTI OS ActiveX controls are an appropriate choice for developing a CTI integration with any
fully ActiveX-compliant container, or any other container that fully supports ActiveX features (e.g.
Powerbuilder, Delphi, and many third-party CRM packages). The ActiveX controls are the easiest
to implement in graphical environments, and help achieve the fastest integrations by providing a
complete user interface. All CTI OS ActiveX components are distributed via dynamic link library
files (.dll), which only have to be registered once to work on any Microsoft Windows platform.
These components are not appropriate for non-Windows environments. You can use the CTI OS
ActiveX controls in Windows Forms .NET applications only if the Runtime Callable Wrappers
(RCWs) provided with the CTI OS Toolkit are a part of the project. For more information, refer to
“drag-and-drop” integration of CTI and third-party call control with an existing desktop application.
The CTI OS ActiveX controls are an appropriate choice for developing a CTI integration with any
fully ActiveX-compliant container, or any other container that fully supports ActiveX features (e.g.
Powerbuilder, Delphi, and many third-party CRM packages). The ActiveX controls are the easiest
to implement in graphical environments, and help achieve the fastest integrations by providing a
complete user interface. All CTI OS ActiveX components are distributed via dynamic link library
files (.dll), which only have to be registered once to work on any Microsoft Windows platform.
These components are not appropriate for non-Windows environments. You can use the CTI OS
ActiveX controls in Windows Forms .NET applications only if the Runtime Callable Wrappers
(RCWs) provided with the CTI OS Toolkit are a part of the project. For more information, refer to
.
•
COM. The CTI OS Client Interface Library for COM (Microsoft’s Component Object Model) is the
appropriate choice for developing a CTI integration with any COM-compliant container, or any
other container that supports COM features, such as Microsoft Internet Explorer or Visual Basic for
Applications scripting languages. The COM CIL is the easiest to implement in scripting
environments, and helps achieve the fastest integrations requiring a custom or non-graphical user
interface. All CTI OS components are distributed via dynamic link library files (.dll), which only
have to be registered once to work on any Microsoft Windows platform. These components are not
appropriate for non-Windows environments. You can use the COM CIL in Windows Forms .NET
applications only if the Runtime Callable Wrappers (RCWs) provided with the CTI OS Toolkit are
a part of the project. For more information, refer to “Adding a Hook for Screenpops” on page 4-9.
appropriate choice for developing a CTI integration with any COM-compliant container, or any
other container that supports COM features, such as Microsoft Internet Explorer or Visual Basic for
Applications scripting languages. The COM CIL is the easiest to implement in scripting
environments, and helps achieve the fastest integrations requiring a custom or non-graphical user
interface. All CTI OS components are distributed via dynamic link library files (.dll), which only
have to be registered once to work on any Microsoft Windows platform. These components are not
appropriate for non-Windows environments. You can use the COM CIL in Windows Forms .NET
applications only if the Runtime Callable Wrappers (RCWs) provided with the CTI OS Toolkit are
a part of the project. For more information, refer to “Adding a Hook for Screenpops” on page 4-9.
•
C++. The CTI OS Client Interface Library for C++ is the appropriate choice for building a
high-performance application running on a Windows platform in a C++ development environment.
The C++ CIL is distributed as a set of header files (.h) that specify the class interfaces to use and
statically linked libraries (.lib) that contain the compiled implementation code.
high-performance application running on a Windows platform in a C++ development environment.
The C++ CIL is distributed as a set of header files (.h) that specify the class interfaces to use and
statically linked libraries (.lib) that contain the compiled implementation code.
•
Java. The CTI OS Java Client Interface Library (Java CIL) is an appropriate choice for
non-Microsoft (typically UNIX) operating systems, as well as for browser based applications.
non-Microsoft (typically UNIX) operating systems, as well as for browser based applications.
•
.NET Cil class libraries. This section covers the steps required to reference the .NET CIL
components in a C# and Visual Basic .NET project files.
components in a C# and Visual Basic .NET project files.
Testing CTI Applications
Testing is often characterized as the most time-consuming part of any application development process.
Developing a Test Plan
Testing CTI applications requires a detailed test plan, specific to the business requirements set forth in
the requirements gathering phase of the project. The test plan should list behaviors (test cases) and set
requirements to prove that each test case is successfully accomplished. If a test case fails, it should be
investigated and corrected (if appropriate) before proceeding to the next phase of testing.
the requirements gathering phase of the project. The test plan should list behaviors (test cases) and set
requirements to prove that each test case is successfully accomplished. If a test case fails, it should be
investigated and corrected (if appropriate) before proceeding to the next phase of testing.
It is recommended that you perform (at minimum) the following test phases: