Внутренняя ошибка сервера directum rx

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

Шаг 1. Изучите архитектуру системы

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

Кратко зафиксируем здесь основные моменты:

  • в основе Directum RX лежит функциональная масштабируемая платформа Sungero, архитектура которой позволяет работать локально и в облаке;
  • платформа имеет трехзвенную архитектуру Клиентские приложенияСервер приложений – Хранилище данных. Такая архитектура обеспечивает безопасность системы. Сотрудники не имеют прямого доступа к базе данных, так как все запросы осуществляются через сервер приложений, веб-сервер или сервер NOMAD. Клиентские приложения Directum RX взаимодействуют с сервером приложений по защищенному протоколу HTTPS;
  • в отличие от монолитных систем, в состав платформы Sungero входят микросервисы – это независимые сервисы, каждый из которых выполняет определенную узкоспециализированную задачу. Например, сервис планировщика периодически инициирует только запуск фоновых процессов системы;
  • за состоянием сервисов следит Агент управления сервисами (ServiceRunner) – служба Windows, следит за работой сервисов и своевременно запускает их, автоматически обновляет или останавливает. Обеспечивает бесперебойную работу сервисов, если один или несколько из них выходят из строя. Регулярно проверяет конфигурационные файлы сервисов и в случае их изменения перезапускает сервисы.

Благодаря использованию микросервисов обеспечивается:

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

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

Шаг 2. Подумайте о будущем – настройте бэкапы

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

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

Далее рассмотрим отдельно особенности и рекомендации по резервному копированию БД и ФХ.

База данных

Резервное копирование и восстановление БД осуществляется средствами СУБД. Поддерживается работа с Microsoft SQL Server и PostgreSQL. В зависимости от используемой СУБД могут использоваться разные варианты: полное, разностное резервное копирование, резервное копирование журнала транзакций.

Выбор плана и стратегии резервного копирования базы данных Directum RX зависит от множества факторов, например, размера БД, приемлемого объема потери данных и активности работы с системой. Для обеспечения минимального достаточного уровня сохранности данных рекомендуется выполнять один из видов резервного копирования ежедневно. Пример реализации плана резервного копирования приведен в разделе справки «Стратегии резервного копирования».

Рекомендации по хранению резервных копий

  • храните резервные копии (бэкапы) на физическом носителе, отличном от того, где размещена исходная БД. Бессмысленно хранить резервные копии на том же диске, на котором расположена рабочая БД. В случае выхода из строя физического носителя, вы потеряете как БД, так и ее резервные копии;
  • целесообразно хранить несколько экземпляров бэкапов на разных носителях;
  • полезно разнести хранилища бэкапов по разным помещениям или даже зданиям – на случай локальных затоплений, пожаров. Как минимум стоит разнести сервер с бэкапами и продуктивный сервер по разным кабинетам.

Восстановление БД из резервных копий

  • перед восстановлением остановите все пулы приложений Directum RX и DrxServiceRunner. После окончания работ вновь запустите;
  • всегда стоит помнить о том, что данные системы также хранятся и в файловом хранилище. Поднятие БД из бэкапа никак не затрагивает данные ФХ. Если их тоже нужно «откатить», то это надо делать дополнительно к работам с БД;
  • если БД восстанавливается на новом сервере или сменилось ее имя, то после восстановления необходимо обновить информацию о подключении к БД во всех конфигурационных файлах серверных компонент Directum RX (сервер приложений, Worker и т.п.). Если серверные компоненты стоят на одном сервере, то обновить информацию о подключении к БД удобно с помощью конфигуратора настроек;
  • если восстановление БД сопровождается изменением аппаратных параметров сервера, например, сменился диск или сервер, то систему нужно заново зарегистрировать новым регистрационным ключом, ключ запросить в службе поддержки Directum.

Файловое хранилище

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

В справке есть раздел «Резервное копирование файлового хранилища». В нем предлагается использовать стандартный компонент Microsoft Windows «Система архивации данных Windows Server».

Рекомендации по частоте создания бэкапов ФХ, месту их хранения те же, что и для бэкапов БД. Они были перечислены выше.

Восстановление ФХ из резервной копии

  • ФХ работает под управлением сервиса хранилищ. Перед восстановлением сервис хранилищ необходимо остановить;
  • после восстановления ФХ из резервной копии необходимо убедиться, что в конфигурационном файле сервиса хранилищ указана правильная папка ФХ;
  • восстановление ФХ из бэкапа стоит производить совместно с восстановлением БД. При этом стоит использовать максимально близкие по времени создания экземпляры бэкапов БД и ФХ.

Допустимо использовать более поздние бэкапы ФХ с более ранними бэкапами БД. Если в базе данных не будет информации о телах документов (версиях), которые есть в файловом хранилище, то эти файлы в ФХ просто не будут использоваться.

Обратная ситуация, когда в ФХ нет файлов для версий документов, которые есть в БД, может привести к ошибкам в работе с этими документами.

Шаг 3. Организуйте наблюдение

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

  • решение «Мониторинг системы Directum RX» для контроля состояния системы и окружения, в котором она работает. Решение наглядно отображает ключевые показатели технического состояния системы: метрики производительности серверов, статистику использования системы, ошибки в разрезе служб. Решение предоставляется бесплатно (при наличии действующего абонемента) по запросу в службу поддержки.

Точки контроля, по-крупному:

    •  
    • работоспособность серверов, сервисов;
    • загрузка CPU. Постоянное нахождение нагрузки на CPU в пиковом диапазоне – признак того, что система не справляется с нагрузкой, не имеет «запаса прочности»;
    • расход ОЗУ. Анализируется аналогично CPU;
    • свободное место на дисках. Отсутствие места на дисках может приводить к выключению сервера.
  • панель управления Kibana и веб-интерфейс RabbitMQ для мониторинга работы полнотекстового поиска документов, задач и заданий;
  • список «Фоновые процессы» для мониторинга и состояния процессов, которые запускаются в системе по заданному расписанию. Например, процессы для рассылки уведомлений о завершении сроков действия договоров или для автоматической выдачи прав доступа на документы;
  • лог-файлы, в которые записываются сообщения об ошибках, предупреждениях и информационные сообщения, появившиеся во время работы.

Работа с лог-файлами

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

Есть несколько видов лог-файлов.

Серверные лог-файлы – место сохранения лог-файлов указано в конфигурационных файлах каждой из серверных компонент. Пример имени серверного лог-файла:

<Имя_сервера>.<Наименование серверной компоненты>.<Дата>.log

Например: SERVER.WebServer.2020-05-28.log

Клиентские лог-файлы десктоп-клиента – хранятся на компьютерах пользователей. Пример имени лог-файла десктоп-клиента:

<Имя_комьютера>.DirectumRX.<Код систем>.<Дата>.log

Например: SERVER.DirectumRX.DEMO.2020-05-28.log

Remote-логирование (веб-клиент) – передача клиентских логов на сервер c целью собрать ошибки клиентов и статистику времени выполнения операций. Логи сохраняются на сервере в настроенную папку, в которой логи разделяются по файлам. Сообщения, которые логируют программный код клиента, накапливаются и передаются пачками, по умолчанию по 100 штук. Исключение составляют сообщения о том, что пользователь разлогинился, они отправляются сразу же. Пример имени лог-файла веб-клиента:

<ip-адрес>.WebClient.<Код системы>.<Дата>.log

Например: 37-235-64-229.WebClient.DirectumRX.2020-05-28.log

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

  • зафиксировать время воспроизведения ошибки;
  • просмотреть все серверные лог-файлы за последний день.

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

Рекомендации по хранению лог-файлов

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

  • не храните лог-файлы на дисках, где находятся файлы операционной системы, исполняемые файлы программ. Выделите для логов отдельные диски. В случае переполнения этих дисков Directum RX просто перестанет писать новые логи. Работа ОС, программ при этом не пострадает.
  • настраивать хранение логов нужно отдельно для каждого серверного компонента Directum RX в их конфигурационных файлах;
  • во избежание переполнения папок с логами настройте регулярные процедуры их архивирования, очистки, переноса на другие диски с обеспечением ротации хранимых данных. Например, напишите скрипты на PowerShell. Определите политику хранения созданных архивов.

Расположение текстовых лог-файлов можно менять в конфигурационных файлах системы. Подробно можно посмотреть в разделе справки «Лог-файлы во время работы».

Шаг 4. Настройте учетные записи

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

Administrator. Администратор системы, под которым выполняется первоначальная настройка системы. Для входа в Directum RX используйте пароль, который был указан при установке системы. После этого:

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

Adviser. Пользователь, у которого есть права на просмотр любых объектов системы. Смените пароль пользователя, если планируете его использовать. Если нет, то в целях безопасности закройте запись данного пользователя.

Integration Service. Учетная запись для сервиса интеграции. Смените пароль пользователя, если планируете использовать интеграцию, например, с 1С. Если интеграция не нужна, то закройте запись данного пользователя.

Итак, в целях безопасности проверьте перечисленные учетные записи для системных пользователей. Для Adviser и Integration Service смените пароли, если они будут использоваться, иначе их нужно закрыть. Учетную запись Administrator закройте и настраивайте систему от своего администратора, с другим логином и паролем.

Кроме того, есть еще Service User. Учетная запись, под которой будут работать сервисы Workflow, сервис предпросмотра, сервис планировщика и другие. Задается на этапе установки системы, если было выбрано значение Использовать стандартную учетную запись «Service User». В дальнейшем не рекомендуется менять пароль данной учетной записи. Но, если по каким-то причинам вы изменили пароль, то нужно доработать вручную конфигурационные файлы для веб-сервера, сервиса выполнения блоков схем задач Workflow и сервиса асинхронных событий. Параметры:

<var nameAUTHENTICATION_USE_THREAD_IDENTITY« value=»false» />

<var nameAUTHENTICATION_USERNAME« value=»Service User» />

<var nameAUTHENTICATION_PASSWORD« value=»0z$Ede» />

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

После этого можно переходить к настройке Directum RX. Обратите внимание, если политики компании предусматривают, что в целях безопасности периодически необходимо менять пароли для входа в систему, то администратор может в настройках учетной записи для пользователя установить Требовать смены пароля при следующем входе. В этом случае при входе в систему у пользователя откроется окно:

И напоследок рекомендации к надежности пароля:

  • пароль не должен содержать имя учетной записи пользователя или какую-либо его часть;
  • пароль должен иметь длину не менее 6 знаков;
  • пароль должен содержать знаки трех из четырех перечисленных ниже категорий:
    • латинские заглавные буквы (от A до Z);
    • латинские строчные буквы (от a до z);
    • цифры (от 0 до 9);
    • символы (например, !, $, #, %, ‘).

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

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

Шаг 1. Изучите архитектуру системы

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

Кратко зафиксируем здесь основные моменты:

  • в основе Directum RX лежит функциональная масштабируемая платформа Sungero, архитектура которой позволяет работать локально и в облаке;
  • платформа имеет трехзвенную архитектуру Клиентские приложенияСервер приложений – Хранилище данных. Такая архитектура обеспечивает безопасность системы. Сотрудники не имеют прямого доступа к базе данных, так как все запросы осуществляются через сервер приложений, веб-сервер или сервер NOMAD. Клиентские приложения Directum RX взаимодействуют с сервером приложений по защищенному протоколу HTTPS;
  • в отличие от монолитных систем, в состав платформы Sungero входят микросервисы – это независимые сервисы, каждый из которых выполняет определенную узкоспециализированную задачу. Например, сервис планировщика периодически инициирует только запуск фоновых процессов системы;
  • за состоянием сервисов следит Агент управления сервисами (ServiceRunner) – служба Windows, следит за работой сервисов и своевременно запускает их, автоматически обновляет или останавливает. Обеспечивает бесперебойную работу сервисов, если один или несколько из них выходят из строя. Регулярно проверяет конфигурационные файлы сервисов и в случае их изменения перезапускает сервисы.

Благодаря использованию микросервисов обеспечивается:

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

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

Шаг 2. Подумайте о будущем – настройте бэкапы

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

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

Далее рассмотрим отдельно особенности и рекомендации по резервному копированию БД и ФХ.

База данных

Резервное копирование и восстановление БД осуществляется средствами СУБД. Поддерживается работа с Microsoft SQL Server и PostgreSQL. В зависимости от используемой СУБД могут использоваться разные варианты: полное, разностное резервное копирование, резервное копирование журнала транзакций.

Выбор плана и стратегии резервного копирования базы данных Directum RX зависит от множества факторов, например, размера БД, приемлемого объема потери данных и активности работы с системой. Для обеспечения минимального достаточного уровня сохранности данных рекомендуется выполнять один из видов резервного копирования ежедневно. Пример реализации плана резервного копирования приведен в разделе справки «Стратегии резервного копирования».

Рекомендации по хранению резервных копий

  • храните резервные копии (бэкапы) на физическом носителе, отличном от того, где размещена исходная БД. Бессмысленно хранить резервные копии на том же диске, на котором расположена рабочая БД. В случае выхода из строя физического носителя, вы потеряете как БД, так и ее резервные копии;
  • целесообразно хранить несколько экземпляров бэкапов на разных носителях;
  • полезно разнести хранилища бэкапов по разным помещениям или даже зданиям – на случай локальных затоплений, пожаров. Как минимум стоит разнести сервер с бэкапами и продуктивный сервер по разным кабинетам.

Восстановление БД из резервных копий

  • перед восстановлением остановите все пулы приложений Directum RX и DrxServiceRunner. После окончания работ вновь запустите;
  • всегда стоит помнить о том, что данные системы также хранятся и в файловом хранилище. Поднятие БД из бэкапа никак не затрагивает данные ФХ. Если их тоже нужно «откатить», то это надо делать дополнительно к работам с БД;
  • если БД восстанавливается на новом сервере или сменилось ее имя, то после восстановления необходимо обновить информацию о подключении к БД во всех конфигурационных файлах серверных компонент Directum RX (сервер приложений, Worker и т.п.). Если серверные компоненты стоят на одном сервере, то обновить информацию о подключении к БД удобно с помощью конфигуратора настроек;
  • если восстановление БД сопровождается изменением аппаратных параметров сервера, например, сменился диск или сервер, то систему нужно заново зарегистрировать новым регистрационным ключом, ключ запросить в службе поддержки Directum.

Файловое хранилище

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

В справке есть раздел «Резервное копирование файлового хранилища». В нем предлагается использовать стандартный компонент Microsoft Windows «Система архивации данных Windows Server».

Рекомендации по частоте создания бэкапов ФХ, месту их хранения те же, что и для бэкапов БД. Они были перечислены выше.

Восстановление ФХ из резервной копии

  • ФХ работает под управлением сервиса хранилищ. Перед восстановлением сервис хранилищ необходимо остановить;
  • после восстановления ФХ из резервной копии необходимо убедиться, что в конфигурационном файле сервиса хранилищ указана правильная папка ФХ;
  • восстановление ФХ из бэкапа стоит производить совместно с восстановлением БД. При этом стоит использовать максимально близкие по времени создания экземпляры бэкапов БД и ФХ.

Допустимо использовать более поздние бэкапы ФХ с более ранними бэкапами БД. Если в базе данных не будет информации о телах документов (версиях), которые есть в файловом хранилище, то эти файлы в ФХ просто не будут использоваться.

Обратная ситуация, когда в ФХ нет файлов для версий документов, которые есть в БД, может привести к ошибкам в работе с этими документами.

Шаг 3. Организуйте наблюдение

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

  • решение «Мониторинг системы Directum RX» для контроля состояния системы и окружения, в котором она работает. Решение наглядно отображает ключевые показатели технического состояния системы: метрики производительности серверов, статистику использования системы, ошибки в разрезе служб. Решение предоставляется бесплатно (при наличии действующего абонемента) по запросу в службу поддержки.

Точки контроля, по-крупному:

    •  
    • работоспособность серверов, сервисов;
    • загрузка CPU. Постоянное нахождение нагрузки на CPU в пиковом диапазоне – признак того, что система не справляется с нагрузкой, не имеет «запаса прочности»;
    • расход ОЗУ. Анализируется аналогично CPU;
    • свободное место на дисках. Отсутствие места на дисках может приводить к выключению сервера.
  • панель управления Kibana и веб-интерфейс RabbitMQ для мониторинга работы полнотекстового поиска документов, задач и заданий;
  • список «Фоновые процессы» для мониторинга и состояния процессов, которые запускаются в системе по заданному расписанию. Например, процессы для рассылки уведомлений о завершении сроков действия договоров или для автоматической выдачи прав доступа на документы;
  • лог-файлы, в которые записываются сообщения об ошибках, предупреждениях и информационные сообщения, появившиеся во время работы.

Работа с лог-файлами

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

Есть несколько видов лог-файлов.

Серверные лог-файлы – место сохранения лог-файлов указано в конфигурационных файлах каждой из серверных компонент. Пример имени серверного лог-файла:

<Имя_сервера>.<Наименование серверной компоненты>.<Дата>.log

Например: SERVER.WebServer.2020-05-28.log

Клиентские лог-файлы десктоп-клиента – хранятся на компьютерах пользователей. Пример имени лог-файла десктоп-клиента:

<Имя_комьютера>.DirectumRX.<Код систем>.<Дата>.log

Например: SERVER.DirectumRX.DEMO.2020-05-28.log

Remote-логирование (веб-клиент) – передача клиентских логов на сервер c целью собрать ошибки клиентов и статистику времени выполнения операций. Логи сохраняются на сервере в настроенную папку, в которой логи разделяются по файлам. Сообщения, которые логируют программный код клиента, накапливаются и передаются пачками, по умолчанию по 100 штук. Исключение составляют сообщения о том, что пользователь разлогинился, они отправляются сразу же. Пример имени лог-файла веб-клиента:

<ip-адрес>.WebClient.<Код системы>.<Дата>.log

Например: 37-235-64-229.WebClient.DirectumRX.2020-05-28.log

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

  • зафиксировать время воспроизведения ошибки;
  • просмотреть все серверные лог-файлы за последний день.

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

Рекомендации по хранению лог-файлов

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

  • не храните лог-файлы на дисках, где находятся файлы операционной системы, исполняемые файлы программ. Выделите для логов отдельные диски. В случае переполнения этих дисков Directum RX просто перестанет писать новые логи. Работа ОС, программ при этом не пострадает.
  • настраивать хранение логов нужно отдельно для каждого серверного компонента Directum RX в их конфигурационных файлах;
  • во избежание переполнения папок с логами настройте регулярные процедуры их архивирования, очистки, переноса на другие диски с обеспечением ротации хранимых данных. Например, напишите скрипты на PowerShell. Определите политику хранения созданных архивов.

Расположение текстовых лог-файлов можно менять в конфигурационных файлах системы. Подробно можно посмотреть в разделе справки «Лог-файлы во время работы».

Шаг 4. Настройте учетные записи

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

Administrator. Администратор системы, под которым выполняется первоначальная настройка системы. Для входа в Directum RX используйте пароль, который был указан при установке системы. После этого:

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

Adviser. Пользователь, у которого есть права на просмотр любых объектов системы. Смените пароль пользователя, если планируете его использовать. Если нет, то в целях безопасности закройте запись данного пользователя.

Integration Service. Учетная запись для сервиса интеграции. Смените пароль пользователя, если планируете использовать интеграцию, например, с 1С. Если интеграция не нужна, то закройте запись данного пользователя.

Итак, в целях безопасности проверьте перечисленные учетные записи для системных пользователей. Для Adviser и Integration Service смените пароли, если они будут использоваться, иначе их нужно закрыть. Учетную запись Administrator закройте и настраивайте систему от своего администратора, с другим логином и паролем.

Кроме того, есть еще Service User. Учетная запись, под которой будут работать сервисы Workflow, сервис предпросмотра, сервис планировщика и другие. Задается на этапе установки системы, если было выбрано значение Использовать стандартную учетную запись «Service User». В дальнейшем не рекомендуется менять пароль данной учетной записи. Но, если по каким-то причинам вы изменили пароль, то нужно доработать вручную конфигурационные файлы для веб-сервера, сервиса выполнения блоков схем задач Workflow и сервиса асинхронных событий. Параметры:

<var nameAUTHENTICATION_USE_THREAD_IDENTITY« value=»false» />

<var nameAUTHENTICATION_USERNAME« value=»Service User» />

<var nameAUTHENTICATION_PASSWORD« value=»0z$Ede» />

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

После этого можно переходить к настройке Directum RX. Обратите внимание, если политики компании предусматривают, что в целях безопасности периодически необходимо менять пароли для входа в систему, то администратор может в настройках учетной записи для пользователя установить Требовать смены пароля при следующем входе. В этом случае при входе в систему у пользователя откроется окно:

И напоследок рекомендации к надежности пароля:

  • пароль не должен содержать имя учетной записи пользователя или какую-либо его часть;
  • пароль должен иметь длину не менее 6 знаков;
  • пароль должен содержать знаки трех из четырех перечисленных ниже категорий:
    • латинские заглавные буквы (от A до Z);
    • латинские строчные буквы (от a до z);
    • цифры (от 0 до 9);
    • символы (например, !, $, #, %, ‘).

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

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

Шаг 1. Изучите архитектуру системы

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

Кратко зафиксируем здесь основные моменты:

  • в основе Directum RX лежит функциональная масштабируемая платформа Sungero, архитектура которой позволяет работать локально и в облаке;
  • платформа имеет трехзвенную архитектуру Клиентские приложенияСервер приложений – Хранилище данных. Такая архитектура обеспечивает безопасность системы. Сотрудники не имеют прямого доступа к базе данных, так как все запросы осуществляются через сервер приложений, веб-сервер или сервер NOMAD. Клиентские приложения Directum RX взаимодействуют с сервером приложений по защищенному протоколу HTTPS;
  • в отличие от монолитных систем, в состав платформы Sungero входят микросервисы – это независимые сервисы, каждый из которых выполняет определенную узкоспециализированную задачу. Например, сервис планировщика периодически инициирует только запуск фоновых процессов системы;
  • за состоянием сервисов следит Агент управления сервисами (ServiceRunner) – служба Windows, следит за работой сервисов и своевременно запускает их, автоматически обновляет или останавливает. Обеспечивает бесперебойную работу сервисов, если один или несколько из них выходят из строя. Регулярно проверяет конфигурационные файлы сервисов и в случае их изменения перезапускает сервисы.

Благодаря использованию микросервисов обеспечивается:

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

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

Шаг 2. Подумайте о будущем – настройте бэкапы

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

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

Далее рассмотрим отдельно особенности и рекомендации по резервному копированию БД и ФХ.

База данных

Резервное копирование и восстановление БД осуществляется средствами СУБД. Поддерживается работа с Microsoft SQL Server и PostgreSQL. В зависимости от используемой СУБД могут использоваться разные варианты: полное, разностное резервное копирование, резервное копирование журнала транзакций.

Выбор плана и стратегии резервного копирования базы данных Directum RX зависит от множества факторов, например, размера БД, приемлемого объема потери данных и активности работы с системой. Для обеспечения минимального достаточного уровня сохранности данных рекомендуется выполнять один из видов резервного копирования ежедневно. Пример реализации плана резервного копирования приведен в разделе справки «Стратегии резервного копирования».

Рекомендации по хранению резервных копий

  • храните резервные копии (бэкапы) на физическом носителе, отличном от того, где размещена исходная БД. Бессмысленно хранить резервные копии на том же диске, на котором расположена рабочая БД. В случае выхода из строя физического носителя, вы потеряете как БД, так и ее резервные копии;
  • целесообразно хранить несколько экземпляров бэкапов на разных носителях;
  • полезно разнести хранилища бэкапов по разным помещениям или даже зданиям – на случай локальных затоплений, пожаров. Как минимум стоит разнести сервер с бэкапами и продуктивный сервер по разным кабинетам.

Восстановление БД из резервных копий

  • перед восстановлением остановите все пулы приложений Directum RX и DrxServiceRunner. После окончания работ вновь запустите;
  • всегда стоит помнить о том, что данные системы также хранятся и в файловом хранилище. Поднятие БД из бэкапа никак не затрагивает данные ФХ. Если их тоже нужно «откатить», то это надо делать дополнительно к работам с БД;
  • если БД восстанавливается на новом сервере или сменилось ее имя, то после восстановления необходимо обновить информацию о подключении к БД во всех конфигурационных файлах серверных компонент Directum RX (сервер приложений, Worker и т.п.). Если серверные компоненты стоят на одном сервере, то обновить информацию о подключении к БД удобно с помощью конфигуратора настроек;
  • если восстановление БД сопровождается изменением аппаратных параметров сервера, например, сменился диск или сервер, то систему нужно заново зарегистрировать новым регистрационным ключом, ключ запросить в службе поддержки Directum.

Файловое хранилище

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

В справке есть раздел «Резервное копирование файлового хранилища». В нем предлагается использовать стандартный компонент Microsoft Windows «Система архивации данных Windows Server».

Рекомендации по частоте создания бэкапов ФХ, месту их хранения те же, что и для бэкапов БД. Они были перечислены выше.

Восстановление ФХ из резервной копии

  • ФХ работает под управлением сервиса хранилищ. Перед восстановлением сервис хранилищ необходимо остановить;
  • после восстановления ФХ из резервной копии необходимо убедиться, что в конфигурационном файле сервиса хранилищ указана правильная папка ФХ;
  • восстановление ФХ из бэкапа стоит производить совместно с восстановлением БД. При этом стоит использовать максимально близкие по времени создания экземпляры бэкапов БД и ФХ.

Допустимо использовать более поздние бэкапы ФХ с более ранними бэкапами БД. Если в базе данных не будет информации о телах документов (версиях), которые есть в файловом хранилище, то эти файлы в ФХ просто не будут использоваться.

Обратная ситуация, когда в ФХ нет файлов для версий документов, которые есть в БД, может привести к ошибкам в работе с этими документами.

Шаг 3. Организуйте наблюдение

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

  • решение «Мониторинг системы Directum RX» для контроля состояния системы и окружения, в котором она работает. Решение наглядно отображает ключевые показатели технического состояния системы: метрики производительности серверов, статистику использования системы, ошибки в разрезе служб. Решение предоставляется бесплатно (при наличии действующего абонемента) по запросу в службу поддержки.

Точки контроля, по-крупному:

    •  
    • работоспособность серверов, сервисов;
    • загрузка CPU. Постоянное нахождение нагрузки на CPU в пиковом диапазоне – признак того, что система не справляется с нагрузкой, не имеет «запаса прочности»;
    • расход ОЗУ. Анализируется аналогично CPU;
    • свободное место на дисках. Отсутствие места на дисках может приводить к выключению сервера.
  • панель управления Kibana и веб-интерфейс RabbitMQ для мониторинга работы полнотекстового поиска документов, задач и заданий;
  • список «Фоновые процессы» для мониторинга и состояния процессов, которые запускаются в системе по заданному расписанию. Например, процессы для рассылки уведомлений о завершении сроков действия договоров или для автоматической выдачи прав доступа на документы;
  • лог-файлы, в которые записываются сообщения об ошибках, предупреждениях и информационные сообщения, появившиеся во время работы.

Работа с лог-файлами

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

Есть несколько видов лог-файлов.

Серверные лог-файлы – место сохранения лог-файлов указано в конфигурационных файлах каждой из серверных компонент. Пример имени серверного лог-файла:

<Имя_сервера>.<Наименование серверной компоненты>.<Дата>.log

Например: SERVER.WebServer.2020-05-28.log

Клиентские лог-файлы десктоп-клиента – хранятся на компьютерах пользователей. Пример имени лог-файла десктоп-клиента:

<Имя_комьютера>.DirectumRX.<Код систем>.<Дата>.log

Например: SERVER.DirectumRX.DEMO.2020-05-28.log

Remote-логирование (веб-клиент) – передача клиентских логов на сервер c целью собрать ошибки клиентов и статистику времени выполнения операций. Логи сохраняются на сервере в настроенную папку, в которой логи разделяются по файлам. Сообщения, которые логируют программный код клиента, накапливаются и передаются пачками, по умолчанию по 100 штук. Исключение составляют сообщения о том, что пользователь разлогинился, они отправляются сразу же. Пример имени лог-файла веб-клиента:

<ip-адрес>.WebClient.<Код системы>.<Дата>.log

Например: 37-235-64-229.WebClient.DirectumRX.2020-05-28.log

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

  • зафиксировать время воспроизведения ошибки;
  • просмотреть все серверные лог-файлы за последний день.

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

Рекомендации по хранению лог-файлов

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

  • не храните лог-файлы на дисках, где находятся файлы операционной системы, исполняемые файлы программ. Выделите для логов отдельные диски. В случае переполнения этих дисков Directum RX просто перестанет писать новые логи. Работа ОС, программ при этом не пострадает.
  • настраивать хранение логов нужно отдельно для каждого серверного компонента Directum RX в их конфигурационных файлах;
  • во избежание переполнения папок с логами настройте регулярные процедуры их архивирования, очистки, переноса на другие диски с обеспечением ротации хранимых данных. Например, напишите скрипты на PowerShell. Определите политику хранения созданных архивов.

Расположение текстовых лог-файлов можно менять в конфигурационных файлах системы. Подробно можно посмотреть в разделе справки «Лог-файлы во время работы».

Шаг 4. Настройте учетные записи

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

Administrator. Администратор системы, под которым выполняется первоначальная настройка системы. Для входа в Directum RX используйте пароль, который был указан при установке системы. После этого:

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

Adviser. Пользователь, у которого есть права на просмотр любых объектов системы. Смените пароль пользователя, если планируете его использовать. Если нет, то в целях безопасности закройте запись данного пользователя.

Integration Service. Учетная запись для сервиса интеграции. Смените пароль пользователя, если планируете использовать интеграцию, например, с 1С. Если интеграция не нужна, то закройте запись данного пользователя.

Итак, в целях безопасности проверьте перечисленные учетные записи для системных пользователей. Для Adviser и Integration Service смените пароли, если они будут использоваться, иначе их нужно закрыть. Учетную запись Administrator закройте и настраивайте систему от своего администратора, с другим логином и паролем.

Кроме того, есть еще Service User. Учетная запись, под которой будут работать сервисы Workflow, сервис предпросмотра, сервис планировщика и другие. Задается на этапе установки системы, если было выбрано значение Использовать стандартную учетную запись «Service User». В дальнейшем не рекомендуется менять пароль данной учетной записи. Но, если по каким-то причинам вы изменили пароль, то нужно доработать вручную конфигурационные файлы для веб-сервера, сервиса выполнения блоков схем задач Workflow и сервиса асинхронных событий. Параметры:

<var nameAUTHENTICATION_USE_THREAD_IDENTITY« value=»false» />

<var nameAUTHENTICATION_USERNAME« value=»Service User» />

<var nameAUTHENTICATION_PASSWORD« value=»0z$Ede» />

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

После этого можно переходить к настройке Directum RX. Обратите внимание, если политики компании предусматривают, что в целях безопасности периодически необходимо менять пароли для входа в систему, то администратор может в настройках учетной записи для пользователя установить Требовать смены пароля при следующем входе. В этом случае при входе в систему у пользователя откроется окно:

И напоследок рекомендации к надежности пароля:

  • пароль не должен содержать имя учетной записи пользователя или какую-либо его часть;
  • пароль должен иметь длину не менее 6 знаков;
  • пароль должен содержать знаки трех из четырех перечисленных ниже категорий:
    • латинские заглавные буквы (от A до Z);
    • латинские строчные буквы (от a до z);
    • цифры (от 0 до 9);
    • символы (например, !, $, #, %, ‘).

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

Итак, произошло то, что произошло, сегодня невозможно сделать сет Directum RX на MS SQL. Microsoft перестал отгружать лицензии в России. Для многих это стало неожиданностью, а для нас — нет. Задолго до введения санкционных ограничений мы позаботились о переходе на PostgreSQL и Linux. Причины были банальны — хотелось сократить расходы на лицензию. 

Также хотелось научиться переводить системы Directum RX на PostgreSQL, предполагая, что слонёнок будет востребован у наших заказчиков по той же финансовой причине. Для нас отказ от баз Microsoft был плановым. Кроме того, мы перевели инфраструктуры вместе с Directum RX на Linux. Сегодня оцениваем эту попытку “переехать” с сокращением затрат как отчасти удачную. 

Я, Виталий Волнянский, руководитель практики технологических решений (CTO), директор по продажам (VPS) ООО “ЕАЕ-Консалт”, под катом расскажу о том, как проходила миграция и с какими проблемами нам пришлось столкнуться.

Предыстория: ещё пару слов о мотивах

Как вы, вероятно, поняли, основным мотивом переезда на PostgreSQL было то, что не нужно платить за лицензию MS SQL. Для PostgreSQL можно купить поддержку, но обязательной опцией она не является, да и цена саппорта не сравнима со стоимостью лицензии Microsoft.

Directum RX мы эксплуатируем с 2017 года. В тот период предложения от вендора было сложно назвать оптимальными, проявлялись несовместимости внутренней инфраструктуры с MS SQL 14. Кроме того, вендор настоятельно рекомендовал использовать в инсталляции ARR Server с устаревшей аутентификацией NTP Authentication, которая применялась в настольном клиенте и не работала с протоколом HTTPS.

Единственным балансировщиком, который нормально поддерживал это решение, был ARR, но у него всё совсем печально с механизмами балансировки. Когда ложился основной сервер, балансировщик не мог эффективно перераспределить новые запросы на резервный. Это и явилось одним из триггерных факторов, которые мотивировали нас усовершенствовать платформу.

Мы осознали, что текущий стек не позволяет добиться высокой доступности, а в нагрузку получаем ещё рутинное избыточное администрирование и отладку систем Directum RX. При использовании балансировки (т.е. при применении нескольких компонентов резервирования) время администрирования увеличивается, приходится отслеживать работоспособность компонентов, следить за тем, куда уходят запросы.

В 2018 году мы решили избавиться от избыточности, поставили один Application Server, одну базу данных. Система была оптимизирована и развивалась, но проблемы продолжали возникать. С выходом третьей версии Directum RX появился web-клиент, в связи с чем произошел переход на новые механизмы аутентификации OpenID и мы поняли, что ARR можно заменить на более эффективный балансировщик, т.е. на Nginx.

Более оптимальный алгоритм и наличие здорового Health Check серьёзно упростили нам жизнь. После замены балансировщика попробовали развернуть второй сервер, что в полной мере не удалось. Поэтому до выхода четвертой версии Directum RX мы вернулись к использованию ARR. Но ещё на версии 3.4 было принято решение о миграции с MS SQL в PostgreSQL как способе сократить лицензионные расходы.

Последовательность действий

Для того, чтобы мигрировать, была определена последовательность этапов:

  1. Обследовать систему.

  2. Подготовить новую систему в Yandex Cloud: установить ВМ, серверы, установить приложения.

  3. Конвертировать данные из MS SQL в PostgreSQL.

  4. Мигрировать в Яндекс.Облако, предоставляемое ЕАЕ-Консалт, обеспечить миграцию Hystax.

  5. Осуществить миграцию стандартного ландшафта.

  6. Поднять ВМ.

  7. Установить Directum RX.

  8. Настроить канал связи между площадками.

  9. Провести синк документов, копирование БД и тестирование в рамках предпродуктивной миграции.

  10. Осуществить продуктивную миграцию.

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

Обследование системы

Предварительным этапом закономерно стало обследование системы. В этой стадии нужно было заранее исключить возможные проблемы совместимости версий.

Что мы делали:

  • проверили объемы баз данных;

  • проанализировали аппаратные требования к миграции, оценили совместимость, и, поняв на какой из версий Linux-систем будет работать Directum RX, выбрали Ubuntu 20.04;

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

На этом подготовительный этап был завершен и можно было перейти к инструменту миграции баз.

Изучение и доработка инструмента миграции из MS SQL в PostgreSQL

Задача конвертации данных из MS SQL в PostgreSQL не далась быстро. Мы были первыми, кто проводил такую миграцию. В то время мы использовали версию Directum RX 3.6, к которой вендор представил специальный инструмент для переноса данных из одной базы в другую. В связи с кастомным расширением нашей системы и использованием модуля CRM, инструмент работал исключительно с “родной” структурой, таблицами и дефолтным внутренним взаимодействием.

Для полноценной работы инструмент пришлось долго и мучительно настраивать и модифицировать SQL-скрипты. Часть модуля CRM использовал .NET Framework, и его пришлось адаптировать для корректной работы на .Net Core и Linux. Вендор оказал поддержку, дописывая решение под нас. Сейчас сложно сказать, сколько раз мы проводили миграцию в процессе отладки. Много. В 2021 году закончили переход на PostgreSQL и решили перейти к следующему этапу. С этого момента мы перестали платить за лицензии MS SQL.

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

Критерии выбора облака и результаты миграции

Оптимизация системы предполагала миграцию из облака вендора, т.е. Directum RXв облако Яндекс. Финансовая суть задачи состояла в том, чтобы сменить инвестиционные расходы на операционные, используя сервис вместо приобретения оборудования. Яндекс был выбран в силу того, что наша компания — партнёр Яндекса, и предложенное ими решение нас полностью удовлетворило.

Предпродуктивное тестирование

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

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

Значимые обновления, хранение данных и режим высокой доступности

После конвертации, возникло желание заставить платформу работать в режиме высокой доступности. Начиная с версии Directum RX 3.6 появилась информация о поддержке Linux-серверов, что обнадёживало. Позже нам предоставили тестовый релиз, и мы поняли, что в системе появились признаки микросервисной архитектуры.

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

До версии 3.8 весь объем данных по умолчанию записывался напрямую в базу. Это приводило к росту баз до неприличных объемов и вызывало проблемы при создании бэкапа и восстановлении системы. К томe же, для работы базы требовалось много оперативной памяти.

Как раз, когда мы конвертировались в PostgreSQL, вендор оптимизировал хранение данных и трансформировал их распределение, отправив контент в файловое хранилище, что здорово упростило бэкап. Несмотря на то, что база не выросла до чудовищных размеров, скорость её роста не предвещала ничего хорошего. Обновленное решение с хранением контента позволило нам существенно упростить задачу и снизить требования к RAM почти в 4 раза. Вместе с этим снизить стоимость виртуальной машины с СУБД. Если раньше резервное копирование базы длилось 3 часа, то сейчас стало занимать не более 20 минут и, соответственно, восстановление системы тоже происходит быстрее.

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

Проблемы внедрения

После того, как было принято решение использовать Yandex Cloud, мы применили Managed PostgreSQL (чтобы частично снять с себя часть ответственности за постоянное администрирование), а также автоматизировать развертывание и внедрить контейнеры kubernetes. Проведя установку, мы поняли, что возникает проблема, инсталлятор требовал полномочий суперпользователя, уровня sys admin. Наличие полных прав на управление базы данных инсталлятору было недостаточно. Ему нужен был полный доступ к серверу PostrgreSQL! 

Вероятно, что тот, кто сделал инсталлятор, имел такой доступ и реализовал решение по существующему шаблону. Решение спорное и не очень распространённое. Обычно в крупных компаниях, где существуют отдельные подразделения, занимающиеся администрированием баз данных, создают кластер серверов, где при необходимости заказываются БД. В данном же случае таких решений не предусмотрели. Мы решили не “ковырять” инсталлятор и отказаться от использования.

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

Сухой остаток

В силу того, что режим высокой доступности в полном смысле реализовать не получилось, возникли проблемы с Managed PostgreSQL, автоматической установкой и контейнерами, абсолютно успешным этот кейс считать сложно. При этом мы решили главные задачи, а именно:

  • сэкономили на лицензиях Microsoft, пока они были доступны в России;

  • сократили текущие расходы, переведя их из инвестиционных в операционные, благодаря использованию Yandex Cloud и уменьшению размера виртуальных машин;

  • гарантировали системе безопасность, ограничив влияние санкционных вендоров;

  • научились проводить миграцию на Linux и PostgreSQL и готовы предложить её клиентам в качестве сервиса, который, по всей видимости, будет достаточно актуальным среди использующих Directum RX.

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

Содержание

  1. Агент веб-доступа DIRECTUM 5.0
  2. Одна из причин подвисания системы DIRECTUM (случай из практики)
  3. Одна из причин подвисания системы DIRECTUM (случай из практики)
  4. Для чего написана эта статья?
  5. Настройка рабочего места для работы с web-интерфейсом СЭД DIRECTUM 5.4
  6. Сетевые настройки
  7. Требования к прикладному ПО
  8. Установка Агента-веб-доступа
  9. Настройка выплывающих окон
  10. Chrome
  11. Firefox
  12. Internet Explorer
  13. Настройка обработчика приложений
  14. Chrome
  15. Firefox
  16. Directum RX 4.1 для локальной установки в вопросах и ответах
  17. Как снизить нагрузку на веб-сервер?
  18. Зачем нужна утилита RxCmd? И чем она отличается от DrxUtil?
  19. Сколько существует типов аутентификации с сервисом интеграции?
  20. Можно ли шифровать параметры в конфигурационных файлах?
  21. Что сделано для Directum RX на Linux?
  22. Поддерживается ли работа с облачной электронной подписью?
  23. Как разработчикам создавать сценарии для правил согласования?
  24. Можно ли изменять стили для документов, заданий и записей справочников?
  25. Как установить сервисы Directum Ario?
  26. Есть ли изменения в мобильных решениях Directum RX?

Агент веб-доступа DIRECTUM 5.0

Опубликовано:
18 февраля 2014 в 08:24

В DIRECTUM 5.0 заметно преобразился и расширил свой функционал веб-доступ. Во многом это произошло благодаря появлению на свет Агента веб-доступа – приложения для Windows, которое устанавливается на компьютере пользователя и позволяет:

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

При входе в систему DIRECTUM через веб-доступ автоматически появится запрос на установку Агента. После установки Агент веб-доступа запускается при каждом входе в систему через веб-доступ и работает в фоновом режиме. В области уведомлений панели задач Windows появится значок

Теперь редактировать документы в веб-доступе стало так же просто, как в desktop-клиенте! Достаточно привычным образом открыть документ и начать его редактирование. Все изменения автоматически сохранятся в системе, дополнительных действий не потребуется.

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

Веб-доступ в DIRECTUM 5.0 во многом приблизился к своему старшему брату – desktop-клиенту. Приятной вам работы в обновленном веб-доступе!

Источник

Опубликовано:
11 апреля 2014 в 17:50

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

Как правило, в такой ситуации необходимо искать причину либо в блокировках на SQL-сервере, либо проблема с ресурсами самого железа (сервер, сеть и т.д.).

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

Что было предпринято: стандартный набор – записаны и проанализированы счетчики ОС и SQL сервера. Так вот, выяснилось, что в некоторые моменты времени происходило полное исчерпание всей доступной оперативной памяти на сервере. Здесь стоит отметить, что на SQL расположен один экземпляр SQL и более не стоит никакого дополнительного ПО.

С другой стороны SQL обычно использует всю доступную ему память под кэширование пользовательских запросов, если эти аппетиты не ограничить явно настройкой Minimum Server Memory и Maximum Server Memory.

Так вот в нашем случае, для нужд системы был оставлен запас не менее 10-12 ГБ (без учета потребления самим процессом sqlservr.exe), что теоретически должно было исключить резкое исчерпание доступной памяти. Но в нашем случае, 10 ГБ свободного пространства не спасали от этой проблемы.

Кроме того, ситуация усугублялась тем, что после нескольких таких «исчерпаний», кластер считал, что ноду недоступной (собственно логично) и переводил активность на резервную.

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

Тем не менее ситуация с исчерпанием памяти повторилась через несколько недель:

Т.е. по сути уменьшив объем буферного пула SQL мы лишь отсрочили появление проблемы.

Не буду описывать в деталях, но было выяснено, что в некоторый момент времени, процесс sqlservr.exe потреблял памяти значительно больше, чем было доступно системе, что в итоге и приводило к подвисанию системы DIRECTUM и всего SQL-сервера

Далее был проведен детальный анализ для выяснения того, что именно приводит к увеличению потребления памяти процессом sqlservr.exe, в том числе с привлечением специалистов MicroSoft.

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

Узнать размер хранилища TokenAndPermUserStore можно с помощью запроса:

И действительно, в моменты «исчерпания» всей доступной памяти значения TokenAndPermUserStore значительно отличались от обычного.

Одной из наиболее вероятных причин была названа утечка памяти, описанная в статьях http://support.microsoft.com/kb/2277078 и http://support.microsoft.com/kb/927396/en-us. И хотя в статьях идет речь о исправлении проблемы в CU3 для 2008 и проблеме в 2005 версии SQL соответственно, по факту проблема имеет место быть и в 2008 R2 версии, хотя ее вероятность значительно снижена.

В качестве временных рекомендаций для устранения этой проблемы предложено периодически выполнять очистку кэша этого хранилища:

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

Для чего написана эта статья?

Во-первых, поделится опытом с сообществом, возможно, кому-то этот опыт будет полезен.

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

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

Источник

Настройка рабочего места для работы с web-интерфейсом СЭД DIRECTUM 5.4

Оглавление

Статьи раздела

Сетевые настройки

Агент веб-доступа не поддерживает работу через прокси-сервера, в связи с чем для корректной работы веб-доступа необходимо настроить подключение к ресурсу https://doc.nsso.ru минуя прокси, через NAT.

При использовании PAC (Proxy Auto-Configuration) скриптов необходимо явное указание прокси сервера и порта в настройках браузера.

Требования к прикладному ПО

  • .net framework 4
  • Microsoft Internet Explorer 10 и выше
  • Google Chrome 60 и выше
  • Mozilla Firefox 54 и выше

Установка Агента-веб-доступа

При первом подписании документа на экране появится сообщение следующего содержания:

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

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

После того как установка завершена в правом нижнем углу рабочего стола появится значок Агента веб-доступа после чего вы можете приступать к подписыванию документов.

Настройка выплывающих окон

Для корректной работы экспорта в DIRECTUM необходимо разрешить всплывающие окна, для это выполните следующие настройки:

Chrome

В адресной сроке браузера введите chrome://settings/content/popups?search=site, в открывшемся окне добавьте адрес https://doc.nsso.ru в раздел разрешенных

Firefox

В адресной сроке браузера введите about:preferences#content, в открывшемся окне добавьте адрес https://doc.nsso.ru в раздел разрешенных

Internet Explorer

Настройки-Конфиденциальность-Включить блокирование всплывающих окон-Параметры, в открывшемся окне добавьте адрес https://doc.nsso.ru в раздел разрешенных

Настройка обработчика приложений

Chrome

Убедитесь что обработчики приложений включены в браузере, для этого в адресной строке введите chrome://settings/handlers?search=Handlers, в открывшемся окне опция должна быть включена.

Firefox

В адресной строке браузера введите about:preferences#applications, в открывшемся окне должна быть запись waagenbt54

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

Источник

Опубликовано:
30 августа в 11:37

Из статьи вы узнаете, какие новые сервисы помогут снизить нагрузку с веб-сервера, как разработчикам создавать свои сценарии для правил согласования, чем утилита RxCmd отличается от DrxUtil и многое другое.

ПРИМЕЧАНИЕ. Версия Directum RX 4.1 для локальной установки включает все новинки облачной версии.

Как снизить нагрузку на веб-сервер?

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

Схема работы сервиса отчетов (ReportService):

Схема работы сервиса виджетов (WidgetsService):

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

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

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

Зачем нужна утилита RxCmd? И чем она отличается от DrxUtil?

В новой версии на смену утилите DrxUtil пришла новая утилита RxCmd. Теперь исключительно она используется для решения следующих задач:

  • запуск интеллектуальной обработки документов, полученных с электронной почты или из папки с помощью службы ввода Directum Capture Service (DCS);
  • настройка классификации документов в сервисах Directum Ario;
  • импорт, экспорт и удаление шаблонов документов.

Главное преимущество RxCmd в том, что эта утилита кроссплатформенная: работает в операционных системах Microsoft Windows и Linux. Кроме того, новая утилита выполняет команды быстрее.

Старая утилита DrxUtil продолжает поставляться, но для узких задач, например для синхронизации данных из 1С и Active Directory. Если вы самостоятельно разрабатывали интеграции с помощью утилиты DrxUtil, то этот код продолжит работать, но его рекомендуется перевести на плагины RxCmd. В ближайших версиях поддержка утилиты DrxUtil будет прекращена.

Подробнее об особенностях работы утилиты расскажем в отдельной статье. Следите за публикациями на Directum Club.

Сколько существует типов аутентификации с сервисом интеграции?

Шесть. При обмене данными внешние системы обязательно проходят аутентификацию при обращении к сервису интеграции. Раньше использовалась только базовая аутентификация (basic access authentication). Для идентификации сервису интеграции требовались учетные данные пользователя с типом аутентификации по паролю. В новой версии для обращения к сервису добавлены:

  • базовая аутентификация с использованием доменных учетных записей (LDAP);
  • аутентификация по протоколам NTLM и Kerberos. Протокол NTLM обычно используется при обращении к сервису извне, например из дома, а Kerberos – при обращении внутри сети;
  • аутентификация по токенам;
  • аутентификация на основе Сookies.

Какой тип использовать – зависит от требований внешней системы и ситуации.

Можно ли шифровать параметры в конфигурационных файлах?

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

Утилита входит в стандартную поставку. Зашифровать данные можно после установки системы, при ее сопровождении.

Порядок шифрования зависит от операционной системы, на которой развернута система Directum RX. Подробнее см. в справке:

Что сделано для Directum RX на Linux?

1. Компоненты системы переведены на версию .NET Core 3.1

Веб-сервер, среда разработки и все микросервисы Directum RX переведены на версию .NET Core 3.1. Если вы используете какие-либо сторонние компоненты в своей разработке, то их необходимо перевести на указанную версию.

Если же ваши сторонние компоненты поддерживают работу только с .NET Framework и используются в вычислениях сервиса асинхронных событий Worker, то для совместимости оставлена возможность перенастроить сервис на работу под .NET Framework 4.8.

Если сторонние компоненты используются в других вычислениях, но при этом также поддерживают работу только с .NET Framework, перенесите ваш программный код в асинхронные обработчики. После этого также измените настройку в конфигурационном файле агента ServiceRunner, чтобы сервис Worker работал под .NET Framework 4.8.

2. В среде разработки появилась возможность создавать отладочные пакеты

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

При публикации такого пакета в Directum RX в лог-файл веб-сервера записывается информация о номерах строк кода, в которых возникла ошибка. Поэтому становится проще устранить ошибки.

3. Служба ввода документов теперь устанавливается на Linux

Перед интеллектуальной обработкой документы заносятся в Directum RX. За это отвечает служба ввода документов Directum Capture Service (DCS): она захватывает документы из папки или электронной почты, делит их на комплекты и загружает в систему. В новой версии служба ввода DCS сделана кроссплатформенной: ее можно развернуть в Microsoft Windows и системах на базе Linux.

Поддерживается ли работа с облачной электронной подписью?

Да, поддерживается с версии Directum RX 4.1. При использовании облачной подписи закрытый ключ и средство криптографической защиты информации (СКЗИ) хранятся на сервере. Подписание также выполняется на сервере. Использование облачной электронной подписи:

  • упрощает настройку инфраструктуры. На клиентских компьютерах не нужно устанавливать закрытый ключ и СКЗИ. Кроме того, подписание выполняется без использования веб-агента;
  • сокращает финансовые затраты на работу с электронной подписью. Не нужно приобретать лицензии СКЗИ и токены для каждого сотрудника, работающего с ЭП.

Подписание выполняется с помощью сервера КриптоПро DSS. Можно развернуть свой сервер или использовать готовый, который предоставляет удостоверяющий центр. В системе Directum RX в справочнике Цифровые сертификаты в новом поле Плагин задается привязка сертификата к плагину облачной ЭП.

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

Как разработчикам создавать сценарии для правил согласования?

В прошлой новости мы писали, что теперь в Directum RX для настройки правил согласования можно использовать сценарии:

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

Теперь путем наследования вы можете легко встраивать в правило согласования свои сценарии:

В справку добавлен пример, с помощью которого будет проще разобраться, как реализованы сценарии в базовом решении Directum RX, и разработать новые сценарии.

Можно ли изменять стили для документов, заданий и записей справочников?

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

Эти настройки задаются в редакторе типа сущности в узле «Стили». Раньше узел отображался только для типов документов. В новой версии настройка появилась у типов заданий, уведомлений и заданий на приемку, а также у типов справочников:

В табличной части задаются условия, при соблюдении которых изменяется стиль записи. Для настройки условий используются свойства с типом Логическое, Дата, Перечисление и Ссылка, а также операторы <>, >, >=, .Execute() и ExecuteAllMonitoringBlocks().

Благодаря обновлению блока «Мониторинг» в базовом решении Directum RX ускорено многоадресное рассмотрение документов и работа с составными поручениями. А для задач со сроком «Неделя» или «Месяц» интервал проверки увеличен – это позволило еще и снизить нагрузку на веб-сервер.

Как установить сервисы Directum Ario?

Установить новую версию сервисов Directum Ario, включая необходимую для их работы поисковую систему Elasticsearch, службу Directum Capture Service (DCS) и сервис хранилищ MinIO, теперь можно с помощью одной программы установки:

В программе можно проверить сервер на соответствие системным требованиям. Если на сервере есть не всё требуемое ПО, для его установки и настройки достаточно нажать одну кнопку:

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

Есть ли изменения в мобильных решениях Directum RX?

Конечно! Каждую версию мобильные решения становятся лучше. Например, в этой версии у администратора появилась возможность включать обязательную блокировку Directum Solo на всех устройствах сотрудников. Блокировка срабатывает после 15 минут бездействия, а для её снятия нужно ввести PIN-код. Такое поведение позволяет защитить мобильное приложение от несанкционированного доступа.

Подробнее об изменении мобильных решений также будет отдельная статья на Directum Club.

В статье перечислены основные новинки версии. Полный список новых возможностей можно изучить в документах «Изменения Directum RX 4.1» и «Изменения Directum RX 4.1. Исправленные замечания» на сайте поддержки . Если у вас остались вопросы, мы готовы ответить на них в комментариях.

Источник

Установка
веб-доступа


Известные проблемы и пути их решения

Не
работают гиперссылки на документы DIRECTUM

При работе с гиперссылками
на документы DIRECTUM существуют следующие проблемы и пути их
решения:

1.     
Если вместо
загружаемого документа отображается текст с параметрами документа,
то причина в том, что на клиентском компьютере не установлено
соответствие обработчика isb-файлов и расширения «.isb». В этом
случае необходимо переустановить клиентскую часть на клиентском
компьютере.

2.     
При установке
сервера веб-доступа к DIRECTUM неверно заданы параметры локальной
сети. Можно исправить ситуацию, выполнить следующее:

·        
Шаг 1. Запустите
утилиту конфигурирования сервера веб-доступа
C:Program
FilesDIRECTUM
CompanyWebAccessConfigDirWebConfigurator.exe;

·        
Шаг 2. Окно
«Выбор веб-узла Сервера веб-доступа к
DIRECTUM»:

а)    
в выпадающем
списке выберите веб-узел сервера веб-доступа к
DIRECTUM. По умолчанию «Сервер
веб-доступа к
DIRECTUM»;

б)    
нажмите на
кнопку OK
;

·        
Шаг 3. Окно
«Параметры Сервера веб-доступа к
DIRECTUM», закладка
«Общие»:

а)    
перейдите на
закладку «Обработчик гиперссылок»;

б)    
заполните поля
«Идентификатор сети» и «Маска подсети» группы «Параметры локальной
сети» корректными значениями;

в)    
нажмите на
кнопку OK.

3.     
В свойствах
веб-узла не задана обработка isb-файлов. Для устранения этой
проблемы необходимо сделайте следующее:

·        
Шаг 1. Запустите
утилиту конфигурирования сервера веб-доступа
C:Program
FilesDIRECTUM
CompanyWebAccessConfigDirWebConfigurator.exe;

·        
Шаг 2. Окно
«Выбор веб-узла Сервера веб-доступа к
DIRECTUM»:

а)    
в выпадающем
списке выберите веб-узел сервера веб-доступа к
DIRECTUM. По умолчанию «Сервер
веб-доступа к
DIRECTUM»;

б)    
нажмите на
кнопку OK
;

·        
Шаг 3. Окно
«Параметры Сервера веб-доступа к
DIRECTUM», закладка
«Общие»:

а)    
перейдите на
закладку «Настройка веб-узла»;

б)    
нажмите на
кнопку Установить требуемые значения;

в)    
нажмите на
кнопку OK.

4.     
На сервере
веб-доступа не установлен обработчик ASP-сценариев. Для
восстановления обработки, с помощью мастера установки компонент
Windows установите компоненту Active Server Pages. Для IIS
6.0 после установки убедитесь, что расширение веб-служб Active
Server Pages
разрешено. Для этого:

а)    
откройте консоль
администратора «Управление компьютером»;

б)    
перейдите в узел
«Службы и приложения» → «Диспетчер служб IIS» →  «Расширения
веб-служб»;

Для IIS 6.0
после установки добавьте в свойствах веб-узла библиотеку ISAPI,
соответствующую расширению ASP. Для этого:

а)    
на закладке
Фильтры ISAPI добавьте новый фильтр с названием ASP;

б)    
в качестве
обработчика установите файл
%WINDIR%system32inetsrvasp.dll;

в)    
перезапустить
Internet Information Services.

5.     
Если на
клиенте(ах) не установлен обработчик ярлыков IS-Builder (isbexec),
а клиент входит в локальную сеть (группа полей «Параметры локальной
сети» на закладке «Обработчик гиперссылок» утилиты конфигурирования
сервера веб-доступа), то необходимо включить этого клиента(ов) в
список исключений. При обращении с адресов из списка исключений
гиперссылки всегда будут открываться через веб-доступ, а не
генерировать ярлыки IS-Builder. Для настройки списка исключений
сделайте следующее:

·        
Шаг 1. Запустите
утилиту конфигурирования сервера веб-доступа
C:Program
FilesDIRECTUM
CompanyWebAccessConfigDirWebConfigurator.exe.

·        
Шаг 2. Окно
«Выбор веб-узла Сервера веб-доступа к
DIRECTUM»:

а)    
в выпадающем
списке выберите веб-узел сервера веб-доступа к
DIRECTUM. По умолчанию «Сервер
веб-доступа к
DIRECTUM»;

б)    
нажмите на
кнопку OK
;

·        
Шаг 3. Окно
«Параметры Сервера веб-доступа к
DIRECTUM», закладка
«Общие»:

а)    
перейдите на
закладку «Обработчик гиперссылок»;

б)    
заполните поля
«Идентификатор сети» и «Маска подсети» группы «Параметры списка
исключений» требуемыми значениями;

в)    
нажмите на
кнопку OK.

См. также:

·        

Сообщение «Неизвестная ошибка сервера сеансов
IS-Builder»
.

О чем этот сайт? DirectumRX | Электронный документооборот

Дата добавления сайта в базу: 13 Июля 2020 г. (2 года назад)

Проверить работу сайта

Дата последней проверки на работоспособность: Понедельник 16 Января 2023 г. 10:49 г. (1 неделя назад)

Оцените работу сайта

Сейчас работает
Сейчас не работает

Поделитесь, спросите у друзей, почему не работает сайт?:

Оцените сам сайт, насколько он вам нравится:

Проголосовавших: 1 чел.
Средний рейтинг: 5 из 5.

Что делать, если не открывается сайт rx.directum.ru? Если с недавнего времени перестал работать ресурс, попробуйте найти причину в нижеприведенных возможных ошибках, которые могут находиться как на стороне сервера, так и на стороне пользователя.

4xx (ошибка клиента)

Коды ответа 4xx при открытии сайта rx.directum.ru в интернет-браузере означают, что произошла ошибка на стороне пользователя:

Ошибка 400

Не работает сайт rx.directum.ru, ошибка в браузере 400 — плохой запрос, в запросе присутствует синтаксическая ошибка (например, в протоколе передачи данных);

Ошибка 401

Недоступен сайт rx.directum.ru, ошибка браузера 401 — авторизация не пройдена, нужна авторизация, но она не пройдена, либо введен неверный логин/пароль. Обычно возникает в случае ввода в форму авторизации неправильных данных;

Ошибка 403

Код ошибки браузера 403 — доступ запрещен. Ошибка 403 означает, что доступ к данным запрещен даже с авторизацией, открыть страницу не получится вообще;

Ошибка 404

Ошибка сайта rx.directum.ru, ошибка 404 — страница с текущим адресом не найдена, запрашиваемый документ (страница) отсутствует или ее адрес изменен.

5xx (ошибка сервера)

Еще один вид ошибок при открытии сайта rx.directum.ru в браузере — 5xx, ошибки на стороне сервера:

Ошибка 500

При открытии сайта rx.directum.ru появляется код ошибки 500 — внутренняя ошибка сервера, на сервере произошла неизвестная ошибка;

Ошибка 501

Недоступность rx.directum.ru, серверная ошибка 501 — не реализовано, сервер не поддерживает технологии для обработки запроса;

Ошибка 503

Не хочет работать сайт rx.directum.ru, код ошибки сервера 503 — сервер недоступен. Сервер по техническим причинам не может обрабатать запрос;

Ошибка 522

Не работает сайт — rx.directum.ru, ошибка сервера 522 — сервер перегружен, например, из-за большого количества посещений или DDoS-атаки.

При открытии rx.directum.ru на экране белое окно

Если вместо сайта rx.directum.ru белое окно, пустое место, значит, в глобальной Сети или на стороне провайдера возникли ошибки маршрутизации, либо владельцы вовремя не продлили действие домена — rx.directum.ru и он стал неактивным.

При невозможности открытия любых сайтов наиболее вероятна причина с общей недоступностью Интернета, либо интернет-ресурс может быть заблокирован по решению суда Роскомнадзором, согласно Федеральному закону ФЗ-149. Случаи, когда невозможно войти в личный кабинет rx.directum.ru, выходят за рамки этой заметки.

Последние проверенные сайты

Разработчики и люди, профессионально работающие с веб-приложениями, боятся 500 Internal Server Error. Оптимальный способ её устранения зависит от сервера и того, что на нём запущено. В данной статье приводятся советы по диагностике и исправлению ошибки 500.

  • Ошибка 500 Internal Server Error — диагностика
  • Ошибка 500 Internal Server Error — устранение на популярных платформах
  • Ошибка 500 Internal Server Error — устранение на стороне серверных скриптов
  • Попросите помощи у системного администратора
  • Ошибку 500 Internal Server Error довольно легко устранить

Важно помнить, что эта ошибка происходит на стороне сервера. Это значит, что HTML-код, выполняемый на стороне клиента, а также JavaScript или любые другие запущенные в браузере объекты, не могут быть причиной, по которой возникает ошибка 500 Internal Server Error. Само название (Internal Server Error – ‘внутренняя ошибка сервера’) говорит о том, что ошибка происходит на сервере.

Многие пользователи устанавливают на свой сервер популярные CMS-системы, такие как WordPress, Joomla, Drupal и они не должны вызывать ошибку 500, если всё настроено правильно. Однако она всё равно всплывает – из-за несовместимости версий, некачественных установок или сбоя прав доступа на сервере.

Вот некоторые распространённые проблемы, которые могут вызывать подобную ошибку в часто используемых CMS:

  • Если вы только что обновили движок до новой версии, вероятно, обновление прошло с ошибками и необходимо провести его повторно. Скорее всего, на сайте разработчика есть инструкции, как это правильно сделать.
  • Если вы только что активировали новый плагин или новую тему, стоит попробовать отменить эти изменения. Даже профессионально написанные плагины могут конфликтовать с другими и вызывать 500 Internal Server Error nginx
  • Если вы обновляли CMS, старые плагины и темы могут быть с ней несовместимы. Единственное, что можно сделать в таком случае — отключать их по очереди, пока ошибка 500 не исчезнет.
  • Неправильно заданные права доступа на сервере или ошибки в файле .htaccess. Серверу не удаётся получить доступ к скриптам, файлам и другим ресурсам, поэтому он выдаёт ошибку.

Когда причиной, по которой возникает ошибка 500 Internal Server Error являются скрипты и плагины, лучше всего искать ответы на сайтах их разработчиков.

Другой причиной по которой может возникнуть ошибка 500 Internal Server Error может стать разработка и тестирование собственных скриптов.

Чтобы справиться с такой ошибкой, попробуйте следующие решения:

  • Настройка прав на сервере: часто неверная настройка прав доступа к файлу или папке приводит к тому, что сервером выдаётся ошибка 500 Internal Server Error. Из-за того, что ему не удаётся запустить скрипт. Выясните, какие права должны быть настроены, и выставьте их соответствующим образом.
  • Превышено время ожидания: возможно, истекло время ожидания ответа от PHP или другого серверного скрипта. Это происходит из-за того, что недоступен определённый ресурс или коде была допущена ошибка, запускающая бесконечный цикл.
  • Превышено время ожидания соединения с сервером: если сервер был занят, перезагружался или потерял соединение, скрипт может выдать ошибку 500 Internal Server Error. Возможно, в следующий раз ошибки не будет. Но если ошибка появляется при тестировании, велика вероятность того, что она встретится и пользователям.
  • Ошибки в файле .htaccess: в некоторых случаях ошибку 500 может вызывать код, прописанный в файле .htaccess.
  • Ошибки в скрипте: если ошибку выдаёт скрипт, можете запросить у него подробную информацию об ошибке. К примеру, в PHP можно включить вывод ошибок на экран или в лог-файл, добавив директиву display_errors. По умолчанию среда выполнения может скрывать ошибки, но это не очень удобно для отладки программы.

В некоторых случаях у разработчиков нет полного контроля над сервером.

Если скрипт запускается на сервере сторонней организации, она может помочь вам в следующем:

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

Ошибка 500 Internal Server Error — как исправить? В большинстве случаев причины возникновения ошибки 500 легко исправляются. Проблема заключается в том, что без конкретной информации определение причины возникновения сбоя усложняется. Легче всего справиться с ошибкой, когда разработчик выяснит, что изменилось перед возникновением ошибки.

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

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

Коды статуса http – 500 ошибка сервера

Сообщение 500 Internal Server Error может отображаться любым количеством способов, поскольку каждому веб-сайту разрешено настраивать собственную форму.

Вот несколько распространенных способов появления ошибки HTTP 500:

  • внутренняя ошибка сервера 500
  • HTTP 500 – внутренняя ошибка сервера
  • Временная ошибка (500)
  • Внутренняя ошибка сервера
  • Внутренняя ошибка HTTP 500
  • Ошибка 500
  • Ошибка HTTP 500
  • 500. Это ошибка!

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

Различные варианты отображения внутренней ошибки сервера с кодом 500

В большинстве случаев в окне интернет-браузера отображается ошибка 500 Internal Server Error.

Причины ошибок HTTP 500

Как мы уже упоминали выше, сообщения о внутренних ошибках сервера не указывают какой-то конкретной проблемы.

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

Более конкретная информация о причине конкретной ошибки HTTP 500 часто предоставляется, когда она возникает на сервере с использованием программного обеспечения Microsoft IIS. Ищите числа после 500, как в HTTP Error 500.19 – Internal Server Error, это означает, что данные конфигурации недействительны.

Как исправить внутреннюю ошибку сервера

Как мы упоминали выше, 500 Internal Server Error – это ошибка на стороне сервера, означающая, что проблема, вероятно, не в вашем компьютере или интернет-соединении, а на сервере веб-сайта.

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

  1. Перезагрузите веб-страницу. Вы можете сделать это, нажав кнопку обновления/перезагрузки, нажав F5 или Ctrl + R или повторив попытку URL-адреса из адресной строки.

    Даже если ошибка 500 Internal Server Error является проблемой на веб-сервере, проблема может быть временной. Повторная попытка загрузки страницы часто бывает успешной.

    Если во время оформления заказа у интернет-продавца появляется сообщение «500 Internal Server Error», учтите, что повторные попытки оформления заказа могут привести к созданию нескольких заказов – и даже нескольких платежей! У большинства торговцев есть автоматическая защита от подобных действий, но об этом нужно помнить.

  2. Очистите кеш вашего браузера. Если есть проблема с кэшированной версией просматриваемой страницы, это может вызвать проблемы HTTP 500. Внутренние ошибки сервера редко вызваны проблемами с кэшированием, но я видел, как ошибка исчезла после очистки кэша. Это такая простая и безвредная вещь, которую можно попробовать в самом начале.

  3. Удалите куки вашего браузера. Некоторые проблемы с 500 Internal Server Error можно исправить, удалив файлы cookie, связанные с сайтом, на котором вы получаете ошибку. После удаления файлов cookie перезапустите браузер и повторите попытку.

  4. Устраните неисправность как ошибку тайм-аута 504 шлюза. Это не очень часто, но некоторые серверы выдают внутреннюю ошибку сервера с кодом 500, когда на самом деле 504 Gateway Timeout является более подходящим сообщением, основанным на причине проблемы.

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

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

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

Исправление ошибки 500 на вашем собственном сайте

Внутренняя ошибка сервера 500 на вашем собственном сайте требует совершенно другого поведения. Как мы упоминали выше, большинство из 500 ошибок являются ошибками на стороне сервера, а это, вероятно, ваша проблема, которую нужно исправить, если это ваш сайт.

Существует множество причин, по которым ваш сайт может показывать пользователям ошибку 500, но наиболее распространенные:

  • Ошибка разрешений. В большинстве случаев ошибка 500 Internal Server Error связана с неправильным разрешением для одного или нескольких файлов или папок. В большинстве этих случаев, неправильное разрешение имеют скрипты PHP и CGI. Обычно они должны быть установлены на 0755 (-rwxr-xr-x).
  • Тайм-аут PHP. Если ваш сценарий подключается к внешним ресурсам, время ожидания этих ресурсов может приводить к ошибке HTTP 500. Правила тайм-аута или лучшая обработка ошибок в вашем скрипте должны помочь, если это является причиной ошибки 500.
  • Ошибка кодирования в .htaccess. Хотя это не так часто, убедитесь, что файл .htaccess вашего сайта правильно структурирован.

Если вы используете WordPress, Joomla или другую систему управления контентом или CMS, обязательно поищите в их центрах поддержки более конкретную помощь по устранению неисправности 500 Internal Server Error.

Больше способов увидеть внутреннюю ошибку сервера

В Internet Explorer сообщение «Веб-сайт не может отобразить страницу» часто указывает на внутреннюю ошибку сервера HTTP 500. Ошибка 405 Method Not Allowed – это ещё один вариант, но должны найти соответствующее подтверждение в строке заголовка IE.

Когда службы Google, такие как Gmail, испытывают внутреннюю ошибку сервера 500, они часто сообщают о временной ошибке (500) или просто 500.

Когда Центр обновления Windows сообщает о внутренней ошибке сервера, она отображается как сообщение WU_E_PT_HTTP_STATUS_SERVER_ERROR или как код ошибки 0x8024401F.

Если веб-сайт, который сообщает об ошибке 500, работает под управлением Microsoft IIS, вы можете получить более конкретное сообщение об ошибке:

Ошибка 500 Internal Server Error
Код Объяснение
500,0 Произошла ошибка модуля или ISAPI.
500,11 Приложение закрывается на веб-сервере.
500,12 Приложение занято перезагрузкой на веб-сервере.
500,13 Веб-сервер слишком занят.
500,15 Прямые запросы на Global.asax не допускаются.
500,19 Данные конфигурации неверны.
500,21 Модуль не распознан.
500,22 Конфигурация ASP.NET httpModules не применяется в режиме управляемого конвейера.
500,23 Конфигурация ASP.NET httpHandlers не применяется в режиме управляемого конвейера.
500,24 Конфигурация олицетворения ASP.NET не применяется в режиме управляемого конвейера.
500,50 Произошла ошибка перезаписи во время обработки уведомления RQ_BEGIN_REQUEST. Произошла ошибка выполнения конфигурации или входящего правила.
500,51 Произошла ошибка перезаписи во время обработки уведомления GL_PRE_BEGIN_REQUEST. Произошла глобальная конфигурация или ошибка выполнения глобального правила.
500,52 Произошла ошибка перезаписи во время обработки уведомления RQ_SEND_RESPONSE. Выполнение исходящего правила.
500,53 Произошла ошибка перезаписи во время обработки уведомления RQ_RELEASE_REQUEST_STATE. Произошла ошибка выполнения правила для исходящих сообщений. Правило настроено для выполнения до обновления выходного пользовательского кэша.
500,100 Внутренняя ошибка ASP.

Ошибки, похожие на HTTP 500

Многие сообщения об ошибках браузера аналогичны сообщению 500 Internal Server Error, поскольку все они являются ошибками на стороне сервера, например 502 Bad Gateway, 503 Service Unavailable и 504 Gateway Timeout.

Также существует множество кодов состояния HTTP на стороне клиента, например, популярная ошибка 404 Not Found.

Пользователи интернета и владельцы сайтов периодически сталкиваются с различными ошибками на веб-страницах. Одной из самых распространенных ошибок является error 500 (ошибка 500). Поговорим в нашей статье о том, что это за ошибка и как ее исправить.

Где и когда можно встретить ошибку 500

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

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

Отображаться ошибка может по-разному. Вот пример:

Ошибка 500

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

Если ошибка появилась на вашем сайте, то нужно скорее ее исправлять. Далее я расскажу, как это можно сделать.

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подписаться

Причины возникновения ошибки

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

Основной причиной ошибки 500 может быть:

  1. Неверный синтаксис файла .htaccesshtaccess – это файл, в котором можно задавать настройки для работы с веб-сервером Apache и вносить изменения в работу сайта (управлять различными перенаправлениями, правами доступа к файлам, опциями PHP, задавать собственные страницы ошибок и т.д.). 
    Узнать больше о файле .htaccess можно в статье «Создание и настройка .htaccess».
  2. Ошибки в скриптах сайта, то есть сценариях, созданных для автоматического выполнения задач или для расширения функционала сайта.
  3. Нехватка оперативной памяти при выполнении скрипта.
  4. Ошибки в коде CMS, системы управления содержимым сайта. В 80% случаев виноваты конфликтующие плагины. 

Год хостинга в подарок при заказе лицензии 1С-Битрикс

Выбирайте надежную CMS с регулярными обновлениями системы и профессиональной поддержкой.

Заказать

Как получить больше данных о причине ошибки 

Что означает ошибка 500, мы теперь знаем. Когда она перестала быть таким загадочным персонажем, не страшно копнуть глубже — научиться определять причину ошибки. В некоторых случаях это можно сделать самостоятельно, так что обращаться за помощью к профильному специалисту не понадобится.

Отображение ошибки бывает разным. Ее внешний облик зависит от того, чем она вызвана.

Самые частые причины ошибки 500 можно распознать по тексту ошибки или внешнему виду страницы. 

  1. Сообщение Internal Server Error говорит о том, что есть проблемы с файлом .htaccess (например, виновата некорректная настройка файла). Убедиться, что .htaccess является корнем проблемы, поможет следующий прием: переименуйте файл .htaccess, добавив единицу в конце названия. Это можно сделать с помощью FTP-клиента (например, FileZilla) или файлового менеджера на вашем хостинге (в Timeweb такой есть, с ним довольно удобно работать). После изменения проверьте доступность сайта. Если ошибка больше не наблюдается, вы нашли причину.
  2. Сообщение HTTP ERROR 500 или пустая страница говорит о проблемах со скриптами сайта. В случае с пустой страницей стоит учесть, что отсутствие содержимого сайта не всегда указывает на внутреннюю ошибку сервера 500.

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

Как открыть панель разработчика

  • Нажмите клавишу F12 (способ актуален для большинства браузеров на Windows). Используйте сочетание клавиш Cmd+Opt+J, если используете Google Chrome на macOS. Или примените комбинацию Cmd+Opt+C в случае Safari на macOS (но перед этим включите «Меню разработки» в разделе «Настройки» -> «Продвинутые»). Открыть инструменты разработчика также можно, если кликнуть правой кнопкой мыши в любом месте веб-страницы и выбрать «Просмотреть код» в контекстном меню. 
  • Откройте вкладку «Сеть» (или «Network») и взгляните на число в поле «Статус». Код ответа об ошибке 500 — это соответствующая цифра.

Причины ошибки 500Более детальную диагностику можно провести с помощью логов.

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

Как вы видите, данных в логи записывается немало, поэтому они разделены по типам. За сведениями о нашей ошибке можно обратиться к логам ошибок (error_log). Обычно такие логи предоставляет служба поддержки хостинга, на котором размещен сайт. В Timeweb вы можете включить ведение логов и заказать необходимые данные в панели управления. Разобраться в полученных логах поможет статья «Чтение логов».

Как устранить ошибку

Теперь поговорим о том, как исправить ошибку 500. Вернемся к популярным причинам этой проблемы и рассмотрим наиболее эффективные способы решения.

Ошибки в файле .htaccess

У этого файла довольно строгий синтаксис, поэтому неверно написанные директивы (команды) могут привести к ошибке. Попробуйте поочередно удалить команды, добавленные последними, и проверьте работу сайта. 
Также найти проблемную директиву можно с помощью логов ошибок (через те же инструменты разработчика в браузере). На ошибку в директиве обычно указывает фраза «Invalid command». Информацию о верном написании директивы или способе исправления ошибок в .htaccess вы можете найти в интернете. Не нужно искать, почему сервер выдает ошибку 500, просто введите в строку поиска название нужной команды или текст ошибки из логов.

Ошибки в скриптах сайта

Скрипт не запускается

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

Не хватает оперативной памяти

Если в логах вы видите ошибку «Allowed memory size», для устранения ошибки 500 стоит оптимизировать работу скрипта. Вы можете воспользоваться специальными расширениями для анализа производительности скрипта или обратиться за помощью к специалисту, который поработает над его оптимизацией.

Если ваш сайт размещен на отдельном физическом или виртуальном сервере, можно попробовать увеличить максимальное использование оперативной памяти на процесс (memory_limit). На шаред хостинге этот параметр обычно не изменяется, но есть возможность купить хостинг помощнее.

Ошибки в CMS

Если код CMS содержит неверный синтаксис, это может вывести сайт из строя. В таком случае логи сообщат вам об ошибке 500 текстом «PHP Parse error: syntax error, unexpected». Так происходит, когда некорректно работает плагин (или тема, используемая в CMS, но реже) либо есть ошибки в коде. Ошибка может быть допущена случайно, произойти при обновлении плагина или версии CMS.

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

Ошибка 500 из-за плагинов ВордпрессТакже в большинстве случаев подобные проблемы помогает решить поддержка CMS.

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

Удачи! 

Время на прочтение
7 мин

Количество просмотров 4.1K

Итак, произошло то, что произошло, сегодня невозможно сделать сет Directum RX на MS SQL. Microsoft перестал отгружать лицензии в России. Для многих это стало неожиданностью, а для нас — нет. Задолго до введения санкционных ограничений мы позаботились о переходе на PostgreSQL и Linux. Причины были банальны — хотелось сократить расходы на лицензию. 

Также хотелось научиться переводить системы Directum RX на PostgreSQL, предполагая, что слонёнок будет востребован у наших заказчиков по той же финансовой причине. Для нас отказ от баз Microsoft был плановым. Кроме того, мы перевели инфраструктуры вместе с Directum RX на Linux. Сегодня оцениваем эту попытку “переехать” с сокращением затрат как отчасти удачную. 

Я, Виталий Волнянский, руководитель практики технологических решений (CTO), директор по продажам (VPS) ООО “ЕАЕ-Консалт”, под катом расскажу о том, как проходила миграция и с какими проблемами нам пришлось столкнуться.

Предыстория: ещё пару слов о мотивах

Как вы, вероятно, поняли, основным мотивом переезда на PostgreSQL было то, что не нужно платить за лицензию MS SQL. Для PostgreSQL можно купить поддержку, но обязательной опцией она не является, да и цена саппорта не сравнима со стоимостью лицензии Microsoft.

Directum RX мы эксплуатируем с 2017 года. В тот период предложения от вендора было сложно назвать оптимальными, проявлялись несовместимости внутренней инфраструктуры с MS SQL 14. Кроме того, вендор настоятельно рекомендовал использовать в инсталляции ARR Server с устаревшей аутентификацией NTP Authentication, которая применялась в настольном клиенте и не работала с протоколом HTTPS.

Единственным балансировщиком, который нормально поддерживал это решение, был ARR, но у него всё совсем печально с механизмами балансировки. Когда ложился основной сервер, балансировщик не мог эффективно перераспределить новые запросы на резервный. Это и явилось одним из триггерных факторов, которые мотивировали нас усовершенствовать платформу.

Мы осознали, что текущий стек не позволяет добиться высокой доступности, а в нагрузку получаем ещё рутинное избыточное администрирование и отладку систем Directum RX. При использовании балансировки (т.е. при применении нескольких компонентов резервирования) время администрирования увеличивается, приходится отслеживать работоспособность компонентов, следить за тем, куда уходят запросы.

В 2018 году мы решили избавиться от избыточности, поставили один Application Server, одну базу данных. Система была оптимизирована и развивалась, но проблемы продолжали возникать. С выходом третьей версии Directum RX появился web-клиент, в связи с чем произошел переход на новые механизмы аутентификации OpenID и мы поняли, что ARR можно заменить на более эффективный балансировщик, т.е. на Nginx.

Более оптимальный алгоритм и наличие здорового Health Check серьёзно упростили нам жизнь. После замены балансировщика попробовали развернуть второй сервер, что в полной мере не удалось. Поэтому до выхода четвертой версии Directum RX мы вернулись к использованию ARR. Но ещё на версии 3.4 было принято решение о миграции с MS SQL в PostgreSQL как способе сократить лицензионные расходы.

Последовательность действий

Для того, чтобы мигрировать, была определена последовательность этапов:

  1. Обследовать систему.

  2. Подготовить новую систему в Yandex Cloud: установить ВМ, серверы, установить приложения.

  3. Конвертировать данные из MS SQL в PostgreSQL.

  4. Мигрировать в Яндекс.Облако, предоставляемое ЕАЕ-Консалт, обеспечить миграцию Hystax.

  5. Осуществить миграцию стандартного ландшафта.

  6. Поднять ВМ.

  7. Установить Directum RX.

  8. Настроить канал связи между площадками.

  9. Провести синк документов, копирование БД и тестирование в рамках предпродуктивной миграции.

  10. Осуществить продуктивную миграцию.

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

Обследование системы

Предварительным этапом закономерно стало обследование системы. В этой стадии нужно было заранее исключить возможные проблемы совместимости версий.

Что мы делали:

  • проверили объемы баз данных;

  • проанализировали аппаратные требования к миграции, оценили совместимость, и, поняв на какой из версий Linux-систем будет работать Directum RX, выбрали Ubuntu 20.04;

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

На этом подготовительный этап был завершен и можно было перейти к инструменту миграции баз.

Изучение и доработка инструмента миграции из MS SQL в PostgreSQL

Задача конвертации данных из MS SQL в PostgreSQL не далась быстро. Мы были первыми, кто проводил такую миграцию. В то время мы использовали версию Directum RX 3.6, к которой вендор представил специальный инструмент для переноса данных из одной базы в другую. В связи с кастомным расширением нашей системы и использованием модуля CRM, инструмент работал исключительно с “родной” структурой, таблицами и дефолтным внутренним взаимодействием.

Для полноценной работы инструмент пришлось долго и мучительно настраивать и модифицировать SQL-скрипты. Часть модуля CRM использовал .NET Framework, и его пришлось адаптировать для корректной работы на .Net Core и Linux. Вендор оказал поддержку, дописывая решение под нас. Сейчас сложно сказать, сколько раз мы проводили миграцию в процессе отладки. Много. В 2021 году закончили переход на PostgreSQL и решили перейти к следующему этапу. С этого момента мы перестали платить за лицензии MS SQL.

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

Критерии выбора облака и результаты миграции

Оптимизация системы предполагала миграцию из облака вендора, т.е. Directum RXв облако Яндекс. Финансовая суть задачи состояла в том, чтобы сменить инвестиционные расходы на операционные, используя сервис вместо приобретения оборудования. Яндекс был выбран в силу того, что наша компания — партнёр Яндекса, и предложенное ими решение нас полностью удовлетворило.

Предпродуктивное тестирование

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

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

Значимые обновления, хранение данных и режим высокой доступности

После конвертации, возникло желание заставить платформу работать в режиме высокой доступности. Начиная с версии Directum RX 3.6 появилась информация о поддержке Linux-серверов, что обнадёживало. Позже нам предоставили тестовый релиз, и мы поняли, что в системе появились признаки микросервисной архитектуры.

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

До версии 3.8 весь объем данных по умолчанию записывался напрямую в базу. Это приводило к росту баз до неприличных объемов и вызывало проблемы при создании бэкапа и восстановлении системы. К томe же, для работы базы требовалось много оперативной памяти.

Как раз, когда мы конвертировались в PostgreSQL, вендор оптимизировал хранение данных и трансформировал их распределение, отправив контент в файловое хранилище, что здорово упростило бэкап. Несмотря на то, что база не выросла до чудовищных размеров, скорость её роста не предвещала ничего хорошего. Обновленное решение с хранением контента позволило нам существенно упростить задачу и снизить требования к RAM почти в 4 раза. Вместе с этим снизить стоимость виртуальной машины с СУБД. Если раньше резервное копирование базы длилось 3 часа, то сейчас стало занимать не более 20 минут и, соответственно, восстановление системы тоже происходит быстрее.

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

Проблемы внедрения

После того, как было принято решение использовать Yandex Cloud, мы применили Managed PostgreSQL (чтобы частично снять с себя часть ответственности за постоянное администрирование), а также автоматизировать развертывание и внедрить контейнеры kubernetes. Проведя установку, мы поняли, что возникает проблема, инсталлятор требовал полномочий суперпользователя, уровня sys admin. Наличие полных прав на управление базы данных инсталлятору было недостаточно. Ему нужен был полный доступ к серверу PostrgreSQL! 

Вероятно, что тот, кто сделал инсталлятор, имел такой доступ и реализовал решение по существующему шаблону. Решение спорное и не очень распространённое. Обычно в крупных компаниях, где существуют отдельные подразделения, занимающиеся администрированием баз данных, создают кластер серверов, где при необходимости заказываются БД. В данном же случае таких решений не предусмотрели. Мы решили не “ковырять” инсталлятор и отказаться от использования.

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

Сухой остаток

В силу того, что режим высокой доступности в полном смысле реализовать не получилось, возникли проблемы с Managed PostgreSQL, автоматической установкой и контейнерами, абсолютно успешным этот кейс считать сложно. При этом мы решили главные задачи, а именно:

  • сэкономили на лицензиях Microsoft, пока они были доступны в России;

  • сократили текущие расходы, переведя их из инвестиционных в операционные, благодаря использованию Yandex Cloud и уменьшению размера виртуальных машин;

  • гарантировали системе безопасность, ограничив влияние санкционных вендоров;

  • научились проводить миграцию на Linux и PostgreSQL и готовы предложить её клиентам в качестве сервиса, который, по всей видимости, будет достаточно актуальным среди использующих Directum RX.

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

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В прошлый раз мы с вами методы оплаты телефона билайн, я привел вам 5 примеров описывающих 5 приложений и сервисов банков. Сегодня я хочу поговорить вновь про административные вещи, а именно мы рассмотрим по каким причинам может медленно запускаться и работать Directum 5 на терминальной ферме. Думаю с данной проблемой сталкивались многие администраторы и пользователи, так как данное ПО очень популярное.

Описание проблемы

Есть Remote Desktop Services High Availability ферма построенная на базе Windows Server 2019, там установлена система документооборота и автоматизации бизнес процессов Directum 5. Пользователи массово стали жаловаться на долгое открытие и работу в системе irectum 5. Само открытие только занимало от 40 секунд, что самое интересное, на старой RDS ферме, которая была на базе Windows Server 2012 R2, все открывалось за 5 секунд. Короче работать было невозможно.

Возможности системы Directum RX

Долго открывается Directum на терминальной ферме

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

Требования к серверам

  • Тип дисков, очень рекомендуется SSD, тут думаю это требования для всех подойдет
  • От 12 ГБ ОЗУ на сервере приложений с компонентами (IIS)
  • Старайтесь разносить сервер приложений и SQL базу. Для сервера SQL минимум 8 ГБ ОЗУ
  • Скорость локальной сети 1 ГБ
  • ОС Windows Server 2008 R2 и выше, MSQ SQL 2008 и выше

Подробнее можно ознакомиться вот тут — https://www.directum.ru/products/directum/technical_requirements

Проверка ресурсов сервера и клиента

Второе, что вы должны проверить, это не упираетесь ли вы по ресурсам, как на сервере, так и на клиентских станциях. Если у вас есть система мониторинга, например Zabbix, то вы можете посмотреть данные там, если же ее нет, то стоит о ней задуматься, а пока откройте диспетчер задач, сделать это можно через нажатие CTRL+SHIFT+ESC. Тут в режиме реального времени посмотрите нагрузку на CPU и память, если показания высокие, то есть смысл в увеличении ресурсов. Например, у меня данный терминальный сервер находится на виртуальной машине, которая работает на базе гипервизора ESXI 6.5, который в свою очередь лежит на физическом сервере Dell Power Edge R740.

Если в системе явно присутствую зависания, медленное отрывание окон, то откройте «Мониторинг ресурсов»

Мониторинг ресурсов Directum в Windows

Посмотрите на вкладке «Диск», какие процессы у вас к нему обращаются, тут нужно выделить два момента, которые будут вам говорить, о проблемах со скоростью дисковой подсистемы:

Демонстрация обработки и рассмотрения входящего письма (веб-клиент)

  1. Время ответа у процессов — если оно очень высокое, более 100 для HDD и более 20 для SSD, то ваш диск вероятнее всего загружен, что вызывает медленную работу приложений и Directum.
  2. Второй момент это длина очереди, которая не должна превышать 1, если более, то плохо.

Просмотр очередей к диску при медленной работе Directum

Проверка опции DFSS

Ранее я вам рассказывал про функционал Dynamic Fair Share Scheduling (DFSS), который помогал сделать честное распределение ресурсов между пользователями терминалов, но как показала практика, это может приводить и к нехорошим последствиям, когда при запуске приложения ему не хватает ресурсов, в следствии чего вы наблюдаете тормоза, зависания и медленную работу приложений.

После дискуссии с разработчиками Directum (ЕСУД) было выяснено, что лучше отключать Dynamic Fair Share Scheduling (DFSS), так как он сильно влияет на работу приложения. Напоминаю, что там двум ключам EnableCpuQuota и EnableFairShare нужно выставить значение «0».

function Date

«$(Date) Quering computers from AD»
$out_file = «C:TempIS_1112.csv»

«ComputerName;EnableCpuQuota;EnableFairShare» | Out-File $out_file -Force

$comps_file = «C:Tempcomps.txt»
$comps = Get-Content $comps_file
«$(Date) Going to process $($comps.Length) computer records»

foreach ($comp in $comps) # | sort DNSHostName
if (Test-Connection $comp -Count 1 -Quiet)
«$(Date) $comp is online»

«$(Date) Checking for Fair Share CPU Scheduling»

$RegKey1 = $RegKey2 = $EnableCpuQuota = $EnableFairShare = $null

try # $EnableDFSS = (Get-WmiObject -ComputerName $comp.DNSHostName -Class win32_terminalservicesetting -Namespace «rootcimv2TerminalServices»).EnableDFSS
$Reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey(‘LocalMachine’, $comp)

$RegKey1 = $Reg.OpenSubKey(«SYSTEMCurrentControlSetControlSession ManagerQuota System»)
$EnableCpuQuota = $RegKey1.GetValue(«EnableCpuQuota»)

$RegKey2 = $Reg.OpenSubKey(«SYSTEMCurrentControlSetServicesTSFairShareDisk»)
$EnableFairShare = $RegKey2.GetValue(«EnableFairShare»)
>
catch «$(Date) $($_.exception.message)»
>

# «$comp;$EnableCpuQuota;$EnableFairShare»
«$comp;$EnableCpuQuota;$EnableFairShare» | Out-File $out_file -Append -Force
>
else
«$(Date) $comp is offline»
>
>

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

Проверка Dynamic Fair Share Scheduling (DFSS) скриптом

После применения данных изменений вам даже не потребуется перезагрузка системы, все изменения вступят сразу в силу, после чего я запустил DIRECTUM и о чудо он стал запускаться за 6-7 секунд вместо 40-50, эврика. В результате чего вся медленная работа превратилась в быструю.

Дополнительно

Еще накидаю возможных вариантов почему может тормозить Directum на Windows Server 2016-2019:

  • Антивирусное решение — попробуйте его отключить или добавить папку приложения в исключение
  • DEP — как его отключить смотрите по ссылке

На этом у меня все, с вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Популярные Похожие записи:

Источник: pyatilistnik.org

Почему не работает сайт Rx.directum.ru?

Что делать, если не открывается сайт rx.directum.ru? Если с недавнего времени перестал работать ресурс, попробуйте найти причину в нижеприведенных возможных ошибках, которые могут находиться как на стороне сервера, так и на стороне пользователя.

4xx (ошибка клиента)

Коды ответа 4xx при открытии сайта rx.directum.ru в интернет-браузере означают, что произошла ошибка на стороне пользователя:

Ошибка 400

Не работает сайт rx.directum.ru, ошибка в браузере 400 — плохой запрос, в запросе присутствует синтаксическая ошибка (например, в протоколе передачи данных);

Ошибка 401

Недоступен сайт rx.directum.ru, ошибка браузера 401 — авторизация не пройдена, нужна авторизация, но она не пройдена, либо введен неверный логин/пароль. Обычно возникает в случае ввода в форму авторизации неправильных данных;

Ошибка 403

Код ошибки браузера 403 — доступ запрещен. Ошибка 403 означает, что доступ к данным запрещен даже с авторизацией, открыть страницу не получится вообще;

Ошибка 404

Ошибка сайта rx.directum.ru, ошибка 404 — страница с текущим адресом не найдена, запрашиваемый документ (страница) отсутствует или ее адрес изменен.

5xx (ошибка сервера)

Еще один вид ошибок при открытии сайта rx.directum.ru в браузере — 5xx, ошибки на стороне сервера:

Ошибка 500

При открытии сайта rx.directum.ru появляется код ошибки 500 — внутренняя ошибка сервера, на сервере произошла неизвестная ошибка;

Ошибка 501

Недоступность rx.directum.ru, серверная ошибка 501 — не реализовано, сервер не поддерживает технологии для обработки запроса;

Ошибка 503

Не хочет работать сайт rx.directum.ru, код ошибки сервера 503 — сервер недоступен. Сервер по техническим причинам не может обрабатать запрос;

Ошибка 522

Не работает сайт — rx.directum.ru, ошибка сервера 522 — сервер перегружен, например, из-за большого количества посещений или DDoS-атаки.

При открытии rx.directum.ru на экране белое окно

Если вместо сайта rx.directum.ru белое окно, пустое место, значит, в глобальной Сети или на стороне провайдера возникли ошибки маршрутизации, либо владельцы вовремя не продлили действие домена — rx.directum.ru и он стал неактивным.

При невозможности открытия любых сайтов наиболее вероятна причина с общей недоступностью Интернета, либо интернет-ресурс может быть заблокирован по решению суда Роскомнадзором, согласно Федеральному закону ФЗ-149. Случаи, когда невозможно войти в личный кабинет rx.directum.ru, выходят за рамки этой заметки.

Источник: nerobit.ru

Миграция электронного документооборота Directum RX на Linux и PostgreSQL

Итак, произошло то, что произошло, сегодня невозможно сделать сет Directum RX на MS SQL. Microsoft перестал отгружать лицензии в России. Для многих это стало неожиданностью, а для нас — нет. Задолго до введения санкционных ограничений мы позаботились о переходе на PostgreSQL и Linux. Причины были банальны — хотелось сократить расходы на лицензию.

Также хотелось научиться переводить системы Directum RX на PostgreSQL, предполагая, что слонёнок будет востребован у наших заказчиков по той же финансовой причине. Для нас отказ от баз Microsoft был плановым. Кроме того, мы перевели инфраструктуры вместе с Directum RX на Linux. Сегодня оцениваем эту попытку “переехать” с сокращением затрат как отчасти удачную.

Я, Виталий Волнянский, руководитель практики технологических решений (CTO), директор по продажам (VPS) ООО “ЕАЕ-Консалт”, под катом расскажу о том, как проходила миграция и с какими проблемами нам пришлось столкнуться.

Предыстория: ещё пару слов о мотивах

Как вы, вероятно, поняли, основным мотивом переезда на PostgreSQL было то, что не нужно платить за лицензию MS SQL. Для PostgreSQL можно купить поддержку, но обязательной опцией она не является, да и цена саппорта не сравнима со стоимостью лицензии Microsoft.

Directum RX мы эксплуатируем с 2017 года. В тот период предложения от вендора было сложно назвать оптимальными, проявлялись несовместимости внутренней инфраструктуры с MS SQL 14. Кроме того, вендор настоятельно рекомендовал использовать в инсталляции ARR Server с устаревшей аутентификацией NTP Authentication, которая применялась в настольном клиенте и не работала с протоколом HTTPS.

Единственным балансировщиком, который нормально поддерживал это решение, был ARR, но у него всё совсем печально с механизмами балансировки. Когда ложился основной сервер, балансировщик не мог эффективно перераспределить новые запросы на резервный. Это и явилось одним из триггерных факторов, которые мотивировали нас усовершенствовать платформу.

Мы осознали, что текущий стек не позволяет добиться высокой доступности, а в нагрузку получаем ещё рутинное избыточное администрирование и отладку систем Directum RX. При использовании балансировки (т.е. при применении нескольких компонентов резервирования) время администрирования увеличивается, приходится отслеживать работоспособность компонентов, следить за тем, куда уходят запросы.

В 2018 году мы решили избавиться от избыточности, поставили один Application Server, одну базу данных. Система была оптимизирована и развивалась, но проблемы продолжали возникать. С выходом третьей версии Directum RX появился web-клиент, в связи с чем произошел переход на новые механизмы аутентификации OpenID и мы поняли, что ARR можно заменить на более эффективный балансировщик, т.е. на Nginx.

Более оптимальный алгоритм и наличие здорового Health Check серьёзно упростили нам жизнь. После замены балансировщика попробовали развернуть второй сервер, что в полной мере не удалось. Поэтому до выхода четвертой версии Directum RX мы вернулись к использованию ARR. Но ещё на версии 3.4 было принято решение о миграции с MS SQL в PostgreSQL как способе сократить лицензионные расходы.

Последовательность действий

Для того, чтобы мигрировать, была определена последовательность этапов:

  1. Обследовать систему.
  2. Подготовить новую систему в Yandex Cloud: установить ВМ, серверы, установить приложения.
  3. Конвертировать данные из MS SQL в PostgreSQL.
  4. Мигрировать в Яндекс.Облако, предоставляемое ЕАЕ-Консалт, обеспечить миграцию Hystax.
  5. Осуществить миграцию стандартного ландшафта.
  6. Поднять ВМ.
  7. Установить Directum RX.
  8. Настроить канал связи между площадками.
  9. Провести синк документов, копирование БД и тестирование в рамках предпродуктивной миграции.
  10. Осуществить продуктивную миграцию.

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

Обследование системы

Предварительным этапом закономерно стало обследование системы. В этой стадии нужно было заранее исключить возможные проблемы совместимости версий.

  • проверили объемы баз данных;
  • проанализировали аппаратные требования к миграции, оценили совместимость, и, поняв на какой из версий Linux-систем будет работать Directum RX, выбрали Ubuntu 20.04;
  • определили, какую базу данных мы можем использовать, определив требования и параметры будущей инфраструктуры и возможности подготовки ландшафтов (в соответствии с рекомендациями вендора).

На этом подготовительный этап был завершен и можно было перейти к инструменту миграции баз.

Изучение и доработка инструмента миграции из MS SQL в PostgreSQL

Задача конвертации данных из MS SQL в PostgreSQL не далась быстро. Мы были первыми, кто проводил такую миграцию. В то время мы использовали версию Directum RX 3.6, к которой вендор представил специальный инструмент для переноса данных из одной базы в другую. В связи с кастомным расширением нашей системы и использованием модуля CRM, инструмент работал исключительно с “родной” структурой, таблицами и дефолтным внутренним взаимодействием.

Для полноценной работы инструмент пришлось долго и мучительно настраивать и модифицировать SQL-скрипты. Часть модуля CRM использовал .NET Framework, и его пришлось адаптировать для корректной работы на .Net Core и Linux. Вендор оказал поддержку, дописывая решение под нас. Сейчас сложно сказать, сколько раз мы проводили миграцию в процессе отладки. Много.

В 2021 году закончили переход на PostgreSQL и решили перейти к следующему этапу. С этого момента мы перестали платить за лицензии MS SQL.

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

Критерии выбора облака и результаты миграции

Оптимизация системы предполагала миграцию из облака вендора, т.е. Directum RX, в облако Яндекс. Финансовая суть задачи состояла в том, чтобы сменить инвестиционные расходы на операционные, используя сервис вместо приобретения оборудования. Яндекс был выбран в силу того, что наша компания — партнёр Яндекса, и предложенное ими решение нас полностью удовлетворило.

Предпродуктивное тестирование

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

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

Значимые обновления, хранение данных и режим высокой доступности

После конвертации, возникло желание заставить платформу работать в режиме высокой доступности. Начиная с версии Directum RX 3.6 появилась информация о поддержке Linux-серверов, что обнадёживало. Позже нам предоставили тестовый релиз, и мы поняли, что в системе появились признаки микросервисной архитектуры.

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

До версии 3.8 весь объем данных по умолчанию записывался напрямую в базу. Это приводило к росту баз до неприличных объемов и вызывало проблемы при создании бэкапа и восстановлении системы. К томe же, для работы базы требовалось много оперативной памяти.

Как раз, когда мы конвертировались в PostgreSQL, вендор оптимизировал хранение данных и трансформировал их распределение, отправив контент в файловое хранилище, что здорово упростило бэкап. Несмотря на то, что база не выросла до чудовищных размеров, скорость её роста не предвещала ничего хорошего. Обновленное решение с хранением контента позволило нам существенно упростить задачу и снизить требования к RAM почти в 4 раза. Вместе с этим снизить стоимость виртуальной машины с СУБД. Если раньше резервное копирование базы длилось 3 часа, то сейчас стало занимать не более 20 минут и, соответственно, восстановление системы тоже происходит быстрее.

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

Проблемы внедрения

После того, как было принято решение использовать Yandex Cloud, мы применили Managed PostgreSQL (чтобы частично снять с себя часть ответственности за постоянное администрирование), а также автоматизировать развертывание и внедрить контейнеры kubernetes. Проведя установку, мы поняли, что возникает проблема, инсталлятор требовал полномочий суперпользователя, уровня sys admin. Наличие полных прав на управление базы данных инсталлятору было недостаточно. Ему нужен был полный доступ к серверу PostrgreSQL!

Вероятно, что тот, кто сделал инсталлятор, имел такой доступ и реализовал решение по существующему шаблону. Решение спорное и не очень распространённое. Обычно в крупных компаниях, где существуют отдельные подразделения, занимающиеся администрированием баз данных, создают кластер серверов, где при необходимости заказываются БД. В данном же случае таких решений не предусмотрели. Мы решили не “ковырять” инсталлятор и отказаться от использования.

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

Сухой остаток

В силу того, что режим высокой доступности в полном смысле реализовать не получилось, возникли проблемы с Managed PostgreSQL, автоматической установкой и контейнерами, абсолютно успешным этот кейс считать сложно. При этом мы решили главные задачи, а именно:

  • сэкономили на лицензиях Microsoft, пока они были доступны в России;
  • сократили текущие расходы, переведя их из инвестиционных в операционные, благодаря использованию Yandex Cloud и уменьшению размера виртуальных машин;
  • гарантировали системе безопасность, ограничив влияние санкционных вендоров;
  • научились проводить миграцию на Linux и PostgreSQL и готовы предложить её клиентам в качестве сервиса, который, по всей видимости, будет достаточно актуальным среди использующих Directum RX.

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

Источник: habr.com

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Cancel Create

directum / memo / readme.md

  • Go to file T
  • Go to line L
  • Copy path
  • Copy permalink

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Cannot retrieve contributors at this time
398 lines (284 sloc) 21.3 KB

  • Open with Desktop
  • View raw
  • Copy raw contents Copy raw contents Copy raw contents

Copy raw contents

Заметки по результатам обновления в Directum с версии 4.9.1 на 5.2.1 в мае 2016 года.

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

На сервере (или на серверах) запускаются только службы, которые выполняют каждая свою узкую функцию:

Session Server (SBSessionServer)

Проверяет количество лицензий и открывает (или нет) пользователю полноценный доступ к SQL-серверу.

Не имеет настроек, требует наличия корректно сгенерированного ключа системы.

Workflow Processing (SBWorkflowProcessingServer)

Фоновая обработка задач и заданий.

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

Служба конфигурируется через файл C:Program Files (x86)DIRECTUM CompanyDIRECTUM 5.2SBWorkflowSrvSettings.xml где просто должны быть указаны все обслуживаемые ею базы данных.

Клиент Directum на сервер не ставится, его функции становятся доступны после установки данной службы.

Storage Service (SBFileStorageService)

Применяется для того, чтобы хранить тексты документов не в базе данных SQL, а в папке, что резко сокращает нагрузку на сервер MS SQL.

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

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

Служба настраивается через файл C:Program Files (x86)DIRECTUM CompanyDIRECTUM 5.2Storage ServicesSBFileStorageSettings.xml в нём также следует указать все БД, обслуживаемые службой.

В БД Directum также требуется указывать, что она обслуживается данной службой, добавив её параметры в Утилиты администратора / Администрирование хранилищ / Хранилища текстов документов

Обычно запуск новой БД (если все службы уже запущены и работают) требует следующих шагов:

  • Восстановление БД из резервной копии
  • Активация БД (настройка служебных пользователей) утилитой SASystemActivator.exe
  • Регистрация системы, то есть получение ключа (лицензии на кол-во пользователей) и внесение его в БД утилитой SAKeyRegistration.exe
  • Подключение БД к службам Workflow и Storage по необходимости

Directum 5.2 не работает на Windows Server 2003, а серверная часть к тому же на Windows XP. Поэтому обновление производилось не «на месте», а на новый сервер Windows Server 2008 R2.

До установки MS SQL нужно убедиться, что на сервере установлена русская локаль (Russia).

Можно устанавливать MS SQL в минимальной конфигурации, однако есть смысл сразу же добавить к нему компоненту Full Text Search. Это можно сделать и позже в любое время.

Рекомендуется дать права администратора SQL (sysadmin) группе OMZGLOBAL#modifyDIT и право доступа на сервер (public) группе NT AUTHORITYAuthenticated Users. Это позволит не создавать логины SQL-сервера для каждого пользователя.

Установка Directum зачастую требует переименования хоста с установленным MS SQL. В этом случае после переименования требуется выполнить команду:

sp_dropserver old_name>; GO sp_addserver new_name>, local; GO

Directum требует настройки:

sp_configure ‘show advanced options’, 1; RECONFIGURE; sp_configure ‘clr enabled’, 1; RECONFIGURE;

Если планируется использовать (для администрирования) команду xp_cmdshell (например xp_cmdshell ‘net use z: hostfolder’ ), её требуется разрешить:

EXEC sp_configure ‘show advanced options’, 1 GO RECONFIGURE GO EXEC sp_configure ‘xp_cmdshell’, 1 RECONFIGURE

Требуется вручную открыть порты (Windows Firewall with Advanced Security) для служб Directum и для MS SQL:

  • MS SQL: 1433
  • Session: 32300
  • Workflow: 32310
  • Storage: 32320

Установку IIS следует делать по инструкции администратора Directum. Суть: требуется установка компонент

  • ASP.Net
  • ASP
  • Management Service

Требуется добавить в MIME Types строку

Патч для канцелярии

До начала обновления Directum (в случае тестового обновления — до backup) требуется сбить параметр Утилиты разработчика / Типы справочников / РКК / Представления / Главное / Иерархия на: По журналам регистрации

После обновления можно его вернуть на По местам регистрации .

Убедитесь (на сайте https://support.directum.ru/) что имеется годное разрешение на генерацию ключа.

Выполняется согласно инструкции по обновлению Directum запуском STConverter.exe и указанием пакета обновления Packagedirectum_to_521.dat

  • Конвертировать только разработку платформы
  • НЕ: Автоматически конвертировать, Автоматически разрешать конфликты импорта разработки системы
  • НЕ: Повторное сравнение разработки

Настройка вариантов запуска компонент: SBLauncher.exe -CT=ComponentTokenDesigner

Запуск от имени Administrator, пакет PackageDIRECTUM52_tokens.xml

Настройка домена для пользователей (при помощи консоли MS SQL):

Update MBUser Set Domain=’OMZGLOBAL’ Where Domain is Null And NeedEncode = ‘W’ And UserStatus = ‘П’

При помощи Проводника Directum:

  • Импорт записей справочников Роли PackageStandardDataРОЛ
  • Импорт типовых маршрутов PackageStandardDataТМТ Внимание! Часть блоков может не заполниться (см. лог импорта), требуется донастроить их вручную
  • Импорт обложек из PackageStandardDataОбложки (Документы произвольной формы), в Установках WebFoldersAllowed = Y, уже должна быть запущена служба Storage

Дополнительно для обновления с версии 4.9.1

Эти шаги тоже делаются согласно инструкции, вот они в краткой форме:

  • Шаг 1
  • Импорт записей справочников PackageStandardDataCurrency
  • Утилиты разработчика / Типовые маршруты / Канцелярия / Исполнение поручений / Параметры
  • Типовой маршрут для создания подчиненных поручений = Отправка подчиненного поручения на исполнение
  • Типовой маршрут для контроля исполнения = Контроль исполнения поручения (уже)
  • Типовой маршрут для создания подчиненных поручений = Отправка подчиненного поручения на исполнение
  • Импорт записей справочника PackageStandardDataOTP
  • Утилиты администратора / Общее администрирование / Мастера действий / * / Параметры
  • Оформление заявления (отпуск/отгул/увольнение) ТМЗаявление = Утверждение заявления
  • Оформление служебной записки. ТМ = Согласование служебных записок
  • PackageAssignmentsAndTypicalAssignments
  • Справочник Настройки дополнительных реквизитов справочников: Настройки: Поручения по РКК -> Поручения
  • Спрятать ссылку на Поручения по РКК
  • Делопроизводители
  • Руководство
  • Руководители подразделения
  • Делопроизводители Обращения граждан и организаций
  • Тип карточки документа = Договорные документы (уже)
  • Исполнение поручений по РКК = Исполнение поручений (. )
  • Справочник Правила вычисления ролей / ПомощникРуководителя для типовых маршрутов
  • Ничего не делаем (переносим из Роли Секретарь руководителя)

Сервер ссылок Hyperlink

Устанавливается простым копированием в папку C:inetpubwwwroot .

Рекомендуется обращаться к ней через Default Web Site (привязанный к адресу *) по ссылке вида http://directum.omzglobal.com/doc.asp.

Настройка клиентов: Установки системы

  • MB_AWebServerName = directum.omzglobal.com

Пока гиперссылки не работают, обложки папок тоже работать не будут!

Устанавливается по инструкции, для него создаётся отдельный Virtual site, рекомендуется привязать его к хосту Directum.

Подключение клиентов выполняется через Установки системы

  • HelpServerName = http://directum/DIRECTUM

Установка клиента Directum на пользовательские машины

Разработчик предлагает делать установку клиента при помощи msi пакета (см. инструкцию администратора).

Однако в версии 5.2 в msi пакет не попал установщик SQL Native Client, в результате чего свежеустановленный клиент Directum оказывается неработоспособным на машинах с Windows XP.

Был разработан альтернативный вариант установки при помощи самописного скрипта (конфигурируемого при помощи файла YAML), запускающего стандартный установщик клиента Directum (Client.exe).

Для массового обновления клиентов в ночь обновления был дописан ещё один самописный скрипт, который проверяет наличие на машине стандартной папки Directum v4.9.1, запускает его удаление при помощи msiexec и передаёт управление скрипту установки. Факт попытки обновления журналируется. Скрипт может быть запущен на все клиентские машины при помощи SCCM.

Дополнительные клиентские компоненты

Дистрибутивы расположены в DIRECTUM Enterprise 5 2 1 с инструментом разработчика.zip (в папке DIRECTUMF$DirectumDistrib5.2.1):

  • Конструктор документов — DocumentGeneratorDocumentGenerator-??bit.exe
  • Интеграция с MS Office — OfficeIntOfficeIntegration-??bit.exe

Настройка после обновления

Directum самостоятельно настраивает резервное копирование БД в процессе установки.
Рекомендуется его отключить (SQL Server Agent / Jobs) и настроить своё.

Почтовые настройки Directum

В ходе обновления был отключён механизм рассылки через Microsoft Outlook и настроена рассылка по протоколу SMTP как кардинально более простая.

Настройки заданы в константе MailOutgoingSettings (или через пункт Почта на обложке Настройки системы), используется пользователь OMZGLOBALdirectummail, созданный специально для этой цели.

Directum предлагает два вида полнотекстового поиска:

  • По текстам документов. Признан ненужным и не используется
  • По текстам задач и заданий

Второй тип поиска требует настройки (согласно инструкции):

  1. Однократного запуска сценария Индексирование текстов и слепков объектов
  2. Периодического регулярного запуска того же сценария

Directum требует массы периодических заданий. Для их настройки используется стандартный Task Scheduler, в котором заведена отдельная папочка Directum.

На данный момент настроены задания:

  • block — блокирование пользователей Directum, заблокированных в AD
  • ca — импорт сертификатов ЭЦП
  • fulltext — обновление полнотекстовых индексов
  • mail — рассылка уведомлений о заданиях (используется сценарий MailJobs, полученный правкой стандартного сценария Агент рассылки входящих заданий)
  • Выгрузка в 1С
  • Совещания

Тексты простых скриптов расположены в папке tasks.

Остальные скрипты — в папке dist.

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

Скрипты для администрирования Directum

В ходе обновления был создан механизм написания сложных скриптов для администрирования Directum.

Скрипты пишутся на языке CoffeeScript, может быть также использован обычный JavaScript. Исходные коды транслируются в JavaScript, собираются и дополнительно сжимаются.

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

Исходные коды, готовые утилиты и краткие инструкции по сборке расположены в репозитории https://github.com/ukoloff/directum/

Directum 5.2 гораздо хуже относится к дублированию кода системы. Все экземпляры системы должны иметь разный код, даже если они установлены на разных серверах.

Служба File Storage Service бывает самопроизвольно останавливается и не запускается. Лечится удалением файлов C:Program Files (x86)DIRECTUM CompanyDIRECTUM 5.2Storage ServicesOpenedDocumentVersionInfoList*.cfg

Некоторые странные ошибки на клиенте (включая вызванные совпадение кодов системы, но не только) лечатся очисткой метаданных.

На клиентском компьютере выполняется (универсальный) скрипт:

rd «%TEMP%IS-Builder» /s /q rd «%APPDATA%NPO ComputerIS-Builder» /s /q rd «%SystemDrive%Documents and SettingsDefault UserApplication DataNPO ComputerIS-Builder» /s /q rd «%SystemDrive%UsersDefaultAppDataRoamingNPO ComputerIS-Builder» /s /q

Очистка метададанных на стороне сервера (лучше выполнять в нерабочее время):

  • Выполнить SQL: Update SBMetadataLastUpdates Set LastUpdate = GETDATE(), Metadata = null
  • Перезапустить сервер сеансов
  • Запустить сценарий «Обновление кэша метаданных»

Источник: github.com

Внутренняя ошибка сервера directum rx

Установка веб-доступа

Известные проблемы и пути их решения

Не работают гиперссылки на документы DIRECTUM

При работе с гиперссылками на документы DIRECTUM существуют следующие проблемы и пути их решения:

1. Если вместо загружаемого документа отображается текст с параметрами документа, то причина в том, что на клиентском компьютере не установлено соответствие обработчика isb-файлов и расширения «.isb». В этом случае необходимо переустановить клиентскую часть на клиентском компьютере.

2. При установке сервера веб-доступа к DIRECTUM неверно заданы параметры локальной сети. Можно исправить ситуацию, выполнить следующее:

· Шаг 1. Запустите утилиту конфигурирования сервера веб-доступа C : Program Files DIRECTUM Company WebAccessConfig DirWebConfigurator . exe ;

· Шаг 2. Окно «Выбор веб-узла Сервера веб-доступа к DIRECTUM »:

а) в выпадающем списке выберите веб-узел сервера веб-доступа к DIRECTUM . По умолчанию «Сервер веб-доступа к DIRECTUM »;

б) нажмите на кнопку OK ;

· Шаг 3. Окно «Параметры Сервера веб-доступа к DIRECTUM », закладка «Общие»:

а) перейдите на закладку «Обработчик гиперссылок»;

б) заполните поля «Идентификатор сети» и «Маска подсети» группы «Параметры локальной сети» корректными значениями;

в) нажмите на кнопку OK.

3. В свойствах веб-узла не задана обработка isb-файлов. Для устранения этой проблемы необходимо сделайте следующее:

· Шаг 1. Запустите утилиту конфигурирования сервера веб-доступа C : Program Files DIRECTUM Company WebAccessConfig DirWebConfigurator . exe ;

· Шаг 2. Окно «Выбор веб-узла Сервера веб-доступа к DIRECTUM »:

а) в выпадающем списке выберите веб-узел сервера веб-доступа к DIRECTUM . По умолчанию «Сервер веб-доступа к DIRECTUM »;

б) нажмите на кнопку OK ;

· Шаг 3. Окно «Параметры Сервера веб-доступа к DIRECTUM », закладка «Общие»:

а) перейдите на закладку «Настройка веб-узла»;

б) нажмите на кнопку Установить требуемые значения;

в) нажмите на кнопку OK.

4. На сервере веб-доступа не установлен обработчик ASP-сценариев. Для восстановления обработки, с помощью мастера установки компонент Windows установите компоненту Active Server Pages. Для IIS 6.0 после установки убедитесь, что расширение веб-служб Active Server Pages разрешено. Для этого:

а) откройте консоль администратора «Управление компьютером»;

б) перейдите в узел «Службы и приложения» → «Диспетчер служб IIS» → «Расширения веб-служб»;

Для IIS 6.0 после установки добавьте в свойствах веб-узла библиотеку ISAPI, соответствующую расширению ASP. Для этого:

а) на закладке Фильтры ISAPI добавьте новый фильтр с названием ASP;

б) в качестве обработчика установите файл %WINDIR%system32inetsrvasp.dll;

в) перезапустить Internet Information Services.

5. Если на клиенте(ах) не установлен обработчик ярлыков IS-Builder (isbexec), а клиент входит в локальную сеть (группа полей «Параметры локальной сети» на закладке «Обработчик гиперссылок» утилиты конфигурирования сервера веб-доступа), то необходимо включить этого клиента(ов) в список исключений. При обращении с адресов из списка исключений гиперссылки всегда будут открываться через веб-доступ, а не генерировать ярлыки IS-Builder. Для настройки списка исключений сделайте следующее:

· Шаг 1. Запустите утилиту конфигурирования сервера веб-доступа C : Program Files DIRECTUM Company WebAccessConfig DirWebConfigurator . exe .

· Шаг 2. Окно «Выбор веб-узла Сервера веб-доступа к DIRECTUM »:

а) в выпадающем списке выберите веб-узел сервера веб-доступа к DIRECTUM . По умолчанию «Сервер веб-доступа к DIRECTUM »;

б) нажмите на кнопку OK ;

· Шаг 3. Окно «Параметры Сервера веб-доступа к DIRECTUM », закладка «Общие»:

а) перейдите на закладку «Обработчик гиперссылок»;

б) заполните поля «Идентификатор сети» и «Маска подсети» группы «Параметры списка исключений» требуемыми значениями;

в) нажмите на кнопку OK.

Источник: www.erpandcrm.ru

Содержание

  1. Агент веб-доступа DIRECTUM 5.0
  2. Одна из причин подвисания системы DIRECTUM (случай из практики)
  3. Одна из причин подвисания системы DIRECTUM (случай из практики)
  4. Для чего написана эта статья?
  5. Настройка рабочего места для работы с web-интерфейсом СЭД DIRECTUM 5.4
  6. Сетевые настройки
  7. Требования к прикладному ПО
  8. Установка Агента-веб-доступа
  9. Настройка выплывающих окон
  10. Chrome
  11. Firefox
  12. Internet Explorer
  13. Настройка обработчика приложений
  14. Chrome
  15. Firefox
  16. Directum RX 4.1 для локальной установки в вопросах и ответах
  17. Как снизить нагрузку на веб-сервер?
  18. Зачем нужна утилита RxCmd? И чем она отличается от DrxUtil?
  19. Сколько существует типов аутентификации с сервисом интеграции?
  20. Можно ли шифровать параметры в конфигурационных файлах?
  21. Что сделано для Directum RX на Linux?
  22. Поддерживается ли работа с облачной электронной подписью?
  23. Как разработчикам создавать сценарии для правил согласования?
  24. Можно ли изменять стили для документов, заданий и записей справочников?
  25. Как установить сервисы Directum Ario?
  26. Есть ли изменения в мобильных решениях Directum RX?

Агент веб-доступа DIRECTUM 5.0

Опубликовано:
18 февраля 2014 в 08:24

В DIRECTUM 5.0 заметно преобразился и расширил свой функционал веб-доступ. Во многом это произошло благодаря появлению на свет Агента веб-доступа – приложения для Windows, которое устанавливается на компьютере пользователя и позволяет:

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

При входе в систему DIRECTUM через веб-доступ автоматически появится запрос на установку Агента. После установки Агент веб-доступа запускается при каждом входе в систему через веб-доступ и работает в фоновом режиме. В области уведомлений панели задач Windows появится значок

Теперь редактировать документы в веб-доступе стало так же просто, как в desktop-клиенте! Достаточно привычным образом открыть документ и начать его редактирование. Все изменения автоматически сохранятся в системе, дополнительных действий не потребуется.

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

Веб-доступ в DIRECTUM 5.0 во многом приблизился к своему старшему брату – desktop-клиенту. Приятной вам работы в обновленном веб-доступе!

Источник

Одна из причин подвисания системы DIRECTUM (случай из практики)

Опубликовано:
11 апреля 2014 в 17:50

Одна из причин подвисания системы DIRECTUM (случай из практики)

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

Как правило, в такой ситуации необходимо искать причину либо в блокировках на SQL-сервере, либо проблема с ресурсами самого железа (сервер, сеть и т.д.).

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

Что было предпринято: стандартный набор – записаны и проанализированы счетчики ОС и SQL сервера. Так вот, выяснилось, что в некоторые моменты времени происходило полное исчерпание всей доступной оперативной памяти на сервере. Здесь стоит отметить, что на SQL расположен один экземпляр SQL и более не стоит никакого дополнительного ПО.

С другой стороны SQL обычно использует всю доступную ему память под кэширование пользовательских запросов, если эти аппетиты не ограничить явно настройкой Minimum Server Memory и Maximum Server Memory.

Так вот в нашем случае, для нужд системы был оставлен запас не менее 10-12 ГБ (без учета потребления самим процессом sqlservr.exe), что теоретически должно было исключить резкое исчерпание доступной памяти. Но в нашем случае, 10 ГБ свободного пространства не спасали от этой проблемы.

Кроме того, ситуация усугублялась тем, что после нескольких таких «исчерпаний», кластер считал, что ноду недоступной (собственно логично) и переводил активность на резервную.

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

Тем не менее ситуация с исчерпанием памяти повторилась через несколько недель:

Т.е. по сути уменьшив объем буферного пула SQL мы лишь отсрочили появление проблемы.

Не буду описывать в деталях, но было выяснено, что в некоторый момент времени, процесс sqlservr.exe потреблял памяти значительно больше, чем было доступно системе, что в итоге и приводило к подвисанию системы DIRECTUM и всего SQL-сервера

Далее был проведен детальный анализ для выяснения того, что именно приводит к увеличению потребления памяти процессом sqlservr.exe, в том числе с привлечением специалистов MicroSoft.

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

Узнать размер хранилища TokenAndPermUserStore можно с помощью запроса:

И действительно, в моменты «исчерпания» всей доступной памяти значения TokenAndPermUserStore значительно отличались от обычного.

Одной из наиболее вероятных причин была названа утечка памяти, описанная в статьях http://support.microsoft.com/kb/2277078 и http://support.microsoft.com/kb/927396/en-us. И хотя в статьях идет речь о исправлении проблемы в CU3 для 2008 и проблеме в 2005 версии SQL соответственно, по факту проблема имеет место быть и в 2008 R2 версии, хотя ее вероятность значительно снижена.

В качестве временных рекомендаций для устранения этой проблемы предложено периодически выполнять очистку кэша этого хранилища:

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

Для чего написана эта статья?

Во-первых, поделится опытом с сообществом, возможно, кому-то этот опыт будет полезен.

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

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

Источник

Настройка рабочего места для работы с web-интерфейсом СЭД DIRECTUM 5.4

Оглавление

Статьи раздела

Сетевые настройки

Агент веб-доступа не поддерживает работу через прокси-сервера, в связи с чем для корректной работы веб-доступа необходимо настроить подключение к ресурсу https://doc.nsso.ru минуя прокси, через NAT.

При использовании PAC (Proxy Auto-Configuration) скриптов необходимо явное указание прокси сервера и порта в настройках браузера.

Требования к прикладному ПО

  • .net framework 4
  • Microsoft Internet Explorer 10 и выше
  • Google Chrome 60 и выше
  • Mozilla Firefox 54 и выше

Установка Агента-веб-доступа

При первом подписании документа на экране появится сообщение следующего содержания:

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

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

После того как установка завершена в правом нижнем углу рабочего стола появится значок Агента веб-доступа после чего вы можете приступать к подписыванию документов.

Настройка выплывающих окон

Для корректной работы экспорта в DIRECTUM необходимо разрешить всплывающие окна, для это выполните следующие настройки:

Chrome

В адресной сроке браузера введите chrome://settings/content/popups?search=site, в открывшемся окне добавьте адрес https://doc.nsso.ru в раздел разрешенных

Firefox

В адресной сроке браузера введите about:preferences#content, в открывшемся окне добавьте адрес https://doc.nsso.ru в раздел разрешенных

Internet Explorer

Настройки-Конфиденциальность-Включить блокирование всплывающих окон-Параметры, в открывшемся окне добавьте адрес https://doc.nsso.ru в раздел разрешенных

Настройка обработчика приложений

Chrome

Убедитесь что обработчики приложений включены в браузере, для этого в адресной строке введите chrome://settings/handlers?search=Handlers, в открывшемся окне опция должна быть включена.

Firefox

В адресной строке браузера введите about:preferences#applications, в открывшемся окне должна быть запись waagenbt54

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

Источник

Directum RX 4.1 для локальной установки в вопросах и ответах

Опубликовано:
30 августа в 11:37

Из статьи вы узнаете, какие новые сервисы помогут снизить нагрузку с веб-сервера, как разработчикам создавать свои сценарии для правил согласования, чем утилита RxCmd отличается от DrxUtil и многое другое.

ПРИМЕЧАНИЕ. Версия Directum RX 4.1 для локальной установки включает все новинки облачной версии.

Как снизить нагрузку на веб-сервер?

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

Схема работы сервиса отчетов (ReportService):

Схема работы сервиса виджетов (WidgetsService):

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

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

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

Зачем нужна утилита RxCmd? И чем она отличается от DrxUtil?

В новой версии на смену утилите DrxUtil пришла новая утилита RxCmd. Теперь исключительно она используется для решения следующих задач:

  • запуск интеллектуальной обработки документов, полученных с электронной почты или из папки с помощью службы ввода Directum Capture Service (DCS);
  • настройка классификации документов в сервисах Directum Ario;
  • импорт, экспорт и удаление шаблонов документов.

Главное преимущество RxCmd в том, что эта утилита кроссплатформенная: работает в операционных системах Microsoft Windows и Linux. Кроме того, новая утилита выполняет команды быстрее.

Старая утилита DrxUtil продолжает поставляться, но для узких задач, например для синхронизации данных из 1С и Active Directory. Если вы самостоятельно разрабатывали интеграции с помощью утилиты DrxUtil, то этот код продолжит работать, но его рекомендуется перевести на плагины RxCmd. В ближайших версиях поддержка утилиты DrxUtil будет прекращена.

Подробнее об особенностях работы утилиты расскажем в отдельной статье. Следите за публикациями на Directum Club.

Сколько существует типов аутентификации с сервисом интеграции?

Шесть. При обмене данными внешние системы обязательно проходят аутентификацию при обращении к сервису интеграции. Раньше использовалась только базовая аутентификация (basic access authentication). Для идентификации сервису интеграции требовались учетные данные пользователя с типом аутентификации по паролю. В новой версии для обращения к сервису добавлены:

  • базовая аутентификация с использованием доменных учетных записей (LDAP);
  • аутентификация по протоколам NTLM и Kerberos. Протокол NTLM обычно используется при обращении к сервису извне, например из дома, а Kerberos – при обращении внутри сети;
  • аутентификация по токенам;
  • аутентификация на основе Сookies.

Какой тип использовать – зависит от требований внешней системы и ситуации.

Можно ли шифровать параметры в конфигурационных файлах?

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

Утилита входит в стандартную поставку. Зашифровать данные можно после установки системы, при ее сопровождении.

Порядок шифрования зависит от операционной системы, на которой развернута система Directum RX. Подробнее см. в справке:

Что сделано для Directum RX на Linux?

1. Компоненты системы переведены на версию .NET Core 3.1

Веб-сервер, среда разработки и все микросервисы Directum RX переведены на версию .NET Core 3.1. Если вы используете какие-либо сторонние компоненты в своей разработке, то их необходимо перевести на указанную версию.

Если же ваши сторонние компоненты поддерживают работу только с .NET Framework и используются в вычислениях сервиса асинхронных событий Worker, то для совместимости оставлена возможность перенастроить сервис на работу под .NET Framework 4.8.

Если сторонние компоненты используются в других вычислениях, но при этом также поддерживают работу только с .NET Framework, перенесите ваш программный код в асинхронные обработчики. После этого также измените настройку в конфигурационном файле агента ServiceRunner, чтобы сервис Worker работал под .NET Framework 4.8.

2. В среде разработки появилась возможность создавать отладочные пакеты

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

При публикации такого пакета в Directum RX в лог-файл веб-сервера записывается информация о номерах строк кода, в которых возникла ошибка. Поэтому становится проще устранить ошибки.

3. Служба ввода документов теперь устанавливается на Linux

Перед интеллектуальной обработкой документы заносятся в Directum RX. За это отвечает служба ввода документов Directum Capture Service (DCS): она захватывает документы из папки или электронной почты, делит их на комплекты и загружает в систему. В новой версии служба ввода DCS сделана кроссплатформенной: ее можно развернуть в Microsoft Windows и системах на базе Linux.

Поддерживается ли работа с облачной электронной подписью?

Да, поддерживается с версии Directum RX 4.1. При использовании облачной подписи закрытый ключ и средство криптографической защиты информации (СКЗИ) хранятся на сервере. Подписание также выполняется на сервере. Использование облачной электронной подписи:

  • упрощает настройку инфраструктуры. На клиентских компьютерах не нужно устанавливать закрытый ключ и СКЗИ. Кроме того, подписание выполняется без использования веб-агента;
  • сокращает финансовые затраты на работу с электронной подписью. Не нужно приобретать лицензии СКЗИ и токены для каждого сотрудника, работающего с ЭП.

Подписание выполняется с помощью сервера КриптоПро DSS. Можно развернуть свой сервер или использовать готовый, который предоставляет удостоверяющий центр. В системе Directum RX в справочнике Цифровые сертификаты в новом поле Плагин задается привязка сертификата к плагину облачной ЭП.

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

Как разработчикам создавать сценарии для правил согласования?

В прошлой новости мы писали, что теперь в Directum RX для настройки правил согласования можно использовать сценарии:

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

Теперь путем наследования вы можете легко встраивать в правило согласования свои сценарии:

В справку добавлен пример, с помощью которого будет проще разобраться, как реализованы сценарии в базовом решении Directum RX, и разработать новые сценарии.

Можно ли изменять стили для документов, заданий и записей справочников?

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

Эти настройки задаются в редакторе типа сущности в узле «Стили». Раньше узел отображался только для типов документов. В новой версии настройка появилась у типов заданий, уведомлений и заданий на приемку, а также у типов справочников:

В табличной части задаются условия, при соблюдении которых изменяется стиль записи. Для настройки условий используются свойства с типом Логическое, Дата, Перечисление и Ссылка, а также операторы <>, >, >=, .Execute() и ExecuteAllMonitoringBlocks().

Благодаря обновлению блока «Мониторинг» в базовом решении Directum RX ускорено многоадресное рассмотрение документов и работа с составными поручениями. А для задач со сроком «Неделя» или «Месяц» интервал проверки увеличен – это позволило еще и снизить нагрузку на веб-сервер.

Как установить сервисы Directum Ario?

Установить новую версию сервисов Directum Ario, включая необходимую для их работы поисковую систему Elasticsearch, службу Directum Capture Service (DCS) и сервис хранилищ MinIO, теперь можно с помощью одной программы установки:

В программе можно проверить сервер на соответствие системным требованиям. Если на сервере есть не всё требуемое ПО, для его установки и настройки достаточно нажать одну кнопку:

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

Есть ли изменения в мобильных решениях Directum RX?

Конечно! Каждую версию мобильные решения становятся лучше. Например, в этой версии у администратора появилась возможность включать обязательную блокировку Directum Solo на всех устройствах сотрудников. Блокировка срабатывает после 15 минут бездействия, а для её снятия нужно ввести PIN-код. Такое поведение позволяет защитить мобильное приложение от несанкционированного доступа.

Подробнее об изменении мобильных решений также будет отдельная статья на Directum Club.

В статье перечислены основные новинки версии. Полный список новых возможностей можно изучить в документах «Изменения Directum RX 4.1» и «Изменения Directum RX 4.1. Исправленные замечания» на сайте поддержки . Если у вас остались вопросы, мы готовы ответить на них в комментариях.

Источник

О чем этот сайт? DirectumRX | Электронный документооборот

Дата добавления сайта в базу: 13 Июля 2020 г. (2 года назад)

Проверить работу сайта

Дата последней проверки на работоспособность: Понедельник 16 Января 2023 г. 10:49 г. (2 месяца назад)

Оцените работу сайта

Сейчас работает
Сейчас не работает

Поделитесь, спросите у друзей, почему не работает сайт?:

Оцените сам сайт, насколько он вам нравится:

Проголосовавших: 1 чел.
Средний рейтинг: 5 из 5.

Что делать, если не открывается сайт rx.directum.ru? Если с недавнего времени перестал работать ресурс, попробуйте найти причину в нижеприведенных возможных ошибках, которые могут находиться как на стороне сервера, так и на стороне пользователя.

4xx (ошибка клиента)

Коды ответа 4xx при открытии сайта rx.directum.ru в интернет-браузере означают, что произошла ошибка на стороне пользователя:

Ошибка 400

Не работает сайт rx.directum.ru, ошибка в браузере 400 — плохой запрос, в запросе присутствует синтаксическая ошибка (например, в протоколе передачи данных);

Ошибка 401

Недоступен сайт rx.directum.ru, ошибка браузера 401 — авторизация не пройдена, нужна авторизация, но она не пройдена, либо введен неверный логин/пароль. Обычно возникает в случае ввода в форму авторизации неправильных данных;

Ошибка 403

Код ошибки браузера 403 — доступ запрещен. Ошибка 403 означает, что доступ к данным запрещен даже с авторизацией, открыть страницу не получится вообще;

Ошибка 404

Ошибка сайта rx.directum.ru, ошибка 404 — страница с текущим адресом не найдена, запрашиваемый документ (страница) отсутствует или ее адрес изменен.

5xx (ошибка сервера)

Еще один вид ошибок при открытии сайта rx.directum.ru в браузере — 5xx, ошибки на стороне сервера:

Ошибка 500

При открытии сайта rx.directum.ru появляется код ошибки 500 — внутренняя ошибка сервера, на сервере произошла неизвестная ошибка;

Ошибка 501

Недоступность rx.directum.ru, серверная ошибка 501 — не реализовано, сервер не поддерживает технологии для обработки запроса;

Ошибка 503

Не хочет работать сайт rx.directum.ru, код ошибки сервера 503 — сервер недоступен. Сервер по техническим причинам не может обрабатать запрос;

Ошибка 522

Не работает сайт — rx.directum.ru, ошибка сервера 522 — сервер перегружен, например, из-за большого количества посещений или DDoS-атаки.

При открытии rx.directum.ru на экране белое окно

Если вместо сайта rx.directum.ru белое окно, пустое место, значит, в глобальной Сети или на стороне провайдера возникли ошибки маршрутизации, либо владельцы вовремя не продлили действие домена — rx.directum.ru и он стал неактивным.

При невозможности открытия любых сайтов наиболее вероятна причина с общей недоступностью Интернета, либо интернет-ресурс может быть заблокирован по решению суда Роскомнадзором, согласно Федеральному закону ФЗ-149. Случаи, когда невозможно войти в личный кабинет rx.directum.ru, выходят за рамки этой заметки.

Последние проверенные сайты

Установка
веб-доступа


Известные проблемы и пути их решения

Не
работают гиперссылки на документы DIRECTUM

При работе с гиперссылками
на документы DIRECTUM существуют следующие проблемы и пути их
решения:

1.     
Если вместо
загружаемого документа отображается текст с параметрами документа,
то причина в том, что на клиентском компьютере не установлено
соответствие обработчика isb-файлов и расширения «.isb». В этом
случае необходимо переустановить клиентскую часть на клиентском
компьютере.

2.     
При установке
сервера веб-доступа к DIRECTUM неверно заданы параметры локальной
сети. Можно исправить ситуацию, выполнить следующее:

·        
Шаг 1. Запустите
утилиту конфигурирования сервера веб-доступа
C:Program
FilesDIRECTUM
CompanyWebAccessConfigDirWebConfigurator.exe;

·        
Шаг 2. Окно
«Выбор веб-узла Сервера веб-доступа к
DIRECTUM»:

а)    
в выпадающем
списке выберите веб-узел сервера веб-доступа к
DIRECTUM. По умолчанию «Сервер
веб-доступа к
DIRECTUM»;

б)    
нажмите на
кнопку OK
;

·        
Шаг 3. Окно
«Параметры Сервера веб-доступа к
DIRECTUM», закладка
«Общие»:

а)    
перейдите на
закладку «Обработчик гиперссылок»;

б)    
заполните поля
«Идентификатор сети» и «Маска подсети» группы «Параметры локальной
сети» корректными значениями;

в)    
нажмите на
кнопку OK.

3.     
В свойствах
веб-узла не задана обработка isb-файлов. Для устранения этой
проблемы необходимо сделайте следующее:

·        
Шаг 1. Запустите
утилиту конфигурирования сервера веб-доступа
C:Program
FilesDIRECTUM
CompanyWebAccessConfigDirWebConfigurator.exe;

·        
Шаг 2. Окно
«Выбор веб-узла Сервера веб-доступа к
DIRECTUM»:

а)    
в выпадающем
списке выберите веб-узел сервера веб-доступа к
DIRECTUM. По умолчанию «Сервер
веб-доступа к
DIRECTUM»;

б)    
нажмите на
кнопку OK
;

·        
Шаг 3. Окно
«Параметры Сервера веб-доступа к
DIRECTUM», закладка
«Общие»:

а)    
перейдите на
закладку «Настройка веб-узла»;

б)    
нажмите на
кнопку Установить требуемые значения;

в)    
нажмите на
кнопку OK.

4.     
На сервере
веб-доступа не установлен обработчик ASP-сценариев. Для
восстановления обработки, с помощью мастера установки компонент
Windows установите компоненту Active Server Pages. Для IIS
6.0 после установки убедитесь, что расширение веб-служб Active
Server Pages
разрешено. Для этого:

а)    
откройте консоль
администратора «Управление компьютером»;

б)    
перейдите в узел
«Службы и приложения» → «Диспетчер служб IIS» →  «Расширения
веб-служб»;

Для IIS 6.0
после установки добавьте в свойствах веб-узла библиотеку ISAPI,
соответствующую расширению ASP. Для этого:

а)    
на закладке
Фильтры ISAPI добавьте новый фильтр с названием ASP;

б)    
в качестве
обработчика установите файл
%WINDIR%system32inetsrvasp.dll;

в)    
перезапустить
Internet Information Services.

5.     
Если на
клиенте(ах) не установлен обработчик ярлыков IS-Builder (isbexec),
а клиент входит в локальную сеть (группа полей «Параметры локальной
сети» на закладке «Обработчик гиперссылок» утилиты конфигурирования
сервера веб-доступа), то необходимо включить этого клиента(ов) в
список исключений. При обращении с адресов из списка исключений
гиперссылки всегда будут открываться через веб-доступ, а не
генерировать ярлыки IS-Builder. Для настройки списка исключений
сделайте следующее:

·        
Шаг 1. Запустите
утилиту конфигурирования сервера веб-доступа
C:Program
FilesDIRECTUM
CompanyWebAccessConfigDirWebConfigurator.exe.

·        
Шаг 2. Окно
«Выбор веб-узла Сервера веб-доступа к
DIRECTUM»:

а)    
в выпадающем
списке выберите веб-узел сервера веб-доступа к
DIRECTUM. По умолчанию «Сервер
веб-доступа к
DIRECTUM»;

б)    
нажмите на
кнопку OK
;

·        
Шаг 3. Окно
«Параметры Сервера веб-доступа к
DIRECTUM», закладка
«Общие»:

а)    
перейдите на
закладку «Обработчик гиперссылок»;

б)    
заполните поля
«Идентификатор сети» и «Маска подсети» группы «Параметры списка
исключений» требуемыми значениями;

в)    
нажмите на
кнопку OK.

См. также:

·        

Сообщение «Неизвестная ошибка сервера сеансов
IS-Builder»
.

Directum RXDirectum RX — российская интеллектуальная система управления цифровыми процессами и документами с набором готовых решений. Систему используют как малые и средние, так и крупные компании.

Это продукт российской разработки, созданный  ООО «ДИРЕКТУМ» в качестве нового серьёзного шага на российском рынке СЭД.

«Галактика ИТ» стала партнёром DIRECTUM 2010 году и уже много лет активно и успешно внедряет системы электронного документооборота этого разработчика в организациях и учебных заведениях РФ. «Галактика ИТ» также активно развивает собственную партнёрскую сеть DIRECTUM, реализуя ЕСМ-проекты во взаимодействии с различными структурами корпорации и получив статус Экспертного центра по СЭД корпорации «Галактика».  Реализация проектов по внедрению Directum RX – новый этап развития бизнеса в области ЕСМ.

Directum RX

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

Преимущества

Функциональные решения для разных задач бизнеса

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

Возможности встроенной интеллектуальной обработки документов

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

Современный интерфейс и удобство работы пользователей

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

Легкая адаптация системы под требования бизнеса

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

https://www.directum.ru/adaptation-rx

Кроссплатформенность

Directum RX поддерживает работу с СУБД Microsoft SQL Server, PostgreSQL и Postgres Pro, которую все чаще стали использовать крупные компаний.

Веб-клиент становится основным вариантом доступа к рабочему информационному пространству. Преимущества очевидны — кроссплатформенность (ОС Linux, Mac, Windows и др.), простота развертывания и администрирования. Для мобильной работы предлагаются приложения Directum Solo и Jazz.

Современная архитектура

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

Открытый API и готовые интеграционные решения

Система готова к интеграции с ERP- и другими системами, сервисами обмена. Поддерживается совместная работа с продуктами MS Office, Р7-Офис, МойОфис, LibreOffice и ONLYOFFICE.

https://www.directum.ru/architecture-rx

Готовое решение для юридически значимого обмена с контрагентами

Система поддерживает полный цикл документооборота – от создания документа до его отправки контрагенту. В Directum RX встроена возможность электронного обмена юридически значимыми документами с контрагентами через сервисы ЭДО для максимального удобства пользователей и экономической выгоды компании. Доступен собственный сервис обмена от компании Directum — Synerdocs.

Работа локально и в облаке

Облачный вариант поставки Directum RX выбирают заказчики, которым важно быстро развернуть систему без больших стартовых затрат, при этом наличие собственного штата ИТ-специалистов не требуется. Гарантируется доступность системы в режиме 24/7, безопасность и целостность данных в облаке согласно SLA. Если у компании имеются собственные серверы, систему можно развернуть локально.

Функциональные возможности

Directum RX Бизнес-процессы

https://www.directum.ru/solution/rx_business_process_management

Моделируйте процессы, устанавливайте последовательность действий и правила согласования со статическими или вычисляемыми ролями пользователей. Привлекать ИТ-специалистов не потребуется – все удобно настраивается в графическом редакторе через drag’n’drop.

Directum RX Документы

https://www.directum.ru/solution/rx_document_management

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

Directum RX Интеллектуальная обработка документов

https://www.directum.ru/solution/intelligent_processing

Экономьте время на рутинных ручных операциях – интеллектуальные сервисы Directum Ario помогают распределять поток входящих документов по комплектам, автоматически регистрируют и заполняют карточки в системе.

Directum RX Договоры

https://www.directum.ru/solution/rx_contract_management

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

Directum RX Контроль исполнительской дисциплины

https://www.directum.ru/solution/rx_discipline_control

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

Directum RX Делопроизводство

https://www.directum.ru/solution/rx_records_management

Контролируйте исполнение поручений. Переводите в электронный вид работу с распорядительной документацией, входящими и исходящими письмами.

Directum RX HR-процессы

https://www.directum.ru/solution/hr_process_rx

Сокращайте трудоемкость кадровых процессов – автоматизируйте ключевые направления: прием, перевод и увольнение персонала, работу с отпусками в соответствии с ТК РФ, оформление кадровых заявлений и массовое ознакомление сотрудников с документами под личную подпись.

Directum RX Обмен с контрагентами

https://www.directum.ru/solution/rx_extra_document_management

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

Directum RX Командировки и авансовые отчеты

https://www.directum.ru/solution/business_trip_clearance

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

Directum RX Совещания

https://www.directum.ru/solution/rx_meeting_management

Планируйте совещания в системе – формируйте повестки и протоколы в электронном виде. Принятые решения автоматически отправляются из протокола на исполнение ответственным.

Directum RX Счета на оплату

https://www.directum.ru/solution/rx_invoice_management

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

Directum RX Долговременный архив

https://www.directum.ru/solutions/business_solutions/long-term-archive

Храните документы из разных систем централизованно. Комплексно управляйте бумажным и электронным архивом с гарантией юридической значимости.

Интеграция с онлайн-редакторами ONLYOFFICE и P7-Офис https://www.directum.ru/solution/integration_onlyoffice

Сравнение документов https://www.directum.ru/solution/comparison_document

Личный кабинет https://www.directum.ru/solution/employee_self_service

Финансовый архив https://www.directum.ru/solution/rx_finarchive

Перекомплектование документовhttps://www.directum.ru/solution/repackaging_documents

Доверенности https://www.directum.ru/solution/rx_warrant

Проекты https://www.directum.ru/solution/rx_project_management

Сведения о контрагентах https://www.directum.ru/solution/rx_counterparties

Directum Solo https://www.directum.ru/solo

Directum Jazz https://www.directum.ru/jazz

Directum Bot https://www.directum.ru/chat-bots и https://www.directum.ru/solution/chat-bot-rx

Мониторинг системы Directum RX https://www.directum.ru/solution/monitoring_DirectumRX

Обращения граждан https://www.directum.ru/solution/rx_petitions_management

Интернет-приемная обращений граждан https://www.directum.ru/solution/Internet_reception

Разработчик и правообладатель (Лицензиар) — ООО «ДИРЕКТУМ». Система Directum RX зарегистрирована в Федеральной службе по интеллектуальной собственности, патентам и товарным знакам. Свидетельство об официальной регистрации программ для ЭВМ №2015614659 от 22.04.2015г  Страна происхождения – Российская Федерация. Номер регистрации в реестре Минкомсвязи -4499 (локальная поставка) и 382 (облачный сервис).

Время на прочтение
7 мин

Количество просмотров 4.4K

Итак, произошло то, что произошло, сегодня невозможно сделать сет Directum RX на MS SQL. Microsoft перестал отгружать лицензии в России. Для многих это стало неожиданностью, а для нас — нет. Задолго до введения санкционных ограничений мы позаботились о переходе на PostgreSQL и Linux. Причины были банальны — хотелось сократить расходы на лицензию. 

Также хотелось научиться переводить системы Directum RX на PostgreSQL, предполагая, что слонёнок будет востребован у наших заказчиков по той же финансовой причине. Для нас отказ от баз Microsoft был плановым. Кроме того, мы перевели инфраструктуры вместе с Directum RX на Linux. Сегодня оцениваем эту попытку “переехать” с сокращением затрат как отчасти удачную. 

Я, Виталий Волнянский, руководитель практики технологических решений (CTO), директор по продажам (VPS) ООО “ЕАЕ-Консалт”, под катом расскажу о том, как проходила миграция и с какими проблемами нам пришлось столкнуться.

Предыстория: ещё пару слов о мотивах

Как вы, вероятно, поняли, основным мотивом переезда на PostgreSQL было то, что не нужно платить за лицензию MS SQL. Для PostgreSQL можно купить поддержку, но обязательной опцией она не является, да и цена саппорта не сравнима со стоимостью лицензии Microsoft.

Directum RX мы эксплуатируем с 2017 года. В тот период предложения от вендора было сложно назвать оптимальными, проявлялись несовместимости внутренней инфраструктуры с MS SQL 14. Кроме того, вендор настоятельно рекомендовал использовать в инсталляции ARR Server с устаревшей аутентификацией NTP Authentication, которая применялась в настольном клиенте и не работала с протоколом HTTPS.

Единственным балансировщиком, который нормально поддерживал это решение, был ARR, но у него всё совсем печально с механизмами балансировки. Когда ложился основной сервер, балансировщик не мог эффективно перераспределить новые запросы на резервный. Это и явилось одним из триггерных факторов, которые мотивировали нас усовершенствовать платформу.

Мы осознали, что текущий стек не позволяет добиться высокой доступности, а в нагрузку получаем ещё рутинное избыточное администрирование и отладку систем Directum RX. При использовании балансировки (т.е. при применении нескольких компонентов резервирования) время администрирования увеличивается, приходится отслеживать работоспособность компонентов, следить за тем, куда уходят запросы.

В 2018 году мы решили избавиться от избыточности, поставили один Application Server, одну базу данных. Система была оптимизирована и развивалась, но проблемы продолжали возникать. С выходом третьей версии Directum RX появился web-клиент, в связи с чем произошел переход на новые механизмы аутентификации OpenID и мы поняли, что ARR можно заменить на более эффективный балансировщик, т.е. на Nginx.

Более оптимальный алгоритм и наличие здорового Health Check серьёзно упростили нам жизнь. После замены балансировщика попробовали развернуть второй сервер, что в полной мере не удалось. Поэтому до выхода четвертой версии Directum RX мы вернулись к использованию ARR. Но ещё на версии 3.4 было принято решение о миграции с MS SQL в PostgreSQL как способе сократить лицензионные расходы.

Последовательность действий

Для того, чтобы мигрировать, была определена последовательность этапов:

  1. Обследовать систему.

  2. Подготовить новую систему в Yandex Cloud: установить ВМ, серверы, установить приложения.

  3. Конвертировать данные из MS SQL в PostgreSQL.

  4. Мигрировать в Яндекс.Облако, предоставляемое ЕАЕ-Консалт, обеспечить миграцию Hystax.

  5. Осуществить миграцию стандартного ландшафта.

  6. Поднять ВМ.

  7. Установить Directum RX.

  8. Настроить канал связи между площадками.

  9. Провести синк документов, копирование БД и тестирование в рамках предпродуктивной миграции.

  10. Осуществить продуктивную миграцию.

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

Обследование системы

Предварительным этапом закономерно стало обследование системы. В этой стадии нужно было заранее исключить возможные проблемы совместимости версий.

Что мы делали:

  • проверили объемы баз данных;

  • проанализировали аппаратные требования к миграции, оценили совместимость, и, поняв на какой из версий Linux-систем будет работать Directum RX, выбрали Ubuntu 20.04;

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

На этом подготовительный этап был завершен и можно было перейти к инструменту миграции баз.

Изучение и доработка инструмента миграции из MS SQL в PostgreSQL

Задача конвертации данных из MS SQL в PostgreSQL не далась быстро. Мы были первыми, кто проводил такую миграцию. В то время мы использовали версию Directum RX 3.6, к которой вендор представил специальный инструмент для переноса данных из одной базы в другую. В связи с кастомным расширением нашей системы и использованием модуля CRM, инструмент работал исключительно с “родной” структурой, таблицами и дефолтным внутренним взаимодействием.

Для полноценной работы инструмент пришлось долго и мучительно настраивать и модифицировать SQL-скрипты. Часть модуля CRM использовал .NET Framework, и его пришлось адаптировать для корректной работы на .Net Core и Linux. Вендор оказал поддержку, дописывая решение под нас. Сейчас сложно сказать, сколько раз мы проводили миграцию в процессе отладки. Много. В 2021 году закончили переход на PostgreSQL и решили перейти к следующему этапу. С этого момента мы перестали платить за лицензии MS SQL.

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

Критерии выбора облака и результаты миграции

Оптимизация системы предполагала миграцию из облака вендора, т.е. Directum RXв облако Яндекс. Финансовая суть задачи состояла в том, чтобы сменить инвестиционные расходы на операционные, используя сервис вместо приобретения оборудования. Яндекс был выбран в силу того, что наша компания — партнёр Яндекса, и предложенное ими решение нас полностью удовлетворило.

Предпродуктивное тестирование

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

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

Значимые обновления, хранение данных и режим высокой доступности

После конвертации, возникло желание заставить платформу работать в режиме высокой доступности. Начиная с версии Directum RX 3.6 появилась информация о поддержке Linux-серверов, что обнадёживало. Позже нам предоставили тестовый релиз, и мы поняли, что в системе появились признаки микросервисной архитектуры.

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

До версии 3.8 весь объем данных по умолчанию записывался напрямую в базу. Это приводило к росту баз до неприличных объемов и вызывало проблемы при создании бэкапа и восстановлении системы. К томe же, для работы базы требовалось много оперативной памяти.

Как раз, когда мы конвертировались в PostgreSQL, вендор оптимизировал хранение данных и трансформировал их распределение, отправив контент в файловое хранилище, что здорово упростило бэкап. Несмотря на то, что база не выросла до чудовищных размеров, скорость её роста не предвещала ничего хорошего. Обновленное решение с хранением контента позволило нам существенно упростить задачу и снизить требования к RAM почти в 4 раза. Вместе с этим снизить стоимость виртуальной машины с СУБД. Если раньше резервное копирование базы длилось 3 часа, то сейчас стало занимать не более 20 минут и, соответственно, восстановление системы тоже происходит быстрее.

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

Проблемы внедрения

После того, как было принято решение использовать Yandex Cloud, мы применили Managed PostgreSQL (чтобы частично снять с себя часть ответственности за постоянное администрирование), а также автоматизировать развертывание и внедрить контейнеры kubernetes. Проведя установку, мы поняли, что возникает проблема, инсталлятор требовал полномочий суперпользователя, уровня sys admin. Наличие полных прав на управление базы данных инсталлятору было недостаточно. Ему нужен был полный доступ к серверу PostrgreSQL! 

Вероятно, что тот, кто сделал инсталлятор, имел такой доступ и реализовал решение по существующему шаблону. Решение спорное и не очень распространённое. Обычно в крупных компаниях, где существуют отдельные подразделения, занимающиеся администрированием баз данных, создают кластер серверов, где при необходимости заказываются БД. В данном же случае таких решений не предусмотрели. Мы решили не “ковырять” инсталлятор и отказаться от использования.

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

Сухой остаток

В силу того, что режим высокой доступности в полном смысле реализовать не получилось, возникли проблемы с Managed PostgreSQL, автоматической установкой и контейнерами, абсолютно успешным этот кейс считать сложно. При этом мы решили главные задачи, а именно:

  • сэкономили на лицензиях Microsoft, пока они были доступны в России;

  • сократили текущие расходы, переведя их из инвестиционных в операционные, благодаря использованию Yandex Cloud и уменьшению размера виртуальных машин;

  • гарантировали системе безопасность, ограничив влияние санкционных вендоров;

  • научились проводить миграцию на Linux и PostgreSQL и готовы предложить её клиентам в качестве сервиса, который, по всей видимости, будет достаточно актуальным среди использующих Directum RX.

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

Содержание

  1. Агент веб-доступа DIRECTUM 5.0
  2. Одна из причин подвисания системы DIRECTUM (случай из практики)
  3. Одна из причин подвисания системы DIRECTUM (случай из практики)
  4. Для чего написана эта статья?
  5. Настройка рабочего места для работы с web-интерфейсом СЭД DIRECTUM 5.4
  6. Сетевые настройки
  7. Требования к прикладному ПО
  8. Установка Агента-веб-доступа
  9. Настройка выплывающих окон
  10. Chrome
  11. Firefox
  12. Internet Explorer
  13. Настройка обработчика приложений
  14. Chrome
  15. Firefox
  16. Directum RX 4.1 для локальной установки в вопросах и ответах
  17. Как снизить нагрузку на веб-сервер?
  18. Зачем нужна утилита RxCmd? И чем она отличается от DrxUtil?
  19. Сколько существует типов аутентификации с сервисом интеграции?
  20. Можно ли шифровать параметры в конфигурационных файлах?
  21. Что сделано для Directum RX на Linux?
  22. Поддерживается ли работа с облачной электронной подписью?
  23. Как разработчикам создавать сценарии для правил согласования?
  24. Можно ли изменять стили для документов, заданий и записей справочников?
  25. Как установить сервисы Directum Ario?
  26. Есть ли изменения в мобильных решениях Directum RX?

Агент веб-доступа DIRECTUM 5.0

Опубликовано:
18 февраля 2014 в 08:24

В DIRECTUM 5.0 заметно преобразился и расширил свой функционал веб-доступ. Во многом это произошло благодаря появлению на свет Агента веб-доступа – приложения для Windows, которое устанавливается на компьютере пользователя и позволяет:

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

При входе в систему DIRECTUM через веб-доступ автоматически появится запрос на установку Агента. После установки Агент веб-доступа запускается при каждом входе в систему через веб-доступ и работает в фоновом режиме. В области уведомлений панели задач Windows появится значок

Теперь редактировать документы в веб-доступе стало так же просто, как в desktop-клиенте! Достаточно привычным образом открыть документ и начать его редактирование. Все изменения автоматически сохранятся в системе, дополнительных действий не потребуется.

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

Веб-доступ в DIRECTUM 5.0 во многом приблизился к своему старшему брату – desktop-клиенту. Приятной вам работы в обновленном веб-доступе!

Источник

Одна из причин подвисания системы DIRECTUM (случай из практики)

Опубликовано:
11 апреля 2014 в 17:50

Одна из причин подвисания системы DIRECTUM (случай из практики)

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

Как правило, в такой ситуации необходимо искать причину либо в блокировках на SQL-сервере, либо проблема с ресурсами самого железа (сервер, сеть и т.д.).

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

Что было предпринято: стандартный набор – записаны и проанализированы счетчики ОС и SQL сервера. Так вот, выяснилось, что в некоторые моменты времени происходило полное исчерпание всей доступной оперативной памяти на сервере. Здесь стоит отметить, что на SQL расположен один экземпляр SQL и более не стоит никакого дополнительного ПО.

С другой стороны SQL обычно использует всю доступную ему память под кэширование пользовательских запросов, если эти аппетиты не ограничить явно настройкой Minimum Server Memory и Maximum Server Memory.

Так вот в нашем случае, для нужд системы был оставлен запас не менее 10-12 ГБ (без учета потребления самим процессом sqlservr.exe), что теоретически должно было исключить резкое исчерпание доступной памяти. Но в нашем случае, 10 ГБ свободного пространства не спасали от этой проблемы.

Кроме того, ситуация усугублялась тем, что после нескольких таких «исчерпаний», кластер считал, что ноду недоступной (собственно логично) и переводил активность на резервную.

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

Тем не менее ситуация с исчерпанием памяти повторилась через несколько недель:

Т.е. по сути уменьшив объем буферного пула SQL мы лишь отсрочили появление проблемы.

Не буду описывать в деталях, но было выяснено, что в некоторый момент времени, процесс sqlservr.exe потреблял памяти значительно больше, чем было доступно системе, что в итоге и приводило к подвисанию системы DIRECTUM и всего SQL-сервера

Далее был проведен детальный анализ для выяснения того, что именно приводит к увеличению потребления памяти процессом sqlservr.exe, в том числе с привлечением специалистов MicroSoft.

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

Узнать размер хранилища TokenAndPermUserStore можно с помощью запроса:

И действительно, в моменты «исчерпания» всей доступной памяти значения TokenAndPermUserStore значительно отличались от обычного.

Одной из наиболее вероятных причин была названа утечка памяти, описанная в статьях http://support.microsoft.com/kb/2277078 и http://support.microsoft.com/kb/927396/en-us. И хотя в статьях идет речь о исправлении проблемы в CU3 для 2008 и проблеме в 2005 версии SQL соответственно, по факту проблема имеет место быть и в 2008 R2 версии, хотя ее вероятность значительно снижена.

В качестве временных рекомендаций для устранения этой проблемы предложено периодически выполнять очистку кэша этого хранилища:

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

Для чего написана эта статья?

Во-первых, поделится опытом с сообществом, возможно, кому-то этот опыт будет полезен.

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

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

Источник

Настройка рабочего места для работы с web-интерфейсом СЭД DIRECTUM 5.4

Оглавление

Статьи раздела

Сетевые настройки

Агент веб-доступа не поддерживает работу через прокси-сервера, в связи с чем для корректной работы веб-доступа необходимо настроить подключение к ресурсу https://doc.nsso.ru минуя прокси, через NAT.

При использовании PAC (Proxy Auto-Configuration) скриптов необходимо явное указание прокси сервера и порта в настройках браузера.

Требования к прикладному ПО

  • .net framework 4
  • Microsoft Internet Explorer 10 и выше
  • Google Chrome 60 и выше
  • Mozilla Firefox 54 и выше

Установка Агента-веб-доступа

При первом подписании документа на экране появится сообщение следующего содержания:

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

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

После того как установка завершена в правом нижнем углу рабочего стола появится значок Агента веб-доступа после чего вы можете приступать к подписыванию документов.

Настройка выплывающих окон

Для корректной работы экспорта в DIRECTUM необходимо разрешить всплывающие окна, для это выполните следующие настройки:

Chrome

В адресной сроке браузера введите chrome://settings/content/popups?search=site, в открывшемся окне добавьте адрес https://doc.nsso.ru в раздел разрешенных

Firefox

В адресной сроке браузера введите about:preferences#content, в открывшемся окне добавьте адрес https://doc.nsso.ru в раздел разрешенных

Internet Explorer

Настройки-Конфиденциальность-Включить блокирование всплывающих окон-Параметры, в открывшемся окне добавьте адрес https://doc.nsso.ru в раздел разрешенных

Настройка обработчика приложений

Chrome

Убедитесь что обработчики приложений включены в браузере, для этого в адресной строке введите chrome://settings/handlers?search=Handlers, в открывшемся окне опция должна быть включена.

Firefox

В адресной строке браузера введите about:preferences#applications, в открывшемся окне должна быть запись waagenbt54

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

Источник

Directum RX 4.1 для локальной установки в вопросах и ответах

Опубликовано:
30 августа в 11:37

Из статьи вы узнаете, какие новые сервисы помогут снизить нагрузку с веб-сервера, как разработчикам создавать свои сценарии для правил согласования, чем утилита RxCmd отличается от DrxUtil и многое другое.

ПРИМЕЧАНИЕ. Версия Directum RX 4.1 для локальной установки включает все новинки облачной версии.

Как снизить нагрузку на веб-сервер?

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

Схема работы сервиса отчетов (ReportService):

Схема работы сервиса виджетов (WidgetsService):

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

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

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

Зачем нужна утилита RxCmd? И чем она отличается от DrxUtil?

В новой версии на смену утилите DrxUtil пришла новая утилита RxCmd. Теперь исключительно она используется для решения следующих задач:

  • запуск интеллектуальной обработки документов, полученных с электронной почты или из папки с помощью службы ввода Directum Capture Service (DCS);
  • настройка классификации документов в сервисах Directum Ario;
  • импорт, экспорт и удаление шаблонов документов.

Главное преимущество RxCmd в том, что эта утилита кроссплатформенная: работает в операционных системах Microsoft Windows и Linux. Кроме того, новая утилита выполняет команды быстрее.

Старая утилита DrxUtil продолжает поставляться, но для узких задач, например для синхронизации данных из 1С и Active Directory. Если вы самостоятельно разрабатывали интеграции с помощью утилиты DrxUtil, то этот код продолжит работать, но его рекомендуется перевести на плагины RxCmd. В ближайших версиях поддержка утилиты DrxUtil будет прекращена.

Подробнее об особенностях работы утилиты расскажем в отдельной статье. Следите за публикациями на Directum Club.

Сколько существует типов аутентификации с сервисом интеграции?

Шесть. При обмене данными внешние системы обязательно проходят аутентификацию при обращении к сервису интеграции. Раньше использовалась только базовая аутентификация (basic access authentication). Для идентификации сервису интеграции требовались учетные данные пользователя с типом аутентификации по паролю. В новой версии для обращения к сервису добавлены:

  • базовая аутентификация с использованием доменных учетных записей (LDAP);
  • аутентификация по протоколам NTLM и Kerberos. Протокол NTLM обычно используется при обращении к сервису извне, например из дома, а Kerberos – при обращении внутри сети;
  • аутентификация по токенам;
  • аутентификация на основе Сookies.

Какой тип использовать – зависит от требований внешней системы и ситуации.

Можно ли шифровать параметры в конфигурационных файлах?

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

Утилита входит в стандартную поставку. Зашифровать данные можно после установки системы, при ее сопровождении.

Порядок шифрования зависит от операционной системы, на которой развернута система Directum RX. Подробнее см. в справке:

Что сделано для Directum RX на Linux?

1. Компоненты системы переведены на версию .NET Core 3.1

Веб-сервер, среда разработки и все микросервисы Directum RX переведены на версию .NET Core 3.1. Если вы используете какие-либо сторонние компоненты в своей разработке, то их необходимо перевести на указанную версию.

Если же ваши сторонние компоненты поддерживают работу только с .NET Framework и используются в вычислениях сервиса асинхронных событий Worker, то для совместимости оставлена возможность перенастроить сервис на работу под .NET Framework 4.8.

Если сторонние компоненты используются в других вычислениях, но при этом также поддерживают работу только с .NET Framework, перенесите ваш программный код в асинхронные обработчики. После этого также измените настройку в конфигурационном файле агента ServiceRunner, чтобы сервис Worker работал под .NET Framework 4.8.

2. В среде разработки появилась возможность создавать отладочные пакеты

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

При публикации такого пакета в Directum RX в лог-файл веб-сервера записывается информация о номерах строк кода, в которых возникла ошибка. Поэтому становится проще устранить ошибки.

3. Служба ввода документов теперь устанавливается на Linux

Перед интеллектуальной обработкой документы заносятся в Directum RX. За это отвечает служба ввода документов Directum Capture Service (DCS): она захватывает документы из папки или электронной почты, делит их на комплекты и загружает в систему. В новой версии служба ввода DCS сделана кроссплатформенной: ее можно развернуть в Microsoft Windows и системах на базе Linux.

Поддерживается ли работа с облачной электронной подписью?

Да, поддерживается с версии Directum RX 4.1. При использовании облачной подписи закрытый ключ и средство криптографической защиты информации (СКЗИ) хранятся на сервере. Подписание также выполняется на сервере. Использование облачной электронной подписи:

  • упрощает настройку инфраструктуры. На клиентских компьютерах не нужно устанавливать закрытый ключ и СКЗИ. Кроме того, подписание выполняется без использования веб-агента;
  • сокращает финансовые затраты на работу с электронной подписью. Не нужно приобретать лицензии СКЗИ и токены для каждого сотрудника, работающего с ЭП.

Подписание выполняется с помощью сервера КриптоПро DSS. Можно развернуть свой сервер или использовать готовый, который предоставляет удостоверяющий центр. В системе Directum RX в справочнике Цифровые сертификаты в новом поле Плагин задается привязка сертификата к плагину облачной ЭП.

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

Как разработчикам создавать сценарии для правил согласования?

В прошлой новости мы писали, что теперь в Directum RX для настройки правил согласования можно использовать сценарии:

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

Теперь путем наследования вы можете легко встраивать в правило согласования свои сценарии:

В справку добавлен пример, с помощью которого будет проще разобраться, как реализованы сценарии в базовом решении Directum RX, и разработать новые сценарии.

Можно ли изменять стили для документов, заданий и записей справочников?

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

Эти настройки задаются в редакторе типа сущности в узле «Стили». Раньше узел отображался только для типов документов. В новой версии настройка появилась у типов заданий, уведомлений и заданий на приемку, а также у типов справочников:

В табличной части задаются условия, при соблюдении которых изменяется стиль записи. Для настройки условий используются свойства с типом Логическое, Дата, Перечисление и Ссылка, а также операторы <>, >, >=, .Execute() и ExecuteAllMonitoringBlocks().

Благодаря обновлению блока «Мониторинг» в базовом решении Directum RX ускорено многоадресное рассмотрение документов и работа с составными поручениями. А для задач со сроком «Неделя» или «Месяц» интервал проверки увеличен – это позволило еще и снизить нагрузку на веб-сервер.

Как установить сервисы Directum Ario?

Установить новую версию сервисов Directum Ario, включая необходимую для их работы поисковую систему Elasticsearch, службу Directum Capture Service (DCS) и сервис хранилищ MinIO, теперь можно с помощью одной программы установки:

В программе можно проверить сервер на соответствие системным требованиям. Если на сервере есть не всё требуемое ПО, для его установки и настройки достаточно нажать одну кнопку:

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

Есть ли изменения в мобильных решениях Directum RX?

Конечно! Каждую версию мобильные решения становятся лучше. Например, в этой версии у администратора появилась возможность включать обязательную блокировку Directum Solo на всех устройствах сотрудников. Блокировка срабатывает после 15 минут бездействия, а для её снятия нужно ввести PIN-код. Такое поведение позволяет защитить мобильное приложение от несанкционированного доступа.

Подробнее об изменении мобильных решений также будет отдельная статья на Directum Club.

В статье перечислены основные новинки версии. Полный список новых возможностей можно изучить в документах «Изменения Directum RX 4.1» и «Изменения Directum RX 4.1. Исправленные замечания» на сайте поддержки . Если у вас остались вопросы, мы готовы ответить на них в комментариях.

Источник

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

Шаг 1. Изучите архитектуру системы

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

Кратко зафиксируем здесь основные моменты:

  • в основе Directum RX лежит функциональная масштабируемая платформа Sungero, архитектура которой позволяет работать локально и в облаке;
  • платформа имеет трехзвенную архитектуру Клиентские приложенияСервер приложений – Хранилище данных. Такая архитектура обеспечивает безопасность системы. Сотрудники не имеют прямого доступа к базе данных, так как все запросы осуществляются через сервер приложений, веб-сервер или сервер NOMAD. Клиентские приложения Directum RX взаимодействуют с сервером приложений по защищенному протоколу HTTPS;
  • в отличие от монолитных систем, в состав платформы Sungero входят микросервисы – это независимые сервисы, каждый из которых выполняет определенную узкоспециализированную задачу. Например, сервис планировщика периодически инициирует только запуск фоновых процессов системы;
  • за состоянием сервисов следит Агент управления сервисами (ServiceRunner) – служба Windows, следит за работой сервисов и своевременно запускает их, автоматически обновляет или останавливает. Обеспечивает бесперебойную работу сервисов, если один или несколько из них выходят из строя. Регулярно проверяет конфигурационные файлы сервисов и в случае их изменения перезапускает сервисы.

Благодаря использованию микросервисов обеспечивается:

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

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

Шаг 2. Подумайте о будущем – настройте бэкапы

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

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

Далее рассмотрим отдельно особенности и рекомендации по резервному копированию БД и ФХ.

База данных

Резервное копирование и восстановление БД осуществляется средствами СУБД. Поддерживается работа с Microsoft SQL Server и PostgreSQL. В зависимости от используемой СУБД могут использоваться разные варианты: полное, разностное резервное копирование, резервное копирование журнала транзакций.

Выбор плана и стратегии резервного копирования базы данных Directum RX зависит от множества факторов, например, размера БД, приемлемого объема потери данных и активности работы с системой. Для обеспечения минимального достаточного уровня сохранности данных рекомендуется выполнять один из видов резервного копирования ежедневно. Пример реализации плана резервного копирования приведен в разделе справки «Стратегии резервного копирования».

Рекомендации по хранению резервных копий

  • храните резервные копии (бэкапы) на физическом носителе, отличном от того, где размещена исходная БД. Бессмысленно хранить резервные копии на том же диске, на котором расположена рабочая БД. В случае выхода из строя физического носителя, вы потеряете как БД, так и ее резервные копии;
  • целесообразно хранить несколько экземпляров бэкапов на разных носителях;
  • полезно разнести хранилища бэкапов по разным помещениям или даже зданиям – на случай локальных затоплений, пожаров. Как минимум стоит разнести сервер с бэкапами и продуктивный сервер по разным кабинетам.

Восстановление БД из резервных копий

  • перед восстановлением остановите все пулы приложений Directum RX и DrxServiceRunner. После окончания работ вновь запустите;
  • всегда стоит помнить о том, что данные системы также хранятся и в файловом хранилище. Поднятие БД из бэкапа никак не затрагивает данные ФХ. Если их тоже нужно «откатить», то это надо делать дополнительно к работам с БД;
  • если БД восстанавливается на новом сервере или сменилось ее имя, то после восстановления необходимо обновить информацию о подключении к БД во всех конфигурационных файлах серверных компонент Directum RX (сервер приложений, Worker и т.п.). Если серверные компоненты стоят на одном сервере, то обновить информацию о подключении к БД удобно с помощью конфигуратора настроек;
  • если восстановление БД сопровождается изменением аппаратных параметров сервера, например, сменился диск или сервер, то систему нужно заново зарегистрировать новым регистрационным ключом, ключ запросить в службе поддержки Directum.

Файловое хранилище

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

В справке есть раздел «Резервное копирование файлового хранилища». В нем предлагается использовать стандартный компонент Microsoft Windows «Система архивации данных Windows Server».

Рекомендации по частоте создания бэкапов ФХ, месту их хранения те же, что и для бэкапов БД. Они были перечислены выше.

Восстановление ФХ из резервной копии

  • ФХ работает под управлением сервиса хранилищ. Перед восстановлением сервис хранилищ необходимо остановить;
  • после восстановления ФХ из резервной копии необходимо убедиться, что в конфигурационном файле сервиса хранилищ указана правильная папка ФХ;
  • восстановление ФХ из бэкапа стоит производить совместно с восстановлением БД. При этом стоит использовать максимально близкие по времени создания экземпляры бэкапов БД и ФХ.

Допустимо использовать более поздние бэкапы ФХ с более ранними бэкапами БД. Если в базе данных не будет информации о телах документов (версиях), которые есть в файловом хранилище, то эти файлы в ФХ просто не будут использоваться.

Обратная ситуация, когда в ФХ нет файлов для версий документов, которые есть в БД, может привести к ошибкам в работе с этими документами.

Шаг 3. Организуйте наблюдение

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

  • решение «Мониторинг системы Directum RX» для контроля состояния системы и окружения, в котором она работает. Решение наглядно отображает ключевые показатели технического состояния системы: метрики производительности серверов, статистику использования системы, ошибки в разрезе служб. Решение предоставляется бесплатно (при наличии действующего абонемента) по запросу в службу поддержки.

Точки контроля, по-крупному:

    •  
    • работоспособность серверов, сервисов;
    • загрузка CPU. Постоянное нахождение нагрузки на CPU в пиковом диапазоне – признак того, что система не справляется с нагрузкой, не имеет «запаса прочности»;
    • расход ОЗУ. Анализируется аналогично CPU;
    • свободное место на дисках. Отсутствие места на дисках может приводить к выключению сервера.
  • панель управления Kibana и веб-интерфейс RabbitMQ для мониторинга работы полнотекстового поиска документов, задач и заданий;
  • список «Фоновые процессы» для мониторинга и состояния процессов, которые запускаются в системе по заданному расписанию. Например, процессы для рассылки уведомлений о завершении сроков действия договоров или для автоматической выдачи прав доступа на документы;
  • лог-файлы, в которые записываются сообщения об ошибках, предупреждениях и информационные сообщения, появившиеся во время работы.

Работа с лог-файлами

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

Есть несколько видов лог-файлов.

Серверные лог-файлы – место сохранения лог-файлов указано в конфигурационных файлах каждой из серверных компонент. Пример имени серверного лог-файла:

<Имя_сервера>.<Наименование серверной компоненты>.<Дата>.log

Например: SERVER.WebServer.2020-05-28.log

Клиентские лог-файлы десктоп-клиента – хранятся на компьютерах пользователей. Пример имени лог-файла десктоп-клиента:

<Имя_комьютера>.DirectumRX.<Код систем>.<Дата>.log

Например: SERVER.DirectumRX.DEMO.2020-05-28.log

Remote-логирование (веб-клиент) – передача клиентских логов на сервер c целью собрать ошибки клиентов и статистику времени выполнения операций. Логи сохраняются на сервере в настроенную папку, в которой логи разделяются по файлам. Сообщения, которые логируют программный код клиента, накапливаются и передаются пачками, по умолчанию по 100 штук. Исключение составляют сообщения о том, что пользователь разлогинился, они отправляются сразу же. Пример имени лог-файла веб-клиента:

<ip-адрес>.WebClient.<Код системы>.<Дата>.log

Например: 37-235-64-229.WebClient.DirectumRX.2020-05-28.log

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

  • зафиксировать время воспроизведения ошибки;
  • просмотреть все серверные лог-файлы за последний день.

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

Рекомендации по хранению лог-файлов

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

  • не храните лог-файлы на дисках, где находятся файлы операционной системы, исполняемые файлы программ. Выделите для логов отдельные диски. В случае переполнения этих дисков Directum RX просто перестанет писать новые логи. Работа ОС, программ при этом не пострадает.
  • настраивать хранение логов нужно отдельно для каждого серверного компонента Directum RX в их конфигурационных файлах;
  • во избежание переполнения папок с логами настройте регулярные процедуры их архивирования, очистки, переноса на другие диски с обеспечением ротации хранимых данных. Например, напишите скрипты на PowerShell. Определите политику хранения созданных архивов.

Расположение текстовых лог-файлов можно менять в конфигурационных файлах системы. Подробно можно посмотреть в разделе справки «Лог-файлы во время работы».

Шаг 4. Настройте учетные записи

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

Administrator. Администратор системы, под которым выполняется первоначальная настройка системы. Для входа в Directum RX используйте пароль, который был указан при установке системы. После этого:

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

Adviser. Пользователь, у которого есть права на просмотр любых объектов системы. Смените пароль пользователя, если планируете его использовать. Если нет, то в целях безопасности закройте запись данного пользователя.

Integration Service. Учетная запись для сервиса интеграции. Смените пароль пользователя, если планируете использовать интеграцию, например, с 1С. Если интеграция не нужна, то закройте запись данного пользователя.

Итак, в целях безопасности проверьте перечисленные учетные записи для системных пользователей. Для Adviser и Integration Service смените пароли, если они будут использоваться, иначе их нужно закрыть. Учетную запись Administrator закройте и настраивайте систему от своего администратора, с другим логином и паролем.

Кроме того, есть еще Service User. Учетная запись, под которой будут работать сервисы Workflow, сервис предпросмотра, сервис планировщика и другие. Задается на этапе установки системы, если было выбрано значение Использовать стандартную учетную запись «Service User». В дальнейшем не рекомендуется менять пароль данной учетной записи. Но, если по каким-то причинам вы изменили пароль, то нужно доработать вручную конфигурационные файлы для веб-сервера, сервиса выполнения блоков схем задач Workflow и сервиса асинхронных событий. Параметры:

<var nameAUTHENTICATION_USE_THREAD_IDENTITY« value=»false» />

<var nameAUTHENTICATION_USERNAME« value=»Service User» />

<var nameAUTHENTICATION_PASSWORD« value=»0z$Ede» />

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

После этого можно переходить к настройке Directum RX. Обратите внимание, если политики компании предусматривают, что в целях безопасности периодически необходимо менять пароли для входа в систему, то администратор может в настройках учетной записи для пользователя установить Требовать смены пароля при следующем входе. В этом случае при входе в систему у пользователя откроется окно:

И напоследок рекомендации к надежности пароля:

  • пароль не должен содержать имя учетной записи пользователя или какую-либо его часть;
  • пароль должен иметь длину не менее 6 знаков;
  • пароль должен содержать знаки трех из четырех перечисленных ниже категорий:
    • латинские заглавные буквы (от A до Z);
    • латинские строчные буквы (от a до z);
    • цифры (от 0 до 9);
    • символы (например, !, $, #, %, ‘).

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

Услуга включает в себя

Установка и базовая настройка системы Directum RX на Linux

Установка и настройка необходимых компонентов операционной системы

Установка и настройка СУБД Postgres на мощностях заказчика

За время работы с Linux-системами командой системных инженеров «СТАРКОВ Групп» накоплен значительный опыт проектирования, развёртывания, конфигурирования и поддержки систем различного масштаба и сложности, который позволит максимально быстро и качественно реализовать проект под любого заказчика.

Функционирующая система, готовая к наполнению данными

Настроенное резервное копирование Базы Данных системы в соответствии с планом резервирования заказчика

«Паспорт системы» с описанием конфигурации установленной системы, логинов и паролей, внесённых изменений в конфигурационные файлы системы

Резервная копия файлов конфигурации системы по состоянию на момент сдачи системы заказчику

Варианты пакетов предоставления услуги:

Минимальный Стандарт Расширенный
система развёртывается на одном сервере. Как правило подходит для работы до 50 одновременно работающих пользователей. система развёртывается на нескольких серверах. Может включать в себя до 3х серверов: сервер приложений, сервер СУБД, сервис «файлового хранилища» может быть вынесен на отдельную ВМ. В пакет включена установка и настройка сервера Nomad. пакет предусматривает проектирование и развёртывание сложных систем, с учётом пожелания и возможности заказчика. Подходит для клиентов с большим количеством (>100) одновременно работающих пользователей. В данном варианте возможна установка и настройка дополнительных технических решений для системы Directum RX.
46 000 р. без НДС 92 000 р. без НДС Рассчитывается индивидуально под перечень необходимых задач.

Для быстрого и качественного оказания услуги от вас потребуется:

  • Виртуальная машина или физический сервер заказчика;
  • Установленная операционная система из списка поддерживаемых;
  • Пользователь с правами администратора(root);
  • Прямой доступ до сервера (ssh/rdp без использования посредников rms и т.д.)
  • Зарегистрированное доменное имя системы (FQDN), адрес по которому будет доступна система.
  • В случае если используется шифрование и протокол HTTPS необходим ssl сертификат выданный на FQDN имя системы;
  • Прямой доступ в интернет, с машины на которой предполагается развёртывание системы Directum RX
  • Адрес электронной почты администратора системы.
  • Адрес сервера smtp и реквизиты подключения к нему для настройки отправки уведомлений из системы на электронную почту.
  • План резервного копирования Базы Данных системы.

Перечень требований для расширенного пакета уточняется в индивидуальном порядке.

Заказать услугу и получить ответы на все интересующие вас вопросы поможет Иван Засыпкин – руководитель Службы поддержки и сопровождения:

Время на прочтение
7 мин

Количество просмотров 4.8K

Итак, произошло то, что произошло, сегодня невозможно сделать сет Directum RX на MS SQL. Microsoft перестал отгружать лицензии в России. Для многих это стало неожиданностью, а для нас — нет. Задолго до введения санкционных ограничений мы позаботились о переходе на PostgreSQL и Linux. Причины были банальны — хотелось сократить расходы на лицензию. 

Также хотелось научиться переводить системы Directum RX на PostgreSQL, предполагая, что слонёнок будет востребован у наших заказчиков по той же финансовой причине. Для нас отказ от баз Microsoft был плановым. Кроме того, мы перевели инфраструктуры вместе с Directum RX на Linux. Сегодня оцениваем эту попытку “переехать” с сокращением затрат как отчасти удачную. 

Я, Виталий Волнянский, руководитель практики технологических решений (CTO), директор по продажам (VPS) ООО “ЕАЕ-Консалт”, под катом расскажу о том, как проходила миграция и с какими проблемами нам пришлось столкнуться.

Предыстория: ещё пару слов о мотивах

Как вы, вероятно, поняли, основным мотивом переезда на PostgreSQL было то, что не нужно платить за лицензию MS SQL. Для PostgreSQL можно купить поддержку, но обязательной опцией она не является, да и цена саппорта не сравнима со стоимостью лицензии Microsoft.

Directum RX мы эксплуатируем с 2017 года. В тот период предложения от вендора было сложно назвать оптимальными, проявлялись несовместимости внутренней инфраструктуры с MS SQL 14. Кроме того, вендор настоятельно рекомендовал использовать в инсталляции ARR Server с устаревшей аутентификацией NTP Authentication, которая применялась в настольном клиенте и не работала с протоколом HTTPS.

Единственным балансировщиком, который нормально поддерживал это решение, был ARR, но у него всё совсем печально с механизмами балансировки. Когда ложился основной сервер, балансировщик не мог эффективно перераспределить новые запросы на резервный. Это и явилось одним из триггерных факторов, которые мотивировали нас усовершенствовать платформу.

Мы осознали, что текущий стек не позволяет добиться высокой доступности, а в нагрузку получаем ещё рутинное избыточное администрирование и отладку систем Directum RX. При использовании балансировки (т.е. при применении нескольких компонентов резервирования) время администрирования увеличивается, приходится отслеживать работоспособность компонентов, следить за тем, куда уходят запросы.

В 2018 году мы решили избавиться от избыточности, поставили один Application Server, одну базу данных. Система была оптимизирована и развивалась, но проблемы продолжали возникать. С выходом третьей версии Directum RX появился web-клиент, в связи с чем произошел переход на новые механизмы аутентификации OpenID и мы поняли, что ARR можно заменить на более эффективный балансировщик, т.е. на Nginx.

Более оптимальный алгоритм и наличие здорового Health Check серьёзно упростили нам жизнь. После замены балансировщика попробовали развернуть второй сервер, что в полной мере не удалось. Поэтому до выхода четвертой версии Directum RX мы вернулись к использованию ARR. Но ещё на версии 3.4 было принято решение о миграции с MS SQL в PostgreSQL как способе сократить лицензионные расходы.

Последовательность действий

Для того, чтобы мигрировать, была определена последовательность этапов:

  1. Обследовать систему.

  2. Подготовить новую систему в Yandex Cloud: установить ВМ, серверы, установить приложения.

  3. Конвертировать данные из MS SQL в PostgreSQL.

  4. Мигрировать в Яндекс.Облако, предоставляемое ЕАЕ-Консалт, обеспечить миграцию Hystax.

  5. Осуществить миграцию стандартного ландшафта.

  6. Поднять ВМ.

  7. Установить Directum RX.

  8. Настроить канал связи между площадками.

  9. Провести синк документов, копирование БД и тестирование в рамках предпродуктивной миграции.

  10. Осуществить продуктивную миграцию.

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

Обследование системы

Предварительным этапом закономерно стало обследование системы. В этой стадии нужно было заранее исключить возможные проблемы совместимости версий.

Что мы делали:

  • проверили объемы баз данных;

  • проанализировали аппаратные требования к миграции, оценили совместимость, и, поняв на какой из версий Linux-систем будет работать Directum RX, выбрали Ubuntu 20.04;

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

На этом подготовительный этап был завершен и можно было перейти к инструменту миграции баз.

Изучение и доработка инструмента миграции из MS SQL в PostgreSQL

Задача конвертации данных из MS SQL в PostgreSQL не далась быстро. Мы были первыми, кто проводил такую миграцию. В то время мы использовали версию Directum RX 3.6, к которой вендор представил специальный инструмент для переноса данных из одной базы в другую. В связи с кастомным расширением нашей системы и использованием модуля CRM, инструмент работал исключительно с “родной” структурой, таблицами и дефолтным внутренним взаимодействием.

Для полноценной работы инструмент пришлось долго и мучительно настраивать и модифицировать SQL-скрипты. Часть модуля CRM использовал .NET Framework, и его пришлось адаптировать для корректной работы на .Net Core и Linux. Вендор оказал поддержку, дописывая решение под нас. Сейчас сложно сказать, сколько раз мы проводили миграцию в процессе отладки. Много. В 2021 году закончили переход на PostgreSQL и решили перейти к следующему этапу. С этого момента мы перестали платить за лицензии MS SQL.

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

Критерии выбора облака и результаты миграции

Оптимизация системы предполагала миграцию из облака вендора, т.е. Directum RXв облако Яндекс. Финансовая суть задачи состояла в том, чтобы сменить инвестиционные расходы на операционные, используя сервис вместо приобретения оборудования. Яндекс был выбран в силу того, что наша компания — партнёр Яндекса, и предложенное ими решение нас полностью удовлетворило.

Предпродуктивное тестирование

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

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

Значимые обновления, хранение данных и режим высокой доступности

После конвертации, возникло желание заставить платформу работать в режиме высокой доступности. Начиная с версии Directum RX 3.6 появилась информация о поддержке Linux-серверов, что обнадёживало. Позже нам предоставили тестовый релиз, и мы поняли, что в системе появились признаки микросервисной архитектуры.

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

До версии 3.8 весь объем данных по умолчанию записывался напрямую в базу. Это приводило к росту баз до неприличных объемов и вызывало проблемы при создании бэкапа и восстановлении системы. К томe же, для работы базы требовалось много оперативной памяти.

Как раз, когда мы конвертировались в PostgreSQL, вендор оптимизировал хранение данных и трансформировал их распределение, отправив контент в файловое хранилище, что здорово упростило бэкап. Несмотря на то, что база не выросла до чудовищных размеров, скорость её роста не предвещала ничего хорошего. Обновленное решение с хранением контента позволило нам существенно упростить задачу и снизить требования к RAM почти в 4 раза. Вместе с этим снизить стоимость виртуальной машины с СУБД. Если раньше резервное копирование базы длилось 3 часа, то сейчас стало занимать не более 20 минут и, соответственно, восстановление системы тоже происходит быстрее.

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

Проблемы внедрения

После того, как было принято решение использовать Yandex Cloud, мы применили Managed PostgreSQL (чтобы частично снять с себя часть ответственности за постоянное администрирование), а также автоматизировать развертывание и внедрить контейнеры kubernetes. Проведя установку, мы поняли, что возникает проблема, инсталлятор требовал полномочий суперпользователя, уровня sys admin. Наличие полных прав на управление базы данных инсталлятору было недостаточно. Ему нужен был полный доступ к серверу PostrgreSQL! 

Вероятно, что тот, кто сделал инсталлятор, имел такой доступ и реализовал решение по существующему шаблону. Решение спорное и не очень распространённое. Обычно в крупных компаниях, где существуют отдельные подразделения, занимающиеся администрированием баз данных, создают кластер серверов, где при необходимости заказываются БД. В данном же случае таких решений не предусмотрели. Мы решили не “ковырять” инсталлятор и отказаться от использования.

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

Сухой остаток

В силу того, что режим высокой доступности в полном смысле реализовать не получилось, возникли проблемы с Managed PostgreSQL, автоматической установкой и контейнерами, абсолютно успешным этот кейс считать сложно. При этом мы решили главные задачи, а именно:

  • сэкономили на лицензиях Microsoft, пока они были доступны в России;

  • сократили текущие расходы, переведя их из инвестиционных в операционные, благодаря использованию Yandex Cloud и уменьшению размера виртуальных машин;

  • гарантировали системе безопасность, ограничив влияние санкционных вендоров;

  • научились проводить миграцию на Linux и PostgreSQL и готовы предложить её клиентам в качестве сервиса, который, по всей видимости, будет достаточно актуальным среди использующих Directum RX.

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

Стабильная и производительная информационная система обеспечивает выполнение бизнес-задач. Остановка ее работы может привести к финансовым потерям компании.

Решение «Мониторинг системы Directum RX» позволяет наглядно отображать ключевые показатели технического состояния системы: метрики производительности серверов, статистику использования системы, ошибки в разрезе служб.

Возможности решения:

  • Быстрая оценка текущего состояния системы. Решение дает полную картину работы серверов: стабильность развернутых сервисов, загрузка процессора, свободная оперативная память, свободное место на диске и т.д.;
  • Расследование инцидентов. Администратор может быстро найти связанную с ошибками информацию: пользователей, типы объектов, временной интервал, состояние серверов и т.д. Это помогает решить проблему самостоятельно или подготовить максимально полное обращение в службу поддержки Directum RX;
  • Проактивная работа с ошибками. Решение своевременно сообщает об узких местах в работе системы: недостаточном дисковом пространстве, длительной высокой загрузке процессора или превышении количества ошибок определенного типа. Благодаря этому администратор устраняет проблему раньше, чем она успевает повлиять на работу пользователей;
  • Контроль производительности системы. Рост объема хранящихся данных, увеличение числа пользователей и другие факторы могут привести к снижению производительности системы. Регулярный мониторинг скорости выполнения ключевых операций позволяет своевременно принять меры для повышения производительности.

Описание решения

Решение собирает и анализирует данные из лог-файлов системы Directum RX и значения счетчиков производительности операционной системы. Полученные результаты выводятся на сайте решения.

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

monitoring

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

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

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

При необходимости решение можно встроить в уже существующую систему мониторинга и адаптировать под потребности организации.

Бизнес-эффект

Решение повышает эффективность сопровождения системы Directum RX:

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

Понравилась статья? Поделить с друзьями:
  • Внутренняя ошибка сервера телеграмм на пк
  • Внутренняя ошибка сервера cristalix
  • Внутренняя ошибка сервера телеграм
  • Внутренняя ошибка сервера 5хх фикбук
  • Внутренняя ошибка сервера сбис как исправить