Release Notes
What's new
- It's now possible to configure up to 10 custom activity fields of ECE to be included within the activity detail report
- The ECE data integration got improved by using indexed fields for the incremental load
- There is a new detail data extract of unhandled tasks available for BI exports
- Other little changes and improvements (see details below)
- Bugfixes
Compatibility
Cisco Contact Center Software
- Cisco Unified Intelligence Center (CUIC) version 11.6 with COP10 or newer, 12.0, 12.5 and 12.6
- Cisco Unified Contact Center Enterprise (UCCE) version 11.0*, 11.5*, 11.6*, 12.0 and 12.5
- Cisco Packaged Contact Center Enterprise (PCCE) version 11.0*, 11.5*, 11.6*, 12.0 and 12.5
* ECE data integration is not supported for versions before CCE 12.0.
3rd Party Software
- Microsoft SQL Server 2012 Standard Edition 64bit
- Microsoft SQL Server 2014 Standard Edition 64bit
- Microsoft SQL Server 2016 Standard Edition 64bit
- Microsoft SQL Server 2017 Standard Edition 64bit
- Microsoft SQL Server 2019 Standard Edition 64bit
Important notes
Change in calculation of TotalCompleted
The calculation of TotalCompleted tasks within CallType Performance reports has changed with this version. Instead of Answered tasks, we use Handled tasks to calculate the total. Answered and Handled are normally the same number but in case of a failure at the agent desktop after answering a task, the same task is counted twice in the former calculation.
Layout change for grid reports from CUIC 11.0
Cisco introduced a "Universal Grid" with CUIC 11.0 and changed the format from "auto adjustment" to "fixed width" and removed word wraps. Displayed data will always collapse based on the configured grouping.
Reports designed for CUIC 10.5 and before will not fit to the new grid and need to be adjusted manually or replaced with the new templates of this release.
New Features
This section lists new features or functionality for this version.
BREP-516 - ECE custom fields for activity should be included within activity reports
Requirements: The custom fields that are configured for activities should get extracted as well and be part of the activity reports.
Solution Abstract: Including 10 general custom fields into the activity data export, having a custom section to configure the real field names within the solution.
Limitation: Max. 10 custom fields supported. The field length is truncated to max. 256 characters. The names of the custom fields are general names (renaming within reports required).
BREP-515 - ECE incremental load workaround based on indexed fields
Requirements: The data load from the ECE database should run against the fields, where indexes already exists.
Solution Abstract: In order to read data incrementally, values for suggested columns can be retained as max value (last read) as tide marks
- EGPL_CASEMGMT_CASE table – use column update_version to identify new and modified data. Modified and new row of data will have greater value thanlast read value
- EGPL_CASEMGMT_ACTIVITY table - use column update_version to identify new and modified data. Modified and new row of data will have greater value thanlast read value
- EGPL_EVENT_HISTORY_CASE_MGMT table – Use column event_id; This is insert only table hence customer would need to check new data in this tables sincelast check based on column 'Event_ID' which is incrementing number.
Limitation: unknown
BREP-502 - Performance issues with reports 111 and 211
Requirements: None
Solution Abstract: A customer has noticed performance issues when using report 211 with an Enterprise CallType which contains a lot of CallTypes. The cause of the issue is that the historical data in the query is not limited, meaning the report query always joins the historical data of all Enterprise CallTypes with today's intervals. The solution is to limit the data that is selected in the historical data part.
Limitation: Only affects reports 111 and 211
BREP-491 - New RONA & AbandAtAgent data extract
BREP-482 - SLThreshold in ECT Reports should take actual Threshold settings into consideration
Requirements: Change the definition of the field SLThreshold in all historical Enterprise CallType reports
Solution Abstract: Instead of showing the SLThreshold which is globally configured for the whole deployment, it should display the actual value of the Call Types that are configured for each Enterprise CallType.
Limitation: If there are multiple SLThreshold values in an Enterprise CallType, it will display the minimum value.
Bug Fixes
This section lists bug fixes for this version.
BREP-514 - Calculation of WaitTime in calltype detail should be done based on milliseconds
Symptom: WaitTime in CallType Detail data is sometimes one second higher than measured from Cisco for the ServiceLevelCalls.
Conditions: WaitTime is calculated as the datediff in seconds between two timestamps. This means, that it calculates the value only based on seconds and ignores the milliseconds. This can result in a full second for a millisecond, if it's around the full second. The value should be calculated based on the difference in milliseconds and then taken as full seconds like this: datediff(ms,timestamp1, timestamp2) / 1000
Workaround: calculate the value by your own
Further Problem Description: This calculation has to be corrected in procedures export_ctd and export_acd. It can't be used in export_mr in this detail because it overflows with large waiting time.
BREP-513 - Answered Calls with false Non-Agent (CD 14) classification not counted as answered in call details
Symptom: Some answered calls are not counted as Answered in call_type_detail and call_type_detail_handled.
Conditions: Some answered calls with a classification as non-agents (CD = 14) are not treated and logged as answered calls but they are in Call_Type_Interval. If RingTime and InstrumentPortNumber of the agent is available, they are not non-agents and therefor normally counted. For such calls, CD 14 actually is not correct.
Workaround: None
Further Problem Description: -
BREP-512 - Open tasks not classified as CompletedResult in calltype_detail
Symptom: Tasks with long queue time are not classified within Completed result
Conditions: If call detail data is loaded from RCD, it might be that no TCDs are available at the time of the data load. Such tasks should get updated later on when the result is clear.
Workaround: None
Further Problem Description: -
BREP-511 - Unanswered AgentError calls not classified as CompletedResult in calltype_detail
Symptom: CompletedResult in bs_calltype_detail not assigned for some calls
Conditions: The Fault result is only assigned for routing errors logged by RCDs. If calls are routed properly but an error occurs at agent desktop before a call is answered, these calls are not classified as faults and remain NULL in the CompletedResult field.
Workaround: None
Further Problem Description: -
BREP-510 - AgentErrorCounts are counted twice in TotalCompleted of Call_Type_Interval data
Symptom: Calls that are Answered can also be counted as Fault in CallType Performance Reports. This results in a wrong summary of completed calls.
Conditions: Answered Calls where an error occurs at agent desktop are counted twice in TotalCompleted because AgentErrorCount is also part of the Fault volume. AgentErrorCount can occur before or after a call is answered. To get the correct volume of TotalCompleted, Handled instead of Answered calls must be taken to create the sum.
Workaround: -
Further Problem Description: -
BREP-509 - Answered Calls with Error (CD 27) not counted as answered in call details
Symptom: Some answered calls are not counted as Answered in call_type_detail and call_type_detail_handled.
Conditions: Answered calls with agent error during call handling (CD = 27) are not treated and logged as answered calls.
Workaround: None
Further Problem Description: -
BREP-508 - Classic RONA for MR Tasks not included into redirected tasks
Symptom: Tasks with classic RONA implemented are not measured as redirected or RONA within all CallByCall data
Conditions: Sometimes, the classic RONA is implemented with technical "Redirect-Agents" to treat workflows with eGain. Those tasks are counted as RONA within Cisco statistics but not within call detail reports.
Workaround: None
Further Problem Description: -
BREP-507 - SLThreshold in Report 190 is empty when using the system default value
Symptom: The Service Level threshold field in report 190 is empty
Conditions: The system default value is used for the Service Level threshold
Workaround: -
Further Problem Description: Report 190 and the corresponding admin reports 191, 192 and 193 are missing a check whether the value "ServiceLevelThreshold" is null. If it is null, it should display the system default value, otherwise it should display the configured value.
BREP-506 - procedure check_load_setting not available if no ECE connection exists
Symptom: Procedure check_load_setting is not available during the setup process
Conditions: If no connection to ECE exists, the procedure is dropped and not created anymore because the ECE views are no present and create a query error.
Workaround: Fill in the load timestamps without the help of this procedure
Further Problem Description: -
BREP-501 - calltype_detail data: Missing answered calls and wrong TCDRecoveryKey of answered calls
Symptom: There are less answered calls within bs_calltype_detail than available in bs_calltype_handled_detail
Conditions: If many requests are present for the same customer call, some conditions of the join between RCD and TCD can result in some missing or wrong data. This includes:
- if the agent leg contains NetQTime or Delay before answering the call
- if TCD leg start-RingTime-timestamp starts earlier than 2 seconds than the BeganRoutingDateTime of RCD
- if not all RCDs are present for the same call due to the records limit when loading data
- if second RCD starts earlier than start-RingTime-timestamp of first answered call
- if NetworkTime for non voice tasks influences the RONA legs start time
- if classic RONA happens for non voice tasks before task is answered in conditions with the row level limit
Workaround: None
Further Problem Description: -
BREP-479 - PK violation in export_acd in one special case
Symptom: Primary Key violation in load procedure export_acd
Conditions: If there are two records in TCD with the same RCKD, RCK, StartTimeUTC and SequenceNumber and one of them was answered, it creates a conflict in the join with the first or last answered call. It will create a duplicate record that can't be filled into the table t_contact_summary because of a primary key violation.
Workaround: None
Further Problem Description: -
Issues fixed in Service Release 4.1.1
BREP-538 - Wrong transfer target after reloading data in contact history
Symptom: Transfer target is wrong within bs_contact_history for transferred calls
Conditions: After reloading export_acd data, the transfer number, calltype and agent is wrong within contact history data. This can happen if the same ICRCallKey is assigned twice within the limit for the data load (10'000 records and 7 days). There must be an additional condition to join the correct ICRCallKey.
Workaround: None
Further Problem Description: -
BREP-537 - Transfer target unknown in contact history
Symptom: Transfer number is NULL within bs_contact_history for transferred calls
Conditions: If the export_acd data load is executed after an answered customer call was written into TCD but the transferred call is still ongoing, there is no transfer target found for the contact history data. To prevent this situation, there must be a certain wait time until data gets extracted.
Workaround: Re-Loading data will solve this issue for old data.
Further Problem Description: -
BREP-536 - Contact summary data (ACD / MR) should always include RCD Variables, unless the task was answered
Requirements: Follow-up to BREP-523. There are some scenarios where the variables do not contain the latest values, for example if a forward is happening after a RONA. In this case we include the values of the variables that were present on the last TCD leg. If the call is forwarded afterwards and the values of the variables change, these changes are not reflected in the Contact Summary data.
Solution Abstract: Always include the variables from Route_Call_Detail in the contact summary for ACD and MR. Exception: when the task was answered / handled, include the Termination_Call_Detail variables.
Limitation: None
BREP-535 - Inbound history tables (ACD & MR) not being filled in certain scenarios
Symptom: The 2 tables t_acd_inbound_history and t_mr_inbound_history stay empty after executing the respective load procedure, even though data is available
Conditions: The 2 tables mentioned are empty, e.g. when performing a new installation, enabling the ACD or MR data load or when reloading all of the ACD and / or MR data
Workaround: None
Further Problem Description: Caused by a missing condition in the 2 load procedures export_acd and export_mr, resulting in no data being saved into the inbound history tables
BREP-534 - Transferred acd calls to agents missing into incoming direct bs_dn_calls
Symptom: Less incoming calls within bs_dn_calls (call by call) compared with DNInAnswered of agent interval data
Conditions: If an agent transfers an incoming acd call to a direct number of another agent, this call is missing within the incoming direct calls of the destination agent.
Workaround: None
Further Problem Description: -
BREP-525 - Certain fields in Enterprise CallType Reports may produce arithmetic overflow error
Symptom: When reporting on MediaRouting (MR) CallTypes, it might happen that the corresponding reports throw an error. This is caused by wait time fields, which can be quite large for MR CallTypes.
Conditions: Selecting a large number of MR CallTypes or Enterprise CallType(s) containing a lot of MR CallTypes, where the wait times are high.
Workaround: Reduce the number of CallTypes inside the EnterpriseCallTypes; or reduce the number of CallTypes in the filter; or select a shorter date & time frame.
Further Problem Description: Error thrown: Arithmetic overflow error converting expression to data type int.
BREP-524 - CallType Detail procedure stops loading data
Symptom: When reloading data, no data is loaded anymore, even if newer data is available
Conditions: After system restarts (when a lot of data is written at the same time) and reloading old CallType detail data
Workaround: None
Further Problem Description: We differentiate between two different scenarios: the "normal" one and the "reloading" one. In the normal scenario, we trim the data that is loaded into the data mart. It may happen that we trim that data as well in the reloading scenario, which causes the data load to stop.
BREP-523 - CallType Detail data should always include RCD Variables
Requirements: There are some scenarios where the variables do not contain the latest values, for example if a forward is happening after a RONA. In this case we include the values of the variables that were present on the RONA leg. If the call is forwarded afterwards and the values of the variables change, these changes are not reflected in the CallType Detail data.
Solution Abstract: Always include the Variables from Route_Call_Detail
Limitation: If the Variables from Termination_Call_Detail are required, they have to be joined from the calltype_handled_detail data