Cisco Cisco Computer Telephony Integration Option 9.0 Developer's Guide
3-3
CTI OS Developer’s Guide for Cisco ICM/IPCC Enterprise & Hosted Editions Release 7.0(0)
Chapter 3 CIL Coding Conventions
Asynchronous Program Execution
Asynchronous Program Execution
Synchronous execution is the most common programming approach used by most
applications. In a synchronous execution mode, a method call will execute all of
the code required to complete the request and provide return values as well as
error codes. Client-server programming can be synchronous (the client
application will make a blocking request and will continue execution when the
request is completed) or asynchronous (the client application makes a request, and
continues processing immediately, with the result of the request to follow at a later
time).
applications. In a synchronous execution mode, a method call will execute all of
the code required to complete the request and provide return values as well as
error codes. Client-server programming can be synchronous (the client
application will make a blocking request and will continue execution when the
request is completed) or asynchronous (the client application makes a request, and
continues processing immediately, with the result of the request to follow at a later
time).
CTI programming is unique in that requests are often serviced by third-party
servers or applications, such as a PBX/ACD in the contact center. The
asynchronous nature of CTI programming requires developers to note the
distinction between an error code and the response to a request. In non-CTI
programming, developers test the error codes (return values from method calls) to
determine whether a method request succeeded or failed. However in a distributed
architecture such as CTI OS, success or failure is often determined by some
external server or component such as the PBX/ACD.
servers or applications, such as a PBX/ACD in the contact center. The
asynchronous nature of CTI programming requires developers to note the
distinction between an error code and the response to a request. In non-CTI
programming, developers test the error codes (return values from method calls) to
determine whether a method request succeeded or failed. However in a distributed
architecture such as CTI OS, success or failure is often determined by some
external server or component such as the PBX/ACD.
The CTI OS Client Interface Library API specifies error codes, which are return
values for method calls. These error codes relate to the success or failure of the
method call, but not the success or failure of the underlying operation. By the
success of the method call, we mean that the parameters sent were of the correct
format, that internal memory allocations were successful, and that the request was
put on the send queue to be transmitted to the CTI OS Server. Generally, the CIL
error code returned from method calls will be CIL_OK, indicating that the method
call was made successfully. However, this does not indicate that the request was
actually serviced by the CTI OS Server or successfully completed at the
PBX/ACD.
values for method calls. These error codes relate to the success or failure of the
method call, but not the success or failure of the underlying operation. By the
success of the method call, we mean that the parameters sent were of the correct
format, that internal memory allocations were successful, and that the request was
put on the send queue to be transmitted to the CTI OS Server. Generally, the CIL
error code returned from method calls will be CIL_OK, indicating that the method
call was made successfully. However, this does not indicate that the request was
actually serviced by the CTI OS Server or successfully completed at the
PBX/ACD.
UNSIGNED
SHORT
SHORT
unsigned short
Integer
unsigned short
int
System.Int32
BOOL
bool
Boolean
VARIANT_BO
OL
OL
Boolean
System.Boolean
ARGUMENTS
Arguments
Arguments
IArguments *
Arguments
Arguments
ARG
Arg
Arg
IArg *
Arg
Arg
Table 3-1
CTI OS CIL Data Type (continued)