Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

CMS Agent Trace

Status
Not open for further replies.

offdahook

Technical User
Oct 22, 2008
81
0
0
US
hi all,

Due to a high volume of agents and agent activity my agent trace reports are getting overwritten approx every 3-3.5 weeks. I have a need to go back alot further than this time period and was wondering if anyone had encountered this problem and came up with a solution?...
 
check your data storage allocation. 'number of agent trace records'
 
I have this set to max, it's not so much a data storage issue, it's the volume of activity
 
The agent trace table is a circular table. New data overwrites the oldest data. Regardless of size chosen, eventually the data will be overwritten and lost.

You need to extract the data and store it in a more permanent location. You can't put it back so any reporting will have to be developed using something other than Supervisor. You will find that the data returned from the Supervisor based extract will be limited in size. When I used to do this, based on my number of agents and frequency of state changes, I could only extract 3 days max at a time.

Depending on the version of CMS used you can make use of OpenLink and ODBC.
This is valid up to V14 as that is what I have. I think that V15 required JDBC or somesuch.

I extract every 5 minutes via ODBC and store in a .txt file. Every hour a new .txt file is created. Weekly the hourly files are combined into daily files.
 
There is an additional package called ECH, this increases the capacity by offloading the data somewhere else.
In the company I used to work for, we ran SQL queries on the SUN box, running on a CRON timer.
This data would be outputted to CSV files,and put in a dir on the SUN box.
Then a second box would pick up the data via FTP (automated) and move it to a MySQL database, on a server with a web frontend.
Advantage to this was that we could also combine the data with other "sales" data.

The versions, their capacities, and options can be found here:
 
Thanks for the replies guys.....I will review and let you know how I get on, 1 thing I do see though is that my version of CMS is 16.3 so it's safe to say that some of these solutions are not available to me?
 

ODBC still works for 16.x systems. You just need the licenses to connect to CMS via ODBC.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top