July 1998

BY CARL R. STRATHMEYER

Computer telephony integration (CTI) is not an application, it's a feature - a feature that needs to be added to a huge number of existing applications, be they off-the-shelf or custom-built. And if the CTI industry adopts the computing industry's established methods for application integration, it will be much easier to include these CTI features in any application we want. For the forseeable future, the most efficient and effective integration methods will be based on the principle of packaged software components. Let's take a look at how computer telephony fits into that software component

ActiveX OR JAVA BEANS, THE CHOICE IS YOURS
There are two principal models for packaged software components in today's commercial marketplace. Microsoft promotes the ActiveX architecture (formerly called OCX), and Sun Microsystems promotes the Java Beans architecture. Each has advantages and disadvantages. ActiveX modules can only be used in Windows environments such as Windows 95, Windows NT, and Internet Explorer. Java Bean modules are platform-independent and can be used (at least in principle) on any operating system or browser platform that supports Java. But for the moment at least, ActiveX holds the edge with respect to commercial importance -there are many more commercially available container applications that support ActiveX software components.

The principles behind these two architectures are much the same. A container application provides the overall structure, while software component modules can be embedded into the container framework to provide specific capabilities. The software components are portable and can be embedded into many different containers; the component and its container need not come from the same source. Once a component module is embedded in a container, the functions of that module become available to the container application. The functions are usually invoked via some kind of macro language or other flexible customization mechanism.

Current State Of Affairs
The ActiveX and Java Bean software component architectures make it much easier to add CTI features to applications. CTI-based applications have historically been difficult to develop, because application developers had to use complex procedural programming interfaces (APIs) to get access to the CTI capabilities they needed. For example, telephone-based applications generally involve responding to call events that arrive at random times. These are difficult to handle with traditional telephony APIs, because the flow of the application software must be interrupted when a telephony event is processed. It takes a programmer with special experience developing real-time systems to properly handle these interruptions without disrupting other portions of the application. Furthermore, interrupt-based application software is difficult to test and maintain. This state of affairs explains why there are still comparatively few CTI-enhanced applications on the market even though customer interest is high.

Change Just Around The Bend
Software component technology will change this, and change it quickly. For example, both ActiveX and Java Beans standardize real-time event handling. Container applications know that events will be signaled by a software component in a certain way, and they have standard methods for handling them. The application developer simply provides a series of instructions that specify what action should be taken when each specific kind of event occurs, and does not have to construct the more difficult underlying event-handling mechanisms. When a telephone event is detected, the software component signals the container application, which in turn executes the series of application instructions specified for that event. All of the complex real-time event mechanisms are handled automatically within the software components and the container application, greatly reducing the likelihood of programming errors. The result is a dramatic reduction in the complexity of CTI-based applications, and the very attractive possibility of adding CTI capabilities to nearly any component-compliant container application.

The best way to appreciate this dramatic simplification is to look at a concrete example of using the software component strategy to add CTI features to an existing application. For our example, we will work with the ActiveX architecture, although the same principles apply to applications based on Java Beans. The environment we chose for this example is Microsoft Access, a very popular application generator and database package. Microsoft Access is an ActiveX container environment, which means that we can include ActiveX packaged software components into applications built with it. For our application, we chose the NorthWind sample application that Microsoft ships with Access. This application includes many of the functions, screens, and data elements required by a typical sales organization.

REAL-WORLD APPLICATION
In the example that follows, we will add a preview dialing function to the existing NorthWind customer screen. With this new CTI function, a user can view a customer information record and then click on a Dial button to launch a telephone call to that customer using a telephone number in the customer record. We will use the ActiveX control supplied by Dialogic as part of its CT-Connect CTI server product.

[This ActiveX control, as well as a free evaluation copy of CT-Connect and a copy of the modified NorthWind application from this example, can be found at www.dialogic.com/prod-ucts/ctconnect. If you want to try this example yourself, download both the CT-Connect Evaluation Kit Windows client module and the CT-Connect ActiveX control and accompanying documentation, and install them on your Windows 95 or Windows NT system. (To actually launch a call, you will also need a CTI-equipped telephone system and the CT-Connect Evaluation Kit server module.)]

Once you have the ActiveX control installed on your system, creating the preview dialing function for the NorthWind application involves just a few simple steps. First, we must place the ActiveX control on the form. To do this, start Access and open the NorthWind application. Open the Customer form in design mode and use the toolbar's Custom Control button to select the CT-Connect ActiveX control. Paint the control onto the form in any convenient location; the control will be invisible when the application is running. Right-click on the control and open its Properties window. Set the name of the control to "MyPhone," and set the custom properties to indicate the telephone line that you want the control to represent. (These custom properties are explained in the control's User Guide.)

Next, we must place a Dial button on the form and connect it to the MakeCall function of the ActiveX control. Click the Command Button tool on the Access toolbar and paint a new command button in a convenient location. Right-click the button and open its properties window. Change both the button's name and its caption to "Dial."

Close the button's properties window and right-click the Dial button again to open the Build Event editor. Select the Code Builder function. When Access opens this window, it will build a new event-handling subroutine for the Dial button's Click event. This is where you specify what should happen when someone clicks on the new Dial button. In our case, we want to launch a CTI call. So in the subroutine area, enter:
MyPhone.MakeCall Phone

This simple instruction invokes the MakeCall function of the ActiveX control. The data item called "Phone" is the field in the NorthWind customer table where the customer's telephone number is stored.

We have one more housekeeping matter to take care of. The CT-Connect ActiveX control must be turned on before it is used, and should be turned off before the application terminates. Access has Form Load and Form Unload events that we can use to trigger these actions. To set these up, select Form in the top left drop-down box; in the top right drop-down box, select Load. Access creates a subroutine that will be executed when the Customer screen is first displayed. Enter:
MyPhone.StartMonitoring

That's all it takes to get the control turned on at the appropriate time. Turn it off the same way: In the top right drop-down box, select "Unload." In the subroutine that Access creates for you, enter:
MyPhone.StopMonitoring

You're done! Save the modified form using the "File" menu item at the top of the screen. Your NorthWind application now has a new preview dialing function. Wasn't that easy? With a few more steps, you can add a complete set of screen-phone functions (answer, hang up, transfer, conference, hold, and even agent login and logout functions) and a screen pop when inbound calls arrive. These functions are all illustrated in the example NorthWind application file on the Web site mentioned at the end of this article.

IDENTIFY CALLERS
When you are implementing CTI functions, you will quickly discover that it is important to accurately identify callers, and that the calling party telephone number is not always suitable for doing that. Most applications use some form of interactive voice response (IVR) to identify the callers. If you have an existing IVR system, you can modify its scripts so that the data it collects is deposited somewhere for later use by the desktop systems that execute the screen pops. Then an ActiveX or Java Bean control can be used within a desktop application to signal the arriving call, whereupon the application retrieves the caller's data from the IVR's repository.

As an alternative to a full-fledged IVR system, you can use voice-processing boards with an enhanced ActiveX control such as the "Etrog" controls available from N-Soft. Such controls, in conjunction with a CTI-equipped telephone system and server, allow you to easily generate voice prompts to callers, collect identifying information, store that information for later desktop use, and then trigger screen pops and other actions based on that data within desktop container applications.

CONCLUSION
All of this is going to change the way the market sells and installs CTI systems. Until now, the market has relied primarily on off-the-shelf CTI application products. With the emergence of packaged CTI software components that fit into industry-standard container applications, CTI features can now be added to existing applications in the field. Even more important, this work is now easier to understand and execute, and it uses the same skills utilized by application integrators working with other software components. As you have just seen, if you can paint a button on a visual form, you can construct a CTI application. Exciting, isn't it?

Carl R. Strathmeyer is marketing director, Computer-Telephone Division, of Dialogic Corporation. Dialogic is a leading manufacturer of high-performance, standards-based computer telephony components. Dialogic products are used in voice, fax, data, voice recognition, speech synthesis, and call center management CT applications. The company is headquartered in Parsippany, New Jersey, with regional headquarters in Tokyo and Brussels, and sales offices worldwide. For more information, visit the Dialogic Web site.