Сообщение о значении переменной пользователя UCCE

[Omar Deen]

Этот запрос может быть полезен в зависимости от размера вашего контакт-центра. Его можно запустить только в отношении логгера; базы данных aw и hds не содержат данных в таблице постоянных переменных. SELECT uv.ObjectType, pv.ValueInt, uv.VariableName, pv.ValueChar
FROM Persistent_Variable pv, User_Variable uv
WHERE pv.UserVariableID = uv.UserVariableID
ORDER BY uv.VariableName DESC Другой вариант — использовать rttest. Вы можете войти в Call Router и запустить его через командную строку, например. C:>rttest /system
/cust rttest: expr
.
. rttest doc: http://www.cisco.com/en/US/products/sw/custcosw/ps1001/products_tech_note09186a00800ac69b.shtml

[jpsweeney77]

Кроме того, я помню, что в системах 8.x была проблема, при которой необходимый флаг в Logger отключался при установке/обновлении. Этот флаг реестра в Logger находится по адресу... ICM
//LoggerA/Logger/CurrentVersion/HistoricalData/Persistent/Variable

[piyush aghera]

Пожалуйста, сообщите, следует ли установить значение 1 для вышеуказанного ключа реестра на обоих регистраторах.
У меня возникла проблема: некоторые пользовательские переменные, которые отображаются в регистраторе стороны B, отсутствуют в регистраторе стороны A. Как синхронизировать обе стороны?
Наша организация недавно обновила систему UCCE с версии 8.0 до 10.0.

[Omar Deen]

Да, у Logger A и Logger B значение ключа Variable должно быть установлено на 1.

[piyush aghera]

Спасибо, Омар. Надеюсь, что вышеуказанные изменения не повлияют на работу каких-либо действующих сервисов. Нужно ли перезапускать/перезагружать какие-либо сервисы на логгерах? Спасибо.

[Eric Krieger]

Привет, Пиюш, У меня были те же вопросы, но теперь я только что узнал, что эти изменения реестра (как для дистрибьютора, так и для логгеров) будут активированы немедленно (по крайней мере, для нашей платформы 9.0), без необходимости перезапуска. С этого момента каждый узел SET, настроенный и выполняемый скриптом, содержащим эти узлы SET, будет сохранять эти значения в таблицах БД (без автоматического сброса из памяти маршрутизатора в эти таблицы).

[bruce.finney]

jpsweeney77, молодец! Я знаю, что прошло уже полтора года, но я только сейчас дошел до твоего поста. Работает отлично и на 8, без необходимости перезапуска. Теперь у меня есть отчет CUIC, который показывает моей группе поддержки активный номер дежурного после рабочего времени в виде панели инструментов. Увы, они, вероятно, никогда не будут его использовать, но для меня это открывает огромные возможности. Спасибо.

[dndillon]

Это старый пост, но я хотел бы обсудить с вами эту тему. У меня открыта отчетность Persistent_Variable, и я настроил несколько панелей мониторинга CUIC для отчетности по определенным переменным типа вызовов и т. д. Я заметил, что таблица Persistent_Variable обновляется нерегулярно. То есть тег переменной меняется, функция маршрутизации из памяти маршрутизаторов работает нормально, все работает как надо, но таблица не обновляет правильное значение ValueChar. Иногда это занимает несколько часов, иногда несколько минут. Ничто не совпадает, как если бы это были интервальные данные. Когда это происходит, я запускаю проверку переменной по отношению к маршрутизатору, и она работает как часы. Просто отчетность работает очень медленно (до уровня регистратора). Кто-нибудь еще сталкивался с этим?

[david.macias]

Прошло много времени, но я помню, что видел это раньше. Мне даже кажется, что в старом SRND упоминалось, что использование постоянных переменных отчетов создает дополнительную нагрузку на базу данных, и я всегда предполагал, что это означает, что они будут второстепенными и не будут обновляться с той же частотой, что и другие таблицы, но в конечном итоге они всегда обновлялись. Я бы открыл заявку в службу поддержки и спросил, есть ли какой-нибудь волшебный регистрационный ключ, который мог бы ускорить этот процесс. Дэвид Блог
|
Работа

[dndillon]

Спасибо, Дэвид! Ждал этого уже некоторое время. Если что-нибудь появится, я обновлю информацию здесь.

[bill.king1]

Помимо случая с TAC, вы пробовали проверить, происходит ли это на обоих логгерах или только на одном? Например, если вы сравниваете сторону A со стороной B, то оба ли они всегда задерживаются и задерживаются на одинаковое количество времени?

[dndillon]

Да, сэр, то же самое с обеих сторон. Tac наконец-то связался со мной и сказал, что это связано с
CSCwn98505
. Я видел это в наших журналах RPL, так что все подтверждается. Я посмотрю, есть ли возможность получить исправление с обратной кодировкой для ES до версии 15. Посмотрим!