Передовые технологии на службе СЭД

Аннотация

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

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

Введение

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

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

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

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

Приведу на мой взгляд современные проблемы разработки:

1. Чем больше типов обрабатываемых данных, тем дольше и сложнее разработка на каждом этапе – данная проблема связана с использованием по привычке устаревших технологий, к которым можно отнести и классические реляционные базы данных, концепция которых была принята ещё в далёком 1971 году и изначально адаптирована к данным со статичной структурой;

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

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

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

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

Предметная область

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

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

Каждый участник платформы имеет собственные внутрикорпоративные стандарты ведения электронного документооборота и при отправке документ может быть сканом в виде рисунка TIFF, PNG, JPG, документом Word, Excel, ODT, ODS, PDF с различными версиями, файлами TXT или CSV и презентациями PPT или ODP.

Бизнес-процессы участников описаны в нотации BPMN 2.0 и могут следовать стандартам ISO 9000, ISO 20000, ITIL, COBIT с применением инструментов BPM от различных компаний.

Нагрузку возьмём из частоты подписания системой ежедневно новых договоров более 500, а это каждый раз запуск соответствующего бизнес-процесса со множеством согласований, не говоря уже о тысячах первичных документов бухгалтерского учёта и доп. соглашений по существующим договорам – пик нагрузки в итоге может превысить 5 тыс. запросов (средний размер 200 байт) в секунду с заполнением канала в 10 Мбит при 20 тысячах пользователей онлайн.

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

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

Технологии

База данных: PostgreSQL

В разное время Oracle и Uber (Uber отказался от PostgreSQL в пользу MySQL от Oracle) опубликовали статьи на тему «Почему не стоит использовать PostgreSQL» – следует поблагодарить ребят за кропотливую работу и заботливые напоминания, сделав прекрасный подарок в виде необходимого и достаточного чек-листа взросления PostgreSQL.

Вот чек-лист на мой взгляд зрелости современной PostgreSQL:

• выбор и использование именно PostgreSQL обусловлено крайне широкой поддержкой JSON с соответствующей реализацией большого количества функций и расширений, кроме того, PostgreSQL позволяет выстраивать внешние связи между JSON-данными, что например не умеет журнальный MongoDB;

• PostgreSQL выполняет запросы с полями типа JSON быстрее Oracle до 5 раз и быстрее MongoDB до 10 раз – что ставит PostgreSQL в один ряд с No-SQL базами данных, а учитывая возможность PostgreSQL также строить высокоскоростные key-value (hstore) хранилища с богатым функционалом и поддержкой журнала транзакций (чего нет в Redis), то и первым в ряду;

• если сравнивать скорость выполнения запросов реляционных таблиц и JSON с тем же набором данных в самом PostgreSQL, то разница составит до 2000 раз, а разница выгрузки в контейнер сервлетов результата JSON-запросов составит более 100 мс на каждые 100 тыс. записей, также размер JSON-хранилища на диске меньше до 2 раз и до 8 раз меньше размер индексов при больших массивах данных;

• подключив видеопамять к серверу производительность PostgreSQL по всем типам запросов автоматически увеличится в среднем на 17%, конечно, также не стоит использовать конфигурационный файл по дефолту, т.к. его адаптация под станцию и ОС – увеличит производительность до 3 раз;

• наличие активно развивающегося расширения Apache MadLib, разработанный учёными университета Berkeley совместно с инженерами корпорации Dell EMC (предоставили для тестирования терабайты финансовой статистики за десятилетия), где реализованы все известные математические алгоритмы машинного обучения для работы с данными в реальном времени непосредственно в базе данных;

• появился скоростной индекс RUM, который позволяет строить качественный релевантный мультиязычный полнотекстовый поиск с синтаксисом поискового web-запроса по таблицам с десятками миллионов записей за ~400 мс обычным сканированием индекса за счёт избыточной индексации без использования оперативной памяти – что позволяет исключить кластер ElasticSearch с огромными требованиями к памяти и дублированием базы данных в отдельном хранилище;

• PostgreSQL умеет также в реальном времени строить куб в параллельных потоках непосредственно в базе данных, что считается продвинутым на рынке OLAP и с явным преимуществом в виде: уровней абстракций (рекурсивные кубы), декларативного языка запросов и сравнительно более высокой точности;

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

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

class JObject : Serializable {
    var id: UUID? = null
    var jtree: JsonNode? = null
}

Многие системы на определённом этапе переходят в разряд высоконагруженных, что часто ведёт к их переписанию и первым порядком идёт отказ от использования Hibernate ORM как от бутылочного горлышка, что ускоряет запросы к БД от 10 раз и выше, а операции вставки до 5 раз. И конечно, в этом деле, использование подхода No-SQL от PostgreSQL играет ключевую роль.

Движок бизнес-процессов: Activiti

Безусловными лидерами корпоративного рынка движков бизнес-процессов (BPM) являются коммерческие (проприетарные) движки Lombardi Teamworks, Pegasystems SmartBPM, Savvion Business Manager, Oracle BPM Suite, Intalio BPMS, TIBCO Business Studio включающие в себя мощные инструменты имитационного моделирования для проигрывания различных сценариев поведения бизнес-моделей и аналитические средства мониторинга для выявления узких мест.

Выбор бесплатной Activiti BPM по следующим причинам: Activiti создал программист, в своё время, разработавший jBPM для компании JBoss, также, в разработке продукта участвуют программисты из Spring Source – настолько сильной командой и компетенциями не может похвастаться ни один из проприетарных движков BPM.

Разработчики Activiti не позиционируют свой продукт как высоконагруженный, но после несложных правок в схеме БД и конфигурации движка, получаем 20% прирост производительности. Инфраструктура вокруг Activiti слабая, отсутствуют штатные средства мониторинга, но в своё время был анонсирован в рамках проекта Activiti Cloud web-редактор бизнес-процессов, который можно бесплатно интегрировать в СЭД и кустомизировать.

Бэкенд: Reactive Spring Cloud

Для организации взаимодействия подсистем (микросервисов) между собой классически используется архитектурный шаблон сервис-ориентированной архитектуры (SOA). И в соответствии с SOA появилась новая концепция шины данных Talend ESB основанная на интеграционном фреймворке Apache Camel. Полностью поддержанная Activiti BPM и позволяющая напрямую интегрироваться в ESB-шину с возможностью использовать непосредственно в бизнес-процессах технических шагов Talend ESB. Такая возможность из коробки отсутствует в большинстве BPM-движках.

Talend ESB также базируется на Apache Karaf, что позволяет динамически загружать и выгружать Java-классы, в следствии чего, бизнес-процессы Activiti BPM становятся динамичными. Talend публикует целую линейку технологий для работы с данными: MDM, Big Data ETL, Data Quality – каждая из которых имеет визуальные средства моделирования и вся линейка интегрируема друг в друга.

Вот, как бы, вся мощь империи, но ESB-шины при всей своей широкой функциональности и гибкости имеют свои архитектурные рамки, за которые выйти без нарушения внутренней логики невозможно. И таким образом, эволюционно, появился Spring Cloud, предоставляя максимальную свободу и представляя собой ESB-шину без рамок, при этом, унаследовав всю терминологию и базовые принципы ESB-шин такие как: Discovery, Gateway, Config Server, Secrets и т.д.

Шли годы и современные требования заявили о необходимости поддержки высокой нагрузки, так появился на свет Reactive Spring Cloud, в основе которого находится сервер Reactor Netty. Netty быстрее Tomcat в 10 раз и NodeJS в 3 раза, что позволяет разработчикам создавать реактивные системы корпоративного уровня со всей инфраструктурой отказоустойчивости и масштабируемости Spring Cloud. Более нет необходимости в разбалансировке 10 подов сервиса Spring на базе Tomcat, когда достаточно 2 подов с Netty – в этом и суть новых технологий, когда стоимость разработки и владения уменьшаются в разы.

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

Для реактивной разработки используется микрофреймворк WebFlux на базе библиотеки Project Reactor, более продвинутой чем RxJava. Асинхронный код лаконичен и если ещё писать на Kotlin, то в итоге код становится в несколько раз меньше от аналогичного на классической Java, т.е. во много раз читабельнее. На Kotlin проще и продуктивнее работать. При работе с WebFlux необходимо учитывать рецепты от команды SberDevices.

Неотъемлемой частью WebFlux является реактивная модель, основанная на управляемых событиях Event-Driven (EDA) с использованием одного из брокеров сообщений. В качестве брокера обычно выбирают Kafka из-за скорости и гарантии доставки. Kafka быстрее ActiveMQ и RabbitMQ в 5 раз. Но выбор пал на NATS из-за отсутствия необходимости в дополнительном сервере ZooKeeper. NATS быстрее Kafka в 2 раза. Скорость NATS в особенности реализации, когда сообщения доставляются напрямую от отправителя к получателю. NATS прост, из коробки сжимает с gRPC все сообщения, естественно интегрируется в реактивный стиль за счёт поддержки pub/sub/stream.

Гарантия доставки NATS построена на действительно революционной подсистеме JetStream с правилом at-least-once delivery (доставка хотя бы один раз), оптимизированной для безопасной обработки миллиардов сообщений. JetStream обеспечивает несколько способов получения данных от одного источника – это очень похоже на распределённое реплицируемое блочное устройство (DRBD) с поддержкой multi-path (несколько каналов связи между узлами), входящее в ядро Linux и применяемое для построения отказоустойчивых кластерных систем на ОС Linux.

Фронтенд: Angular

Безусловно, Angular имеет сравнительно высокий уровень порог вхождения, но выбор сделан из-за web-редактора бизнес-процессов Activiti, который реализован на Angular.

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

Если разрабатывать с нуля адаптированный скелет фронтенда, то на этом можно впустую потратить время. Лучшим вариантом будет покупка современного шаблона от профессионалов – цена минимальная, а качество на мировом уровне. Кроме того, в комплекте будет присутствовать целая коллекция стильных компонентов типа Material Design. И как правило, шаблон протестирован на всех браузерах и мобильных устройствах. Такой же практики придерживаются практически все крупнейшие IT-гиганты.

Архитектура

Шаги реализации

1) Базовые таблицы БД:

Схемы форм Angular хранятся соответственно в form. Осмысление папок тривиальна. В поле jtree хранятся помимо name и description, любые уникальные атрибуты записи и как видно, присутствует во всех таблицах. Все объекты сохраняются в одну таблицу jobject, в которой записи распределяются по наследуемым таблицам по типу папки. Все объекты могут ссылаться друг на друга несколько раз и с разными типами связей (структура каждого типа уникальна).

CREATE FUNCTION public.jfolder_by_code(p_code text) RETURNS uuid
    LANGUAGE plpgsql AS
$$
declare
    jfolder_id uuid;
BEGIN
    SELECT id into jfolder_id FROM jfolder WHERE code = p_code;
    RETURN jfolder_id;
END;
$$;

CREATE TABLE public.form
(
    id         uuid                     DEFAULT uuid_generate_v1mc() NOT NULL PRIMARY KEY,
    jtree      jsonb                                                 NOT NULL,
    created_at timestamp with time zone DEFAULT timezone('utc'::text, CURRENT_TIMESTAMP)
);

CREATE TABLE public.jfolder
(
    id         uuid                     DEFAULT uuid_generate_v1mc() NOT NULL PRIMARY KEY,
    code       text                                                  NOT NULL,
    jtree      jsonb                                                 NOT NULL,
    form_id    uuid REFERENCES form (id),
    parent_id  uuid REFERENCES jfolder (id),
    created_at timestamp with time zone DEFAULT timezone('utc'::text, CURRENT_TIMESTAMP)
);

CREATE TABLE public.jobject
(
    id         uuid                     DEFAULT uuid_generate_v1mc() NOT NULL,
    jtree      jsonb                                                 NOT NULL,
    jfolder_id uuid                                                  NOT NULL REFERENCES jfolder (id),
    created_at timestamp with time zone DEFAULT timezone('utc'::text, CURRENT_TIMESTAMP),
    tsv        tsvector,
    PRIMARY KEY (id, jfolder_id)
) PARTITION BY LIST (jfolder_id);

CREATE TABLE public.jobject_jobject
(
    id        uuid DEFAULT uuid_generate_v1mc() NOT NULL PRIMARY KEY,
    left_id   uuid                              NOT NULL REFERENCES jobject (id),
    right_id  uuid                              NOT NULL,
    jtree     jsonb,
    parent_id uuid REFERENCES jobject_jobject (id)
);

INSERT INTO public.jfolder(code, jtree) VALUES ('document', '{"name": "Документы"}');
INSERT INTO public.jfolder(code, jtree) VALUES ('organization', '{"name": "Организации"}');
INSERT INTO public.jfolder(code, jtree) VALUES ('employee', '{"name": "Сотрудники"}');
INSERT INTO public.jfolder(code, jtree) VALUES ('file', '{"name": "Файлы"}');
INSERT INTO public.jfolder(code, jtree) VALUES ('type', '{"name": "Типы документов"}');

CREATE TABLE jobject_document PARTITION OF jobject FOR VALUES IN (jfolder_by_code('document'));
CREATE TABLE jobject_organization PARTITION OF jobject FOR VALUES IN (jfolder_by_code('organization'));
CREATE TABLE jobject_employee PARTITION OF jobject FOR VALUES IN (jfolder_by_code('employee'));
CREATE TABLE jobject_file PARTITION OF jobject FOR VALUES IN (jfolder_by_code('file'));
CREATE TABLE jobject_type PARTITION OF jobject FOR VALUES IN (jfolder_by_code('type'));

2) Базовые принципы бэкенда:

Для взаимодействия с базами данных используется реактивный Spring Data, в которой вместо Hibernate располагается R2DBC поддерживающий реактивные драйвера баз данных и являющийся аналогом JDBC, но с чуть большей скоростью выполнения запросов. Понятия Entity-прокси больше не существует, реактивный JpaRepository оперирует обычными классами и маппит результат через FastMethodInvoker, сравнимый по скорости с прямым доступом.

Возможности реактивного репозитория Spring Data при наследовании от интерфейса JpaRepository не соответствует современным требованиям, перепишем его на уровне спецификации в отдельную библиотеку с новым наименованием наследуемого интерфейса DslRepository, чтобы:

• перегрузить функции репозитория на дополнительный параметр типа Dsl – этот подход напоминает https://github.com/querydsl/querydsl, но значительно удобнее в использовании и весьма функциональнее;

• отключить проверку на обязательность в классах JPA-аннотаций, т.е. использовать обычные классы как есть – через Dsl можно легко объединять таблицы, также классы могут содержать любые поля, т.к. DslRepository будет использовать только те из них, что соответствуют полям в таблицах БД.

Основная идея Dsl – сократить время разработки через максимальную простоту работы с БД и формирование на фронтенде всех возможных критерий без внесения изменений в бэкенд:

localhost:8080/items?query= shops.type==mega; name~~biggest; price>=100 & fields=id; name & page=0 & size=20 & sort=itemType:asc, createdAt:desc

по которой генерируется SQL:

select id, name from items join shops on items.shop_id = shops.id where shops.type='mega' and name ilike '%biggest%' and price >= 100 order by item_type asc, created_at desc limit 20 offset 0

Dsl умеет спускаться через связанные таблицы на любой уровень как это показано в примере. Также можно работать напрямую с клиентом базы данных:

val dsl = Dsl.create().id(100L).getCriteriaBy(JObject::class)
client.select().from(JObject::class).matching(dsl).fetch().one()

Dsl всегда формирует запрос через Criteria Builder, что исключает Sql-инъекцию. Текущая версия реактивной DslRepository находится в корпоративном Nexus, но также есть и публичная версия, которую давно не обновлял – с предыдущей версией Spring Data работает отлично.

Все аспекты авторизации вынесли из Spring Security во внешние SSO-сервера. По рекомендации команды Spring следует использовать Keycloak, который по умолчанию используется web-редактором бизнес-процессов Activiti. Расширим реактивную Spring Security до поддержки модели безопасности ABAC, которая через совокупность правил умеет строить гибкую и детальную политику безопасности. ABAC также зафиксирует разрешённые Dsl-запросы по каждому методу REST-контроллера.

Создание правила «Только инспектор может просматривать все документы своего отдела»:

insert into abac_rule (name, description, type, target, condition)
values ('Инспектор видит все документы и только своего отдела',
        'может просматривать только те документы, которые созданы в отделе юзера',
        'Document',
        'action == ''show department documents''',
        'authUser.role == ''inspector'' and authUser.departmentId == domainObject.departmentId');

Применение правила ABAC в аннотации над методом:

@PreAuthorize("rule('connect only from department') and rule('show department documents')")

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

@PostMapping
fun add(@RequestBody jobject: JObject) = objectService.save(jobject)

@GetMapping(value = ["{jfolderId}"])
fun findAll(@PathVariable("jfolderId") jfolderId: UUID, dsl: Dsl) = objectService.findAll(jfolderId, dsl)

Всего 2 метода контроллера могут обеспечить все потребности фронтенда при работе с базой данных. Бэкенд при этом знает только об абстрактной таблице jobject, от которой могут быть унаследованы до нескольких сотен реальных. Функция add принимает данные с произвольной структурой и сохраняет как есть в JSON.

3) Подходы разработки фронтенда:

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

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

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

Одним из способов ускорения реализации СЭД – в создании отдельной библиотеки со всеми оперируемыми моделями данных фронтенда, где внутри, библиотека также содержит конфигурационный файл Maven для конвертации моделей Angular в схемы Apache Avro с автоматической генерацией Java-классов на нужды сервисов. Сгенерированные классы можно с ходу использовать в DslRepository, где единственное правило – чтобы присутствовало поле с именем id.

Реализация сложной бизнес-логики безусловно удобнее отдельном сервисе, где используются классы, сгенерированные по моделям Angular, а также при возможности NATS в качестве транспорта. Но типичные алгоритмы желательно хранить в виде Kotlin-скриптов в базе данных, с возможностью редактирования в одном из бесплатных визуальных редакторов исходного кода. Компилировать скрипты можно на этапе старта сервиса или при каждом модификации скрипта – это позволяет оперативно дорабатывать на фронте алгоритмы без перезагрузки подов сервиса. Такой подход также делает бизнес-процессы Activiti полностью динамичными.

4) Консолидация данных:

С десяток форматов документов с различными версиями могут быть загружены в систему, по которым необходимо организовать полнотекстовый поиск. Бесплатным инструментом извлечения текста с должным качеством является Apache Tika, который также умеет распознавать текст с рисунков через библиотеку Tesseract OCR.

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

Эффективный запрос релевантного полнотекстового поиска:

SELECT id, jtree->>'name' as title, ts_rank_cd(s.tsv, websearch_to_tsquery('russian', 'рынок (союз | -покрытие)'))
FROM (
         SELECT id, jtree, tsv
         FROM jobject, websearch_to_tsquery('russian', 'рынок (союз | -покрытие)') AS q
         WHERE (tsv @@ q)
     ) AS s
ORDER BY ts_rank_cd(s.tsv, websearch_to_tsquery('russian', 'рынок (союз | -покрытие)')) DESC;

5) Разработка Data Mining и OLAP

Возможность непосредственно в БД запускать алгоритмы машинного обучения и построения OLAP-кубов позволяет многократно уменьшить используемые ресурсы, обеспечивая обработку и вывод результатов в реальном режиме времени.

Встроенный в PostgreSQL в виде расширения инструмент Apache MadLib очень прост в использовании из-за языка запросов в виде SQL, что в равной степени касается и синтаксиса построения OLAP-кубов.

Многие данные в период начального сбора или из открытых источников фрагментированы, либо имеют искажения и работа по восстановлению занимает много времени. Тут важно, чтобы работа шла с применением мощных инструментов, какими обладает PostgreSQL и внедрённый воедино MadLib.

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

В MadLib представлена обычная линейная регрессия, но доработать её до рекурсивной средствами PgSQL не составит труда. Единственно, можно ещё доработать и сам MadLib (написанный на Python) строящий запросы в реляционной модели, т.е. если внедрить свойства No-SQL, то получаем ускорение в сотни раз.

Есть непрофильные алгоритмы для MadLib, например, латентно-семантический анализ (LSA), но с другой стороны свободных библиотек много и не сложно внедрить LSA в виде отдельного расширения PostgreSQL. Затем, комбинируя результат релевантного полнотекстового поиска и обученную модель LSA, можно быстро дополнить результат индексами соответствия и ссылками на ближайшие документы.

6) Динамическая отчётность

Jasper Reports позволяет строить отчёты и графики без взаимодействия с БД, т.е. отправляя на вход Json со всеми данными – сразу формируется отчёт или график в нужном формате.

Помимо прочего, можно сформировать не только сложный отчёт, но и полноценный документ в формате Word или PDF типа договора. Другими словами, использовать Jasper Reports в качестве генератора сложных документов с разнообразием отчёта.

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

Резюме

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

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

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