Cisco Cisco Customer Voice Portal 8.0(1)
2-14
Cisco Customer Voice Portal (CVP) Release 3.0(0) Product Description
Chapter 2 CVP Solution Components
CVP System Administration
Capture (CAP) Micro-Application
The Capture (CAP) micro-application is new for CVP 3.0. It has been added to allow you to trigger the
storage of current call data at multiple points in the ICM routing script. The CAP micro-application must
be configured as a VRU script, and it is executed using a RunExternalScript node, just as with any other
CVP micro-application. The VRU Script Name should be “CAP” or “CAP,xxx”, where “xxx” is any
arbitrary string to be used if necessary for uniqueness purposes. There is no VRU Script Config string.
storage of current call data at multiple points in the ICM routing script. The CAP micro-application must
be configured as a VRU script, and it is executed using a RunExternalScript node, just as with any other
CVP micro-application. The VRU Script Name should be “CAP” or “CAP,xxx”, where “xxx” is any
arbitrary string to be used if necessary for uniqueness purposes. There is no VRU Script Config string.
Executing a Capture microapplication causes the ICM PG to produce an intermediate termination record.
Specifically, it writes a record in the Termination_Call_Detail (TCD) table which includes all current
call variables (but not the VRUProgress variable), router call keys, date and time, caller entered digits,
etc. Together with the TCD record, the Capture micro-application writes a set of records to the
Termination_Call_Variable (TCV) table which includes the current values of all ECC variables.
Specifically, it writes a record in the Termination_Call_Detail (TCD) table which includes all current
call variables (but not the VRUProgress variable), router call keys, date and time, caller entered digits,
etc. Together with the TCD record, the Capture micro-application writes a set of records to the
Termination_Call_Variable (TCV) table which includes the current values of all ECC variables.
ICM provides no standard reporting templates for TCD and TCV records. These tables are very large
and minimally indexed, and are optimized for writing rather than querying, in order to minimally impact
call handling throughput. If you plan to report on this data, you should create off-hours extract processes
which copy rows in their raw format into a database which is external to ICM. From there you can
organize the tables in the way that best supports your querying requirements.
and minimally indexed, and are optimized for writing rather than querying, in order to minimally impact
call handling throughput. If you plan to report on this data, you should create off-hours extract processes
which copy rows in their raw format into a database which is external to ICM. From there you can
organize the tables in the way that best supports your querying requirements.
If using the Capture microapplication you should keep in mind that it places a heavy demand on ICM
resources. Each time you use it, the ICM writes one TCD record and multiple TCV records. Though it
can conveniently capture the information you need, it is also likely to capture a great deal of extra
information which you do not require. If you overuse this microapplication, you may end up placing a
heavy load on the ICM both in terms of processing time and disk space, which despite the minimal
indexing, may nevertheless impact ICM’s ability to handle the expected call load. Therefore it is
recommended that you choose carefully where in your scripts you really need to capture information,
and that you spread data items into as many different call variables as possible in order to maximize the
usefulness of each invocation.
resources. Each time you use it, the ICM writes one TCD record and multiple TCV records. Though it
can conveniently capture the information you need, it is also likely to capture a great deal of extra
information which you do not require. If you overuse this microapplication, you may end up placing a
heavy load on the ICM both in terms of processing time and disk space, which despite the minimal
indexing, may nevertheless impact ICM’s ability to handle the expected call load. Therefore it is
recommended that you choose carefully where in your scripts you really need to capture information,
and that you spread data items into as many different call variables as possible in order to maximize the
usefulness of each invocation.
Note
Refer to the CVP 3.0 Configuration and Administration Guide for more information about the CAP
micro-application.
micro-application.
Service Control Database Reporting
The Service Control Interface reports termination call detail records, service, trunk group, and peripheral
real-time records. The VRU PG derives the real-time statistics from the Service Control Messages
exchanged with CVP.
real-time records. The VRU PG derives the real-time statistics from the Service Control Messages
exchanged with CVP.
CVP Error Handling
CVP error handling and reporting generate information the system can use to:
•
Diagnose a system remotely.
•
Automatically report service-affecting events.
Some logging is controlled by the user; some logging–such as entries related to error conditions–is
always reported.
always reported.
There are a variety of methods the CVP uses to calculate metrics and handle and report errors:
•
Standalone Distributed Diagnostics and Services Network (SDDSN) provides a mechanism for
remote diagnosis of component failures.
remote diagnosis of component failures.