UNICOM Intelligence Interviewer - Server Admin architecture

This section presents architecture diagrams and detailed scenarios showing how the user interfaces and objects interact. For more information about the UNICOM Intelligence Interviewer - Server Admin architecture, see Interviewer Session engine. For more information about interaction with the UNICOM Intelligence Dialer, see Dialer Interface component.

This section describes interaction with a particular dialer, but is still useful to gain an understanding of the UNICOM Intelligence Interviewer - Server Admin architecture.

The following diagram is a generic view of the architecture. It is your responsibility to build the highlighted components: that is, the dialing SM provider, and the dialer component. You will be implementing the ISampleManagement and IDialingProvider interfaces for your dialer. Many of the methods on the ISampleManagement interface are actually implemented by the Sample Management Providers but the Get and Return methods are very important to your implementation. You might also want to separate your dialer communication into a separate dialer component.

UNICOM Intelligence Interviewer - Server Admin is a multi-tiered clustered architecture that supports failover. The components are hosted on the Interview Service tier. There can be multiple Interviewer Session Engines on each physical server and multiple servers hosting the Interviewer Session Engine. Therefore, there can be multiple instances of your dialing provider components on a single physical server and multiple servers running your dialing provider components. A single project can be loaded by multiple Interviewer Session Engines to provide additional capacity. As a result, there can also be multiple servers hosting a single project.

The diagram in How respondents are connected displays the ISampleManagement.Get implementation for the UNICOM Intelligence Dialer group dialing provider. This implementation uses a predictive dialing algorithm that is hosted by UNICOM Intelligence Interviewer. You might want to use a similar architecture for your provider if your dialer does not implement a predictive dialing algorithm.

The following diagram displays a possible implementation of ISampleManagement.Get for a dialer that hosts its own predictive algorithm.

Thread A: This is the request thread from Phone Participants. Calls on this thread generally block.

Thread B: This thread is created by your dialer components to handle asynchronous communication with the dialer. The steps involved in group dialing, as labeled in the diagram, are described as follows.

1 The Interviewer Session Engine calls the ISampleManagement.Get method. The Get method must block until the interviewer is connected, which will necessitate an additional thread.

2 The dialing provider adds the interviewer information to a waiting interviewers structure and creates an event synchronization object.

1 Asynchronously, the dialer might request numbers to dial based on its calculation of the amount of numbers required to cache on the dialer.

2 The dialer components retrieve additional sample records from the sample management provider using the ISampleManagement.Get method. The sample records are returned as SampleRecordXml. It is critical that the entire SampleRecordXml be returned when the number is connected or a record is returned with a disposition. This means that the dialing provider needs to hold these records in memory until they are returned.

4 Asynchronously, the dialer signals that a respondent has been connected to an interviewer. This event handler can also handle the return of records that have not been connected.