UCCE Reporting, Tracing single call with Skill Group Details

Document created by cdnadmin on Jan 24, 2014
Version 1Show Document
  • View in full screen mode
This document was generated from CDN thread

Created by: Sebastian Obermeier on 10-11-2010 08:14:28 PM
we need to pursuit a single call in the AW database, to report which action occurs to the call.
Our main issue is to know to which skill groups the call has been queued and how long he has been queued.
Is it possible to trigger a new entry in the Call Termination Detail trough the ICM Script before queuing to a new skill group? Or is there any other solution to solve this issue?
The System is a UCCE 8.0 with CVP.

Subject: RE: UCCE Reporting, Tracing single call with Skill Group Details
Replied by: Paige Delk on 11-11-2010 10:22:13 PM
This is an excerpt from and old whitepaper, but it describes the feature that will allow you to write out Termination_Call_Detail rows at any point during scripting.  It is only available in deployments where the
NetworkVRU is CVP.
A new microapplication has been added which allows the
script writer to trigger the storage of current call data at multiple
designated points in the ICM routing script.  The CAP microapplication must be configured as a VRU script,
and it is executed using a RunExternalScript node, just as with any CVP
microapplication.  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
cut 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 new VRUProgress variable), router call keys, date and time,
caller entered digits, etc. 
Together with the TCD record, the Capture microapplication writes a set
of records to the Termination_Call_Variable (TCV) table which includes the
current values of all ECC variables. 
(Later in this document we will use the abbreviation TCD in more generic
terms, to refer to both the Termination_Call_Detail table and its corresponding
set of Termination_Call_Variable records, together.)
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, it
is strongly recommended that you create off-hours extract processes which copy
rows in their raw format into a database which is external to ICM.  There you can organize the tables in
whatever way best supports your querying requirements.
To that end, there are several things you need to know about
these records:
     records for a given call may be identified because they contain the same
     RouterCallKeyDay and RouterCallKey. 
     Successive TCD records are ordered by incrementing

     TCD records may be identified because they contain a CallDisposition of
     53, ¿PartialCall¿.  Only the
     last TCD record for the call contains the actual disposition.

TCV records
     corresponding to a particular TCD record may be obtained by joining on
     TCV.TCDRecoveryKey.  This key
     matches the RecoveryKey value in the TCD record.

As of
     ICM 6.0, the TCD record¿s CallTypeId is populated even for VRU
     peripherals.  This means you can
     determine the call¿s current CallType at the time of each Capture
     microapplication invocation, as well as at the end of the call.

     Comprehensive Model deployments, these records will be associated with the
     VRU leg peripheral.  If you
     are doing VRU application reporting, you probably want to filter for TCD
     records which contain the PeripheralID of the CVP VRU leg.

Please remember that the Capture
microapplication is a fairly expensive operation.  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.

More information can be found in the scripting guide:  http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/ipcc_enterprise/ipccenterprise8_0_1/user/guide/ipce80sg.pdf