Developer Documentation Library > Dialer SDK > Overview > UNICOM Intelligence Interviewer - Server Admin architecture
 
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 are still useful to gain an understanding of the UNICOM Intelligence Interviewer - Server Admin architecture. This following diagram is a generic view of the architecture. It is your responsibility to build the highlighted components. 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 architecture
This graphic is described in the surrounding text.
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.
ISampleManagement.Get for predictive algorithms
This graphic is described in the surrounding text.
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.
Thread A: The request thread
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.
3 The interviewer is made available to the group for dialing.
4 Get blocks awaiting a signal that the interviewer has been connected.
Thread B: Your dialer thread
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.
3 The retrieved numbers from the sample records are passed to the dialer for group dialing.
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.
5 If connected, add the record to the waiting interviewers structure and signal.
Thread A: The request thread
Remove the waiting interviewer entry from the structure and return the sample record.
See also
Scenarios
Interviewing
Supervisor monitoring
Reports and the history table
UNICOM Intelligence Dialer Software Development Kit (SDK)