Database Architecture
Fundamental to our approach is the use of ODBC. Softdial Campaign Manager™ can work with any DBMS that provides an ODBC level 2 compliant data source. There are proven installations using Oracle (V8 and V9), SQL server and MS Access (see Database Deployment Issues). Softdial Campaign Manager™ interrogates the user's data, picking up column name and type information, and uses the capabilities of the data source in storing its own metadata.
The approach we have taken to using ODBC in C# is to provide a managed code wrapper to use the C++ ODBC classes provided by MFC. In this way we can continue to support as many RDBMS implementations as possible using proven technology.
The database operations for each campaign are managed through a dedicated thread. All operations are asynchronous i.e. any database requests are made via PostThreadMessage. See Fig. 1.
Fig. 1 - Database Architecture

Initially the switch outcome column of all new records contains NULL or 0 (zero). When a record is selected for sending to Softdial CallGem™ for the first time it is moved to the primary cache and the switch outcome field is set to -1.

The following Softdial Campaign Manager™ server
- TelephoneNumberMaxLength
- TelephoneNumberMinLength
- ValidStartCodes
See
By default, null, 0 and 'space' are considered invalid. Extended validation using the registry settings may be based on a predefined set of start codes or minimum/ maximum length.
The NumberInvalidOutcomeValue setting (which defaults to 101), sets the Switch_Result field value for an invalid number.
Windows client - if using the Softdial Campaign Manager™ wizard to configure the database columns, the Switch_Result column is used to store the switch outcome data.

The retry recordsets and rescheduled calls are polled every 2 minutes on alternate minutes.

A call is picked up by Softdial Campaign Manager™ as a retry if:
- the retry timestamp field is non-0 (zero), and is due either sometime in the past, or in the next hour.
- the switch outcome column contains the value -4.
Softdial Campaign Manager™ sets this value automatically when determining when a call that failed to connect will be rescheduled.
For more details of how retries and rescheduled calls are handled in the database, see Retry Handling.
Softdial Campaign Manager™ will process retries according to the following rules:
If the call is
- past due, it will be processed immediately.
- becoming due within the next hour, it will be cached until the retry is due. At the point in time where the retry is due the call will be put at the head of the cache to be served as the next number delivered to Softdial CallGem™.
Retries will maintain strict FIFO order.

A call is picked up by Softdial Campaign Manager™ as a rescheduled call if:
- the retry timestamp field is non-0 (zero), and is due either sometime in the past, or in the next hour.
- the switch outcome column contains a non-NULL, non-0 (zero) value.
Softdial Campaign Manager™ will process rescheduled calls according to the following rules:
If the call is
- past due by more than 1 hour, it will be processed immediately.
- becoming due within the next hour, it will be cached until the callback is within 5 minutes of being due. At this point Softdial Campaign Manager™ will place the call with Softdial CallGem™ as a planned time call.

There are additional notifications raised by Softdial Campaign Manager™ because of integrity issues caused by very slow database performance. The slow database performance is usually on account of
- very large tables, or
- poor indexing, or
- generally overloaded database
If messages are seen such as
Processing delay of xx.yy seconds for retry scan. Delays of more than 20 seconds will lead to data integrity issues.
this means that scanning the database for retries is occurring 20 seconds or more later than scheduled. Softdial Campaign Manager™ Server single-threads all database activity in order to ensure high throughput and preserve integrity. If there is a large processing backlog, behaviour becomes unpredictiable. These messages are an early warning of database overload. Any time they are seen, you should look at how to improve database performance.

The main recordset is closed and reopened each time a timezone availability change occurs. The main recordset is opened at the start of the campaign with no timezone selection and whenever a selection criteria change is enforced to determine the overall size of the calling list. The recordset is then closed and reopened with the correct timezone selection criteria.
The primary queue size is user-configurable. The primary queue is topped up from the secondary queue when retries are coming due in that queue and from the main recordset. The primary queue requests more data when it is halfway depleted. So if the primary queue size is set to the default (200 records), once it is depleted to 100 records a request to read the next 100 rows from the main recordset will be issued. The queue needs to be large enough to be able to cope with dialer demand whilst the recordset is closed and reopened for timezone change or selection criteria change.

Softdial Campaign Manager™ has been designed to work as the single point of contact with the user's database from the call center's perspective. It can of course be used to deliver record keys to a client application, which will then perform a database lookup, but experience shows that for delivery of large-scale systems this leads to degradation of database performance.
Softdial Campaign Manager™ uses the Data (DT) parameter on various Softdial CallGem™ messages to marshall data communication between client and server.
Softdial Campaign Manager™ delivers field name, data type and value information for all of the columns in the table or view used as the primary record source for the campaign.
From the client end, it is possible to send back requests to update a number of different tables with values. In addition to this, Softdial Campaign Manager™ also maintains state information for rescheduling calls and retries, providing that the hooks for doing so are set up as part of the campaign configuration.

Includes a mechanism to limit row count on column analysis cursor and main cursor to improve performance when using a large number of records (e.g. more than 200,000). The mechanism is controlled at a tenant level in the registry -
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Sytel\CMServer\[Tenant] (64bit OS) .
For more information,

For countries covering more than one time zone (most notably the USA), to determine valid times to call it is necessary to know the following 2 pieces of information:
- which time zone a called party is in
- which legislature (state) a called party is in
It is highly unlikely that a user will store time zone information in their database, so we must derive it from potentially 3 sources of data within a user's database:
- Telephone Area Code
- Postal / Zip Code
- State / Legislature Code
Softdial Campaign Manager™ will maintain maps in memory to facilitate lookups for time zone and legislature (state). These maps will work on partial information but quality of results will suffer.
Given a permuted time zone and state, Softdial Campaign Manager™ calculates start and end times for calling represented in UTC and writes this back to the database as a 'start of job' activity. These values are then used to construct the query used for the primary recordset. It should be noted that the recordset is closed and reopened every 15 minutes to take account of changes in allowed time to call.
Sample Data Sets
As part of the installation of Softdial Campaign Manager™, a sample US time zone and dialing rule database is supplied in XML format. This was correct as at October 2001 but it is the user's responsibility to ensure that this information is kept up to date.
See also Timezone Data Import