Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Programmatic changes to ICM tables

We are using IPCC 6.0(0)sr3 with CTIOS desktop. We have approximately 500 agents and ~40 skills.

We are attempting to write a web application to allow supervisors to re-skill agents without having to remote-control into an AW (too complicated and cumbersome by their report). We can certainly make table changes on the AW, and even on the loggers (in the lab, of course). However, the changes don't appear to be reflected in ICM and CTI. They do show up in Configuration Manager though.

What are we missing? Is there some additional procedure we have to perform to get the change committed, or some security procedure to allow the change to take?

Any assistance is appreciated. Pulling this off will be a great big win for my team.

Dave Wolgast

HealthNow New York Inc

1 ACCEPTED SOLUTION

Accepted Solutions
Green

Re: Programmatic changes to ICM tables

See if I can explain what happens when you make a change with Configure ICM on an Admin Workstation and you will see why your idea won't work.

As you probably know, you cannot run Configure ICM on an distributor AW if it does not have the real-time feed. You have probably seen this when the ICM services (RTDist, RTClient, UpdateAW, Logger) had not been started and you fired up the Config GUI and it hung for a minute before reporting that it could not get the real time feed.

On a client Admin Workstation it's running through the Distributor AW, and a proxy situation applies. Still, a real time feed is required.

Assuming you have the Config tool running, and you change an agent's skill group.

1. The Config tool sends the request to the DBAgent process running on the Router.

2. DBAgent confirms the user's credentials against the Domain Controller.

3. DBAgent sends the request to the Router process (rtr).

4. The rtr process informs the lgr process running on the Logger over the MDS channel.

5. The lgr updates the Central Controller Microsoft SQL database.

6. Once the change has been committed to the DB, the lgr informs the rtr that the update was successful, and now the rtr updates its in-memory config. This is done after the commit was successful - should the SQL commit have failed, the rtr config does not change.

7. The rtr process informs the DBAgent process.

8. The DBAgent updates the Config ICM gui over the real-time feed and it shows that the skill group has changed.

9. At the same time, the rtr process tells the RTServer process running on the Router to tell the Distributor AWs (you probably have two) that there has been a change to the configuration.

10. The RTDist process running on the Dist AW hears about the change and tells all RTClients that the config has changed.

11. RTDist also tells the UpdateAW process running on the Dist AW that the config has changed.

12. UpdateAW queries the Central Controller database to get the config change, and tells the lgr process running on the Dist AW.

13. The lgr process writes the data to the AW DB.

If someone opens the Config ICM tool anew they read the information from the AW database, but it was updated with the change as the last item in a complex chain.

The upshot of all this is - don't do it!!

What you want to do is upgrade to ICM 7.0 and you will get two items that will make you happy:

* a Web interface to changing skill assignments.

* the enhancement that agents don't have to log out and log back in to get calls for the new skill they were just given - it's dynamic (as it should be).

There you go - a big win for your team at the cost of an ICM upgrade. ;-)

6 REPLIES
New Member

Re: Programmatic changes to ICM tables

have you tried to resatrt all the services and see if that is updating

Let me know how you are doing this and would be interesting to implement in our site

New Member

Re: Programmatic changes to ICM tables

Directly making change in ICM table is not desirable, as far as I know, ICM won't load this change automatically, and won't even track this change, and sync to another side.

'exit_router' on call router could force ICM re-load configurations from logger database.

Wei

Green

Re: Programmatic changes to ICM tables

See if I can explain what happens when you make a change with Configure ICM on an Admin Workstation and you will see why your idea won't work.

As you probably know, you cannot run Configure ICM on an distributor AW if it does not have the real-time feed. You have probably seen this when the ICM services (RTDist, RTClient, UpdateAW, Logger) had not been started and you fired up the Config GUI and it hung for a minute before reporting that it could not get the real time feed.

On a client Admin Workstation it's running through the Distributor AW, and a proxy situation applies. Still, a real time feed is required.

Assuming you have the Config tool running, and you change an agent's skill group.

1. The Config tool sends the request to the DBAgent process running on the Router.

2. DBAgent confirms the user's credentials against the Domain Controller.

3. DBAgent sends the request to the Router process (rtr).

4. The rtr process informs the lgr process running on the Logger over the MDS channel.

5. The lgr updates the Central Controller Microsoft SQL database.

6. Once the change has been committed to the DB, the lgr informs the rtr that the update was successful, and now the rtr updates its in-memory config. This is done after the commit was successful - should the SQL commit have failed, the rtr config does not change.

7. The rtr process informs the DBAgent process.

8. The DBAgent updates the Config ICM gui over the real-time feed and it shows that the skill group has changed.

9. At the same time, the rtr process tells the RTServer process running on the Router to tell the Distributor AWs (you probably have two) that there has been a change to the configuration.

10. The RTDist process running on the Dist AW hears about the change and tells all RTClients that the config has changed.

11. RTDist also tells the UpdateAW process running on the Dist AW that the config has changed.

12. UpdateAW queries the Central Controller database to get the config change, and tells the lgr process running on the Dist AW.

13. The lgr process writes the data to the AW DB.

If someone opens the Config ICM tool anew they read the information from the AW database, but it was updated with the change as the last item in a complex chain.

The upshot of all this is - don't do it!!

What you want to do is upgrade to ICM 7.0 and you will get two items that will make you happy:

* a Web interface to changing skill assignments.

* the enhancement that agents don't have to log out and log back in to get calls for the new skill they were just given - it's dynamic (as it should be).

There you go - a big win for your team at the cost of an ICM upgrade. ;-)

New Member

Re: Programmatic changes to ICM tables

Updating the ICM configuration tables is only supported using the Cisco provided AW Toolset. Making changes directly to the ICM configuration tables may impact call routing and the Logger/Router processes.

The feature you are interested in (Dynamic reskilling) is available with ICM 7.0.

New Member

Re: Programmatic changes to ICM tables

Hi,

there someone have a solution for doing Reskilling with customized application in Java and CTI OS toolkit?

does it exist an API for doing reskilling function? how can i perform that?

Regards

Silver

Re: Programmatic changes to ICM tables

Hi,

we use a third party Product(Darondo Tool), works great and is as far as i know really cheap.

http://www.bucher-suter.com/products/darondoR-admintool.html?L=0

HTH

570
Views
5
Helpful
6
Replies