Скрипт для выгрузки обращений из Omnidesk в локальную бд.
Клонируем репозиторий, а затем в папке скрипта создаем файл settings_local.py,
содержащий настройки подключения к Omnidesk:
OMNIDESK_DOMAIN = 'example' # поддомен Omnidesk
OMNIDESK_EMAIL = 'example@example.com' # email сотрудника
OMNIDESK_API_KEY = 'EXAMPLE_API_KEY' # API-ключДля проверки тестового задания этот файл будет предоставлен отдельно.
Аргументы командной строки
python ./omnidesk_loader.py --help
usage: python3 ./omnidesk_loader.py [-h] [--from_date FROM_DATE]
optional arguments:
-h, --help Вывести это сообщение-подсказку и ничего не загружать
--from_date FROM_DATE
Начало периода, в формате ГГГГ-ММ-ДД (например,
2020-12-31)
python ./omnidesk_loader.py
Предполагается запуск программы при составлении ежемесячных аналитических отчетов. Поэтому программа по-умолчанию пытается найти число "месяц назад" и запрашивать обращения не ранее этой даты.
Как происходит подбор даты. В самом простом случае - это просто "31 день назад", но так как количество дней месяцев не одинаково, то 31 день назад число месяца может отличаться от сегодняшнего числа, что неудобно при составлении отчета. Поэтому мы ищем дату в предыдущем месяце, число которой совпадает с текущим числом. Если такой даты нет (например, в соответствие дате 31 марта мы не можем поставить "31" февраля), то мы берем максимальную дату предыдущего месяца.
Примеры соответствий:
31 января 2022 года -> 31 декабря 2021 года
31 марта 2020 года -> 29 февраля 2022 года
31 марта 2022 года -> 28 февраля 2022 года
Задается дата в формате ГГГГ-ММ-ДД, она используется для фильтрации обращений в API Omnidesk.
Так как пользователи скрипта будут запускать его на собственных компьютерах
(а не получать доступ к серверу), при реализации была поставлена задача обойтись
средствами стандартной библиотеки Python, чтобы пользователь мог просто скачать и запустить
скрипт — без установки дополнительных библиотек (соответственно,
без необходимости разрешения конфликтов между ними). Так, например, вместо urllib
было бы "проще" писать код с помощью requests, который уже стал отраслевым стандартом.
Такой подход приводит к некоторой многословности, но так как функциональность программы довольно простая, то это оправдано, так как обеспечивает удобство эксплуатации.
Целевой версией языка был Python 3.6, а не какая-то из новых версий, чтобы пользователи могли избежать необходимости апгрейда.
Для проекта была выбрана SQLite, потому что она не требует никакой дополнительной настройки конечным пользователем. Также код, пригодный для SQLite легко портируется для использования с другими СУБД.
Если аналитику приходится иметь дело с большими объемами данных, хорошим выбором
будет замена SQLite на PgSQL или MySQL (например, путем добавления соответствующего
docker-compose.yml в проект).