The Architecture of Banking Alerts
.jpg) |
This document provides a high-level overview of the components of the Banking Alerts reference application, and describes the flow of information between the components.
Banking Alerts Components
Banking Alerts is a speech-enabled, distributed Web application that depends on coordinated communication among seven major components. The Banking Alerts Visual Studio solution file contains a separate project for six of these components, and two projects for the remaining component. The following table lists the components. For each component, the table also provides a component reference identification (RID) number, the project name, and a brief description of what the component does. The RID numbers label the components in the diagram that follows the table.
| RID | Component Name | Project Name | Description |
|---|---|---|---|
| 1 | Customer GUI | Customer | The set of .aspx, .htm, graphics files, and the code behind these that create the graphical interface and functionality that customers use when they navigate to the Woodgrove Bank Web site. The graphical components include the Woodgrove Bank Home page, the New Customer Enrollment page, and the Customer Account Information page. Functionality includes customer enrollment, log in, account information display, alert notification setting, and log out. |
| 2 | Dialogues | Dialogues | Collections of the .aspx pages, recognition grammars, and prompt function files that the application uses to deliver an alert notification. The .aspx pages contain the Speech Controls that implement the three main dialogues corresponding to the three types of alert notification the application delivers. The pages implement the common dialogues such as the login dialogue that the application uses regardless of the notification type. The recognition grammars and prompt function files recognize customer speech and generate application responses for all of the various dialogues. |
| 3 | Supervisor GUI | Supervisor | The set of .aspx, .htm, graphics files, and the code behind these that create the graphical interface and functionality that simulated supervisors use to create transactions and edit user data in order to trigger alert notifications. The graphical components include the Transaction Simulator, which displays account information and generates transactions for selected customers, and the Queue Monitor, which displays the events that have triggered alerts, and the list of available interpreters. The graphical components and functionalities are presented on a single page labeled "Transaction Simulator." |
| 4 | Triggered Call Queue (TCQ) | Tcq and TcqHost | A process that runs on the Web server. ASP.NET hosts the TCQ. The TCQ is responsible for tracking:
Functionality includes receiving alert notifications from SSNS, routing call requests to available interpreters, monitoring call request status, and monitoring interpreter status. The "Tcq" project defines the classes for the TCQ assembly, and the "TcqHost" project contains the code that instantiates the TCQ object and starts the TCQ process. |
| 5 | SQL Server Notification Services (SSNS): Banking Alerts Instance | NotificationService | Monitors the SQL database for database events triggered by changes in data that result in conditions meeting the criteria for sending an alert notification. The project file contains the definition and support code that create and update the Banking Alerts instance of SSNS. See the SSNS documentation for more details on how to create or configure SSNS services. |
| 6 | SSNS TCQ Custom Delivery Component | TCQCustomDeliveryProtocol | Receives notifications from SSNS, and delivers an event message to the TCQ. Event messages consist of a customer phone number, and a URL to which the application redirects the outbound call when the customer answers. SSNS includes native support for delivering notifications by various means such as e-mail. The project file defines a custom protocol that extends SSNS, enabling Banking Alerts to deliver notifications as outbound calls. |
| 7 | Microsoft Messaging Queue (MSMQ) | (code is in Tcq) |
.gif)
The Triggered Call Queue (TCQ) Object
Banking Alerts uses an object called the "triggered call queue" (TCQ) to maintain the state of all call requests. Maintaining the state of all call requests enables the TCQ to:
- Retry calls that were busy or not answered on the previous call attempt.
- Notify the agents that request outbound calls whether the request was successful.
The TCQ class uses .Net Remoting, which makes the TCQ object available not only to processes running on the same computer, but also to processes running on other computers. In other words, using .Net Remoting enables programs running on computers that do not host the TCQ object to submit requests for outbound calls.
Because IIS supports authentication of requests, Banking Alerts uses IIS as the host service for the TCQ object. To set up this hosting relationship, the Banking Alerts installer creates a virtual directory called TcqHost that contains the TcqHost.dll (the .dll containing the class definition for the TCQ object). The installer also adds the following entry to the application's web.config file:
<system.runtime.remoting>
<application>
<service>
<wellknown mode="Singleton" type="Tcq.Coordinator,Tcq, Version=1.0.3200.0,
Culture=neutral, PublicKeyToken=deb03e293ded91b2, Custom=null" objectUri="Tcq.rem" />
</service>
<channels>
<channel ref="http">
<serverProviders>
<formatter ref="SOAP" typeFilterLevel="Full"/>
</serverProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
This entry enables Banking Alerts to publish the TCQ object using a well-known URI. This URI is constructed by combining the URI of the TcqHost and the name of the hosted class (TCQ). The SQL Server Notification Services (SSNS) TCQ Custom Delivery Component uses this URI to establish a connection to the TCQ in order to create local proxy objects. The first time that the SSNS TCQ Custom Delivery Component calls a method of a proxy object, the TcqHost instantiates a single instance (singleton) of the TCQ object. This singleton connection is persistent, and subsequent calls on the methods of the proxy objects trigger calls on the TCQ object hosted in TcqHost.
Additional Components
In addition to the major components listed previously, the Banking Alerts solution file contains two additional projects that globally support application functioning. The following table lists these projects, and provides a brief description of their function.
| Project Name | Description |
|---|---|
| Banking | Contains a set of shared routines that the application uses for SQL database data access, data protection, and other data functions. |
| RecordedPrompts | Contains transcriptions of the Banking Alerts prompt recordings, as well as the audio data for each recording. |
Banking Alerts Information Flow
Information about customer accounts and alert notification preferences is stored in a SQL database. When the accounts data controller enters a new transaction using the Transaction Simulator, the application adds data to both the SQL database and to one of the Events tables in the SSNS database used for Banking Alerts. The Banking Alerts SSNS service periodically examines these tables for new entries, and determines whether any of those entries meet the criteria for triggering an alert notification. When the Banking Alerts SSNS service detects that the criteria for triggering one of the Banking Alerts alerts have been met, it sends the alert information to the SSNS TCQ Custom Delivery Component.
The following diagram illustrates the remainder of the Banking Alerts data flow from this point onwards for an outbound call that initially receives a busy signal, but then is answered by the customer on the subsequent retry.
.gif)
The callout numbers in the previous diagram correspond to the following steps that describe the flow of data.
The Custom Delivery Component sends the event information to the TCQ coordinator as arguments for a RequestCall method. The values of the arguments consist of a customer phone number, and a URL to which the application will redirect the outbound call when the customer answers.
The TCQ coordinator generates a CallRequestID to identify the call request. The TCQ coordinator creates an event message using the arguments passed to it by the RequestCall method along with the CallRequestID, and posts this event message to the MSMQ message queue.
A Message Queue Monitor object instantiated by Telephony Application Services (TAS) regularly polls the MSMQ message queue with a callback function. When a new, unassigned event message exists in the queue, MSMQ sends the event message to TAS.
TAS receives the event message, assigns a SALT interpreter from the pool of SALT interpreters that it maintains, and directs the interpreter to load the URL contained in the event message. The interpreter loads the URL, opening the Banking Alerts application .aspx dialog page that corresponds to the type of alert notification required by the event message.
The Banking Alerts application dialog page uses a postback to register the interpreter with the TCQ coordinator, using the CallRequestID to identify the interpreter. Registering the interpreter enables the TCQ coordinator to track the status of the alert notification request represented by the event message.
The application dialog page dials the outbound call, but receives a busy signal. The application uses a postback to notify the TCQ coordinator that the phone number for the alert notification specified by the registered CallRequestID is busy. The application releases interpreter back into the SALT interpreter pool.
After three minutes elapse, the TCQ coordinator once again places this event message on the MSMQ message queue.
A Message Queue Monitor object instantiated by either the same, or by a different an instance of TAS retrieves the event message (multiple instances of TAS can monitor the same MSMQ message queue).
TAS assigns an interpreter, and the interpreter loads the URL contained in the event message.
The Banking Alerts application dialog page uses a postback to register the interpreter with the TCQ coordinator.
The application dialog page dials the outbound call. The call is answered, and the application uses a postback to notify the TCQ coordinator that the outbound call for the registered CallRequestID has successfully connected.
With the call connected, the application continues, running the alert notification dialog. Upon completion of the alert notification dialog, the application uses a postback to notify the TCQ coordinator that the call request has been completed.
Changing SSNS Intervals
Change the amount of time that SSNS waits before polling for new events (the polling interval), and the amount of time that SSNS waits before sending newly generated notifications (the notification interval) in the file labeled adf.xml. Once an interval has been changed in adf.xml, use Visual Studio .NET 2003 to rebuild the Banking Alerts solution, and then run Update.bat. Both adf.xml and Update.bat are located in:
%ProgramFiles%\Microsoft Speech Application SDK Version 1.1\Applications\Banking Alerts\Banking\TCQ\NotificationService\
Set the polling interval using the value contained in the QuantumDuration element that is contained in the SystemName element:
<Distributors>
…
<Distributor>
…
<SystemName>%_NSSystem_%</SystemName>
<QuantumDuration>PT5S</QuantumDuration>
…
Set the notification interval using the value contained in the QuantumDuration element that is contained in the ApplicationExecutionSettings element:
<Distributors>
…
<Distributor>
…
<ApplicationExecutionSettings>
<QuantumDuration>PT5S</QuantumDuration>
…
The default interval for both the polling and the notification intervals is five seconds, indicated by the integer 5 in the value PT5S. Change the integer to change the duration in seconds. For example, to change one of the intervals to thirty seconds, change the value contained in the QuantumDuration element to PT30S.