Сообщение о значении переменной пользователя UCCE
-
Все, где в SQL я могу найти текущее значение пользовательской переменной ICM? Я использую их для многих целей, в том числе для указания часов работы в административных скриптах и при появлении специальных сообщений службы поддержки. Я прочитал документ со схемой базы данных, в котором сказано, что нужно смотреть в таблице t_Persistent_Variable, но она пуста. Заранее благодарю за помощь. UCCE версия 8.5
-
Вы можете включить репликацию этой таблицы постоянных переменных в HDS, изменив соответствующий флаг в реестре дистрибьютора. ICM
//Distributor/RealTimeDistributor/Logger/HistoricalData/Persistent/Variable -
-
Этот запрос может быть полезен в зависимости от размера вашего контакт-центра. Его можно запустить только в отношении логгера; базы данных 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 -
Кроме того, я помню, что в системах 8.x была проблема, при которой необходимый флаг в Logger отключался при установке/обновлении. Этот флаг реестра в Logger находится по адресу... ICM
//LoggerA/Logger/CurrentVersion/HistoricalData/Persistent/Variable -
Пожалуйста, сообщите, следует ли установить значение 1 для вышеуказанного ключа реестра на обоих регистраторах.
У меня возникла проблема: некоторые пользовательские переменные, которые отображаются в регистраторе стороны B, отсутствуют в регистраторе стороны A. Как синхронизировать обе стороны?
Наша организация недавно обновила систему UCCE с версии 8.0 до 10.0. -
Да, у Logger A и Logger B значение ключа Variable должно быть установлено на 1.
-
Спасибо, Омар. Надеюсь, что вышеуказанные изменения не повлияют на работу каких-либо действующих сервисов. Нужно ли перезапускать/перезагружать какие-либо сервисы на логгерах? Спасибо.
-
Привет, Пиюш, У меня были те же вопросы, но теперь я только что узнал, что эти изменения реестра (как для дистрибьютора, так и для логгеров) будут активированы немедленно (по крайней мере, для нашей платформы 9.0), без необходимости перезапуска. С этого момента каждый узел SET, настроенный и выполняемый скриптом, содержащим эти узлы SET, будет сохранять эти значения в таблицах БД (без автоматического сброса из памяти маршрутизатора в эти таблицы).
-
jpsweeney77, молодец! Я знаю, что прошло уже полтора года, но я только сейчас дошел до твоего поста. Работает отлично и на 8, без необходимости перезапуска. Теперь у меня есть отчет CUIC, который показывает моей группе поддержки активный номер дежурного после рабочего времени в виде панели инструментов. Увы, они, вероятно, никогда не будут его использовать, но для меня это открывает огромные возможности. Спасибо.
-
Это старый пост, но я хотел бы обсудить с вами эту тему. У меня открыта отчетность Persistent_Variable, и я настроил несколько панелей мониторинга CUIC для отчетности по определенным переменным типа вызовов и т. д. Я заметил, что таблица Persistent_Variable обновляется нерегулярно. То есть тег переменной меняется, функция маршрутизации из памяти маршрутизаторов работает нормально, все работает как надо, но таблица не обновляет правильное значение ValueChar. Иногда это занимает несколько часов, иногда несколько минут. Ничто не совпадает, как если бы это были интервальные данные. Когда это происходит, я запускаю проверку переменной по отношению к маршрутизатору, и она работает как часы. Просто отчетность работает очень медленно (до уровня регистратора). Кто-нибудь еще сталкивался с этим?
-
Прошло много времени, но я помню, что видел это раньше. Мне даже кажется, что в старом SRND упоминалось, что использование постоянных переменных отчетов создает дополнительную нагрузку на базу данных, и я всегда предполагал, что это означает, что они будут второстепенными и не будут обновляться с той же частотой, что и другие таблицы, но в конечном итоге они всегда обновлялись. Я бы открыл заявку в службу поддержки и спросил, есть ли какой-нибудь волшебный регистрационный ключ, который мог бы ускорить этот процесс. Дэвид Блог
|
Работа -
Спасибо, Дэвид! Ждал этого уже некоторое время. Если что-нибудь появится, я обновлю информацию здесь.
-
Помимо случая с TAC, вы пробовали проверить, происходит ли это на обоих логгерах или только на одном? Например, если вы сравниваете сторону A со стороной B, то оба ли они всегда задерживаются и задерживаются на одинаковое количество времени?
-
Да, сэр, то же самое с обеих сторон. Tac наконец-то связался со мной и сказал, что это связано с
CSCwn98505
. Я видел это в наших журналах RPL, так что все подтверждается. Я посмотрю, есть ли возможность получить исправление с обратной кодировкой для ES до версии 15. Посмотрим!
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти