Re: EIM 4.3.2 - Reinitialize AW Error

BarryMclellan72678_2 · ‎11-29-2010

Thought I would post this here as something to watch out for.

We had an issue today where one of our tech's had to reinitialize the AW. I was unfortunate enough to be logged into EIM, looking at the configured queues when this happened.

EIM does not give you an option, but upon refresh, it gives you an error dialog and then deletes all of the integrated queues on you, and you need to re-enter these after the initialization is complete. Fortunately it only erased the department I was in, and not the other departments.

Thanks

Barry

geoff · ‎11-29-2010

I know all about it.

This can be a massive problem. It deleted 68 integrated agents out of 500 at one customer - and it was a total pain to get them back in there, because the delete was not clean.

The way this system works is EIM resyncs when the PA opens the admin interface, or changes departments on the admin interface, or looks at users or quues etc. I don't know what actual parts of the Admin interface cause it to try to resync with the AW, but it's a total dog and is written extremely poorly.

The most important thing to do when you are running Initialize Local DB is to stop IIS on the CIM Web Servers so no one can log in.

Regards,

Geoff

BarryMclellan72678_2 · ‎11-29-2010

I have a ticket opened with Cisco... so maybe it may save somebody down the line!

In my case I was one day away from our major cutover from Email Manager before all was lost!

As you can see from the sheer amount of posts I have put here about EIM issues, this may have been that one last straw! Tomorrow I get to meet with all kinds of people to discuss why we went with EIM in the first place!

I'm hoping that providing my workflows are not corrupt do to this issue, I can get things restored, tested and installed before the holiday company freeze!

Have a great day!

Barry

lohjintiam · ‎11-30-2010

perseverance will pay off!

-JT-

kimv · ‎11-30-2010

Just to post here with the Defect information.. so it's out there..

Defect ID : CSCsz53964
Defect Title : Integrated queue configuration lost after AWDB connect failure
Defect Description: ES3 for CIM 4.2(5) introduced a new feature for the UCCE integration for 'secondary AWDB retry' following a connection failure to the primary AWDB. In the case of a primary AWDB connection failure, CIM will attempt to connect to the secondary AWDB.

However, it has been observed that when a connection failure to the primary AWDB occurs if no secondary AWDB exists, or the secondary was defined as the same server as the primary, or the connection to the secondary was not available then an exception failure is returned. This is turn causes a "blank value" to be returned by the data adapter query instead of a "network error".

CIM interprets the blank value as "zero rows". This implies to CIM that the ICM object doesn't exist. CIM then proceeds with deleting the integrated objects and mappings associated with whatever the data adapter query was trying to fetch.

Release-note:

Symptom: It has been observed that when a connection failure to the primary AWDB occurs if no secondary AWDB exists, or the secondary was defined as the same server as the primary, or the connection to the secondary was not available then an exception failure is returned. This is turn causes a "blank value" to be returned by the data adapter query instead of a "network error".

CIM interprets the blank value as "zero rows". This implies to CIM that the ICM object doesn't exist. CIM then proceeds with deleting the integrated objects and mappings associated with whatever the data adapter query was trying to fetch.

Conditions: Issue recently observed within 4.3(2) integrated with UCCE 7.2(7) and possibly releases above

Workaround: Either restore the complete eGActiveDB from a prior backup to restore the lost configuration data, or recreate the lost objects and mappings from the CIM UI.

Further Problem Description: ES3 for CIM 4.2(5) introduced a new feature for the UCCE integration for 'secondary AWDB retry' following a connection failure to the primary AWDB. In the case of a primary AWDB connection failure, CIM will attempt to connect to the secondary AWDB.

geoff · ‎12-01-2010

I certainly remember that bug report and the ES3 for 4.2(5) that should have fixed it. We applied it, of course. And this fix would have been in 4.3(1), most likley. I haven't checked the bug report for a while, but now see that there has been an addition:

Defect ID : CSCsz53964
[......]
Conditions: Issue recently observed within 4.3(2) integrated with UCCE 7.2(7) and possibly releases above

The first suggestion in the workaround is not viable

Workaround: Either restore the complete eGActiveDB from a prior backup to restore the lost configuration data, or recreate the lost objects and mappings from the CIM UI.

Restoring eGActiveDB from a backup would totally mess you around - you would lose everything that came in since that backup was made.

It would be nice if eGain separated configuration and historical/active information into two different databases, then this could work. As it is, it would be foolish and only recreation is workable.

Regards,

Geoff

egain_karthik · ‎12-02-2010

I think this defect is more indicative of what is happening.

http://www.cisco.com/en/US/ts/fn/633/fn63371.html

From awlog we are seeing that objects are deleted and recreated on AW and during this time if user is on CIM Admin console, queue,user addition or modification this initiates a check to the awdb and if objects are missing then syncs accordingly.

In Awlogs we see objects deleted,

11:59:23 dis-uaw Trace: Local database must be initialized before proceeding.
11:59:23 dis-uaw Trace: Deleting from table t_ICR_Instance
11:59:23 dis-uaw Trace: Deleting from table t_ICR_Node
11:59:23 dis-uaw Trace: Deleting from table t_Customer_Definition
11:59:23 dis-uaw Trace: Deleting from table t_Customer_Options
11:59:23 dis-uaw Trace: Deleting from table t_Logical_Interface_Controller
11:59:23 dis-uaw Trace: Deleting from table t_Physical_Interface_Controlle
11:59:23 dis-uaw Trace: Deleting from table t_Agent_Desk_Settings
11:59:23 dis-uaw Trace: Deleting from table t_Peripheral
11:59:23 dis-uaw Trace: Deleting from table Cfg_Mngr_User_Desktop_Snap
11:59:23 dis-uaw Trace: Deleting from table Cfg_Mngr_App_Snapshot_State
11:59:23 dis-uaw Trace: Deleting from table Cfg_Mngr_User_Menu
11:59:23 dis-uaw Trace: Deleting from table Cfg_Mngr_View
......
11:59:23 dis-uaw Trace: Copying table t_ICR_Instance
11:59:23 dis-uaw Trace: Copying table t_ICR_Node
11:59:23 dis-uaw Trace: Copying table t_Customer_Definition
11:59:23 dis-uaw Trace: Copying table t_Customer_Options
11:59:23 dis-uaw Trace: Copying table t_Logical_Interface_Controller
11:59:23 dis-uaw Trace: Copying table t_Physical_Interface_Controlle
11:59:23 dis-uaw Trace: Copying table t_Agent_Desk_Settings
11:59:23 dis-uaw Trace: Copying table t_Peripheral
11:59:23 dis-uaw Trace: Copying table Cfg_Mngr_User_Desktop_Snap
11:59:23 dis-uaw Trace: Copying table Cfg_Mngr_App_Snapshot_State
11:59:23 dis-uaw Trace: Copying table Cfg_Mngr_User_Menu
11:59:23 dis-uaw Trace: Copying table Cfg_Mngr_View
11:59:23 dis-uaw Trace: Copying table Cfg_Mngr_Globals
11:59:23 dis-uaw Trace: Copying table Cfg_Mngr_User_Settings
11:59:23 dis-uaw Trace: Copying table Skill_Target