Maximizing the Active Call Center Software's Uptime

Active Call Center includes many features specifically designed to maximize uptime. Some of these features are:

A stable memory and resource usage profile.
Direct low-level integration with the operating system.
The ability to run as a service under Windows NT, 2000, and XP.
Other less obvious features, but we like to keep them a trade secret!

For maximum uptime in a highly scalable call center solution, use Active Call Center Professional.

Since Active Call Center is a user-customized application, the user must take some responsibility for maximizing Active Call Center software's reliability. This section discusses several issues that Active Call Center users interested in high availability should consider.

Integrate Other Applications Carefully When Reliability is an Issue

One of the features that makes Active Call Center unique is that it was designed with the intention of being integrated with existing software, data, and networks.

The integration features of Active Call Center such as the VBScript Macros are one of the likely areas to experience failure, particularly if the Call Tree developer is not careful to take into account various types of errors that may occur. For example, a Call Tree may fail in any of the following situations:

A network data source suddenly becomes accessible, causing errors in data query requests.
A COM component accessed through VBScript crashes.
A COM component accessed through VBScript leaks memory and resources, grinding the system to failure over many calls.

Active Call Center is able to manage many types of errors that occur in external COM objects. In these cases, Active Call Center can keep answering calls even if an error occurs in a COM object. However, there will be situations when a VBScript Macro can crash in a way that also crashes Active Call Center.

Here are some suggestions to minimize crashes coming from external components:

Carefully test each and every branch of a Call Tree for errors.
Implement error handling in the VBScript Macros with the On Error... statement.
If network resources become unavailable, consider using Active Call Center for an outbound call to alert a technician about the error.
Carefully select quality COM objects for use with VBScript Macros.
Database access should be performed with reliable, scalable COM components: for example, Microsoft ADO should be chosen over Microsoft DAO where possible for data access.

Memory Leaks Through VBScript

Microsoft VBScript is designed to be an enterprise class technology; Microsoft uses it as part of their high-end web servers. This is the same scripting technology used in Active Call Center.

Unfortunately, our tests indicate that some COM objects appear to create a memory leak when run in VBScript. For example, under Windows ME, a VBScript Macro with the following code leaks a small amount of memory:

Dim dbEng, db, rs Set dbEng = CreateObject("DAO.DBEngine.35") Set db = dbEng.OpenDatabase_
("C:\Program Files\Active Call Center\Phone Call Log.mdb") Set rs = db.OpenRecordset("SELECT * FROM Calls") rs.Close db.Close

Memory leaks don't happen with all COM objects, but when they do occur, they must be considered in the reliablity planning. A small memory leak by itself is not dangerous: we have tested COM objects that leak small bits of memory over thousands of calls with no crashes. However, eventually an aggregation of many thousands of small leaks will begin to bog down a system. There is an orderly process to dealing with these nefarious memory leaks:

Identify whether or not there is a leak.

The only way to be absolutely sure of whether or not a specific section of VBScript code leaks memory is to run it thousands of times. In most cases the memory leaks are created as objects are created and destroyed when a macro runs and completes. Therefore, using a For ... Next loop for thousands of iterations is not a satisfactory way to identify a leak. One way to identify a memory leak is to run a macro thousands of times by routing or looping calls through the macro's Node thousands of times. Memory leaks will be apparent if one is watching performance monitors at the same time as running the macros.

Minimize the leak by rearranging code.

Our experience has been that most memory leaks in VBScript occur when objects are created in a script and then destroyed after the script has finished. This occurs despite Set objX = Nothing statements. The solution to minimize memory leaks in these cases is to minimize the number of times objects are created and destroyed. This can often be accomplished by structuring the code so that most of the COM object interaction takes place in the Call Ending VBScript Macro. For example, if data is collected from the caller and then saved in a database at each Node, the code can be restructured so that the collected data is saved in a single query during the Call Ending VBScript Macro.

Create or use low-level middleware to manage requests to the COM object.

This is a challenging technique. The idea is to have a "middleware" COM application sit between the COM objects that are needed and Active Call Center. The middleware COM application will create a single instance of the COM objects needed when it is started. Active Call Center will send requests to the middleware application through COM. When Active Call Center sends requests to the middleware, the middleware passes them along to the COM objects. The middleware app returns the results to Active Call Center. A dangerous memory leak is avoided by not creating and destroying the suspect COM objects every time a request is served. Here's an illustration:

Flowchart - Middleware

Another solution that can work is to have the middleware application carefully create and destroy the needed COM objects (this requires low-level COM programming). Other solutions to memory leak problems may also work, depending on the exact details of the situation.

If no satisifactory solution can be found, a regular reboot should be included as part of the operating plan to free up the aggregated memory leaks.

Avoid Saving Data into the Call History in High Volume Applications

When large amounts of recorded audio or other call data are saved into the Call History, the Call History database size can grow significantly. A fresh Active Call Center installation uses a Microsoft Access 2000 format database for the Call History. For high volume calling, consider disabling or using a different database format as discussed in the section on Customizing the Call History Database Format. If large call volumes or large amounts of recorded audio or call data are expected, disable the options in Tools ... Voice Telephony Settings that relate to saving data into the Call History. Recorded audio can be saved as wave files using the SaveFileAfterRecord variable and other call data can be stored elsewhere using VBScript Macros.

Remotely Monitor Availability with a Separate Active Call Center System

A separate Active Call Center system can be used to monitor an Active Call Center phone answering system (or any other phone answering system for that matter). Simply configure an Active Call Center outbound dialer to run at regular intervals using the outbound dialing COM object. Have the system perform some simple actions by touch tone by including touch tones with comma delays in the dial string. If needed, have Active Call Center outbound call record the replies from the answering system.

After the call has completed, have the monitoring program analyze the log files to make sure the call was answered. If a problem is detected, the system can call a service technician to alert them of the situation.

What About the Active Call Center License?

Certain versions of Active Call Center ship with a hardware lock (either USB or parallel port key). The hardware key allows the user complete control of an Active Call Center installation and eliminates issues related to electronic licensing.

Customers that are making larger capital investments may want to consider a limited use source code license. This would provide guaranteed availability of Active Call Center source code for future upgrades, customizations, or installations. Please contact us for details.