Блог

Блоги (Блог)

Основные изменения в архитектуре Инкоманд 7.4

1. Переход на новое объектное ядро

Главным архитектурным изменением Инкоманд 7.4 стало введение нового ядра с поддержкой объектной модели Инкоманд Objects как базового механизма для представления бизнес-сущностей, связей и прикладных данных портала.​ Объектная модель оформлена как полноценный слой поверх OSGi-архитектуры Инкоманд и включает определения объектов, поля, отношения, представления, действия, валидации и разграничение прав доступа.​

Суть изменения

  • В 7.3.x бизнес-сущности в основном реализовывались через Service Builder и жестко описанные таблицы и сервисы, что требовало генерации кода и деплоя модулей при изменении модели данных.​

  • В 7.4.x появляется Инкоманд Objects — low-code слой, где объекты, их поля, связи и логика задаются декларативно через интерфейс и API, без обязательной доработки Java-кода.

Преимущества нового ядра

  • Low-code моделирование. Определения объектов, поля, отношения, валидации и разрешения создаются и изменяются через интерфейс Инкоманд и метаданные, что ускоряет изменение бизнес-модели.​

  • Автоматический headless API. Для объектов формируются REST-интерфейсы для CRUD-операций и интеграций, что упрощает обмен данными с CRM, ERP, СЭД и другими корпоративными системами.​

  • Гибкие представления и действия. Для объектов можно настраивать формы, списки, таблицы, связанные элементы и прикладные действия без модификации ядра портала.

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

  • Поддержка миграции и развития. Документация по объектам описывает работу со связями, ERD-подходом и сценариями переноса данных, что облегчает эволюцию решений, созданных на базе 7.3.x.​

Снижение рисков

  • Снижается зависимость от кастомного кода и отдельных зарубежных библиотек, так как бизнес-логика переносится в декларативный объектный слой, а не в набор уникальных Java-модулей.

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

  • Основной риск связан не с санкциями, а с миграцией существующих кастомных сущностей 7.3.x на Инкоманд Objects, что требует архитектурной подготовки и проверки совместимости.

2. Клиентские расширения и UI

В Инкоманд 7.4 появились клиентские расширения (client-extensions), позволяющие подключать собственные HTML, CSS и JavaScript как отдельные веб-приложения без модификации ядра портала и штатных модулей.​ Это самостоятельный слой расширения интерфейса и функционала, который разворачивается и обновляется независимо от основного релиза платформы.​

Суть изменения

  • В 7.3.x доработки интерфейса и поведения чаще выполнялись через темы, фрагменты, portlet'ы и OSGi-модули, что делало кастомизацию более тесно связанной с базовой платформой.​

  • В 7.4 клиентские расширения позволяют выносить кастомную UI-логику и прикладные интерфейсы в отдельные приложения, работающие через API Инкоманд, без вмешательства в код ядра.

Преимущества по сравнению с 7.3.x

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

  • Гибкое подключение к API. Client-extensions могут использовать API Инкоманд и объектную модель, что позволяет создавать специализированные рабочие места, панели и прикладные экраны без переписывания системных компонентов.

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

Снижение рисков

  • Архитектура расширения становится более импортонезависимой, так как клиентские приложения работают в инфраструктуре заказчика и не требуют использования внешних SaaS-конструкторов или экосистемы Microsoft 365.​

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

3. Переход с Elasticsearch на OpenSearch

Одно из ключевых инфраструктурных изменений Инкоманд 7.4 — отказ от Elasticsearch в пользу OpenSearch 2.19.3 как основной поисковой платформы.​ В документации релиза прямо указано, что Elasticsearch заменён на OpenSearch, который поддерживает кластерные и контейнерные сценарии развёртывания.​

Суть изменения

  • В 7.3.x подсистема полнотекстового поиска и индексации строилась на Elasticsearch.

  • В 7.4 основной поисковый стек переведён на OpenSearch 2.19.3 с поддержкой REST-интерфейсов, индексации контента и развертывания в современных инфраструктурных сценариях, включая Kubernetes.​

Преимущества по сравнению с 7.3.x

  • Лицензионная устойчивость. OpenSearch снижает риски, связанные с изменением модели лицензирования Elasticsearch и зависимостью от коммерческой политики внешнего вендора.​

  • Совместимая поисковая архитектура. Сохраняется привычная логика индексов и API-подхода, что упрощает переход с 7.3.x.​

  • Гибкость внедрения. OpenSearch подходит для on-premise инсталляций, частных облаков и Kubernetes-контуров, что особенно важно для крупных российских компаний и регулируемых отраслей.​

Снижение рисков

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

  • Повышается устойчивость к ограничениям поставок и обновлений, потому что OpenSearch проще зеркалировать и сопровождать в локальном контуре.​

4. Обновление BPM-движка Flowable

Инкоманд 7.4 использует обновлённый движок бизнес-процессов Flowable 6.6.0 вместо версии 6.3.0, применявшейся в предыдущей архитектуре.​ Этот движок лежит в основе модуля для исполнения BPMN-процессов и DMN-правил.

Суть изменения

  • В 7.3.x процессы и правила опирались на более раннюю версию Flowable 6.3.0.​

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

Преимущества по сравнению с 7.3.x

  • Более зрелое процессное ядро. Улучшается работа с историей процессов, задачами, асинхронным исполнением и ошибкоустойчивостью.​

  • Лучшая основа для BPMN/DMN. Обновлённая версия удобнее для сложных маршрутов согласования, автоматизации заявок и интеграции с объектной моделью Инкоманд.

  • Снижение технического долга. Использование более актуальной версии движка упрощает сопровождение и уменьшает накопление устаревших зависимостей.​

Снижение рисков

  • Использование открытого BPM-движка снижает зависимость от иностранных проприетарных BPM-платформ и их условий поддержки.

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

5. Усиление безопасности платформы: обновление библиотек, закрытие уязвимостей и внедрение CSP

Инкоманд 7.4  отличается от ветки 7.3.x не только массовым обновлением технологического стека, но и усилением прикладной безопасности на уровне исполнения контента в браузере. Помимо обновления библиотек и устранения большого числа CVE, в 7.4 реализована Политика безопасности контента (Content Security Policy, CSP), что делает защиту фронтенд‑слоя более современной и системной.

Суть изменения

  • В 7.3.x безопасность Incomand уже строилась на комплексе мер против XSS, CSRF, LFI, clickjacking, content sniffing и других типовых угроз, а также на HTTPS, механизмах аутентификации и настройках портала. Однако в документации 7.3.5 акцент сделан прежде всего на защитные механизмы платформы и безопасную конфигурацию, а не на CSP как отдельный браузерный механизм политики исполнения контента.

  • В 7.4.1 к этому добавляются два важных слоя: обновление большого числа библиотек и компонентов с закрытием CVE, а также реализация CSP, которая ограничивает выполнение небезопасных скриптов и загрузку контента из недоверенных источников на стороне браузера.

Преимущества по сравнению с 7.3.x

  • Более сильная защита от XSS и внедрения нежелательного контента
    Обновление библиотек снижает количество известных уязвимостей, а CSP дополнительно ограничивает возможность исполнения вредоносного JavaScript даже в случаях, когда уязвимость связана с выводом контента в интерфейсе. Это особенно важно для портальных систем с большим количеством виджетов, HTML‑фрагментов и интеграционных экранов.

  • Защита не только на сервере, но и в браузере
    В 7.3.x основной упор делался на серверные механизмы и настройки портала. В 7.4.x безопасность усиливается за счёт контроля источников скриптов, стилей и других ресурсов непосредственно в браузере пользователя, что делает защиту многослойной.

  • Более безопасная работа кастомных интерфейсов и расширений
    Поскольку в 7.4.1 появились client‑extensions и расширенные сценарии кастомизации UI, наличие CSP становится архитектурно важным: платформа получает механизм, который помогает удерживать контроль над тем, какие внешние ресурсы и сценарии реально могут исполняться в пользовательской сессии.

  • Повышение зрелости ИБ‑архитектуры
    Внедрение CSP вместе с обновлением зависимостей, исправлением XSS/CSRF/SSRF/DoS‑рисков и обновлением компонентов уровня Netty, Tomcat, Commons, Tika и других библиотек выводит Incomand 7.4.x на более зрелый уровень по сравнению с 7.3.x.

Снижение рисков

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

  • Лучше управляемый локальный контур
    В сочетании с локальным развёртыванием Incomand, внутренними репозиториями библиотек и собственным управлением client‑extensions политика CSP помогает выстраивать более замкнутый и контролируемый ИТ‑контур без критической зависимости от внешних поставщиков.

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

6. Место Инкоманд в российской архитектуре корпоративных порталов

Сочетание нового объектного ядра, client-extensions, OpenSearch, обновлённого Flowable и актуализированного стека библиотек делает Инкоманд 7.4.x заметно более зрелой платформой по сравнению с веткой 7.3.x. Для российского рынка это особенно важно, поскольку Инкоманд развивается как отечественная альтернатива Microsoft SharePoint и Microsoft Viva с возможностью развертывания в локальном контуре, на российских ОС и СУБД, и с контролируемым технологическим стеком.​

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