80
| 3 | UserStoredFilterColumns-AgentTicketEscalationView | {} |
| 3 | UserTicketOverviewAgentTicketEscalationView | Small |
| 3 | UserLastLogin | 1540921735 |
| 3 | UserDashboardTicketGenericFilter0130-TicketOpen | Locked |
| 3 | UserDashboardTicketGenericFilter0120-TicketNew | All |
+---------+---------------------------------------------------+-------------------+
Я выбрал настройки для пользователя с внутренним идентификатором 3.
Наиболее интересные для нас поля — это время отсутствия в офисе.
Используется системой для определения может ли агент начать работать по
заявке или его нет в офисе вообще. Еще в системе используется календарь, в
котором указывается время работы каждого агента.
Таблица users таблица 2-3-2-14
Имя поля Тип данных Комментарий
Id Int(11) Внутренний идентификатор
Login varchar(200) Имя пользователя (логин)
Pw Varchar(128) Пароль
Title Varchar(50) Должность
first_name Varchar(100) Имя
last_name Varchar(100) Фамилия
valid_id Smallint(6) Идентификатор активности
create_time Datetime Время создания
change_by Datetime Время изменения
Список агентов системы OTRS.
В таблицах несколько раз встречалось поле пароля. Стоит отметить, что в
таблицах хранятся не сами пароли, а хэши, получающиеся после шифрования по
алгоритму ассиметричного шифрования blowfish. Это означает, что можно
только зашифровать данные, но не существует математической модели, по
которой возможно его дешифровать. Процедура аутентификации в этом случае
должна пройти две стадии — читается введенный пароль пользователя,
шифруется и полученный хэш сравнивается с записанным в базе данных.
81
Если злоумышленник сможет прочитать содержимое таблицы, то сможет
получить только логины пользователей, но не сами пароли, что вполне
достаточно для обеспечения достаточного уровня безопасности системы.
82
2.3.3 Структурная схема пакета (дерево вызова программных
модулей)
OTRS имеет модульную структуру. Ее основные компоненты показаны на
рисунке 2-9 ниже (иллюстрации взяты из документации разработчика):
Рис. 2-9
Бирюзовым цветом обозначены интерфейсы взаимодействия с клиентами,
это электронная почта и web сервер. В желтом блоке отображено внутренние
модули системы и карта взаимодействия друг с другом. Каждый блок так же
включает в себя минимум один модуль, выполняющий заданную функцию.
Наиболее простые модули — обработка почты и связь с базой данных. Блок
базы данных состоит из одного модуля, обеспечивающего работу с конкретной
базой — в нашем случае, mysql.
Блок почты тоже прост — в нем используется настройка метода отправки и
соответствующие ему параметры. Больше этот модуль никаких функций не несет.
Пример его настроек показан на рисунке 2-10
83
рис. 2-10. Настройки модуля работы с почтой
Модуль Generic Interface это основной рабочий процесс системы. Его
архитектура показана на рисунке 2-11:
84
Рис. 2-11. Архитектура модуля Generic Interface
Модули Kernel и GenericInterface фактически является контейнером, в
который подключаются дополнительные модули. Каждый модуль выполняет
какую-то определенную функцию и по внутреннему API возвращает результаты
своей работы. Вызывающий модуль обрабатывает эти данные и передает
структурированные данные во Frontend, отрисовывающий страницу интерфейса с
обновленными данными.
По умолчанию OTRS поставляется с набором модулей необходимых для
полноценной организации работы HelpDesk системы. Дополнительные
программные модули типа FAQ или ITSM устанавливаются дополнительно и
имеют свои собственные модули.
85
2.3.4 Описание программных модулей
Все модули написаны на языке программирования Perl и на файловой системе
располагаются в строго отведенных для них директориях:
Рис. 2-12
Скриншот программы Midnight Commander с деревом директорий
содержащих в себе модули.
86
Core модули
Набор core модулей отвечает за логику работы системы. Так же испольуются
для поддержки системных вызовов таких как «блокировка заявки» или «создания
заявки».
Kernel::System::Config (доступ к опциям конфигурации)
Kernel::System::Log (ведение системного журнала)
Kernel::System::DB (доступ к информации в базе данных)
Kernel::System::Auth (поддержка аутентификации пользователей)
Kernel::System::User (управление пользователями)
Kernel::System::Group (управление группами пользователей)
Kernel::System::Email (отправка e-mail)
Frontend модули
Модули находятся в директории Kernel/Modules/* и выполняют различную
работу для фронтэнда. В стандартном пакете инсталляции их 185 штук.
Например, AdminPostMasterFilter.pm позволяет настраивать почтовые фильтры в
интерфейсе администратора. AdminSignature.pm — позволяет редактировать
подписи шаблонов сообщений для различных очередей, AgentTicketPriority.pm
позволяет изменять приоритет сообщения в интерфейсе агента и так далее.
Generic Interface модули
Располагаются в директории Kernel/GenericInterface/*. Используются для
координации работы и обработки данных вызываемых модулей.
Kernel::GenericInterface::Transport (взаимодействие с удаленными
системами)
Kernel::GenericInterface::Mapping (преобразование данных в требуемый
формат)
Kernel::GenericInterface::Requester (для использования OTRS в роли
клиента веб сервисов)
Kernel::GenericInterface::Provider (для использования OTRS в роли сервера
для веб сервисов)
Kernel::GenericInterface::Operation (для запуска заданий Provider модуля)
87
Kernel::GenericInterface::Invoker (для запуска заданий Requester модуля)
Kernel::GenericInterface::Debugger (мониторинг состояний соединений при
работе с внешними веб сервисами)
Time модуль
В информационных системах, работающих в различных часовых поясах,
часто возникает путаница со временем. Например, клиент присылает сообщение,
в котором сказано, что обнаружена проблема в 14:00. Агент, работающий в
другом часовом поясе психологически привязан к местному времени и может дать
заявку службе мониторинга выбрать события за период с 13:50 до 14:00 не учтя
часовой пояс. Поэтому в OTRS принято правило — все время всегда ведется
относительно временной зоны UTC, без учета летнего и зимнего времени. В своих
персональных настройках агент может указать свое локальное время для
удобства, но все смещения будут высчитываться относительно базового UTC.
Модуль занимается арифметическими операциями над временными
данными.
Localization модуль
Модуль занимается переводом интерфейса пользователя в соответствии с его
персональными настройками на лету.
Изначально все сообщения системы составлены на английском языке. Если
требуется локализация, то подключается соответствующий модуль, на вход
которому передается подготовленное сообщение. В соответствии со своей
таблицей замен модуль подыскивает перевод и возвращает не оригинальный
текст, а переведенный.
Все локализованные сообщения находятся в директории i18n/otrs (i18n это
производное от internationalization, т. е. «i»+18букв+«n») в файлах с именами
формата otrs.язык.po. Для русского языка это otrs.ru.po. Содержимое файла
выглядит следующим образом:
--- усечено ---
#. Template: AdminACL
msgid "This field is required."
88
msgstr "Это поле обязательно."
#. Template: AdminACL
msgid "Overwrite existing ACLs?"
msgstr "Перезаписать существующие ACL?"
#. Template: AdminACL
msgid "Upload ACL configuration"
msgstr "Загрузить настройки ACL"
--- усечено ---
Таким образом модуль должен найти метку вызывающего модуля «#.
Template: AdminACL», под ней найти необходимое сообщение и из следующей
строки считать ее перевод, который будет возвращен в основной модуль.
На мой взгляд это очень простое, но абсолютно не эффективное с точки
зрения расходования ресурсов, решение. Полнотекстовый поиск в файлах всегда
был довольно ресурсоемкой задачей, а жесткий диск сервера всегда являлся
самым медленным компонентом. При переводе будет каждый раз создаваться
дескриптор файла, читаться весь или почти весь файл перевода, искаться
последовательно два соответствия и затем считываться результат с последующим
закрытием дескриптора. И так на каждую строку перевода.
Возможно разработчики постарались максимально упростить перевод
системы, пожертвовав производительностью. Но нас в GPL предупреждали о
возможных проблемах, поэтому придется оставить этот алгоритм на откуп самим
разработчикам.
89
2.4 Контрольный пример реализации проекта и его описание
Будем рассматривать классический пример заказа клиентом новой
дополнительной услуги. В процессе будет задействовано четыре человека:
клиент, сотрудник 1-й линии техподдержки, менеджер, инженер.
Клиент отправляет письмо с просьбой подключить новую услугу VPS
(Virtual Private Server) для хостинга. OTRS получает письмо, определяет его как
новое, присваивает заявке уникальный номер и помещает в очередь с новыми
письмами. В основном интерфейсе сотрудника техподдержки появляется письмо
в виде заявки:
рис. 2-13. Новая заявка в интерфейсе агента техподдержки
Открыв заявку, сотрудник техподдержки видит от кого пришло сообщение и
что именно требуется клиенту (рис. 2-14)
Рис. 2-14. Начальная заявка клиента
После нажатия кнопки «Ответить», открывается форма редактирования
ответного сообщения, где сотрудник просит уточнить конфигурацию. Рис. 2-15