Following diagram shows CVP architecture with Reporting service and Database separated for more clarity.

The call server uses a central messaging bus to allow each service to communicate.

The reporting service connects to the message bus through either an in-process plug-in or an out-of-process plug-in, depending on whether the reporting service resides in the same Java Virtual Machine (JVM) with the message bus system.

The service listens to all messages passing through the message bus and captures both call-state change messages sent from Call Server or reporting messages sent from the Reporting Server.

The reporting service then parses those messages, converts them into batches of applicable Structured Query language (SQL) statements, and executes them into an SQL database using the Java Database Connectivity (JDBC) Application provisioning interface (API).

The reporting service can also receive and process Unified CVP messages related to Unified CVP system administrative tasks, such as turning on or off debugging and querying statistics. As the diagram shows, the reporting service can be shared by multiple Call Servers that belong to the same Unified CVP deployment.

Couple of points to note:

• Each Call Server and each VXML Server can be associated with only one reporting server
• A deployment needs only one reporting server. During temporary database outages, messages are buffered to file and are inserted into the database after the database comes back on line
• Unified CVP does not have native reporting engine, but includes templates which can be imported into CUIC. CUIC connects with CVP Reporting server to run these reports.

Database Tables

CVP Reporting server database tables are categorized as below:

• Call tables – This table is the primary record of a call and contains the basic metrics for each call. It contains one record per call. You can get proper CallGUID from this table.
• VXML tables – Events can be captured from VXML for anything that occurs inside of the VXML script. These calls start at the Call table and are linked to the VXMLSession Table using the CallGUID column. The VXMLSession is made up of a series of elements that are visited within the context of an application. Each element may have multiple ancillary attributes such as flags that can be set in an element. Values for these flags may be found in the VXMLElementFlag Table and are linked to using the ElementID.
• Summary / Aggregate tables – Unified CVP Reporting server includes a summary process that aggregates data from the Call and VXMLElement tables into new summary tables. These tables hold summary data on Call metrics and on elements visited in Unified CVP applications.
• Lookup and Reference tables
• Courtesy CallBack tables – These tables support Courtesy Callback functionality. Since this data is of an online-transaction-processing (OLTP) nature, it is retained in its own database, the callback database. When the caller registers a request for a callback, that request is stored in the Callback table. A row is placed into the CallBackQueue table for the call to manage timing and sequencing of calls.