Pull to refresh
0

Приложения в системе электронного документооборота. Часть 2: Компоненты приложения – Документ. Логическая структура

Reading time 7 min
Views 8.1K
Несмотря на кажущуюся очевидность утверждения «главный компонент приложения на базе СЭД — документ, а то, что оно автоматизирует – его «оборот», на практике оказывается, что под документом в приложениях могут иметься в виду самые различные сущности. Зависит это от типа документа и характера его «оборота», т.е. жизненного цикла обработки. Docsvision обеспечивает механизмы для реализации таких объектов. Связано это с тем, что даже для самых типовых приложений СЭД (например, для автоматизации задач классического делопроизводства) нам было необходимо моделировать в системе документ, который описывается очень сложной структурой данных и сложным жизненным циклом. Возможность моделировать такие сложные сущности как документ в делопроизводстве и позволила нам приобрести достаточную универсальность в реализации приложений для обработки документов различной природы. Держа в голове соображения, высказанные в предыдущей статье, попробуем описать модель сущности, которую мы называем словом «документ».


Информация в документе


Документ – прежде всего, носитель информации. Какая информация может содержаться в документе СЭД?

Неструктурированная информация

– разного рода файлы. При этом реальный документ в приложении СЭД может содержать:
  • один файл
  • набор версий файла (хранящих историю его изменения)
  • несколько файлов одного или разных форматов (например, договор и приложения), каждый из которых может содержать историю версий
  • более сложные структуры файлов, включающие иерархическую упорядоченность данных, например, в задачах технического документооборота (описание структуры изделия)

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

Структурированная информация

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

Итак, из чего состоит структурированная часть документа.
  • набор атрибутов стандартных типов (строка, число, дата, время)
  • атрибуты перечисления (простые справочники) – для различных типов документов атрибуты могут быть заполнены предопределенными значениями различных типов (вид договора, уровень доступа и пр.).
  • атрибуты, заполняемые из справочников, в отличие от перечислений, — это могут быть сложноорганизованные справочники (например, сотрудников, контрагентов, номенклатуры дел или товарных позиций и пр.). С одной записью справочника может быть связано несколько атрибутов документа. Например, для конкретного контрагента в документе могут сохранятся такие атрибуты как ФИО, юр. адрес, телефон и пр. В зависимости от способа обработки документа справочное поле может сохранять статическое значение выбранного элемента — справочника или ссылку, которая будет восстанавливать значение при каждом открытии документа, а, возможно, и то и другое.
  • атрибуты, специфичные для конкретной системы обработки документов. Так, например, для Docsvision — это такие атрибуты как ссылка на связанный документ, категория документа, ссылка на папку, в которой хранятся документы, номер документа, ссылка на задание, которое создано по документу и пр. Заполнение подобных полей требует определённой логики обработки в зависимости от типа атрибута.

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

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

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

Информация о достоверности – специальный вид служебной информации, с помощью которой подтверждается подлинность авторства и неизменности документа. Для этого, как правило, используются механизмы электронной подписи с использованием сертификатов. Иногда могут использоваться и менее дорогостоящие механизмы, так, например, в системе Docsvision реализован механизм «простой подписи», не требующий инфраструктуры PKI. Подписываться могут файлы документов и отдельные атрибуты структурированных данных, также в подпись может включаться информация о совершении операций в отношении подписываемых данных.

Системная Информация – используется приложением для выполнения различных сервисных функций и для реализации функций приложений, скрытых от глаз пользователя. К такой информации в системе Docsvision относятся:
  • Время последнего изменения данных документа
  • Информация о правах доступа к документу
  • Наличие блокировки документа или отдельных файлов (Check-in/check-out контроль)
  • Этап жизненного цикла обработки документа (состояние документа)

Как видим, документ в системе документооборота представляет собой сложный информационный объект.

В Docsvision есть несколько возможностей конструировать информационную структуру и визуальный интерфейс формы документов. Низкоуровневый визуальный инструмент Менеджер карточек (CardEditor) позволяет создавать новые типы документов, описывать их информационную структуру и определять ограничение на значения полей. При использовании данного инструмента программный компонент, реализующий интерфейс документа, разрабатывается на любом языке программирования с использованием API платформы Docsvision.

Рисунок 1. Низкоуровневый инструмент CardEditor позволяет описывать информационную структуру документов.

Более высокоуровневый документ – конструктор карточек — позволяет формировать и информационную структуру, и внешний интерфейс определенного вида* документа. Содержит набор элементов управления как общего назначения, так и специализированных. Конструктор карточек позволяет также подключать различные программные обработчики (скрипты) к различным операциям, которые выполняет пользователь, и событиям.
*
Тип – это низкоуровневый объект, который содержит в себе описание структуры данных (схему)
Например, в Docsvision изначально поставляются типы карточек Документ и Задание.
Вид – это разновидность карточки определенного типа. Настраивается при помощи справочников и конструкторов.



Рисунок 2. Высокоуровневый инструмент «Конструктор карточек» позволяет описывать информационную структуру документов и ее интерфейс.

Например, в Docsvision поставляются для типа Документ виды Входящий, Исходящий и т.д.
Для одного документа могут быть сконструированы несколько интерфейсов для его обработки различными пользователи на различных стадиях его жизненного цикла.

Жизненный цикл документа


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

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

В системе Docsvision имеется отдельный конструктор, позволяющий описывать жизненный цикл документа и операции, доступные на каждом этапе жизненного цикла.

Рисунок 3. Инструмент «Конструктор состояний» позволяет описывать жизненный цикл документа.

Замечание! Жизненный цикл документа описывает не процесс его обработки, а изменение документа в процессе его обработки. Обычно в ECM/BPM-системах реализуются две подсистемы – управления жизненным циклом документов (Life Cycle) и бизнес-процессами их обработки (Workflow).

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


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

Однако большое количество сценариев обработки бизнес-логики документа невозможно заранее предугадать. Для их реализации документ Docsvision поддерживает возможность программных расширений. Для этого можно использовать язык #C и специализированное API для доступа и управления данными документа. Программа обработки может быть связана с любым событием, происходящим с документом – его открытием, модификацией поля или файла.

Рисунок 4. Конструктор карточек позволяет создавать различные программные сценарии для реализации расширенной логики обработки документа.

Особая группа логики обработки информации в документе связана с синхронизацией данных из полей содержимого файла (например, ячейки Excel или поля Word) документа и его атрибутами. Для этого в Docsvision реализован специальный инструмент разметки офисных документов.

В следующем разделе мы расскажем про средства оптимизации интерфейса документа для конкретного сценария использования и ролевой модели Docsvision.
Tags:
Hubs:
-1
Comments 0
Comments Leave a comment

Articles

Information

Website
www.docsvision.com
Registered
Founded
Employees
51–100 employees
Location
Россия