Архитектура серверной части системы документооборота.

,

АННОТАЦИЯ:

Описана архитектура серверной части системы документооборота (ДОБР), включая информационную модель системы и хранимые процедуры. Приводятся примеры сценариев документооборота. Описывается модель управления версиями документов, поручений и других типов объектов. Вводится понятие «инсайта» («insight») в значении «углубленное представление, понимание», в отличие от поверхностного «view».

2  Введение

Система документооборота ДОБР реализована в архитектуре клиент-сервер, с использованием штатных средств разработки Oracle Enterprise Edition версий 7 и 8. Клиентская часть системы ДОБР разработана Б. Романовым и другими, на языке С++ с «встроенными» фрагментами на языке PL/SQL. В настоящей статье рассматривается только серверная часть системы ДОБР, включая информационную модель и хранимые процедуры.

Модель управления версиями документов, поручений и других типов объектов, применяемая в системе ДОБР, использует подход, изложенный в статье [1], где документ рассматривается как система представлений, состоящих из фрагментов. В нашей модели фрагментами документа являются части, которые включают поручения и файлы, как объясняется ниже в п. Ошибка! Источник ссылки не найден. «Ошибка! Источник ссылки не найден.». Другие подходы к управлению версиями в системах коллективного создания документов описаны в обзорной статье [2].

3  Информационная модель системы ДОБР

3.1  Особенности

Информационная модель системы ДОБР обладает следующими отличительными свойствами:

НЕ нашли? Не то? Что вы ищете?

·  Множественность взглядов пользователей на документ.

·  Углубленный взгляд пользователя на состояние документа.

3.1.1  Множественность взглядов пользователей на документ

В системе ДОБР документ может по-разному предъявляться различным пользователям. Документ в системе ДОБР имеется в нескольких версиях и состоит из объектов, которые могут иметь версии. Множественность взглядов пользователей на документ в системе ДОБР возникает благодаря сочетанию следующих факторов:

·  Версия опубликованного объекта фиксируется и больше не изменяется никогда. При одновременном редактировании документа несколькими пользователями, каждый пользователь исправляет только свою версию объектов, включенных в состав документа. Затем изменения рассылаются другим пользователям, при этом все объекты публикуются. При дальнейшем редактировании каждым автором создаются новые версии объектов (п. 2.10 «Версии объектов»).

·  При обмене сообщениями происходит слияние изменений с образованием новой версии документа (п. 2.13 «Циркуляция сообщений в системе ДОБР», п. 2.14 «Слияние версий документа»).

·  Механизм прав доступа ограничивает видимость объектов, включенных в состав документа для пользователя, в зависимости от участия пользователя в прохождении данного документа через систему документооборота. (п. 2.10.2 «Версии поручений», п. 2.11 «Права доступа»).

3.1.2  Углубленный взгляд пользователя на состояние документа

Состояние документа в процессе документооборота включает не одно, а несколько событий: регистрацию документа, назначение поручений, изменение условий выполнения, отчеты исполнителей и другие сообщения, которыми обмениваются участники. Пользователи системы автоматизации документооборота нуждаются в поддержке углубленного взгляда на состояние документа с учетом всех происходящих событий, в рамках прав доступа каждого пользователя.

Углубленный взгляд пользователя на состояние документа в системе ДОБР поддержан единой иерархической историей происхождения для различных типов объектов, которая отображается с учетом прав доступа пользователя. (п. 2.15 «Инсайты»).

3.2  История документа

В этом пункте описаны два примерных сценария документооборота, с целью дать представление о предметной области. Действующие лица следующие:

·  Регистратор Валуева. Регистрирует документы и поручения.

·  Контролер Фролова. Контролирует выполнение документов, зарегистри­рованных Валуевой.

·  Чиновник Лачуга. Исполняет поручения и сам дает задания подчиненным.

·  Чиновник Кошкин. Подчиненный Лачуги.

3.2.1  Сценарий А

Валуева регистрирует входящий документ А1. Содержание документа: запрос депутата Госдумы о ходе выполнения постановления правительства. Валуева регистрирует поручение Лачуге, подписанное заместителем министра: рассмотреть и дать ответ. Документ вместе с поручением отсылается Лачуге.

Лачуга готовит ответ депутату и регистрирует его. Возникает исходящий документ А2.

Лачуга составляет отчет контролеру об исполнении поручения и прикладывает к отчету документ А2. Отчет отсылается контролеру Фроловой.

Фролова отмечает выполнение поручения Лачугой и снимает документ А1 с контроля. Лачуге отсылается сообщение о снятии с контроля.

3.2.2  Сценарий В

Валуева регистрирует входящий документ В1 такого же содержания и поручение Лачуге. Документ вместе с поручением отсылается Лачуге.

Лачуга создает свою версию поручения и поручает Кошкину подготовить ответ. Кошкину отсылается документ, в котором он видит свое поручение.

Кошкин готовит ответ депутату и регистрирует его. Возникает документ В2.

Кошкин составляет отчет Лачуге об исполнении поручения и прикладывает к отчету документ В2. Отчет отсылается Лачуге.

Лачуга получает отчет Кошкина. В нем присутствуют два поручения: исходное поручение самому Лачуге и выполненное поручение Лачуги Кошкину. Лачуга отмечает выполнение поручения Кошкиным и отправляет отчет контролеру Фроловой. Кошкину отправляется сообщение о выполнении поручения.

Фролова получает отчет Лачуги. В нем она видит только поручение Лачуге, однако не видит поручения Лачуги Кошкину.

Фролова отмечает выполнение поручения Лачугой и снимает документ В1 с контроля. Лачуге отсылается сообщение о снятии с контроля.

3.3  Объектный подход

Информационная модель системы ДОБР включает следующие признаки объектного подхода:

·  Уникальный код объекта (п.2.4)

·  Наследование базовых свойств для всех типов объектов (п.2.5)

·  Версии объектов (п. 2.10 «Версии объектов»).

·  Права доступа к объекту (2.11)

3.4  Уникальный код объекта

Информационная модель системы ДОБР включает генератор кодов объектов. Генератор кодов объектов функционирует при создании новых объектов. Каждому новому объекту присваивается следующий свободный код объекта и счетчик использованных кодов объектов увеличивается.

Генератор кодов объектов присваивает объектам коды через 100. Младшие две цифры кода объекта назначаются в зависимости от типа объекта, так чтобы по коду объекта можно было удобно определить тип объекта. Типы объектов описаны ниже в п. 2.8.

Каждому типу объекта соответствует некоторая таблица Т в базе данных системы ДОБР. Код объекта является первичным ключом таблицы Т. В следующем пункте объясняется, что код объекта является также первичным ключом таблицы «События», где хранятся базовые свойства объектов. Поэтому каждому экземпляру объекта в базе данных системы ДОБР соответствуют две записи: запись в таблице Т и запись в таблице «События».

3.5  Базовые свойства объекта

Информационная модель системы ДОБР включает наследование базовых свойств для всех типов объектов. Базовые свойства для всех типов объектов хранятся в таблице «События», первичным ключом для которой служит код объекта.

Таблица 1. Базовые свойства объектов в таблице «События».

Свойство

Тип

Описание

1

Код

Number

Код объекта (первичный ключ)

2

Тип

Number

Тип события. См. Таблица 2. Типы событий.»

3

Автор

Number

Автор события

4

Подпись

Number

Кто подписал (код субъекта)

5

Дата создания

Date

Дата создания события

6

Дата изменения

Date

Дата изменения

7

Системный счетчик

Number

Значение генератора "Коды событий" на момент последнего изменения данного объекта

8

Дата публикации

Date

Дата публикации

9

Первичная версия

Number

Самая первая версия объекта. Это свойство объединяет все версии объекта.

10

Предсобытие

Number

Предыдущее событие

11

Предыстория

Varchar2(2000)

Предыстория событий

12

Доп текст

Varchar2(2000)

Дополнительный текст (не индексируется)

13

Отладка

Varchar2(2000)

Отладочная информация

14

Гриф

Number

Гриф секретности

15

Неактуальность

Number

Сдано в архив, уволен и т. п.

16

Cостояние

Number

Состояние ожидания и т. п.

17

Архив фонд

Number

Номер фонда архивного хранения

18

Архив опись

Number

Номер описи архивного хранения

19

Архив дело

Number

Номер дела архивного хранения

20

Основной документ

Number

Для кластеризации записей в БД ДОБР, относящихся к одному документу

21

Терминал

Varchar2(30)

С какого терминала произведено последнее изменение

Для управления версиями используются следующие базовые свойства объектов:

·  Первичная версия. Это свойство группирует все версии одного объекта.

·  Предыстория. Это свойство включает объект в единую иерархическую историю происхождения различных типов объектов.

·  Дата публикации. Это свойство фиксирует версию объекта от дальнейшего изменения автором после пересылки объекта другому пользователю. Объекты с непустой датой публикации называются «опубликованными».

3.6  Типы событий

Система ДОБР различает следующие содержательные типы событий:

Таблица 2. Типы событий.

Описание

Описание

1

Регистрация документа

11

Конкретизация

2

Резолюция

12

Перевод в состояние ожидания

3

Виза

13

Возобновление исполнения

4

Подпись

14

Замена отв. исполнителя

5

Постановка на контроль

15

Добавление исполнителей

6

Периодическое поручение

16

Отчет исполнителя

7

Снятие документа с контроля

17

Напоминание исполнителю

8

Документ просрочен

18

Администратор изменил словари или параметры системы

9

Отсрочка исполнения

19

Выполнение поручения

10

Сокращение срока

20

Поручение просрочено

3.7  Структура документа

Документ в системе ДОБР включает следующие компоненты:

·  Регистрационную карточку

·  Поручения

·  Дополнительные файлы

Новые документы создаются в системе ДОБР на рабочем месте регистратора. При этом заполняется регистрационная карточка документа. Регистрационные карточки хранятся в таблице «Документ». Остальные компоненты включаются в состав документа через таблицу «Части».

При регистрации документа могут быть созданы одно или несколько поручений. Для каждого поручения регистратором создается запись в контрольной карточке. Новая запись в контрольной карточке создается при каждом изменении условий поручения и при выполнении поручения. Каждой записи в контрольной карточке технически соответствуют два объекта: «Часть» и «Поручение».

К документу могут присоединены текстовые или графические файлы, которые также хранятся в БД ДОБР. Файлы также присоединяются к документу через таблицу «Части».

3.8  Типы объектов

В этом разделе описываются типы объектов в информационной модели системы ДОБР.

·  Документ. Объект типа «Документ» в системе ДОБР содержит регистрационную информацию: регистраци­онный номер, вид документа и другие. В документе всегда имеется одна регистрационная карточка.

·  Часть. Объект типа «Часть» в системе ДОБР отвечает записи в контрольной карточке и может содержать код поручения, текстовый или графический файл. Документ может включать одну или несколько частей.

·  Поручение. Объект типа «Поручение» в системе ДОБР содержит свойства поручения: ответственный исполнитель, файл с текстом задания, плановый срок выполнения, фактический срок выполнения и другие.

·  Файл. Объект типа «Файл» в системе ДОБР содержит либо текст различного назначения: содержание документа, задания, тексты сообщений и другие, либо графический образ страницы документа. Текстовые файлы индексируются поисковой подсистемой системы ДОБР в фоновом режиме. Поисковый индекс файлов хранится в таблице «Слова».

·  Субъект. Объекты типа «Субъект» (для краткости просто «субъект») в системе ДОБР соответствуют людям: пользователям и корреспондентам, а также группам: структурным подразделениям министерства и организациям, включенным в адресную книгу. Свойства субъектов следующие: фамилия, имя и отчество, имя, под которым пользователь подключается к системе, для людей; название для групп и подразделений и др. Принадлежность субъектов и подгрупп группам отражается с помощью связей (см. п.Ошибка! Источник ссылки не найден. «Ошибка! Источник ссылки не найден.»). Каждому субъекту в процессе документооборота могут быть назначены права доступа на документы и поручения, как объясняется ниже в п.2.11 «Права доступа».

·  Сообщение. Объект типа «Сообщение» в системе ДОБР соответствует обычному почтовому сообщению внутри системы ДОБР. Сообщение может иметь текст, список адресатов и список вложенных файлов и документов. Система ДОБР различает системные и пользовательские сообщения, как объясняется ниже в п. 2.13«Циркуляция сообщений в системе ДОБР».

·  Папка. Объект типа «Папка» в системе ДОБР соответствует папке почтовой службы, а также папке документооборота. Пользователи снабжаются личными папками. Типы папок следующие: входящие, отправленные, на контроле и исполненные. Использование папок описывается в документации АРМ пользователя системы ДОБР. Система ДОБР поддерживает общий доступ к папкам с помощью механизма прав доступа ( п. 2.11 «Права доступа»).

3.9  Дата изменения папок и субъектов

Дата изменения папок и субъектов используется для поддержки синхронизации клиентской и серверной частей системы ДОБР. При каждом изменении оглавления папки дата изменения объекта «Папка» изменяется серверной частью системы ДОБР. Оглавление папки хранится в виде связей между элементами папки и папкой (п. 2.12 «Связи объектов»). С помощью слежения за датой изменения папки клиентская часть системы ДОБР определяет, когда нужно перезагрузить оглавление папки в локальный кэш.

Система ДОБР поддерживает общий доступ к папкам. Администратором системы ДОБР могут быть выданы права доступа на любую папку любому субъекту. Дата изменения субъекта изменяется при изменении прав доступа субъекта к чужим папкам. С помощью слежения за датой изменения субъекта клиентская часть системы ДОБР определяет, когда нужно перезагрузить список папок субъекта в локальный кэш.

3.10  Версии объектов

Информационная модель системы ДОБР поддерживает множественные версии объектов. Новая версия создается при редактировании объекта каждым новым пользователем. Новая версия создается также при редактировании объекта тем же пользователем, после того как старая версия объекта стала доступной другому пользователю или пользователям, в процессе документооборота.

Версии поддерживаются для следующих типов объектов:

·  Версии документов и регистрационных карточек

·  Версии поручений

·  Версии субъектов

3.10.1  Версии документов и регистрационных карточек

Регистрационные карточки хранятся в таблице «Документы» и могут иметь версии. Новые версии регистрационных карточек возникают при внесении изменений в регистрационную карточку после регистрации документа. В каждой версии документа имеется одна версия регистрационной карточки.

В п. 2.13.1 объясняется, что при регистрации документа версия документа публикуется и рассылается заинтересованным пользователям – участникам документооборота.

В п. 2.14 объясняется, что при пересылке документа по почте внутри системы ДОБР, у получателя может образоваться новая версия документа. При этом также создается новая версия регистрационной карточки.

Подсистема поиска ДОБР всегда показывает пользователю самую свежую доступную версию документа. Это может быть либо собственная версия пользователя, еще не опубликованная и не отправленная другим пользователям, либо последняя из опубликованных версий документа, ставших доступными пользователю в процессе документооборота. Права доступа к объектам обсуждаются в п. 2.11.

Процесс образования новых версий документа прекращается системой после снятия с контроля. С этого момента никакая версия документа не может быть открыта для редактирования, а дальнейшие пересылки документа не приводят к образованию новых версий. С получением уведомления о снятии с контроля, у каждого получателя остается одна и та же последняя версия документа.

Цепочка версий документа от регистрации до снятия с контроля включает все пересылки документа между участниками. Старые версии документа удаляются механизмом сборки мусора (п. 2.16 «Сборка мусора»).

3.10.2  Версии поручений

К созданию новых версий поручений в системе ДОБР приводят следующие типы событий:

·  Постановка на контроль

·  Изменение задания, срока или исполнителей поручения

·  Выполнение поручения. При этом проставляется фактическая дата выполнения.

Цепочка версий поручения отражает цепочку событий от назначения до выполнения. В каждую версию документа входит по одной версии от каждого поручения, поэтому версия документа отражает состояние выполнения всех поручений в некоторый момент времени.

Поручения не удаляются механизмом сборки мусора никогда и могут быть использованы для статистического анализа и итоговых отчетов.

3.10.3  Версии субъектов

Версии субъектов создаются при изменении администратором системы ДОБР свойств или связей субъектов, включая перемещение из группы в группу. Старые версии хранятся для старых документов, но не участвуют в дальнейшем документообороте.

3.11  Права доступа

Система ДОБР поддерживает права доступа на уровне версии объекта, включая права отдельных лиц и групп. Различные версии объекта могут быть доступны различным пользователям. Типы прав доступа следующие: чтение, изменение, удаление. Реализация прав доступа использует списки разрешений, подобные применяемым в Windows NT (access control lists, ACL). Списки разрешений хранятся в таблице «Права». Элемент списка включает права одного субъекта на один объект.

При проверке прав доступа сперва составляется список групп, в которые входит пользователь. Затем просматривается список разрешений для объекта. Если обнаруживается разрешение для данного пользователя или группы, в которую он входит, то права доступа предоставляются.

3.12  Связи объектов

В таблице «Связи» хранятся связи между объектами. Примеры связей между объектами включают следующие: оглавление папки, состав подразделения, исполнители поручения. Запись таблицы «Связи» включает два кода объекта и тип связи. Предполагается, что между двумя любыми объектами возможна только одна связь.

Диапазон типов связей от 1000 и выше отведен для должностей. Один субъект может занимать несколько должностей в различных подразделениях и организациях. Каждой должности данного субъекта отвечает одна связь с подразделением или организацией.

3.13  Циркуляция сообщений в системе ДОБР

Внутри системы ДОБР циркулируют системные и пользовательские сообщения. Системные сообщения генерируются при регистрации документа, при назначении поручений, при внесении изменений в документ и при изменении документа. К системным сообщениям относятся также отчеты пользователей об исполнении поручений и напоминания.

Пользовательские сообщения создаются участниками документооборота как в обычной почтовой системе и не регламентируются системой ДОБР.

3.13.1  Системные сообщения

По окончании регистрации документа в системе ДОБР автоматически выполняется рассылка сообщений. При этом для всех частей документа проставляется дата публикации.

Если возникает необходимость после регистрации документа внести изменения в регистрационную карточку, то регистратор «открывает документ для редактирования» и вносит изменения в регистрационную карточку. Возникает новая версия документа, которая должна быть разослана всем пользователям, у которых имеется данный документ, для того чтобы им стали видны изменения в регистрационной карточке.

По окончании регистрации система ДОБР рассылает сообщения заинтересованным пользователям. Пользователь может иметь права на документ, но не интересоваться текущим состоянием документа. Если документ не лежит у пользователя в папке, то ему не будут приходить сообщения об изменении регистрационной карточки.

3.13.2  Пользовательские сообщения

Для пользовательских сообщений используются папки «Входящие» и «Отправленные». В системе ДОБР поддерживается внутренняя почтовая служба. Список адресатов сообщения хранится в таблице «Адресаты», а список вложений сообщения хранится в таблице «Вложения». Пользователи могут вкладывать в сообщение документы и файлы.

3.13.3  Напоминания

Каждое утро система ДОБР генерирует напоминания участникам документооборота. Напоминания генерируются по экспоненциальной схеме: за 2/3 и 1/3 до истечения срока выполнения поручения, затем за 2/9 и 1/9 срока до истечения срока и т. д., пока частота напоминаний не достигнет ежедневной, затем за день до истечения срока, затем в день истечения срока, затем на следующий день, затем через 3 и 6 дней после истечения планового срока выполнения поручения, затем через 9 и 18 дней и так далее по затухающей.

3.13.4  Бизнес-логика документооборота

Документооборот министерства включает правила бизнес логики, определяющие права доступа участников документооборота к документам и поручениям. Правила бизнес логики влияют на адресацию сообщений в системе ДОБР. Эти правила инкорпорированы в серверную часть системы ДОБР, но здесь подробно не рассматриваются.

3.14  Слияние версий документа

Слияние версий документа происходит при получении системного сообщения с изменениями в документе, копия которого хранится в папке у данного пользователя. Происходит слияние обеих версий документа: присланной и старой. При этом образуется новая версия документа. Слияние не происходит, если документ снят с контроля.

За основу при слиянии берется более поздняя версия регистрационной карточки. Затем сливаются списки частей, содержащих поручения и файлы в обеих версиях документа. При наличии двух версий одного поручения или текста из них выбирается одна версия с более поздней датой изменения.

3.15  Инсайты

Мы используем термин «Инсайт» («insight») в значении «углубленное представление, понимание», в отличие от поверхностного «view». Индивидуальные «взгляды» пользователей на документ поддерживаются в таблице «Инсайты». Каждый инсайт представляет взгляд одного пользователя на один документ и состоит из нескольких строк. Каждая строка инсайта представляет одно событие: регистрацию документа, назначение поручений, изменение условий выполнения, отчеты исполнителей и другие сообщения, которыми обмениваются участники. События фильтруются с учетом прав пользователя. Строкам инсайта приписан уровень в соответствии с иерархией событий. На первом уровне находится документ, под ним могут быть поручения, под ними могут быть изменения условий поручения и т. д.

Запись таблицы «Инсайты» содержит следующие поля:

·  Владелец. Владелец инсайта – пользователь.

·  Объект. Объект инсайта – документ.

·  Строка. Номер строки инсайта.

·  Уровень строки. Уровень строки инсайта.

·  Код события. Код события, про которое данная строка.

·  Тип события. Тип этого события.

·  Дата события. Дата события.

·  Текст. Текст документа, поручения, сообщения.

Текст строки инсайта компилируется из содержания данного события: содержание документа, задание для поручения, перенос сроков, текст сообщения и т. д.

Клиентская часть системы ДОБР может отображать инсайт под документом, в виде списка или в виде лесенки, при показе списков документов и сообщений.

Расчет инсайтов производится системой ДОБР в фоновом режиме, для всех документов, которые лежат в папках у данного пользователя. См. п. 3.3 «Системные процессы».

3.16  Сборка мусора

Сборка мусора включает удаление потерянных сообщений и удаление старых версий исполненных документов. Потерянные сообщения возникают при удалении сообщений пользователем. Технически при этом сообщения не удаляется, а хранятся до сборки мусора.

Старые версии исполненных документов удаляются вместе с системными сообщениями. Системные сообщения по документу, кроме снятия с контроля и отчетов, удаляются через день. Сообщения о снятии с контроля и отчеты удаляются через 2 недели.

Поручения не удаляются механизмом сборки мусора никогда и могут быть использованы для статистического анализа и итоговых отчетов.

Сборка мусора функционирует в системных процессах, выполняемых ежевечерне и ежечасно. См. п. 3.3 «Системные процессы».

4  Хранимые процедуры

Хранимые процедуры системы ДОБР включают триггеры, модули на языке PL/SQL, а также системные процессы.

4.1  Триггеры

Триггеры представляют собой хранимые процедуры на языке PL/SQL, которые вызываются сервером БД автоматически при создании или обновлении записей в таблицах базы данных. В системе ДОБР триггеры поддерживают генерацию внутренних кодов объектов БД и защиту доступа к объектам БД.

4.2  Модули

Модули представляют собой хранимые процедуры на языке PL/SQL, которые исполняются на сервере БД, но могут вызываться как сервером базы данных, так и программным обеспечением клиентского рабочего места. В последнем случае вызов серверного модуля выполняется из встроенного в С++ фрагмента на языке PL/SQL, при помощи механизма удаленного вызова процедур СУБД Oracle.

Таблица 3. Перечень серверных модулей.

Модуль

Назначение

1

PkAccess

Права доступа пользователей к объектам в базе данных

2

PkAdmin

Поддержка АРМ администратора

3

PkAdmin2

Поддержка АРМ администратора

4

PkTasks

Контроль исполнения поручений

5

PkDebug

Отладочные функции

6

PkDocs

Манипулирование документами

7

PkEvents

Управление версиями объектов

8

PkFiles

Манипулирование файлами

9

PkFolders

Манипулирование папками

10

PkGlobals

Глобальные определения

11

PkIns

Инсайты – индивидуальные взгляды пользователей на документ

12

PkIdx

Индексирование файлов

13

PkJobs

Периодические задания, выполняющиеся в системе автоматически

14

PkOff

Процедуры снятия с контроля для документов и поручений

15

PkParams

Параметры системы, хранимые в базе данных

16

PkPurge

Сборка мусора

17

PkReceive

Процедуры приема сообщений

18

PkRegis

Регистрация документов

19

PkRegnums

Поддержка регистрационных номеров для потоков документов

20

PkRemind

Генерация напоминаний

21

PkRoles

Признаки, определяющие участие пользователя в поручении, документе, должность в подразделении.

22

PkRoutes

Поддержка оповещений о текущем состоянии документов

23

PkSend

Создание всех видов сообщений

24

PkSearch

Поиск документов в системе по запросу пользователя

25

PkTrans

Транспортировка сообщений внутри системы

26

PkUsers

Пользователи и группы пользователей

27

PkViews

Извлечение информации из БД в локальный кэш клиента системы ДОБР

28

PkVocs

Поддержка словарей

4.3  Системные процессы

Системные процессы представляют собой процедуры на языке PL/SQL, которые автоматически запускаются сервером БД ДОБР через установленные интервалы времени.

В системе ДОБР установлены следующие системные процессы:

Название

Периодичность

Назначение

JobMinute

Каждую минуту

1.  Расчет инсайтов: 10 штук.

JobHour

Каждый час

Расчет инсайтов: 100 штук.

Чистка исполненных документов: 10 штук.

JobMorning

Каждое утро

Генерация напоминаний.

JobEvening

Каждый вечер

Чистка исполненных документов: 100 штук.

Сборка мусора.

5  Приложение

Таблица 4. Перечень таблиц БД ДОБР.

Таблица

Примечание

1

Документы

Регистрационная карточка документа

2

Части

Части документов: поручения и файлы

3

Поручения

Задание, срок исполнения и другая информация о поручении

4

События

Информация о версии для документов, поручений и других объектов.

5

Связи

Связи между объектами

6

Инсайты

Индивидуальные "взгляды" пользователей на документы

7

Слова

Поисковый индекс текстов

8

Файлы

Тексты и графические образы

9

Субъекты

Лица и группы лиц; структурные подразделения и организации

10

Сообщения

Системные и пользовательские сообщения

11

Вложения

Присоединенные к сообщению документы и файлы

12

Доставка

Информация об адресации и доставке сообщений

13

Папки

Папки для документов и сообщений

14

Права

Права доступа

15

Параметры

Параметры настройки системы ДОБР

6  Литература

1.  , Соловьёв как система представлений. Статья в настоящем сборнике.

2.  Плискин версиями в системах коллективного создания документов // Сборник трудов ИСА РАН «Развитие безбумажной технологии в организационных системах»/Под редакцией и М.: Эдиториал УРСС, 1999. С. 214-251.