Asynchronous Program Execution
The most common programming approach used by applications is synchronous execution. In a synchronous
execution mode, a method call executes all 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 makes a blocking
request and continues 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.
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. The success of the method call means 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 is CIL_OK,
indicating that the method call was successful. However, this does not indicate that the request was actually
serviced by the CTI OS Server or successfully completed at the PBX/ACD.
To determine the success or failure of the underlying telephony operation requested, the CTI programmer
must wait for an event confirming the success or failure of the request. To generalize the message flow model,
most requests made at the CTI OS CIL are answered with a confirmation message and/or an event message.
See the object interface reference in Chapters 8-12 for details on each particular request. This type of response
is called asynchronous—it can arrive at any time after the request is made, but typically requests are services
in sub-second timeframes.
The expected event sequence is described for each method request in the programmer's interface sections of
this document so that programmers know which events to expect. In the event of a request failure, an
eControlFailureConf message is sent to the client; the eControlFailureConf message has a parameter called
MessageType indicating which request failed, and a parameter called ErrorMessage, with a description of the
failure cause.
For example, when sending a MakeCall request, the method typically returns CIL_OK, which means that the
method call was successful. If the underlying make call request is successful, the CIL receives several follow-on
events, such as eBeginCallEvent and eServiceInitiatedEvent. If the request fails, the CIL receives the
eControlFailureConf message.
A common mistake is that developers who have not previously programmed with asynchronous events mistake
the error code returned from a method call for the actual result of the request. The correct semantics are to
interpret the error code as being indicative of the result of the method call, and to interpret the follow-on
events to determine the actual result of the requested operation.
CIL Error Codes
Whenever a method call is invoked by a custom application using the CIL, an error code is returned. The error
codes returned only indicate success or failure of the method call, as indicated in the previous section.
The possible values of the error code returned from C++ and Java CIL methods are defined in the following
table.
CTI OS Developer Guide for Cisco Unified ICM/Unified Contact Center Enterprise, Release 11.6(1)
3
CIL Coding Conventions
Asynchronous Program Execution