Ошибка регистрации клиента на сервере сеансов directum

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

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

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

Необходимо проверить на
компьютере, где запущен сервер веб-доступа, какие компоненты
IS—Builder
выполняются при
выдаче этой ошибки:

1.     
Если запущен
sblogon.exe, но не запущен sbrte.exe, то, вероятно, у пользователя,
от имени которого работает sblogon.exe, нет прав на доступ и запуск
объекта sbrte.exe. Внимательно проверьте порядок настройки прав
доступа в соответствии с разделом «Настройка
прав доступа» настоящего документа.

2.     
В этой же
ситуации возможно, что имя сервера и имя базы данных системы,
прописанные в конфигурационном файле сервера веб-доступа (эти
значения можно просмотреть в полях группы полей «Подключение к
системе DIRECTUM» на закладке «Подключение
к DIRECTUM» утилиты конфигурирования
сервера веб-доступа), не соответствует имени сервера и имени базы
данных системы, прописанной в файле C:Documents and
SettingsAll UsersApplication DataNPO
ComputerIS-BUILDERsysteminfo.xml (зарегистрированные системы
IS-BUILDER).

3.     
Если не запущен
ни sblogon.exe, ни sbrte.exe, то, вероятно, у пользователя, от
имени которого запускаются эти объекты, нет прав доступа к ним. Для
Internet Information Services 6.0 таким пользователем по умолчанию
является ASPNET, но при установке сервера веб-доступа он заменяется
в machine.config на пользователя домена (WDUSER).

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

Более подробную информацию
о такой ошибке можно посмотреть в логах IS—BUILDER
на сервере. По
умолчанию, логи ошибок сохраняются в файл <Имя
компьютера>.log, который располагается в папке «C:Documents
and SettingsAll UsersApplication DataNPO ComputerIS-BUILDER».
Если при установке DIRECTUM был выбран другой каталог
размещения ошибок, то посмотреть его можно в файле «C:Documents
and SettingsAll UsersApplication DataNPO
ComputerIS-BUILDERlogsettings.xml», параметр LogPath.

См. также:

·        

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

Публикую этот пост для тех, кто не видел
статью базы знаний, написанную мной в 2009 году. Бонусом к статье является скрипт GetDirectumLogs.vbs, который копирует лог-файлы DIRECTUM (подробности в последнем разделе статьи).

Введение

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

• Клиентская часть DIRECTUM
• Служба WorkFlow
• Сервер сеансов
• Служба файловых хранилищ
• Службы ввода и преобразования (DCTS)
• Утилита SASystemActivator
• Утилита SAKeyRegistration
• Утилита STConverter
• Репликация
• Сервер веб-доступа к DIRECTUM
• Расширения DIRECTUM для SharePoint
• Набор средств интеграции DIRECTUM
• Программы установки DIRECTUM

Клиентская часть DIRECTUM

Имя лог-файла

*.sbrte.log — документы, ЗЗУ, справочники, сценарии, отчеты

*.sbdte.log — утилиты экспорта-импорта

*.sblogon.log — служба паролей

*.sbsce.log — сценарии, запускаемые SAJobRunner

*.sblauncher.log — загрузка пользовательских компонент

*.isbexec.log — обработчик ISB-файлов

*.sajobrunner.log — утилита запуска агентов

*.sblanguagesetup.log — утилита установки текущего языка системы

* — <имя компьютера>.is-builder

Путь до лог-файла

Задается в ходе установки клиентской части DIRECTUM.

Путь сохраняется в параметре «LogPath» файла «LogSettings.xml», который находится в папке «%ALLUSERSPROFILE%Application DataNPO ComputerIS-Builder». Если параметр «LogPath» пуст или файла настроек нет или не удается записать лог-файл в заданную папку,
лог-файл записывается в папку профиля пользователя «%APPDATA%NPO ComputerIS-Builder». Если папки профиля пользователя не доступна (не существует), то лог-файл записывается в каталог «%SystemDrive%Documents and SettingsDefault UserApplication DataNPO
ComputerIS-Builder» (для Windows XP, 2000, 2003) или «%SystemDrive%UsersDefaultAppDataRoamingNPO ComputerIS-Builder» (для Windows Vista).

В каких случаях записывается информация

При возникновении ошибок в ходе работы клиентской части DIRECTUM.

Фиксируемая информация

Дата ошибки

Время ошибки

ИД процесса

Код системы

Логин пользователя

Тип исключения

Текст сообщения об ошибки

Стек вызова метода, который повлек ошибку

Процесс или приложение, которое вызвало ошибку

Версия системы, в которой вызвана ошибка

Тип и код компоненты, при работе с которой вызвана ошибка

Примечание

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

Также свои лог-файлы могут вести прикладные сценарии DIRECTUM. Более подробная информация об этом находится в описании сценариев.

См. также:

Раздел «Log-файлы» руководства администратора DIRECTUM.

Служба WorkFlow

Имя лог-файла

*.sbworkflowproc.log

*.sbworkflowsrv.log

* — <имя компьютера>.is-builder

Путь до лог-файла

Аналогично клиентской части DIRECTUM.

В каких случаях записывается информация

*.sbworkflowproc.log — при возникновении ошибок в ходе обработки задач.

*.sbworkflowsrv.log — при возникновении ошибок в работе службы Workflow (например, «Система на сервере XXX и базе YYY не обслуживается службой», ошибки при старте/остановке службы).

Фиксируемая информация

Аналогично клиентской части DIRECTUM.

Примечание

Также служба SBWorkflowSrv пишет информацию в журнал событий Windows. Посмотреть журнал можно с помощью оснастки Windows «Просмотр событий»: категория — Приложение, источник — SBWorkflowProcessingServer.

Сервер сеансов

Протоколы сервера сеансов

Имя файла протокола

Сервер сеансов может вести два протокола: протокол обращений к серверу сеансов и протокол регистрации пользователей. Имена протоколов задаются вместе с путями до них.

Путь до файлов протокола

Задается в параметрах файла «SBSessionSrvSettings.xml», который находится в папке с сервером сеансов.

В каких случаях записывается информация

В зависимости от настроек, указанных в файле «SBSessionSrvSettings.xml».

Фиксируемая информация

протокол обращений к серверу сеансов — количество обращений к серверу сеансов по протоколу TCP/IP;

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

См. также

Раздел «Файл SBSessionSrvSettings.xml» руководства администратора DIRECTUM.

Лог-файлы сервера сеансов

Имя лог-файла

<имя компьютера>.is-builder.sbsessionsrv.log

Путь до лог-файла

Аналогично клиентской части DIRECTUM.

В каких случаях записывается информация

При возникновении ошибок в ходе работы сервера сеансов.

Фиксируемая информация

Аналогично клиентской части DIRECTUM.

Примечание

Также служба SBSessionSrv пишет информацию в журнал событий Windows. Посмотреть журнал можно с помощью оснастки Windows «Просмотр событий»: категория — Приложение, источник — SBSessionServer.

Служба файловых хранилищ

Имя лог-файла

<имя компьютера>.is-builder.sbfilestorageserver.log

Путь до лог-файла

Аналогично клиентской части DIRECTUM.

В каких случаях записывается информация

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

Фиксируемая информация

Аналогично клиентской части DIRECTUM.

Примечание

Также служба SBSessionSrv пишет информацию в журнал событий Windows. Посмотреть журнал можно с помощью оснастки Windows «Просмотр событий»: категория — Приложение, источник — SBFileStorageService.

Службы ввода и преобразования (DCTS)

Имя лог-файла

Лог-файл служба ведет в журнале событий Windows.

Путь до лог-файла

Посмотреть журнал можно с помощью оснастки Windows «Просмотр событий», имя журнала «DCTS EventLog».

В каких случаях записывается информация

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

Фиксируемая информация

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

См. также

Раздел «Протокол работы служб ввода» руководства по службам ввода документов DIRECTUM.

Утилита SASystemActivator

Имя лог-файла

<имя компьютера>.is-builder.sasystemactivator.log

Путь до лог-файла

Аналогично клиентской части DIRECTUM.

В каких случаях записывается информация

При возникновении ошибок в ходе работы утилиты.

Фиксируемая информация

Аналогично клиентской части DIRECTUM.

Утилита SAKeyRegistration

Имя лог-файла

<имя компьютера>.is-builder.sakeyregistration.log

Путь до лог-файла

Аналогично клиентской части DIRECTUM.

В каких случаях записывается информация

При возникновении ошибок в ходе работы утилиты.

Фиксируемая информация

Аналогично клиентской части DIRECTUM.

Утилита STConverter

Имя лог-файла

<имя компьютера>.is-builder.stconverter.log — лог-файл утилиты STConverter

stconverter.log — протокол конвертации

Путь до лог-файла

Путь до лог-файла утилиты определяется аналогично клиентской части DIRECTUM.

Путь до протокола конвертации указывается в ходе работы утилиты STConverter.

В каких случаях записывается информация

<имя компьютера>.is-builder.stconverter.log — при возникновении ошибок в ходе работы утилиты STConverter.

stconverter.log — всегда.

Фиксируемая информация

<имя компьютера>.is-builder.stconverter.log — аналогично клиентской части DIRECTUM.

stconverter.log — последовательность действий, которая выполняется в ходе конвертации.

Репликация

Протоколы репликации

Имя файла протокола

ID_<ИД сеанса>_<прием данных от вторичного сервера>_<код вторичного сервера> — протокол приема данных от вторичного сервера

ID_<ИД сеанса>_<прием данных от главного сервера>_<код главного сервера> — протокол приема данных от главного сервера

ID_<ИД сеанса>_<передача данных на вторичный сервер>_<код вторичного сервера> — протокол передачи данных на вторичный сервер

ID_<ИД сеанса>_<передача данных на главный сервер>_<код главного сервера> — протокол передачи данных на главный сервер

Путь до файлов протокола

Располагаются в папке «<Каталог репликации><Код сервера>Protokol» каталога репликации. Каталог репликации задается в параметрах обмена данными в компонентах «Обмен данными с главным сервером» и «Обмен данными со вторичным сервером» или в компоненте «Агент
репликации».

В каких случаях записывается информация

Всегда.

Фиксируемая информация

В протоколе фиксируется результат передачи/приема действий изменения данных.

Лог-файл репликации

Имя лог-файла

<имя компьютера>.err

Путь до лог-файла

Задается в параметре «MB_ALogPath» в установках системы DIRECTUM. Если значение данного параметра не указано, то лог располагается в папке, куда установлена клиентская часть системы DIRECTUM.

В каких случаях записывается информация

Необходимость ведения лога задается в параметре «MB_AExistLog».

Фиксируемая информация

В лог-файле фиксируются ошибки в работе компонент репликации.

Имя лог-файла

Задается вместе с путем до лог-файла. Как правило, лог-файл называется «log.log».

Путь до лог-файла

Задается в ходе установки Сервера веб-доступа к DIRECTUM.

Путь сохраняется в параметре «LogFileName» файла «Web.config» (для версии 4.5 и выше) или «SettingsSettings.xml» (для версии ниже 4.5), который находится в корневом каталоге веб-узла. Как правило, лог-файл располагается в папке «C:InetpubwwwrootDirectumlogs».

В каких случаях записывается информация

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

Фиксируемая информация

Дата ошибки

Время ошибки

Тики процессора

Тип сообщения: ошибка/предупреждение

Библиотека породившая исключение (для ошибок)

Пользователь

URL

IP-адрес клиента

Текст сообщения

Стек вызова

Строгое имя сборки

ИД сессии

Тип браузера

См. также

Раздел Утилита конфигурирования сервера веб-доступа Закладка «Общие» книги «Компоненты системы DIRECTUM».

Расширения DIRECTUM для SharePoint

Имя лог-файла

Задается вместе с путем до лог-файла. Как правило, лог-файл называется «error.log».

Путь до лог-файла

Задается в ходе установки Расширений DIRECTUM для SharePoint.

Путь сохраняется в параметре «LogPath» файла «Settings.xml», который находится в корневом каталоге веб-узла. Как правило, лог-файл располагается в папке «C:InetpubwwwrootwssVirtualDirectories80logs».

В каких случаях записывается информация

При возникновении ошибок в ходе работы расширений.

Фиксируемая информация

Аналогично серверу веб-доступа.

Набор средств интеграции DIRECTUM

Имя лог-файла

*_export_log.txt — выгрузка из DIRECTUM

*_import_log.txt — загрузка в DIRECTUM

* — код записи справочника «Интегрированные системы».

Путь до лог-файла

Указан в параметре «Протоколы» на закладке «Настройки обмена данными» записи справочника «Интегрированные системы».

Программы установки DIRECTUM

Имя лог-файла

Задается ключом командной строки /L утилиты msiexec.exe (setup.exe). Если ключ не указан, но настроена политика безопасности Windows для ведения логов установки, файл лога будет создан в папке «%TEMP%» со случайным уникальным именем «MSI*.LOG». Подробнее
можно прочитать в статье
Logging.

Путь до лог-файла

Аналогично имени лог-файла.

В каких случаях записывается информация

Когда настроено ведение лог-файла.

Фиксируемая информация

В зависимости от ключей, переданных в командной строке или настроек политики безопасности Windows. По-умолчанию в лог-файле фиксируются основные действия установщика. Подробнее о ключах установщика можно прочитать в статье
Command-Line Switches for the Microsoft Windows Installer Tool.

Примечание

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

См. также

Скрипт для получение лог-файлов DIRECTUM

Название

GetDirectumLogs.vbs

Описание

Копирует лог-файлы DIRECTUM текущего компьютера в <Указанная папка>DirectumLogs (если не указана, то в <Текущая папка>DirectumLogs).

GetDirectumLogs.vbs (10,98 Кб)

Агент веб-доступа 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. Исправленные замечания» на сайте поддержки . Если у вас остались вопросы, мы готовы ответить на них в комментариях.

Источник

Обновлено 28.11.2022

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

Устранение ошибки поддержки безопасных каналов

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

Ошибка поддержки безопасных каналов

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

• 1️⃣В интернете все копипастят друг у друга, что в данной ситуации помогает включение TLS, но я проверил и правки в реестре не дают ничего, тем более у меня уже они были активированы, я с этим еще сталкивался, когда получал ошибку «Unable to resolve package source» при установке модуля PowerShell.
• 2️⃣Далее если у вас есть антивирусное решение, то я вам советую его отключить на время, пока будите производить тестирование. Антивирус Касперского тут так же был ни причем
• 3️⃣Далее, что я обычно проверяю, это не производилась ли установка нового софта или обновлений Windows. Обязательно выведите список установленных программ и посмотрите, нет ли там чего-то нового. Бывает ситуация, что некоторые программы могут конфликтовать при совместном использовании, например очень частая ситуация с КриптоПРО, старыми версиями. Если она есть, то попробуйте ее удалить.
• 4️⃣Проверьте не было ли установки новых обновлений, это можно посмотреть в истории параметров Windows или в оснастке appwiz.cpl.

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

Если у вас есть поддержка от Directum, то стоит задать вопрос туда возможно. что-то подскажут, у меня такой возможности нет

Чтобы удалить KB5018411  я воспользуюсь командной строкой и утилитой wusa. Введите:

wusa /uninstall /kb:5018411

У вас выскочит окно с подтверждением удаления данного обновления. Нажмите ок, начнется процесс.

Так же вы можете сделать, и тихое удаление добавим ключи: /quiet /norestart

wusa /uninstall /kb:5018411 /quiet /norestart

После этого мой Directum заработал, посмотрю что будет со следующими обновлениями, может Mixrosoft пофиксит это.

Обновление 28.11.2022

Как и ожидалось, данная ошибка была устранена установкой ноябрьских обновлений KB5019964. С вами был Иван Семин, автор и создатель IT проекта Pyatilistnik.org.

Итак, произошло то, что произошло, сегодня невозможно сделать сет 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С 8, раз­ме­щен­ной в об­ще­до­ступ­ном ка­та­ло­ге в ло­каль­ной сети. Т.е. «вчера» база ра­бо­та­ла ис­прав­но, а «се­год­ня» у поль­зо­ва­те­лей в про­из­воль­ные мо­мен­ты вре­ме­ни, при раз­ных со­бы­ти­ях и дей­стви­ях в базе ра­бо­та поль­зо­ва­те­ля пре­кра­ща­ет­ся с воз­ник­но­ве­ни­ем ошиб­ки: Сеанс от­сут­ству­ет или уда­лен ID= , File=srcSeanceContextImpl.​cpp(984)

В ка­кой-​то мо­мент, пы­та­ясь «пой­мать» ошиб­ку, т.к. она имела пла­ва­ю­щий ха­рак­тер, ра­бо­тая в ре­жи­ме 1С Пред­при­я­тие даже уда­лось по­лу­чить окно ошиб­ки, что на изоб­ра­же­нии выше, но еще до­пол­ни­тель­но с кноп­кой «По­дроб­но…», нажав на ко­то­рую, по­лу­чи­лось из­влечь текст ошиб­ки, но, к со­жа­ле­нию, не уда­лось за­фик­си­ро­вать изоб­ра­же­ние окна ошиб­ки с до­пол­ни­тель­ной кноп­кой.

В этом слу­чае по­лу­чи­лось, что ошиб­ка была в коде, но потом она не по­вто­ря­лась имен­но для этого участ­ка кода и в фор­мах ошиб­ки боль­ше не было кноп­ки «По­дроб­но…». Зна­чит, что дело не в коде, а что на самом деле он не может по­лу­чить дан­ные, на ко­то­рые на­стро­ен по сто­рон­ней при­чине.