NRX dans les version 6.X  a un bug qui fait qu'on voit un répertoire d'archivage nommé %CONTEXT0%.  Si des règles d'archives ont utilisé ce %CONTEXT0%, les appels ne seront pas archivés ni éventuellement supprimés car ils ne seront pas traités par le système.

Nice a une procédure écrite sur comment pallier à cette situation et elle est rattachée à cet article.

Action Plan à For %CONTEXT0% issue correction

1. Execute the below steps:

• Make a database backup (Binary as well as .sql file)
• Take all alarm screen shot which is known

2. Disable failover mechanisms if applicable
3. Stop all NTR services

 

4:  Run:

UPDATE location SET LocationSet_Id = 2 WHERE LocationSet_Id = 3;

UPDATE contentrule SET LocationSet_Id =2 WHERE LocationSet_Id = 3;

 

5: Run:    

A. SELECT * FROM interactionoperation WHERE LocationSet_Id = 3;

               B. SELECT count(*) FROM interactionoperation WHERE LocationSet_Id = 3; à mark the count.

 

         6: Run:

UPDATE interactionoperation SET LocationSet_Id = 2 WHERE LocationSet_Id = 3 AND interactionoperationtype IN (0,3);

Note: Count of the rows affected from this query should match the earlier count from step 5 sub step B

 

         7. Run:

 

SELECT * FROM interactionoperation WHERE LocationSet_Id = 3;

 

Note: This will verify no records are left on Locationset_id 3.

 

8:  From locationset table we will delete the Locationset where id = 3 using below query.

 (We are deleting the %CONTEXT0% location)

Run: DELETE locationset FROM locationset WHERE `Id` = '3';

 

9: After this database has been corrected:

1. Start all NTR services
2. Keep track of the Archiving logfiles to make sure archiving start for calls
3. Verify that the content rules show the correct values and that the context0 locations are gone
4. Clear all alarms and monitor for new alarms raised
5. Verify call playback
6. After no alarms appear after a few minutes.
7. Enable failover mechanisms which were previously disabled.