Электронный архив - набросок проектной документации

Есть у нас проблема: куча информации лежит в экселевских таблицах, текстовых документах и т.п. С этими файлами ведется двоякая работа:
а) В один xls-файл несколько пользователей вносят информацию - маленькие кусочки, но ежедневно. В основном это ежедневная сводка для руководства. Работать с файлом по сети - бывает, Excel начинает виснуть. Да и пойди пойми, кто сейчас занял файл.
Примечание: да, знаю, что по уму это не в файле хранить надо, а в базе данных. Возражения тут следующее: руководство очень часто меняет формат этой сводки, нужная информация должна умещаться на одной-двух страницах; так что разумной автоматизации не получается - поди пойми, что в следующий раз понадобится, а что мешать будет.
б) Разные группы пользователей должны иметь разный доступ к документам, в основном быстро найти и открыть на просмотр. Рулить на уровне NTFS неудобно, к тому же если все в файлах, то имена у этих файлов как автор захочет. Неудобно, в общем.
в) Случайная порча файла - случается; быстро восстановить предыдущую копию - а она хорошо если вчерашняя, а надо бы получасовой давности.

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

1. Общие требования к ЭА

Номинальная емкость системы - 1,000,000 документов, т.е. ID это шестизначное целое число с ведущими нулями. Реальная емкость, исходя из которой рассчитываем сейчас объемы и скорости - 10,000 документов.
Система предназначена для хранения файлов, которые мы считаем бинарными - т.е. без анализа их содержимого. Реально там будут текстовые файлы (форматы txt, doc, odt, pdf, htm и т.п.), файлы электронных таблиц (xls, ods), всевозможные файлы инженерной графики и изображения (в основном отсканированные образы документов).
Быстрая работа системы требуется с текущими версиями документов, добавление нового документа/новой версии, получение одной предыдущей версии документа. Работа с более ранними версиями может быть не быстрой - это гораздо более редкое событие.


2. Хранение файлов в ЭА

Файлы хранятся в папке на сервере, точнее - по подпапкам (не более 100 файлов в папке для ускорения работы с файлом). При помещении в ЭА файл переименовывается - новое имя совпадает с его ID в ЭА с ведущими нулями, расширение остается прежним.
Версии файла нумеруются четырьмя знаками, имя файла версии имеет вид ID_VER, где ID 6 знаков, VER четыре знака. Версии файла, кроме предпоследней, могут храниться как в виде файла на сервере, так и в tar-архиве для экономии места.
Для каждого файла (ID) может быть установлен режим хранения его версий - к примеру, храним одну ежедневную версию (на конец дня), или храним все версии возраста менее недели, потом оставляем из них ежедневные версии, а по истечении месяца - только еженедельные. В заархивированном виде лучше хранить те версии, которые уже предназначены для весного хранения (или можно их разбить по разным архивным файлам).


3. ER-диаграмма ЭА




4. Функции ядра ЭА

Все функции возвращают два результата: успешно или нет; в случае успеха - запрошенное действие (описывается ниже в каждой функции), в случае неудачи - код причины неудачи.

В каждую функцию передается как один из аргументов Пользователь, от имени которого вызывается функция. Две цели: (1) проверить права, может ли данный пользователь выполнять эту функцию; (2) записать в БД имя пользователя как актора действия (там, где это требуется).

ДобавитьНовыйДокумент(Файл /поток загрузки/)
- возвращает ID файла в ЭА

ВзятьДокумент(ID файла, Режим= просмотр/редактирование)
- возвращает поток скачивания файла. Имя файла - то, что задано как пользовательское в БД, можно в комбинации с ID
- если файл взят на редактирование, то устанавливает в БД блокировку на него с указанием имени взявшего файл пользователя

ДобавитьВерсиюДокумента(ID файла, Файл /поток загрузки/)
- возвращает номер версии файла (пред. + 1)

ОсвободитьЗанятыйДокумент(ID файла)
- функцию может выполнять пользователь, взявший файл (не стал редактировать), а также пользователь со спецправами - менеджер. Пример: человек взял файл на редактирование и заболел, надо иметь возможность файл разблокировать пусть даже его работа потеряется.

ПолучитьРеквизитыДокумента(ID файла)
- возвращает список пар "реквизит/значение"

УстановитьРеквизитыДокумента(ID файла, новые реквизиты)
- функция для редактирования всяческих реквизитов файла в БД; новые реквизиты - список пар "реквизит/новое значение"

ПолучитьВерсиюФайлаПоНомеру(ID файла, номер версии)
- возвращает поток скачивания файла. Имя файла - то, что задано как пользовательское в БД, можно в комбинации с ID и номером версии

ПолучитьСписокВерсийФайла(ID файла)
- список троек "номер версии/дата версии/статус (есть ли реально)"


5. Взаимодействие с пользователями и приложениями

В основном с электронным архивом пользователь будет работать не напрямую, а через трекер - практически все документы относятся к какому-нибудь бизнес-процессу, он либо положен в 1С (тогда ID файлов храним там), либо для его автоматизации заводим экземпляр трекера с соответствующей диаграммой состояний, и храним ID файлов в инцидентах.



6. Роботы ЭА

В электронном архиве работают два робота (программы, запускающиеся по времени, раз в сутки).

Робот-архиватор раз в сутки проверяет, не обновились ли указанные в листах-шаблонах файлы (и не появились ли новые), и добавляет новую версию в электронный архив. Требуется в основном для программных файлов на макроязыке 1С (формат txt, ert), места они занимают немного, а когда срочно исправляешь ошибку, можно и забыть сохранить предыдущую версию (особо полезно, когда исправление ошибки привело к возникновению новой - понять, что не так).
Обратное действие к действиям робота - развернуть программные файлы в тех версиях, которые были на определенную дату. Это важно, если мы хотим восстановить старую архивную копию 1С - внутренний программный код сохраняется, а все внешние отчеты и программные модули надо хранить отдельно. Вот для этого робот-архиватор и нужен.

Робот-хранитель чистит и упаковывает архив. Когда экономисты делают свои сводки, то им полезно иметь версии файла после каждой правки - чтобы в случае порчи быстро откатиться назад к последней нормальной версии. Но затем хранить эти версии (десяток за день) не надо - это чисто рабочий материал. Поэтому у каждого документа в ЭА мы указываем режим хранения - какие версии сколько хранить, к примеру "вечное" хранение только для последней версии за сутки, а все другие версии этих суток удаляются. Может, не сразу - через три дня. Да и хранить их в виде файлов слишком роскошно - старые версии сжимаем в архив. Все это делает робот-хранитель.

------------------------------

Вот примерно такой первый набросок. По ходу дела буду додумывать. Хотя бы систему прав - как удобно сделать.

ER-диаграмма трекера (основные таблицы)

Это диаграмма "сущность-связь" нашего трекера. Разумеется, это логическая схема, к тому же на ней нет ничего, связанного с управлением доступом. Трекер пишется с таким расчетом, чтобы можно было под каждый бизнес-процесс заводить свой экземпляр трекера со своей диаграммой состояний. Для управления задачами IT-отдела - один экземпляр, для служебных записок отдела главного металлурга - другой, для заявок от клиентов (та основная задача, ради чего все затевается) - третий. Разумеется, пользователь должен входить в систему один раз и там быть сразу авторизован во всех системах, в которых зарегистрирован. Поэтому мы вынесли систему авторизации вовне.



В общем, с конца октября трекер у нас работает для управления задачами отдела IT, уже более-менее нормально. Чего не сделано из того, что есть на первой ER-диаграмме:

1. Механизм влияющих инцидентов. Управлять задачами, четко указывая, что "задача1 должна быть сделана раньше задачи2" - почти никогда такого нет; скорее "нельзя начинать делать задачу2, не начав делать задачу1" - почти наверняка эта самая зависимость касается только части задачи1, можно ее начать, сделать только то, что необходимо для задачи2, и сначала завершить задачу2, не завершая задачу1. То есть связь не типа "конец-начало", а более гибкая. Расставив зависимости, мы можем посмотреть, какие задачи надо взять в работу, чтобы можно было выполнить эту, нужную. Пока не сделано.

2. Подчиненные инциденты. Иногда одна задача дробится на несколько: к примеру, в заявке заказчика есть несколько деталей, сначала заявка рассматривается коммерческим директором и директором по производству целиком (они имеют право решить, что она нам не интересна), а потом доходит до отдела главного металлурга, где по деталям раздается нескольким технологам, дальше все движение идет по этим подзадачам. И в самом конце эти подзадачи опять собираются вместе и заказчику высылается протокол согласования цены по его заявке. Вот этот механизм - шла одна задача, потом разделилась, а потом снова собралась - пока не реализован. Идея такая: когда задача разделяется, то старая задача замирает без движения в некотором состоянии, и не может двинуться, пока все ее подчиненные задачи не придут в финальные состояния. При этом финальные состояния могут быть как положительными (технология оценена, есть калькуляция на деталь), так и отрицательными (данную деталь мы не можем произвести). Для этого предназначена ссылка "рамочный инцидент", но основная работа - в реализации логики движения. Пока не сделано.

3. Основной исполнитель. Для задач отдела IT ясно, что основное состояние - "в работе". Исполнитель в этом состоянии - тот, кто на самом деле и выполнил эту задачу. Для движения заявок - ясно, что это технолог (при этом менеджер коммерческого отдела, притащивший эту заявку, уже виден как автор задачи). В общем, ловить этого исполнителя и потом анализировать по нему статистику - полезно, но не слишком критично. Пока не сделано.

4. Прикрепленные файлы. Если к трекеру присобачить еще систему управления версиями (электронный архив), то получится хороший инструмент для автоматизации документооборота. Если все файлы хранятся в едином архиве, то в разных экземплярах трекера для разных бизнес-процессов рисуем свои диаграммы состояний - и вот оно, счастье! Это не только не сделано, это я только проектирую. Скорее всего, следующий пост будет об этом.