2.2 Системная архитектура
Разрабатываемое приложение размещено на компьютере с установленной ОС MS Windows Server и связывается с локальной базой данных путем обращения к файлу базы через библиотеку LiteDB.dll (Модуль работы с локальным хранилищем). Заполнение базы локальной базы происходит ручным путем через контроллер модуля работы с API «Slack».
Рисунок 4. Пример пополнения локальной БД.
Информацию из Elasticsearch DB получаем, используя библиотеку Nest.dll (Модуль работы с Elasticsearch БД), путем HTTP запросов. Затем полученные данные обрабатываются и из результата обработки формируется отчет. Передача отчета менеджеру происходит при использовании MargieBot.dll (Модуль работы с API «Slack»), Запрос к API передается на облачный сервер «Slack», затем обрабатывается на стороне мессенджера и передается менеджеру.
Рисунок 5. Диаграмма размещения после внедрения.
Рисунок 6. Пример ответа от приложения в мессенджере.
2.3 Архитектура данных
Процесс проектирования архитектуры начинается с выбора данных, которые необходимо хранить. Архитектура Elasticsearch определена заранее, так как была предложена руководителем проекта как обязательное условие, а архитектура LiteDB спроектирована в процессе разработки. Архитектура выглядит таким образом:
Рисунок 7. Диаграмма данных участвующих в прикладном процессе.
При создании базы данных использовалась СУБД LiteDB, которая представляет собой не реляционную базу данных. Она используется для хранения информации о связях «менеджер-организатор».
LiteDB хранит информацию в виде BSON документов. BSON – является надмножеством JSON, включая дополнительно регулярные выражения, двоичные данные и даты. JSON (англ. JavaScript Object Notation) – текстовый формат обмена данными, основанный на JavaScript. Документы хранятся в коллекции, иными словами коллекция – это группа упорядоченных проиндексированных документов. Так как это не реляционная база, то коллекция аналогична таблице в реляционной БД.
Структура базы данных LiteDB:
Id организатора
Название организатора
Имя закрепленного менеджера
Аккаунт Slack закрепленного менеджера
Модель данных индекса билета, используемого в приложении, получается из основной ИС, и является сложно-агрегированной структурой. Полученная информация из сервиса Elasticsearch является избыточной в рамках реализуемого приложения, поэтому исходя из функциональных требований будут использованы следующие поля
Таблица 2. Описание модели данных.
Название поля |
Тип данных |
Описание |
EventId |
int |
Идентификационный номер мероприятия |
DistributionType |
string |
Тип канала продаж |
PaymentReceived |
bool |
Метка о получении оплаты |
PaymentDate |
DateTime |
Дата получения оплаты |
Deleted |
bool |
Метка об удалении билета |
Amount |
decimal |
Стоимость |
DebitFromUserCash |
decimal |
Количество бонусных баллов |
Рисунок 8. Структура данных, получаемая из Elasticsearch по необходимому индексу.