Разработка отчета сторонними средствами
Модератор: ykolesnikov
Разработка отчета сторонними средствами
Добрый день!
Столкнулся со следующей проблемой - нужно сформировать отчет, в котором бы отражалось количество заявок с нарушениями SLA (время первого ответа, время решения) в разрезе временных периодов. К примеру, в колонках - месяцы, в строках - очереди, на пересечении - количество нарушений SLA. Почитав форум, понял, что стандартные отчеты, реализованные в OTRS, решить данную задачу не помогут, так как в таблице с данными по тикетам не сохраняется информация об эскалациях для закрытых заявок. Как вариант - разработать отчет сторонними средствами, и проводить в нем анализ таблицы "ticket_history". Если в истории есть события "EscalationResponseTimeStart" или "EscalationSolutionTimeStart", считать, что в данной заявке нарушения SLA имели место быть. Хотя, тоже не все однозначно. Ведь у заявки могли по ходу работы изменить SLA и в результате может оказаться, что SLA нарушен не был...
Вопрос также возникает с руссификацией отчета, если например, потребуется выводить текущее состояние заявок (открыто, закрыто и т.п.) или что-нибудь подобное. Создавать таблицы с руссификацией?
Кто как решает подобные задачи? Буду очень признателен, если поделитесь своим опытом. Заранее спасибо!
Столкнулся со следующей проблемой - нужно сформировать отчет, в котором бы отражалось количество заявок с нарушениями SLA (время первого ответа, время решения) в разрезе временных периодов. К примеру, в колонках - месяцы, в строках - очереди, на пересечении - количество нарушений SLA. Почитав форум, понял, что стандартные отчеты, реализованные в OTRS, решить данную задачу не помогут, так как в таблице с данными по тикетам не сохраняется информация об эскалациях для закрытых заявок. Как вариант - разработать отчет сторонними средствами, и проводить в нем анализ таблицы "ticket_history". Если в истории есть события "EscalationResponseTimeStart" или "EscalationSolutionTimeStart", считать, что в данной заявке нарушения SLA имели место быть. Хотя, тоже не все однозначно. Ведь у заявки могли по ходу работы изменить SLA и в результате может оказаться, что SLA нарушен не был...
Вопрос также возникает с руссификацией отчета, если например, потребуется выводить текущее состояние заявок (открыто, закрыто и т.п.) или что-нибудь подобное. Создавать таблицы с руссификацией?
Кто как решает подобные задачи? Буду очень признателен, если поделитесь своим опытом. Заранее спасибо!
OTRS 5s Free, Debian 7.8, MySQL 5.5
-
- OTRS Гуру
- Сообщения: 5196
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: Разработка отчета сторонними средствами
А покликав часик-другой в мастере отчетов, могли бы и получить такой отчетInigo писал(а):Почитав форум, понял, что стандартные отчеты, реализованные в OTRS, решить данную задачу не помогут,
Докажите! Вы сами лично в таблицу заглядывали?Inigo писал(а):так как в таблице с данными по тикетам не сохраняется информация об эскалациях для закрытых заявок
Код: Выделить всё
SELECT tn, escalation_time, escalation_update_time, escalation_response_time, escalation_solution_time FROM ticket
Что касается русификции, то тут вопрос сложный. Дело в том, что в базе все значения хранятся в английском языке. И только вывод в интерфейс переводится. Можно, кончено, статусы сразу на русском сделать. Но тогда - до свидания мультиязычность. Можно, кончено, встроить перевод "на лету" в модуль отчетности, но думаю, что овчинка выделки не стоит.
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Re: Разработка отчета сторонними средствами
Алексей, спасибо за ответ!
Заглядывал. Данные по эскалациям там есть только для открытых заявок. Кстати, это видно и из Вашего отчета. По нему эскалации зафиксированы только в сентябре и октябре. Осмелюсь предположить, что это еще не закрытые заявки. Либо, что мало вероятно, к осени у Вас резко снизился уровень сервиса.alexus писал(а):Докажите! Вы сами лично в таблицу заглядывали?
В случае, если нам придется формировать отчетность сторонними системами (а, скорее всего, так и будет), думаю придется создавать таблицы с переводом терминов и подключать их в запросах через join.alexus писал(а):Что касается русификции, то тут вопрос сложный. Дело в том, что в базе все значения хранятся в английском языке. И только вывод в интерфейс переводится. Можно, кончено, статусы сразу на русском сделать. Но тогда - до свидания мультиязычность. Можно, кончено, встроить перевод "на лету" в модуль отчетности, но думаю, что овчинка выделки не стоит.
Надеюсь на пересмотр оценки.alexus писал(а):В общем, по дисциплине "OTRS - Advanced admin" - "незачёт" !
OTRS 5s Free, Debian 7.8, MySQL 5.5
-
- OTRS Гуру
- Сообщения: 5196
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: Разработка отчета сторонними средствами
Хммм, ок. Просто у нас есть разные тестовые среды. Для базового варианта - да, данные при закрытии сбрасываются. ЗАЧЕТ !
Для внешних систем скорее всего так и придется делать.Inigo писал(а):В случае, если нам придется формировать отчетность сторонними системами (а, скорее всего, так и будет), думаю придется создавать таблицы с переводом терминов и подключать их в запросах через join.
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Re: Разработка отчета сторонними средствами
Алексей, для отмены сброса в таблице "ticket" данных об эскалациях требуется изменение кода, или есть возможность реализовать это через настройки системы? Буду признателен, если подскажите, в какую сторону посмотреть!alexus писал(а):Просто у нас есть разные тестовые среды. Для базового варианта - да, данные при закрытии сбрасываются.
Пока что удалось получить первое приближение того отчета, который хотелось: Основой запроса послужил следующий код (экскюзе-муа силь ву пле за мой SQL ):
Код: Выделить всё
SELECT
a.queue_id AS queue_id,
a.escalation_type_id AS escalation_type_id,
EXTRACT(YEAR FROM a.create_time) AS escalation_year,
EXTRACT(MONTH FROM a.create_time) AS escalation_month,
COUNT(a.ticket_id) AS escalation_count
FROM
(
SELECT
t.queue_id AS queue_id,
th.ticket_id AS ticket_id,
th.history_type_id AS escalation_type_id,
MIN(th.create_time) AS create_time
FROM
ticket_history th
LEFT JOIN ticket t ON (t.id = th.ticket_id)
WHERE
(th.history_type_id IN (1,42,44))
AND (th.create_time BETWEEN @DateFrom AND @DateTo)
GROUP BY
t.queue_id,
th.ticket_id,
th.history_type_id
) a
GROUP BY
a.queue_id,
a.escalation_type_id,
EXTRACT(YEAR FROM a.create_time),
EXTRACT(MONTH FROM a.create_time)
Из рисков. Как говорил ранее, возможна ситуация, когда для заявки определяется SLA, срабатывает эскалация, потом выясняется, что SLA назначен ошибочно, и привязывается другое SLA. Юридически, нарушения SLA не было, а фактическая запись об эскалации в БД есть. Также возможна проблемная ситуация, когда "cron" настроен на срабатывание через достаточно длительный промежуток времени. В этом случае может случиться так, что юридически нарушение SLA произошло, но в БД это зафиксировано не будет - заявку могут закрыть до фиксации нарушения SLA системой.
Все это наводит на мысли, что для более правильного отражения нарушений SLA нужно использовать другой метод. Брать дату регистрации заявки, дату первого ответа, дату закрытия. На основе SLA и данных по привязанному календарю рассчитать время, до которого должен был быть произведен первый ответ и до которого заявка должна была быть закрыта. Затем сравнить фактические даты с расчетными. Но, насколько понимаю, календари в БД не хранятся? Есть возможность достучаться до них из запроса?
OTRS 5s Free, Debian 7.8, MySQL 5.5
-
- OTRS Гуру
- Сообщения: 5196
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: Разработка отчета сторонними средствами
ДаInigo писал(а):Алексей, для отмены сброса в таблице "ticket" данных об эскалациях требуется изменение кода,
Всё верно.Inigo писал(а):Из допущений. В приведенном запросе информация об эскалациях берется из "ticket_history", а информация об очереди, в которой находится заявка - из "ticket". Причина в том, что заявка могла поступить изначально в общую очередь для входящих сообщений, а эскалации по этой заявке могли быть зафиксированы уже после ее перемещения в целевую очередь. Если требуется отражение более детальной истории с указанием фактической очереди, где заявка была зарегистрирована, то поле "queue_id" нужно брать из таблицы "ticket_history".
Изменение SLA - это уже процессный вопрос.Inigo писал(а):Из рисков. Как говорил ранее, возможна ситуация, когда для заявки определяется SLA, срабатывает эскалация, потом выясняется, что SLA назначен ошибочно, и привязывается другое SLA. Юридически, нарушения SLA не было, а фактическая запись об эскалации в БД есть. Также возможна проблемная ситуация, когда "cron" настроен на срабатывание через достаточно длительный промежуток времени. В этом случае может случиться так, что юридически нарушение SLA произошло, но в БД это зафиксировано не будет - заявку могут закрыть до фиксации нарушения SLA системой.
Для четкого постфактного анализа нарушений SLA надо писать модуль, который будет сохранять "на веки вечные" данные по эскалациям в динамические поля.Inigo писал(а): Все это наводит на мысли, что для более правильного отражения нарушений SLA нужно использовать другой метод. Брать дату регистрации заявки, дату первого ответа, дату закрытия. На основе SLA и данных по привязанному календарю рассчитать время, до которого должен был быть произведен первый ответ и до которого заявка должна была быть закрыта. Затем сравнить фактические даты с расчетными. Но, насколько понимаю, календари в БД не хранятся? Есть возможность достучаться до них из запроса?
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
-
- OTRS Новобранец
- Сообщения: 148
- Зарегистрирован: 30 апр 2013, 19:08
- Откуда: Украина, Киев.
- Поблагодарили: 1 раз
Re: Разработка отчета сторонними средствами
Сори за ОфТоп и не сочтите за наглость или поучения. Просто делюсь тем, что знаю )
В таких случаях, чтобы избежать длинных(повторяющихся с select) строк, использую:
Надеюсь ничего плохого не посоветовал.
Код: Выделить всё
GROUP BY
t.queue_id,
th.ticket_id,
th.history_type_id
.....
GROUP BY
a.queue_id,
a.escalation_type_id,
EXTRACT(YEAR FROM a.create_time),
EXTRACT(MONTH FROM a.create_time)
Код: Выделить всё
GROUP BY 1, 2, 3
.....
GROUP BY 1, 2, 3, 4
OTRS 5s, Ubuntu 12.04
Re: Разработка отчета сторонними средствами
mukexa, спасибо за совет! Должен признать, что являюсь рабом привычек, и если есть возможность расписать в коде что-либо подробно, не могу удержаться.
Написание же собственного модуля по фиксации в БД эскалаций, на мой взгляд, будет той еще задачей. Потребуется отслеживать ряд событий в БД (изменение SLA у заявки, действия агента с заявкой, закрытие заявки и т.п.), и проводить изменения в своей таблице с историей эскалаций.
Возможно... Хотя, в этом случае тоже вожможны накладки. Я пока что склоняюсь к необходимости создания хранимой процедуры. На входе - номер заявки, на выходе такие параметры, как:alexus писал(а):Для четкого постфактного анализа нарушений SLA надо писать модуль, который будет сохранять "на веки вечные" данные по эскалациям в динамические поля.
- Время регистрации;
- Текущее состояние;
- Очередь, в которой заявка была зарегистрирована;
- Очередь, в которой заявка находится в текущий момент;
- Время первого ответа;
- Время закрытия;
- Время первого ответа по SLA;
- Время выполнения по SLA;
- Есть или нет нарушение SLA по времени первого ответа;
- Есть или нет нарушение SLA по времени выполнения.
Написание же собственного модуля по фиксации в БД эскалаций, на мой взгляд, будет той еще задачей. Потребуется отслеживать ряд событий в БД (изменение SLA у заявки, действия агента с заявкой, закрытие заявки и т.п.), и проводить изменения в своей таблице с историей эскалаций.
OTRS 5s Free, Debian 7.8, MySQL 5.5
Re: Разработка отчета сторонними средствами
Кто-то победил в вопросе осуществления сохранения данных о нарушениях SLA без сброса при закрытии заявки?
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
-
- OTRS Гуру
- Сообщения: 5196
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: Разработка отчета сторонними средствами
У нас есть модуль фиксации времён эскалации.
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
-
- OTRS Гуру
- Сообщения: 3119
- Зарегистрирован: 24 дек 2010, 09:27
- Откуда: Череповец
- Благодарил (а): 4 раза
- Поблагодарили: 5 раз
- Контактная информация:
Re: Разработка отчета сторонними средствами
http://www.radiantsystem.ru/otrs/uslugi-otrs/ - попробуйте обратиться
С уважением Юрий Колесников
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая