UCCE Reporting, Tracing single call with Skill Group Details

Version 1
    This document was generated from CDN thread

    Created by: Sebastian Obermeier on 10-11-2010 08:14:28 PM
    Hello,
    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.
     
    Thanks.
    Sebastian

    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:
     
    TCD
         records for a given call may be identified because they contain the same
         RouterCallKeyDay and RouterCallKey. 
         Successive TCD records are ordered by incrementing
         RouterCallKeySequenceNumber.

    Intermediate
         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.

    In CVP
         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