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

В версии 4.10 для повышения стабильности работы:

•снижена нагрузка на систему при загрузке большого объема данных в контрол состояния. Теперь, если данные загружаются более 30 секунд или количество элементов превышает 2 000, то загрузка прерывается, и у пользователя появляется сообщение:

•ускорено отображение данных;

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

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

•STATEVIEW_TIMEOUT_IN_SECONDS – максимальное время для отображения контрола состояния. По умолчанию 30 секунд;

•STATEVIEW_MAX_ELEMENT_COUNT – максимальное количество элементов для отображения в контроле состояния. По умолчанию 2 000.

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

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

Также в среде разработки в класс Sungero.Core.StateView (модель контрола состояния) добавлены:

•метод GetBlockCount() – получение количества блоков в контроле состояния;

•свойство MaxElementCount – максимальное количество элементов.

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

Для повышения стабильности работы с блокировками объектов в системе:

•доработан и улучшен механизм блокировок;

•расширено логирование информации об установке и снятии блокировки, а также о невозможности ее установить;

•добавлен новый фоновый процесс «Логирование информации о длительных блокировках».

Улучшение механизма блокировок

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

•добавлен переповтор снятия блокировки, если при разблокировке было потеряно соединение сервиса с базой данных;

•доработана авторазблокировка зависших системных сессий. Например, если перезапустился сервис, ранее установивший блокировку на объект, то она не снималась. Теперь такие блокировки снимаются автоматически;

•добавлена авторазблокировка зависших на клиенте блокировок. Теперь сервер отправляет клиенту список длительных блокировок. На основе этого списка проверяется, какие из них не используются и какие нужно разблокировать;

•улучшена работа внутренних кэшей блокировок сервисов;

•уменьшено время автоматической разблокировки карточек, которые не редактируются. Для всех объектов теперь это время составляет 30 минут, для заданий – 2 часа. По достижении этого времени карточка становится доступной для редактирования коллегам, а у текущего сотрудника появляется сообщение. Ранее оно было информационным, теперь отображается в виде предупреждения и стало более заметным для пользователя:

•постоянные блокировки, не привязанные к сессии, теперь автоматически снимаются через 30 дней. Количество дней задается в новом параметре PERMANENT_LOCKS_LIFETIME_IN_DAYS.

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

Расширенное логирование

Во все сообщения о блокировках, которые пишутся в лог-файлы веб-сервера, добавлена расширенная структурированная информация:

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

•продолжительность блокировки. Если она превышает 60 минут, то в лог-файл добавляется дополнительный атрибут isLong со значением true. По этому атрибуту можно определить потенциально длительные блокировки, которым требуется анализ;

•информацию о заблокированном объекте. По типу и идентификатору объект можно быстро найти в системе;

•идентификаторы блокировки, трассы и клиента. По ним легко найти, где и когда была установлена блокировка.

Для логирования информации о блокировках в таблицы Sungero_System_Locks (блокировки карточек) и Sungero_System_BinDataLocks (блокировки версий документов) базы данных добавлены колонки:

•Id – идентификатор блокировки;

•TraceId – идентификатор трассы, в которой была поставлена блокировка.

Новый фоновый процесс

В системе теперь удобнее отслеживать длительные блокировки и находить объекты, на которые они установлены. Для этого используется новый фоновый процесс «Логирование информации о длительных блокировках». Он запускается 1 раз в сутки ночью и проверят блокировки, установленные более:

•12 часов – на карточки объектов, в лог-файле записывается как lg: "SuspendedLocks";

•24 часа – на содержимое документов, в лог-файле записывается как lg: "SuspendedBinaryLocks".

При выполнении фонового процесса в лог-файл сервиса асинхронных событий Worker в структурированном виде записывается детальная информация:

•идентификатор блокировки, время ее установки и продолжительность;

•идентификатор учетной записи пользователя, установившего блокировку;

•тип заблокированного объекта, его идентификатор и имя;

•идентификатор трассы, по которому можно легко понять, где была поставлена блокировка.

Пример записи в лог-файл информации о блокировке карточки объекта:

В новой версии появилась поддержка Kubernetes – открытого программного обеспечения для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями. Например, это позволяет контролировать нагрузку на сервисы и при ее увеличении автоматически добавлять поды (pods).

Для развертывания Directum RX в кластере Kubernetes в комплект поставки входят Helm Charts (чарты) – пакеты для запуска сервисов, конвертации и обновления базы данных. Кластер Kubernetes перед установкой системы нужно настроить.

Данные сервисов Directum RX, которые развернуты в Kubernetes, можно отслеживать в решении «Мониторинг системы Directum RX». Для этого нужно установить Helm Chart развертывания Filebeat, который входит в комплект поставки решения.

Иногда в базе данных PostgreSQL возникали рассинхронизация или дублирование прав доступа на типы объектов. Из-за этого росло потребление памяти сервисами Directum RX, а также появлялись ошибки в системе. В новой версии уменьшена вероятность появления таких ситуаций.

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