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 12.5 with COP5 or newer, and 12.6
- Cisco Unified Contact Center Enterprise (UCCE) version 12.0, 12.5 and 12.6
- Cisco Packaged Contact Center Enterprise (PCCE) version 12.0, 12.5 and 12.6
3rd Party Software
- 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.
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: -
Issues fixed in Service Release 5.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
BREP-522 - Join of ECC variables not working efficient into contact data exports (acd & mr)
Symptom: CallByCall Job takes very long time since the mapping of ECC variables was configured
Conditions: As soon as ECC variables are configured to be included within call by call data, the export_mr procedure takes more than 10 hours to complete.
Workaround: None
Further Problem Description: -
BREP-521 - Improve Skill_Group_Interval load time over slow network
Requirements: The load procedure export_sgi should finish up faster
Solution Abstract: This load procedure only copies rows, where some useful data is present. This additional check within the where clause can take a long time, if there is no fast network connection in place. The load procedure should be re-designed to copy all data and to do this check locally.
Limitation: -
Issues fixed in Service Release 5.1.2
BREP-550 - calltype_detail data: HandleTime instead of TCDRecoveryKey for answered calls in case of data update
Symptom: Small values for TCDRecoveryKey is filled for some of the answered records in table t_calltype_detail
Conditions: If the completed result was unknown during the data load, those records get updated later on. In this case of the data update, the HandleTime is filled within the field TCDRecoveryKey instead of the real RecoveryKey.
Workaround: None
Further Problem Description: The issue needs to be fixed by an update of the procedure and a data re-load of procedure export_ctd
BREP-549 - Service Level gauge in (Enterprise) CallType RealTime reports showing error message at the start of the day
Requirements: At the start of the day, when no calls were routed yet, the "Service Level Today - Gauge" view within (Enterprise) CallType reports will display an error message. This is due to the fact that the footer formula of the field "Service Level Today" returns an undefined value (NaN; not a number) as a division by zero is calculated.
Solution Abstract: Introduce a new "case" statement for the fields used in the Service Level calculation: "SLOfferedToday" and "SLAnsBeforeToday". As this will be changed in the Reporting Interface, it will fix this issue for the following reports in the Basic reports: 110, 111, 210, 211.
Limitation: None
BREP-547 - Add RouterQueueTime to ctd for separating routed and non-routed abandoned tasks
Requirements: The RouterQueueTime field should be included into table t_calltype_detail and the corresponding load procedure export_ctd to determine if abandoned tasks have been routed or not.
Solution Abstract: To be able to separate routed and non-routed tasks in case of an abandoned tasks, the RouterQueueTime is required to see, if a task was queued or not. This information is only relevant for BI data exports and used within the CCBI Customer Journey.
Limitation: -
BREP-546 - Improve performance of ECE reports
Requirements: On larger systems, the ECE report 840, 843 and 844 may run for a very long time. This is due to the fact that sub queries within the report definition query do not have a where clause and thus joins all the data available in the system (on the affected customer system: several billion records).
Solution Abstract: Change the type of the report definition from a SQL Query to an Anonymous Block in order to limit the results in the sub queries.
Limitation: None
BREP-543 - Improve performance of export_EHCM
Requirements: The load procedure export_EHCM should complete faster
Solution Abstract: Optimize the procedures by using only indexed fields (EVENT_ID) when loading data. Use non-indexed fields like CREATE_DATE only when necessary.
Limitation: None
BREP-541 - Add bs_enterprise_calltype_interval to Detach scripts
Requirements: The view bs_enterprise_calltype_interval is not part of the Detach scripts, thus importing the Basic reports might end up in a time-out on larger systems.
Solution Abstract: Include the view bs_enterprise_calltype_interval in the detach script for normal installations (Detach_Historical_Data) and for viewer database installations (Detach_ViewerDatabase).
Limitation: None
BREP-540 - Improve load time of CallType Transfer and Agent Interval Callbacks over slow network
Requirements: The load procedures export_ct_transfers and export_ai_callbacks should complete faster
Solution Abstract: Optimize the procedures by avoiding local and remote queries in the same statement, i.e. by saving certain information in a variable first.
Limitation: -
Issues fixed in Service Release 5.1.3
BREP-560 - Refine case statements in bs(_enterprise)_calltype_realtime
Symptom: Follow-up to BREP-549; this change caused some confusion as it is manipulating the number of field SLOfferedToday to 1, when no calls have entered the CallType yet. This results in wrong values for the Service Level calculation.
Conditions: Using any of the grid views in the (Enterprise) CallType RealTime Reports 110, 111, 210 and 211
Workaround: -
Further Problem Description: The "case" statement for the field SLOfferedToday will be changed in the same way as for the field SLAnsBeforeToday
BREP-559 - Service Level flag numbers in bs_contact_summary are not calculated correctly
Symptom: Under certain conditions, the calculation of the following fields is wrong: SLCompBefore, SLAnsBefore, SLForwardBefore and SLAbanBefore.
Conditions: The default Service Level threshold in the system settings is set to 30, but the threshold for certain CallTypes is set to a lower number (e.g. 20)
Workaround: -
Further Problem Description: The issue is caused by the current order of "case / when" statements, which will calculated the fields mentioned above incorrectly. To calculate this correctly, there has to be a "case / when" statement which checks whether the default Service Level threshold is used or a custom threshold.
BREP-556 - WaitTime and EndDateTime are wrongly calculated in some cases in export_ctd
Symptom: In some rare cases (see conditions) the EndDateTime and consequently the WaitTime are wrongly calculated.
Conditions: Several scenarios can cause this issue, for example if the call is abandoned in the local queue (CallDisposition 2; TargetType 14) after a RONA.
Workaround: -
Further Problem Description: Refine conditions for TCDRecoveryKey in the corresponding stored procedure when the data is inserted in the temporary table "#rcd_result", as not all scenarios are considered there.