На чем написан docsvision

Docsvision начало — и продолжение

Меня зовут Владимир Андреев, я один из основателей компании «ДоксВижн», в данный момент являюсь ее президентом. В этом, первом для нас, посте я хотел бы вам рассказать о том, что делает наша компания, и немного подготовить к тому, о чём будет наш блог.

Скоро исполнится уже 15 лет с того момента, как мы начали разрабатывать продукт под названием Docsvision. За это время Docsvision превратился из достаточно несложной разработки, «собранной на коленке» двумя энтузиастами, до тиражного продукта, который внедряется в таких организациях, как Сбербанк, Роснефть, Минэкономразвития РФ. Сегодня наша компания выросла почти до сотни человек, в ней появились выделенные службы разработки, проектирования приложений, техподдержки, консалтинга. Нами выбрана исключительно вендорская модель бизнеса и соответственно все внедрения Docsvision осуществляются только нашими авторизованными партнерами. На данный момент наша партнерская сеть состоит из более чем сотни партнеров в России и СНГ.

Меня часто спрашивают: «А как все это начиналось?». Попробую в нашем первом посте кратко рассказать.

Как все хорошее в моей жизни (а, может, и каждого человека) все началось с «белой зависти». Когда я только начинал свою карьеру в IT-отрасли в начале 90-х, жизнь меня столкнула с командой Игоря Агамирзяна (нынешнего руководителя Российской венчурной компании). Тогда он руководил разработкой системы управления документами для Шведского патентного бюро. Этот проект в то время мне тогда показался совершеннейшей фантастикой, было ужасно завидно ребятам, которые работали над этой системой. Так родилась «Мечта жизни» — сделать что-то похожее.

Первый клиент

Первые 5 лет ушли на изучение предметной области и поиск источников инвестирования. К счастью, жизнь меня снова столкнула с хорошим человеком – Андреем Федоровым (одним из основателей Digital Design), который поддержал меня в этом начинании.

Андрей Федоров (на фото слева) и я на выставке Docflow 2005

День рождения Docsvision

Это были, наверное, самые веселые 7 месяцев в моей жизни! В течение проекта наш тот самый единственный разработчик получил приглашение от Microsoft и ушел разрабатывать SQL сервер. В результате чего нам пришлось во второй раз выкинуть весь написанный код. Но, несмотря на все трудности, ровно 31 декабря 1999 года первая версия системы Docsvision 1.0 была запущена в промышленную эксплуатацию на целых 16 рабочих местах.

Интерфейс одной из первых версий Docsvision

Docsvision сегодня

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

Кстати, по данным IDC, рынок систем электронного документооборота (СЭД) растёт на 23% ежегодно, при росте рынка ПО 15% в год.

Интерфейс web-клиента последней версий Docsvision 5.2

Заключение

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

Кто будет авторами в нашем блоге? Программисты, бизнес-аналитики, технические эксперты, инженеры, маркетологи, руководители направлений, – все те, кто участвует в создании Docsvision.

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

Источник

Что такое платформа 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

В 1999 вышла первая версия такой системы, получившая уже название DocsVision 1.0. С 1999 по 2003 год на базе DocsVision 1.0 и 2.0 был реализован ряд успешных проектов, в частности для «Светогорского ЦБК», НК ЮКОС, финансовой службы Октябрьской железной дороги, финансовой службы Министерства путей сообщений, петербургского метрополитена, авиаремонтной компании «Спарк» и РИВЦ Пулково.

В 2004 году вышла версия DocsVision 3.0, в которой система приобрела свои современные очертания – появилась подсистема управления бизнес-процессами и встроенное предложение «Делопроизводство». На базе DocsVision 3.0 был реализован проект по разработке системы автоматизации документооборота в Министерстве экономического развития и торговли РФ, эксплуатирующейся и развивающейся с конца 2003 года по настоящее время. Был заключен договор ISV-партнерства с Microsoft, который явился подтверждением со стороны Microsoft высокого качества системы DocsVision. Благодаря этому соглашению партнеры и заказчики DocsVision могут приобретать ряд программных продуктов Microsoft по специальным льготным ценам.

Количество внедрений продуктов DocsVision, 2005-2009

Компания DocsVision избрала вендорскую модель бизнеса (работать на рынке искючительно через своих партнеров) и начала активно формировать собственную партнерскую сеть. В результате в сентябре 2006 года в Санкт-Петербурге прошел первый из ежегодных партнерских форумов компании DocsVision. Каждый год участниками форума становятся от 100 до 150 представителей компаний-партнеров DocsVision. Цель проводимых форумов — предоставить максимум информации о системе DocsVision, методах ее продаж и внедрения, организовать обмен опытом между партнерами, подвести итоги работы партнерского сообщества за текущий год, представить направления развития компании, партнерского сообщества и системы DocsVision на следующий год.

В 2007 году произошло качественное изменение платфоры – вышла версия DocsVision 4.0. В ней серьезной переработке подверглась технологическая основа, что открыло широкие возможности для следующего витка быстрого развития функциональности и масштабируемости продукта. Появилась мощная подсистема расширенных отчетов — «Расширенные отчеты». Новая версия web-расширений DocsVision позволила строить гораздо более развитый веб-интерфейс к системе на интранет-сайтах и внутренних порталах предприятий, в том числе на базе Microsoft Office SharePoint Server.

Среди компаний, начавших использовать DocsVision на версии 4.0, множество известных российских компаний, таких как инвестиционная компания «А1», холдинг «Металлоинвест», «Полюс золото».

Количество партнеров DocsVision, 2005-2009

В июне 2007 года выпущено новое приложение DocsVision «Административное делопроизводство». Приложение решает весь круг задач, связанных с процессами административного документооборота, и является специализированным решением для тех структур, в которых работа с документами является основным производственным процессом. Среди пользователей DocsVision «Административное делопроизводство»: РУП «Гомельтранснефть Дружба», аппарат правительства Мурманской области, администрация Екатеринбурга и другие.

В компании начинает работу служба DocsVision Consulting. Основная цель службы — предоставление помощи партнерам в реализации наиболее сложных проектов по внедрению системы.

В 2007 году DocsVision уверенно закрепился в тройке наиболее продаваемых российских СЭД.

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

Существенное развитие произошло в технологиях интеграции DocsVision и Microsoft SharePoint. Переработаны интерфейсы веб-частей DocsVision, получивших название «Легкий клиент», реализован сквозной поиск документов по библиотекам SharePoint и хранилищу DocsVision. Впервые выпущен продукт SharePoint Extentions, позволяющий по контекстному меню SharePoint стартовать процессы согласования документов в DocsVision, формировать по ним задания для других пользователей, запускать любые преднастроенные в DocsVision бизнес-процессы, использовать единую систему категоризации документов, хранящихся в DocsVision и SharePoint, а также формировать единое «виртуальное» пространство документов вне зависимости от места их хранения.

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

Важной вехой стало создание SaaS-сервера DocsVision Live при партнерстве с компаниями Microsoft и Parking.Ru. Сервер DocsVision Live помог сотням потенциальных пользователей оценить возможности системы в режиме демо-доступа, без необходимости развертывания системы в своей локальной сети.

Отраслевое распределение проектов DocsVision

К настоящему моменту система DocsVision внедрена и успешно эксплуатируется более чем в 600 компаниях и организациях. Компания приобрела десятки сильных партнеров, способных внедрить систему в любом регионе России, а также странах СНГ и Балтии и оказать квалифицированную помощь клиентам. Наивысший статус «премиум-партнер» на текущий день имеют: Digital Design (Москва, С-Петербург), iDoc (Москва), Syntellect (Москва), Unisoft (Екатеринбург), RKIT Group (Иркутск), «Стек Соф»т (Томск, Новосибирск), «Утилекс АйТи» (Новосибирск), ГК «АКС-ВолгаЭВМкомплекс» (Самара), «Программные технологии» (Самара).

Источник

Структура базы данных 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. Это может быть полезно, чтобы вывести в одно представление карточки разных типов. Во-вторых, в постраничных представлениях чтение всех данных для всех страниц из базы привело бы к существенному снижению производительности, поэтому в генераторе используется соответствующая магия по одной выборке генерируются несколько хранимых процедур.

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

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

Источник