Contact Centers, CRM Customer Engagement

First-Try to run that report with a more limited subset of data. (Fewer CDNs, shorter duration, etc.)

CCMA blocks reports that exceed 50k records returned to prevent system performance impact. (This is not true of the ODBC interface, but the system can be impacted by demanding ODBC queries. I've had to do the troubleshooting for that before and the symptoms involve loss of historical data. Not fun.) I had forgotten this, but was looking up a related point in the documentation when I came across this.

Also, apparently IIS settings (as defined by Avaya) can also result in the request timing out. (That doesn't look like what you have, but if you had a complex report that pulled < 50k records but took a long time, IIS would also choke. Just FYI.)

The point I was looking up was how many specific CDNs you can filter for before the reporting interface chokes. I couldn't find it-but if you have problems with any CDN filters, I recommend removing all filters-it will include all CDNs in the report (which may increase the total number of records returned and thus trigger paragraph one, above.) Which also leads to the suggestion to run the report for a period of less than 365 days.

Second- you can check your historical statistics settings. I don't think this is relevant to your problem, but I recommend you do this anyway.

CCMA Launchpad > Configuration > CCMA (server by name) > Historical Statistics

Within Historical Statistics settings, if you scroll to the bottom of the page, you'll find a "Duration" section. Within duration, you should be able to identify the number of days you can report back to. My recollection is that won't generate this error, but it will tell you for certain how far back you can report. 365 days is a lot. Interval data is very detailed. If your Duration is < 365 days, the data ages out of the system and you can't report back that far anyway.

While you're there, check the top of the settings page-make sure your "Parameters" for CDN "Configured Value" exceeds the "Measured Value." There was a problem in mid-AACC 6.x where there was no validation on creating CDNs, and the platform allowed you to create more CDN's than you'd allocated historical reporting space for. I've seen this error recently, and I'm positive it won't generate your problem-but as I've seen it recently, I figured it's worth mentioning just in case. If Measured Value exceeds Configured Value, then when the system needs data, it will age out data that exceeds configured value. (There is a logic to how it determines which records to age out, but I haven't deduced it or seen documentation for it.)

Beyond that the troubleshooting gets more technical (what version and service pack are you on, what special patches have you installed, can you check that all services are running, restart your system, collect trace logs, etc.)

But I believe that the most likely problem is the 365 days of interval data though, or a combination of interval data + CDN filters used. (One CDN of interval data, for an entire year, 24 hours a day is 35k records. 6P-7A is 11H, at 4 records per hour that's 16k records per year. It would only take the inclusion of 4 CDNs in your report filters to generate sufficient records to cause the report to fail due to CCMA limits.)

As far as your objective-at the CDN level of reporting, you could bring in the after-hours calls on a different CDN (or set of CDNs) to allow you to do daily-weekly-monthly reporting summaries-or deliver the callers to an application that queues callers to one Skillset during the day and a different Skillset at night (with scripting to overflow callers from one to the other during shift change.) Then you could run the reports at the Skillset level (which would omit any callers that disconnected or terminated prior to being queued.)

However, beyond these non-best-practice methods to achieve your reporting objective, you are correct-you're limited to running interval level reports to obtain summary data per-day for the hours in question.

Thank you

Christopher Williams
Architect, Telephony Engineering