Страница 5 из 8

Re: Asternic Call Center Stats Lite - модификация.

СообщениеДобавлено: 30 ноя 2018, 19:45
bestann
Что заметила: у меня субрутина записи разговора вызывается при ответе оператора автоматом (указана в queues.conf). Аргументы я туда не передаю. Если там добавлять событие лога, то номер будет на 1 отличаться от остальных. Либо надо его заранее сохранять в передаваемой переменной, либо событие QueueLog делать не внутри этой субрутины. Через callerid действительно проще и базу меньше забиваешь. Думаю, может действительно нафиг это длинное имя файла, пусть будет callerid, надо будет - сохранить файл - при сохранении могут имя поменять если надо для читабельности.
Получается свою строку добавить. Конечно интересно было бы добавлять данные в имеющийся CONNECT, там все равно 2 последние столбца свободны.
Код: выделить все
27 | 2018-11-30 18:28:12.129522 | 1543591664.15 | 1601      | NONE                                              |       |
28 | 2018-11-30 18:28:18.030731 | 1543591692.16 | 1601      | Анна Тест     | 
29 | 2018-11-30 18:28:18.033950 | 1543591664.15 | 1601      | Анна Тест                                         |       |
30 | 2018-11-30 18:28:34.138340 | 1543591664.15 | 1601      | Анна Тест     


Т.е. то что написан zzz777z проще. Я делаю проверку, когда писать звонки, а когда нет, только при звонках на обычных абонентов. А при звонках на операторов всё пишем, при это membergosub=контекст в queues.conf дает возможность не генерировать кучу пустых файлов, т.к. отрабатывается при ответе оператора.
Тут только учесть момент, о котором писала выше. Либо заранее формировать имя файла (если не используется в дальнейшем для записи, ну и фиг с ним), либо UNIQUEID фиксировать, а то получится 1543591664.15 не равно 1543591692.16.

Re: Asternic Call Center Stats Lite - модификация.

СообщениеДобавлено: 30 ноя 2018, 21:38
bestann
Посмотрела варианты. Получается, что у каждой субрутины свой UNIQUEID?
1 вариант. Задавать имя файла в изначальном контексте (не субрутине записи), тогда UNIQUEID файла будет соответствовать тому что в базе queue_log.
2 вариант. При обработке входящих делаю общие шаги типа проверки черного списка, здесь же фиксирую same = n,Set(__UID=${UNIQUEID}) , после чего UID можно использовать в субрутине в имени файла или в других субрутинах, например при связке с CRM. Затем через Goto перехожу на контекст, где уже разные номер можно распределить по внутренним или IVR. При переходе через Goto UNIQUEID тот же.
3 вариант. Обрезать то что после точки в UNIQUEID.
Зато не надо добавлять дополнительную строку с именем файла (это все равно лишний шаг в плане нумерации, лучше уж UID задать), а зачем мне лишние строки в бд, их надо вносить, когда какие-то дополнительные события понадобится логировать.

Re: Asternic Call Center Stats Lite - модификация.

СообщениеДобавлено: 30 ноя 2018, 22:38
bestann
Еще такой вопрос. А зачем в базе поле data, если оно все время пустое. Ведь мы распределяем по data1-data5.
Код: выделить все
`data` char(64) DEFAULT NULL,

Re: Asternic Call Center Stats Lite - модификация.

СообщениеДобавлено: 01 дек 2018, 01:04
bestann
Записи проигрываются, хотя кнопки более громоздкие чем в CDR Viewer Mod. Тут получается, что все строки шире становятся, чтобы уместить меню проигрывания.
При экспорте в Excel вместо русского крякозябры. Таблица у меня в базе в кодировке utf8mb4. В вебе тоже отображается по-русски все хорошо. Локаль CentOS русская UTF8. Куда копать?

Re: Asternic Call Center Stats Lite - модификация.

СообщениеДобавлено: 05 дек 2018, 17:40
bestann
Экспорт в Excel исправила благодаря этому моду https://github.com/revall/queue-stats (файл export.php).
Там и вкладка Realtime есть, только данные не показывает, хотя вроде видно авторизацию в Asterisk пользователя AMI. Но в manager show connected он тоже не появляется.

Re: Asternic Call Center Stats Lite - модификация.

СообщениеДобавлено: 18 дек 2018, 14:25
zzz777z
Здравствуйте)

Прилетело небольшое обновление.

Убраны split() и теперь php7 не не будет ругаться.

Добавлен отчет Сравнение принятых пропущенных по очередям:

Изображение


И по многочисленным просьбам добавлен реалтайм, работает через AJAM, ну вы разберетесь:

Изображение


Актуальная версия на странице приложения:

https://asterisk-pbx.ru/wiki/soft/call_center/asternic-call-center-stats

Re: Asternic Call Center Stats Lite - модификация.

СообщениеДобавлено: 18 дек 2018, 22:54
zzz777z
bestann писал(а):Экспорт в Excel исправила .

Здравствуйте Анна. Мне очень нравятся Ваши посты :) . Возможно с кодировкой все гораздо проще. Надо при импорте csv указать excel , что кодировка utf8.

Re: Asternic Call Center Stats Lite - модификация.

СообщениеДобавлено: 31 дек 2018, 02:03
bestann
Спасибо за новую версию! В прошлый раз пришлось делать дегрейд php с 7 на 5.
C наступающим новым годом!
В php не шарю (очень бы хотелось), почитала Телеграм. Пишут, что стандарт для подключения к бд уже не mysqli, а PDO.
https://websitebeaver.com/php-pdo-vs-mysqli - сравнение
http://phpfaq.ru/pdo - полное руководство

zzz777z писал(а):
bestann писал(а):Возможно с кодировкой все гораздо проще. Надо при импорте csv указать excel , что кодировка utf8.

А тем экспортом вообще ничего не указывала, открывается сразу как надо в Excel. Буду тестировать.

Re: Asternic Call Center Stats Lite - модификация.

СообщениеДобавлено: 01 янв 2019, 12:53
zzz777z
bestann писал(а):Еще такой вопрос. А зачем в базе поле data, если оно все время пустое. Ведь мы распределяем по data1-data5.
Код: выделить все
`data` char(64) DEFAULT NULL,

Если в файле в /etc/asterisk/asterisk.conf задать:
Код: выделить все
[options]
queue_adaptive_realtime = yes

то все данные событий, вместо распределения по полям data1...data5,
будут помещены в data с pipe в качестве разделителя.

Если создать таблицу без данного поля, в логе asterisk будет генерироваться сообщение о ошибке, но на работоспособность не повлияет.

Re: Asternic Call Center Stats Lite - модификация.

СообщениеДобавлено: 01 янв 2019, 13:18
zzz777z
bestann писал(а):Пишут, что стандарт для подключения к бд уже не mysqli, а PDO.

Это очень хорошее замечание.
И да, использование PDO намного эффективнее, как минимум из-за возможности использовать другие СУБД, например PostgreSQL.
Но я не планирую развивать это приложение дальше в существующем виде.
Возможно будут еще какие-то версии с доп. функционалом, но каких-то ключевых изменений не будет.
Архитектура приложения, а проще говоря код написанный "лапшой", полностью устарела.
Есть MVP нового приложения, построенное на другой парадигме веб программирования.
Я потом напишу про него и хотелось бы задать несколько вопросов тем, кто использует статистику в своих интеграциях.