66
Следующий уровень доступа в иерархии групповой политики –
сотрудник технического отдела. После авторизации у данного пользователя
также открывается раздел работы с обращениями. Здесь появляется
возможность откорректировать и дополнить обращение.
В любой заявке сотрудник технического отдела может оставить
комментарий, а также закрыть это обращение при решении всех заявленных
проблем. Также у сотрудников технического отдела открыт доступ в раздел
формирования отчета по обращениям.
Пользователь с уровнем доступа Руководитель отдела имеет доступ к
функциям управления справочниками информационной системы.
2.3.2. Характеристика базы данных
Архитектура системы
Для подключения UI компонента для работы с файлами к документу
необходимо задать поля djinni модели карточки, из которых будут получены:
1. Идентификатор каталога. В случае если прикладная модель содержит
базовую RpDocument, то это поле RpDocument.mDoc.mUuid.
2. Идентификатор активного события, к которому будут прикрепляться
вложения. В базовой модели это поле RpDocument.mActiveEvents.
Сам UI компонент работает через указатель на объект класса
«IAttachments». Класс «IAttachments» используется в качестве диспетчера для
получения указателя на объект интерфейса конкретного микросервиса. Работа с
контроллером вложений более подробно описана в пункте «Описание API».
UI модули
1. attachments-ui
Объединяет набор UI компонентов для работы с вложениями:
• Компонент отображения вложений в реестре сущностей (Макет)
• Компонент отображения вложений в карточке сущности в виде плиток
(Макет)
67
• Компонент отображений вложений вертикальным списком (Макет диска)
• Составляющие компонентов
Компоненты принимают готовый набор данных, отображают их,
взаимодействие посредством слушателей, событий, обратных вызовов. Не
зависит от микросервиса.
*Сущность – задача, совещание, папка СБИС Диска, платёжный документ
2. attachments-bl
Объединяет механизмы взаимодействия с микросервисами по работе с
вложениями.
3. attachments-download
Объединяет компоненты по скачиванию файлов
Основные микросервисы
1. Микросервис вложений «Attachments»
Основной микросервис для работы с вложениями. UI компонент
содержит указатель на объект интерфейса микросервиса, и все действия над
файлами происходят через него.
Основная структура БД микросервиса представлена на рис. 18.
Рис. 17. Структура БД микросервиса вложений
68
Метаданные вложений хранятся в таблице «Attachment».
Метаданные редакций – в таблице «Redaction». Метаданные подписей – в
таблице «Sign».
Инициализировать синхронизацию метаданных файлов в своем
реестре должен ответственный прикладной разработчик. При синхронизации
прикладных документов/файлов формируется в облаке пакет, содержащий
прикладные данные, базовые данные по документам и метаданные файлов.
RecordSet с метаданными файлов располагается в поле «Attachments». Весь
этот пакет отправляется в мобильное приложение.
На стороне мобильного приложения прикладной мобильный
контроллер принимает весь пакет из облака. Для сохранения метаданных
файлов, пришедших из облака, реализуется класс «ImportAttachments» с
методом «Execute», в который и будет передан пришедший пакет. Для
корректной обработки пакета он должен содержать поле «Files» типа «Record»
с тремя полями типа «RecordSet»: «Attachments», «Redactions» и «Signs». Рядом
с полем «Files» должно быть также поле «AttachmentEvents» для связи
вложений с событиями документооборота.
Формат поля Attachments:
Поле
Тип
Описание
AttachmentId
UUID
Идентификатор вложения в СБИС диске
Catalog
UUID
Идентификатор каталога, к которому прикреплено
вложение на диске
CloudId
String
Облачный идентификатор вложения
FileName
String
Имя файла
Title
String
Название вложения
Folder
UUID
Идентификатор папки
IsFolder
Bool
Является ли вложение папкой
Date
DateTime
Дата создания вложения
69
Type
String
Тип вложения
SubType
String
Под тип вложения
Permissions
Record
Права на вложение для текущего пользователя
(используется в мобильном приложении)
Формат:
CanRead( bool )
CanEdit( bool )
CanDelete( bool )
Формат поля Redactions:
Поле
Тип
Описание
SbisDiskId
String
Идентификатор редакции в СБИС диске
Attachment
UUID
Идентификатор вложения в СБИС диске
FileName
String
Имя редакции
Title
String
Название редакции
ModifyDate
DateTime
Дата последнего изменения файла
Size
Int64
Размер файла редакции
FormatVersion
String
Версия формата
FormatSubVersion
String
Подверсия формата
Version
Int32
Версия
Encrypted
Int16
Тип шифрования файла
ImageWidth
Int32
Ширина изображения preview
ImageHeigh
t
Int32
Высота изображения preview
Формат поля Signs:
Поле
Тип
Описание
Uuid
UUID
Идентификатор файла подписи в СБИС диске
Redaction
String
Идентификатор редакции в СБИС диске
Signer
String
ФИО подписанта
70
ProfileId
String
Идентификатор профиля подписанта
Date
DateTime
Дата формирования подписи
Type
Int16
Тип подписи
Формат поля AttachmentEvents:
Поле
Тип
Описание
Attachment
UUID
Идентификатор вложения в СБИС диске
Redaction
String
Идентификатор редакции в СБИС диске
Sign
UUID
Идентификатор файла подписи в СБИС диске
Event
UUID
Идентификатор события
Также планируется реализовать получение метаданных из облака по
массиву идентификаторов СБИС диска вложений через метод «List»
интерфейса микро сервиса «Attachments». Само получение изменений
метаданных из облака будет происходить через брокер синхронизации по
схеме, указанной ниже.
Рис.18 Схема синхронизации метаданных вложений
71
Метод «Refresh» интерфейса микро сервиса синхронизировать
метаданные не будет – его результат формируется целиком из локальной БД
мобильного приложения.
Содержимое файлов кэшируется на уровне мобильного устройства и
хранится в выделенной под приложение TMP директории «FileStorage». Поля
LocalUrl и PdfUrl таблицы «Redaction» содержат относительные ссылки в «File
Storage» на содержимое самого файла и pdf. Инвалидация кэша будет
происходить при синхронизации метаданных вложений – сравниваются даты
изменения вложения, и в случае, если даты различны, то происходит очистка
кэша.
2. Микро сервис загрузки файлов «FileLoader»
Микро сервис используется для загрузки файлов и изменений их содержимого
в облако из мобильного приложения. Имеет собственную БД для хранения
кэша и интерфейс, и модели данных для работы с микро сервисом. Подробнее
механизм загрузки файлов описан в пункте 4 основных сценариев
взаимодействия UI компонентов и микросервисов.
3. Микро сервис по работе с буфером обмена «Buffer»
Используется для взаимодействия с «СБИС Буфер» мобильного приложения.
4. Микро сервис расшифровки файлов «FileDecryption»
Используется для расшифровки файлов. В рамках данного проекта
существующий функционал по расшифровке файлов будет выделен в
отдельный микро сервис со своим API и моделями данных.
5. Микро сервис подписания «Cryptography»
Используется для подписания файлов. Реализуется новый механизм
подписания вложений.
6. Микро сервис по работе с правами на файлы «FilePermissions»
Используется для отображения списка лиц, у которых есть права на чтение и
редактирование конкретного файла. В рамках данного проекта существующий
72
функционал по работе с правами на файлы будет выделен в отдельный микро
сервис со своим API и моделями данных.
Основные сценарии взаимодействия UI компонента и микро сервисов бизнес-
логики
3. Получение и просмотр списка файлов на карточке документа
UI компонент через «IAttachments» получает указатель на объект контроллера
«Attachments». С помощью метода «List» компонент получает список
метаданных файлов по документу в виде вектора моделей «FileInfo». Внутри
метода запускается задача на синхронизацию метаданных с облаком, а затем
возвращается результат из кэша. После окончания синхронизации будет
вызываться UI callback, который UI сторона может передать в контроллер через
метод «SetDataRefreshCallback».
У модели «FileInfo» есть поле mPreviewUrl, которое для обычных вложений
содержит шаблонную ссылку для скачивания файла превью вложения. В
качестве шаблона можно задать размеры превью через %d/%d/.
В случае требуемых вложений mPreviewUrl будет содержать ссылку на
скачивания файла заглушки.
4. Отображение содержимого файлов
UI компонент через «IAttachments» получает указатель на объект контроллера
«Attachments». UI вызывает метод «ReadAttachment» для получения модели
данных «FileData». Модель данных содержит информацию о теле файла: размер
файла mSize и относительный путь до расположения файла на мобильном
устройстве mLocalUrl. В случае если файл еще не был скачан ранее в кэш, то
будет запущена задача на скачивание. В таком случае в модели «FileData»
будет пустое поле mLocalUrl, а вернется mOperationId – идентификатор
операция для получения событий о результате скачивания вложения. Список
событий описан ниже:
const on_download_operation_success: string = "OnDownloadOperationSuccess";
сonst on_download_operation_failed: string = "OnDownloadOperationFailed";
73
conston_download_operation_progress:string = "OnDownloadOperationProgress";
Для документов с форматами «.xml», «.vsd», «.vsdx», «.rtf» скачивается PDF.
Схема получения тела файла с синхронизацией данных с облаком представлена
на рис. 3.
Рис. 19 Схема отображения содержимого файла
5. Скачивание файлов
Сценарий взаимодействия UI компонента и микросервисов тот же, что и при
отображении содержимого файлов. Разница лишь в том, что UI вызывает метод
download_original (attach_id: i32, redaction_id: optional<i32>, path: string) с
указанием конкретной директории для скачивания. Метод возвращает
идентификатор операции для получения событий о результате скачивания
вложения.
6. Скачивание PDF файлов
Сценарий взаимодействия UI компонента и микро сервисов тот же, что и при
обычном скачивании файлов. Разница в том, что UI вызывает метод
download_as_pdf(bl_object: string, attach_id: i32, redaction_id: optional<i32>).
74
Метод возвращает идентификатор операции для получения событий о
результате скачивания вложения.
7. Скачивание расшифрованного файла
Сценарий взаимодействия UI компонента и микро сервисов тот же, что и при
обычном скачивании файлов. Разница в том, что UI вызывает метод
download_with_decryption(bl_object: string, attach_id: i32, path: string, pass:
optional<string>, stamp: optional<string>). Метод возвращает идентификатор
операции для получения событий о результате скачивания вложения.
8. Расшифровка файла
Схема расшифровки файла изображена на рис. 4.
Рис. 20. Схема расшифровки файла
9. Получение списка подписей по файлу
UI компонент через «IAttachments» получает указатель на объект контроллера
«SignInfo». У контроллера вызывается метод «List», который по переданному
идентификатору редакции вложения возвращает вектор моделей «SignData»
прикрепленных подписей. Процесс синхронизации подписей такой же, как и в
случае с синхронизацией вложений – у «SignInfo» есть метод
«SetDataRefreshCallback» для подписки на событие окончания синхронизации
подписей.
10. Получение списка редакций файла
75
UI компонент через «IAttachments» получает указатель на объект контроллера
«Redaction». У контроллера вызывается метод «List», который по переданному
идентификатору вложения возвращает вектор моделей «FileInfo» редакций.
Процесс синхронизации редакций такой же, как и в случае с синхронизацией
вложений – у «Redaction» есть метод «SetDataRefreshCallback» для подписки на
событие окончания синхронизации редакций.
11. Загрузка файлов / прикрепление файлов к документу
Схема загрузки файлов и их прикрепление к документам:
Рис.21 Схема загрузки файлов через мобильное приложение
Сразу же после сохранения прикрепляемых файлов в локальную
директорию микро сервиса и создания записей с метаданными файлов в БД
микро сервиса «Attachments», у всех вложений и редакций взводится флаг
«Added» у поля «SyncState» таблиц «Attachment» и «Redaction». После того, как
пришло событие об успешной загрузки файла в облако, поле «SyncState»
переходит в состояние «Синхронизирован» (значение в нем становится равным
«0»), а метаданные вложений и редакций обновляются данными из облака.