какую структуру имеют папки в docsvision

Какую структуру имеют папки в docsvision

Папки DocsVision аналогичны папкам Проводника Microsoft Windows и выполняют практически такую же функцию: они предназначены для упорядоченного хранения информации, представленной в виде карточек (в отличие от Проводника, где вся информация представлена в виде файлов).

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

Папки, находящиеся внутри какой-либо другой папки, называют дочерними, вложенными или подпапками. Папка, содержащая внутри дочерние папки, является для них родительской. На наличие вложенных папок указывает знак «+», расположенный рядом с названием папки (рис. 3.1). Нажав на этот знак, можно просмотреть дерево дочерних папок, который при этом преобразуется в знак «–», позволяющий произвести обратную операцию — свернуть дерево папок.

Рис. 3.1. Дерево папок

В DocsVision предусмотрены следующие типы папок:

Подробное описание всех типов папок приводится в следующих разделах Руководства.

Администратор (или пользователь с достаточными правами) может изменять параметры и настройки пользовательских папок: названия, типы карточек, которые могут находиться в папке, права доступа пользователей к содержимому папки и т. д.

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

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

Рис. 3.2. Дерево папок пользователя, не являющегося администратором

Источник

Что такое платформа Docsvision и наши четыре принципа её разработки

Мы, разработчики Docsvision, называем этот продукт платформой. Именно платформой, на базе которой можно создавать различные проектные решения.

Чтобы эти решения было удобнее и быстрее создавать, а в дальнейшем и изменять, для платформы Docsvision мы сделали различные инструменты (конструкторы, модули, шлюзы), которые позволяют за счет настройки смоделировать на платформе решение под конкретного заказчика, с учетом его требований.

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

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

И такая четырехслойная структура была нами выбрана не случайно. При ее проектировании мы сформулировали для себя четыре принципа, на которые решили опираться при разработке последней версии Docsvision:

Принцип №1: Открытость.

Платформа Docsvision должна быть открыта для разработки на ней.

Существует ряд публичных API и интерфейсов, при помощи которых можно модифицировать клиентскую часть Docsvision, причем для этого можно использовать как широко распространённые современные языки программирования (C#, VB.NET), так и популярные в прошлом Visual Basic 6.0 и C++.

Более детальнее про архитектуру платформы Docsvision (в том числе про ядро, объектную модель, системные модули, «движок» обработки процессов и т.д.) мы расскажем в нашем одном из наших следующих постов.

Принцип №2: Гибкость.

В платформе Docsvision все должно настраиваться «под себя», и должны быть инструменты, позволяющие делать это без программирования.

Для этого в последней версии Docsvision мы разработали целых десять конструкторов:

Конструктор процессов.

Конструктор ролей.

Все эти конструкторы нашим партнерам-интеграторам мы предоставляем бесплатно, чтобы они могли создавать различные проектные решения для своих заказчиков. Эксплуатация же готового решения, созданного на платформе Docsvision, не требует от заказчика приобретения этих конструкторов, — только если заказчик захочет самостоятельно модифицировать решение своими силами.

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

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

Принцип №3: Модульность.

Архитектура платформы Docsvision должна быть модульной, чтобы заказчик приобретал только те компоненты, которые ему необходимы.

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

1. Набор готовых приложений

Это, например, такие приложения, как «Договоры», «Управление совещаниями», «Управление документами». Это все независимые готовые продукты, которые добавляют к платформе Docsvision соответствующие объекты – формы карточек (например, карточка «Договор»), справочники (например, справочник «Валюты»), роли (например, «Согласующий», «Подписант»). Как уже говорилось выше, все наши приложения мы делаем с использованием средств конструирования платформы Docsvision, а, значит, в проектном решении эти приложения можно адаптировать под требования заказчика.

2. Набор интеграционных шлюзов.

На данный момент мы разработали шлюзы к почте (SMTP/POP3), к 1С: Предприятие, к SharePoint и к SAP B1. Это своего рода готовые коннекторы, которые за счет их настройки позволяют Docsvision интегрировать с внешними системами. Основные функции всех шлюзов – это мониторинг объектов внешней системы, а также чтение и запись данных.

3. Набор рабочих мест пользователей.

Для платформы Docsvision мы разработали ряд рабочих мест для разных групп пользователей. Вот их краткое описание:

Принцип №4: Производительность.

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

Именно для проверки и подтверждения этого мы развернули у себя специальную инфраструктуру из нескольких серверов, предназначенную для нагрузочного тестирования системы, которое мы выполняем с помощью программной эмуляции действий пользователей в среде Visual Studio Load Test.

Но подробнее об этом стенде, а также о нашей методике тестирования продуктов, мы уже расскажем в нашем следующем посте.

Источник

Основные объекты DocsVision

Содержание:

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

Рис. 3. Навигатор и его основные элементы

Рис. 4. Список карточек, сгруппированных по полю Исполнитель
и отсортированных по названию документа

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

В стандартные приложения «Делопроизводство» и «Управление процессами» входят следующие основные карточки:

В состав приложения «Делопроизводство» включены карточки для описания входящего (рис. 5), внутреннего, исходящего документов, каждая из которых содержит определенные по умолчанию поля.

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

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

Рис. 5. Карточка входящего документа, вкладка Основная

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

Рис. 6. Карточка входящего документа, вкладка Документы и ссылки

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

В целях упорядоченного хранения и удобства доступа пользователей к информации все карточки DocsVision распределены по папкам, аналогичным папкам Проводника Microsoft Windows, в которых хранятся файлы. Папки делятся на несколько видов: пользовательские папки, создаваемые администраторами и пользователями, и системные, необходимые для правильной работы системы и создаваемые ею автоматически.

Рис. 7. Пример структуры дерева папок

Автоматически создаваемые системные папки выполняют следующие функции:

Рис. 8. Два различных представления информации, содержащейся в одной и той же папке

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

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

Механизм расширенных отчетов позволяет вывести отчет по любым данным, хранящимся как в базе данных DocsVision, так и во внешних базах данных SQL Server.

Такой отчет выводится в отдельном окне Internet Explorer или в Microsoft Word. В расширенных отчетах можно применять любые вычисления и форматирование, располагая необходимые результаты на листе необходимым образом.

Необходимые отчеты разрабатываются при внедрении фиксируются в системе в виде карточек расширенных отчетов. Пользователи используют в работе уже преднастроенные отчеты, запуская их на формирование и указывая предусмотренные в нем параметры (интервал дат, виды документов, подразделения и сотрудников, и т.п., по которым строится отчет).

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

В систему DocsVision входят следующие виды справочников и системных карточек, предназначенных как для хранения внутриорганизационной информации, так и для описания настроек некоторых функций системы:

Рис. 9. Справочник сотрудников

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

Для автоматизации исполнения комплекса заданий по документу, в системе DocsVision предусмотрена специальная карточка задачи (рис. 10).

Рис. 10. Шаблон карточки задачи (легкая форма)

Карточка задачи может создаваться как непосредственно из Навигатора, так и из карточки исполняемого документа (вкладка Задачи). Карточка имеет легкую (с основным набором полей) и полную (содержит полный набор полей для тонкой настройки, см. рис. 11) формы, переключаемые кнопкой на панели инструментов.

После активизации карточки задачи указанным в ней сотрудникам будут автоматически разосланы задания.

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

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

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

Рис. 11. Шаблон карточки задачи (полная форма)

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

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

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

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

Если для задания указан контролер, то после завершения его исполнителем оно будет направлено на приемку контролеру, который может его отклонить (вернуть на доработку) или принять.

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

Рис. 12. Карточка задания с полным набором вкладок

Внешний вид и логика обработки задания могут гибко настраиваться. Например, вместо стандартной кнопки «Завершить», могут быть настроены кнопки завершения в соответствии со смыслом задания: «Согласовать», «Отклонить» и пр. Если при выполнении задания необходимо ввести какие-либо данные, то поля для их ввода настраиваются на вкладке Свойства или настраиваются параметры завершения задания, диалог ввода которых открывается при нажатии кнопки «Завершить». Может быть также настроена необходимость формирования отчета при завершении задания и многое другое.

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

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

Рис. 13. Карточка согласования в режиме подготовки

Если сотруднику поступило задание согласовать документ, то он получит доступ к карточке согласования в соответствующем режиме. Он может просмотреть документ, ход согласования, и зафиксировать свои комментарии и решение.

Рис. 14. Карточка согласования в режиме согласования (задание)

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

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

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

Рис. 15. Карточка бизнес-процесса DocsVision

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

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

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

Рис. 16. Карточка процесса WWF в DocsVision

Источник

Структура базы данных Docsvision. От разработчика — разработчику!

Docsvision — это не просто программа, это платформа, позволяющая создавать свои решения для электронного документооборота. Статья нашего коллеги — разработчика Docsvision Димы Лейкина — предназначена как раз для разработчиков таких решений, к коим мы относим партнёров нашей компании и сотрудников IT-подразделений наших компаний-заказчиков.

В материале, разделённом на 5 логических частей, — базовая информация о том, как устроена система Docsvision. Кроме того, для разработчиков, которые хотят устроиться к нам на работу, эти знания будут дополнительным плюсом.

В целом, Docsvision — это клиент-серверная система, и разработка своего решения сводится к разработке набора карточек (то есть библиотеки).

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

Справочник — другое важное понятие. Справочник — это карточка, которая существует в единственном экземпляре. Например, справочник сотрудников, справочник сохраненных поисковых запросов, справочник ролей и т.д.
С самой системой поставляется несколько уже написанных библиотек карточек. Это библиотеки Platform, ManagedPlatform, Takeoffice, Workflow, Backoffice.
Первая серия статей посвящена основе системы — базе данных Docsvision. Конечно, это далеко не полное описание. В основном информация посвящена принципам работы системы, поэтому многими подробностями пришлось пожертвовать ради простоты изложения.

Часть 1. Секционные таблицы

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

Вкратце о метаданных

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

Каждая карточка имеет уникальный идентификатор — идентификатор типа карточки. Аналогично секции и поля имеют уникальные идентификаторы. Идентификаторы секций очень важны, поскольку в данный момент имена секционных таблиц генерируются следующим образом: [dbo].[dvtable_], где id — это идентификатор секции.

Начинающие часто путаются с типами и экземплярами. Например, в таблице [dbo].[dvsys_instances], где хранится информация об экземплярах карточки, в поле InstanceID (идентификатор экземпляра карточки) начинают искать идентификатор типа карточки для карточки документа. И очень удивляются, когда его там не находят. (Тут надо заметить, что в последних версиях Docsvision для справочников идентификатор карточки равен идентификатору типа).

Секция с точки зрения хранения информации в БД

С точки зрения хранения информации секция — это таблица БД. Полю секции в БД соответствует колонка таблицы. Кроме колонок для полей, в каждой «секционной» таблице есть так называемые системные колонки (RowID, InstanceID, ParentRowID, ParentTreeRowID и др.)

Колонки InstanceID и RowID
RowID — уникальный идентификатор (Guid) строчки секционной таблицы (первичный ключ).
InstanceID — идентификатор (Guid) экземляра карточки, к которой принадлежит данная строчка. Соответствует идентификатору карточки из таблицы [dbo].[dvsys_instances].

Можно представить себе секционную таблицу следующим образом:

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

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

Коллекционные секции
Коллекционная секция предназначена для хранения коллекции объектов. С точки зрения БД это означает, что среди строк секционной таблицы могут быть строки с одним и тем же InstanceID.

Секции типа struct
Секция типа struct предназначена для хранения структуры данных. По сути, это та же коллекционная секция, но только в коллекции может быть максимум один объект. С точки зрения БД это означает, что в секционной таблице не может быть двух строк с одинаковым InstanceID. Колонки секционной таблицы соответствуют полям структуры.

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

Дочерние секции
Деревянные секции позволяют хранить для объекта коллекцию дочерних объектов того же типа. А что, если мы хотим хранить коллекцию дочерних объектов другого типа? Для этого предназначены дочерние секции. «Классический» пример родительской и дочерней секции — это секции подразделений и сотрудников в справочнике сотрудников. С каждым подразделением связана коллекция сотрудников. В БД это выглядит следующим образом: в секционной таблице для сотрудников в системной колонке ParentRowID (не путать c ParentTreeRowID) указывается идентификатор родительского подразделения.

Для секционной таблицы дочерней секции генерируется внешний ключ на родительскую таблицу (с ParentRowID дочерней на RowID родительской таблицы) с каскадным удалением. То есть, например, при удалении подразделения, все его сотрудники будут удалены.

Практикум

Как можно использовать эти знания на практике? Допустим, у нас есть база Docsvision, и мы хотим посмотреть, какие сотрудники зарегистрированы в справочнике сотрудников. Для начала нам надо узнать идентификатор секции сотрудников справочника сотрудников. Проще всего, конечно, посмотреть в CardManager или в xml, но если их нет под рукой, не беда:

Находим идентификатор справочника сотрудников:

Получаем список его секций:

Видим в поле SectionTypeID для секции с алиасом Employees идентификатор секции сотрудников ‘DBC8AE9D-C1D2-4D5E-978B-339D22B32482’. Делаем запрос из секционной таблицы сотрудников:

Список сотрудников перед нами. Теперь, допустим, мы хотим посмотреть, какие сотрудники есть в подразделении с именем Test. Аналогично узнаем идентификатор секции подразделений и пишем:

Здесь мы использовали то, что секция сотрудников — дочерняя по отношению к секции подразделений. Теперь попробуем вывести подразделение Test и все его дочерние (в дереве) подразделения:

Здесь мы использовали то, что секция подразделений является деревянной секцией.

Часть 2. Немного подробнее о метаданных

Xml c метаданными карточек представляет из себя xml файл с метаданными карточки VersionedFile библиотеки Platform:

Утилита CardManager

Для работы с метаданными в Docsvision используется утилита для разработчиков CardManager. Утилита позволяет автоматизировать создание и редактирование метаданных карточек.

На скриншоте утилита CardManager с открытой библиотекой Backoffice.

На скриншоте — метаданные справочника сотрудников библиотеки Backoffice. Открыта деревянная секция AlternativeHierarchy, предназначенная для хранения групп пользователей. В ней видны дочерние секции Group и GrpViewFields, а также поля Name, Comments, AccountName и другие.

Часть 3. Ссылки

Поля могут быть разных типов, и в том числе — ссылки на строки(refid) и ссылки на экземпляры карточек (refcardid).

В случае ссылки на строку в ячейке таблицы прописывается идентификатор строки, на которую ссылается данная строка. Но в какой таблице искать строку по этому идентификатору? Это определяется по метаданным того поля, которое предназначено для хранения ссылки (в случае на рисунке — по метаданным поля MyReference).
При хранении ссылки на карточку в ячейке таблицы прописывается идентификатор экземпляра карточки InstanceID из таблицы [dbo].[dvsys_instances]. В метаданных указано, на карточку какого типа хранится ссылка.

Типы ссылок Hard, Weak, Auto

Ссылка на карточку может иметь тип Hard, Weak, Auto.
Hard, или жесткая ссылка, означает следующее: когда удаляется последняя жесткая ссылка на карточку, то карточка будет удалена.
Weak, или слабая ссылка, никак не влияет на удаление карточки.
Auto — автоматическая ссылка также не влияет на удаление карточки, но при удалении карточки сама ссылка будет обнулена.

Таблица [dbo].[dvsys_links]

Для хранения ссылок используется таблица [dbo].[dvsys_links]. В этой таблице собрана вместе та информация о ссылках, которая разбросана по разным секционным таблицам. Рассинхронизации тут произойти не может, поскольку добавление/удаление записей в таблицу обеспечивают те же хранимые процедуры, которые работают с секционными полями.

Для чего нужны ссылки

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

Часть 4. Системные таблицы и библиотеки

Основные системные таблицы

[dbo].[dvsys_globalinfo] – таблица содержит информацию о версии базы данных Docsvision. В этой таблице есть полезное поле Version, содержащее текущую версию базы данных.
Иногда требуется обновить версии для всех библиотек, чтобы они соответствовали версии базы данных, а погружать в базу новые версии библиотек не хочется. Для этого существует следующий способ: посмотреть версию в [dbo].[dvsys_globalinfo] и далее вызвать хранимую процедуру:

Библиотека Platform

Справочник папок
Если Вы когда-нибудь открывали Docsvision Navigator, то первое что Вы видели – это дерево папок и грид с представлением содержащихся в папке карточек. На самом деле, в папке содержатся не сами карточки, а ярлыки на них.

Справочник папок – это справочник FoldersCard библиотеки Platform, где хранится информация о папках, а также о находящихся в папках ярлыках на карточки. Папки хранятся в деревянной секции Folders.

Ярлыки хранятся в дочерней по отношению к ней секции Shortcuts. В этой секции есть поля HardCardID и CardID. И то, и другое поле является ссылкой на карточку. Разница только в том, что поле HardCardID представляет собой жесткую ссылку, а CardID ссылку типа Auto. Таким образом, ярлыки на одну и ту же карточку могут находится в разных папках, и карточка будет удалена, когда будет удален последний ярлык с жесткой ссылкой на неё.

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

Карточка файла с версиями
В библиотеке Platform есть карточка VersionedFile. Эту карточку удобно использовать в случаях, когда необходимо хранить несколько версий одного файла. В карточке есть деревянная секция Versions, которое позволяет хранить дерево версий файла. В секции Versions есть поле FileID типа fileID, где хранится ссылка на файл. В секции MainInfo есть полезное поле CurrentID (типа refid), содержащее ссылку на версию, которая считается текущей.

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

Карточка сохраненных представлений
Карточка используется для хранения информации о пользовательских представлениях – тех представлениях, которые показывает грид Docsvision Navigator.

Карточка сохраненных поисковых запросов
Карточка используется для хранения информации о пользовательских поисковых запросах.

Библиотека Backoffice

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

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

Справочник состояний
В справочнике состояний хранится конечный автомат состояний карточек. При переходе из состояния в состояние производятся операции.

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

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

Справочник скриптов
Справочник скриптов позволяет написать для карточек свои скрипты.

Справочник сотрудников
В справочнике сотрудников хранятся сотрудники и подразделения, а также группы и роли.

Справочник контрагентов
В справочнике контрагентов хранятся организации и сотрудники – контрагенты.

Часть 5. Подсистема поиска и представлений

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

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

Определение поиска и представлений представляет собой, по сути, небольшой язык с синтаксисом xml, и этот язык поддерживает много различных возможностей. Система генерации хранимых процедур на сервере – это транслятор из Xml в Sql.

Поисковая подсистема поддерживает 2 типа поиска – атрибутивный и полнотекстовый. Полнотекстовый поиск позволяет искать карточки или файлы, содержащие определенную строку. Атрибутивный поиск позволяет накладывать условия на значения полей выводимых карточек. Условие на значение поля может использовать операции равно, не равно, больше, меньше, и другие, в зависимости от типа поля. Условия могут комбинироваться с помощью И или ИЛИ. Таким образом, получается дерево условий. При генерации хранимой процедуры по ним генерируется условия в WHERE.

В представлениях используется аналогичный подход, поскольку они тоже в общем случае должны выводить не все карточки. В отличие от поиска, представления поддерживают так называемые вычисляемые поля. Генерацию вычисляемого поля можно представить себе, как добавление еще одного выражения в список инструкции SELECT результирующей выборки хранимой процедуры. Выражения для вычисляемого поля напоминают выражения для дерева условий. По сути, это то же дерево, только вместо операций сравнения в нем наиболее часто используются арифметические операции, а также выражения CASE WHEN (напоминающие switch в C#).

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

На самом деле, конечно, все сложнее. Во-первых, представление может содержать не одну такую выборку, а несколько, и эти выборки объединяются с помощью UNION ALL. Это может быть полезно, чтобы вывести в одно представление карточки разных типов. Во-вторых, в постраничных представлениях чтение всех данных для всех страниц из базы привело бы к существенному снижению производительности, поэтому в генераторе используется соответствующая магия по одной выборке генерируются несколько хранимых процедур.

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

Более подробно модель поиска и представлений можно рассмотреть в одной из будущих статей, а в этом блоке изложена базовая информация.

Источник