Разработка отчета сторонними средствами

[Inigo]

Добрый день!

Столкнулся со следующей проблемой - нужно сформировать отчет, в котором бы отражалось количество заявок с нарушениями SLA (время первого ответа, время решения) в разрезе временных периодов. К примеру, в колонках - месяцы, в строках - очереди, на пересечении - количество нарушений SLA. Почитав форум, понял, что стандартные отчеты, реализованные в OTRS, решить данную задачу не помогут, так как в таблице с данными по тикетам не сохраняется информация об эскалациях для закрытых заявок. Как вариант - разработать отчет сторонними средствами, и проводить в нем анализ таблицы "ticket_history". Если в истории есть события "EscalationResponseTimeStart" или "EscalationSolutionTimeStart", считать, что в данной заявке нарушения SLA имели место быть. Хотя, тоже не все однозначно. Ведь у заявки могли по ходу работы изменить SLA и в результате может оказаться, что SLA нарушен не был...
Вопрос также возникает с руссификацией отчета, если например, потребуется выводить текущее состояние заявок (открыто, закрыто и т.п.) или что-нибудь подобное. Создавать таблицы с руссификацией?
Кто как решает подобные задачи? Буду очень признателен, если поделитесь своим опытом. Заранее спасибо!

[alexus]

Почитав форум, понял, что стандартные отчеты, реализованные в OTRS, решить данную задачу не помогут,

А покликав часик-другой в мастере отчетов, могли бы и получить такой отчет

Отчет по эскалации Время решения.png (30.18 КБ) 13651 просмотр

так как в таблице с данными по тикетам не сохраняется информация об эскалациях для закрытых заявок

Докажите! Вы сами лично в таблицу заглядывали?

Код: Выделить всё

SELECT tn, escalation_time, escalation_update_time, escalation_response_time, escalation_solution_time FROM ticket

В общем, по дисциплине "OTRS - Advanced admin" - "незачёт" !

Что касается русификции, то тут вопрос сложный. Дело в том, что в базе все значения хранятся в английском языке. И только вывод в интерфейс переводится. Можно, кончено, статусы сразу на русском сделать. Но тогда - до свидания мультиязычность. Можно, кончено, встроить перевод "на лету" в модуль отчетности, но думаю, что овчинка выделки не стоит.

[Inigo]

Алексей, спасибо за ответ!

Докажите! Вы сами лично в таблицу заглядывали?

Заглядывал. Данные по эскалациям там есть только для открытых заявок. Кстати, это видно и из Вашего отчета. По нему эскалации зафиксированы только в сентябре и октябре. Осмелюсь предположить, что это еще не закрытые заявки. Либо, что мало вероятно, к осени у Вас резко снизился уровень сервиса.

Что касается русификции, то тут вопрос сложный. Дело в том, что в базе все значения хранятся в английском языке. И только вывод в интерфейс переводится. Можно, кончено, статусы сразу на русском сделать. Но тогда - до свидания мультиязычность. Можно, кончено, встроить перевод "на лету" в модуль отчетности, но думаю, что овчинка выделки не стоит.

В случае, если нам придется формировать отчетность сторонними системами (а, скорее всего, так и будет), думаю придется создавать таблицы с переводом терминов и подключать их в запросах через join.

В общем, по дисциплине "OTRS - Advanced admin" - "незачёт" !

Надеюсь на пересмотр оценки.

[alexus]

Хммм, ок. Просто у нас есть разные тестовые среды. Для базового варианта - да, данные при закрытии сбрасываются. ЗАЧЕТ !

В случае, если нам придется формировать отчетность сторонними системами (а, скорее всего, так и будет), думаю придется создавать таблицы с переводом терминов и подключать их в запросах через join.

Для внешних систем скорее всего так и придется делать.

[Inigo]

Просто у нас есть разные тестовые среды. Для базового варианта - да, данные при закрытии сбрасываются.

Алексей, для отмены сброса в таблице "ticket" данных об эскалациях требуется изменение кода, или есть возможность реализовать это через настройки системы? Буду признателен, если подскажите, в какую сторону посмотреть!

Пока что удалось получить первое приближение того отчета, который хотелось:

Отчет по нарушениям SLA.png (74.7 КБ) 13605 просмотров

Основой запроса послужил следующий код (экскюзе-муа силь ву пле за мой 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)

Из допущений. В приведенном запросе информация об эскалациях берется из "ticket_history", а информация об очереди, в которой находится заявка - из "ticket". Причина в том, что заявка могла поступить изначально в общую очередь для входящих сообщений, а эскалации по этой заявке могли быть зафиксированы уже после ее перемещения в целевую очередь. Если требуется отражение более детальной истории с указанием фактической очереди, где заявка была зарегистрирована, то поле "queue_id" нужно брать из таблицы "ticket_history".

Из рисков. Как говорил ранее, возможна ситуация, когда для заявки определяется SLA, срабатывает эскалация, потом выясняется, что SLA назначен ошибочно, и привязывается другое SLA. Юридически, нарушения SLA не было, а фактическая запись об эскалации в БД есть. Также возможна проблемная ситуация, когда "cron" настроен на срабатывание через достаточно длительный промежуток времени. В этом случае может случиться так, что юридически нарушение SLA произошло, но в БД это зафиксировано не будет - заявку могут закрыть до фиксации нарушения SLA системой.

Все это наводит на мысли, что для более правильного отражения нарушений SLA нужно использовать другой метод. Брать дату регистрации заявки, дату первого ответа, дату закрытия. На основе SLA и данных по привязанному календарю рассчитать время, до которого должен был быть произведен первый ответ и до которого заявка должна была быть закрыта. Затем сравнить фактические даты с расчетными. Но, насколько понимаю, календари в БД не хранятся? Есть возможность достучаться до них из запроса?

[alexus]

Алексей, для отмены сброса в таблице "ticket" данных об эскалациях требуется изменение кода,

Да

Из допущений. В приведенном запросе информация об эскалациях берется из "ticket_history", а информация об очереди, в которой находится заявка - из "ticket". Причина в том, что заявка могла поступить изначально в общую очередь для входящих сообщений, а эскалации по этой заявке могли быть зафиксированы уже после ее перемещения в целевую очередь. Если требуется отражение более детальной истории с указанием фактической очереди, где заявка была зарегистрирована, то поле "queue_id" нужно брать из таблицы "ticket_history".

Всё верно.

Из рисков. Как говорил ранее, возможна ситуация, когда для заявки определяется SLA, срабатывает эскалация, потом выясняется, что SLA назначен ошибочно, и привязывается другое SLA. Юридически, нарушения SLA не было, а фактическая запись об эскалации в БД есть. Также возможна проблемная ситуация, когда "cron" настроен на срабатывание через достаточно длительный промежуток времени. В этом случае может случиться так, что юридически нарушение SLA произошло, но в БД это зафиксировано не будет - заявку могут закрыть до фиксации нарушения SLA системой.

Изменение SLA - это уже процессный вопрос.

Все это наводит на мысли, что для более правильного отражения нарушений SLA нужно использовать другой метод. Брать дату регистрации заявки, дату первого ответа, дату закрытия. На основе SLA и данных по привязанному календарю рассчитать время, до которого должен был быть произведен первый ответ и до которого заявка должна была быть закрыта. Затем сравнить фактические даты с расчетными. Но, насколько понимаю, календари в БД не хранятся? Есть возможность достучаться до них из запроса?

Для четкого постфактного анализа нарушений SLA надо писать модуль, который будет сохранять "на веки вечные" данные по эскалациям в динамические поля.

[mukexa]

Сори за ОфТоп и не сочтите за наглость или поучения. Просто делюсь тем, что знаю )

Код: Выделить всё

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)

В таких случаях, чтобы избежать длинных(повторяющихся с select) строк, использую:

Код: Выделить всё

GROUP BY 1, 2, 3
.....
GROUP BY 1, 2, 3, 4

Надеюсь ничего плохого не посоветовал.

[Inigo]

mukexa, спасибо за совет! Должен признать, что являюсь рабом привычек, и если есть возможность расписать в коде что-либо подробно, не могу удержаться.

Для четкого постфактного анализа нарушений SLA надо писать модуль, который будет сохранять "на веки вечные" данные по эскалациям в динамические поля.

Возможно... Хотя, в этом случае тоже вожможны накладки. Я пока что склоняюсь к необходимости создания хранимой процедуры. На входе - номер заявки, на выходе такие параметры, как:

• Время регистрации;
• Текущее состояние;
• Очередь, в которой заявка была зарегистрирована;
• Очередь, в которой заявка находится в текущий момент;
• Время первого ответа;
• Время закрытия;
• Время первого ответа по SLA;
• Время выполнения по SLA;
• Есть или нет нарушение SLA по времени первого ответа;
• Есть или нет нарушение SLA по времени выполнения.

Имея подобный инструмент, его можно будет гибко использовать в запросах, на мой взгляд, для решения задач по анализу нарушений SLA. Трудность представляет только расчет паратметров "Вермя первого ответа по SLA" и "Время выполнения по SLA". Пока не очень представляю как достучаться до календарей.

Написание же собственного модуля по фиксации в БД эскалаций, на мой взгляд, будет той еще задачей. Потребуется отслеживать ряд событий в БД (изменение SLA у заявки, действия агента с заявкой, закрытие заявки и т.п.), и проводить изменения в своей таблице с историей эскалаций.

[Antony]

Кто-то победил в вопросе осуществления сохранения данных о нарушениях SLA без сброса при закрытии заявки?

[alexus]

У нас есть модуль фиксации времён эскалации.

[ncmps]

Добрый день! А где взять этот модуль? )

[ykolesnikov]

http://www.radiantsystem.ru/otrs/uslugi-otrs/ - попробуйте обратиться