СЭД своими руками. Как создать систему электронного документооборота

Создать собственное ПО для клиентов уровня Enterprise – задача нетривиальная. Предлагаю вашему вниманию взгляд на базовые принципы самостоятельной разработки СЭД (систем электронного документооборота) с учетом отраслевых реалий РФ.

Сегодня крайне важно обеспечивать отечественное происхождение внедряемых ИТ-решений – это общий тренд на рынке ПО для ведущих отраслевых заказчиков. Необходимость создания собственных решений назрела после запуска государством политики импортозамещения в ИТ.

В сегменте СЭД требуется обеспечить решение традиционных задач по управлению контентом и бизнес-процессами крупных компаний, реализовав взаимодействие стандартного для систем этого класса компонентов, таких как СУБД (например, Postgres Pro), фреймворк для пользовательских интерфейсов (Vue.js), сервер приложений (Apache Tomcat 8), веб-сервер (Nginx), интеграционных сервисов взаимодействия (SOAP и/или REST full), а также сервисов обработки и предпросмотра документов, полнотекстового поиска и т.д.

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

Он сработал в нашем случае, но единственно возможным и верным, безусловно, не является.

Ничего лишнего

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

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

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

При создании такой СЭД, которая оптимально соответствует запросам рынка в РФ сегодня, следует по максимуму избегать подобных ситуаций.

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

На своем языке

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

Эта концепция реализована во многих существующих сегодня продуктах (например, в Documentum). Единый язык, который ретранслирует в разные языки запросы для баз данных в рамках системы. Такой подход позволяет менять различные БД при работе с СЭД совершенно безболезненно, не переделывая всю систему на глубинном уровне.

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

Поскольку они являются важной частью СЭД-продукта, то имеет смысл решать данную задачу через предоставление тех же средств доступа к данным, что применяются внутри самой системы.

Оптимальный вариант – разработка собственного SQL-подобного языка, посредством которого осуществляется доступ к данным. После реализации этого принципа к ядру можно добавлять другие функции, неотъемлемые для работы любого СЭД-решения.

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

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

Бизнес-процессы и функционал

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

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

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

Кажущийся минимализм

Многим такое минималистичное решение может показаться недостаточным для построения полноценного СЭД-продукта. Те возможности, которые я предлагаю удалить из ядра, тем не менее, абсолютно нужны в любой СЭД.

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

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

Практически любой микросервис, инструмент или библиотека, при условии ее «упаковки» в плагин, можно органично интегрировать в СЭД-решение.

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

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

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

Резюме

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

Это позволяет обеспечить следующие базовые преимущества итогового СЭД-продукта:

- простая расширяемая архитектура;

- максимальное быстродействие – между бизнес-логикой и СУБД – минимум логических архитектурных слоев, что дает возможность повысить скорость работы решения в 10-100 раз быстрее стандартных показателей;

- разграничение доступа к объектам системы согласно ролевой модели и набору списков прав доступа;

- возможности интеграция с любыми информационными системами (SAP, OEBS/PostgreSQL/MS SQL, 1C, AD, БОСС-Кадровик, EMC Captiva, Abbyy Software).

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

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

Заместитель генерального директора по технологическому развитию компании «АйДи – Технологии управления», Дмитрий Рогов