Обслуживание системы

Логирование и поиск ошибок

Логирование в TESSA настраивается в файлах NLog.config. По умолчанию файл лога log.txt располагается в той же папке, что и NLog.config. Можно настроить по своим правилам, например, чтобы логируемые сообщения записывались в отдельные файлы каждый день с созданием подпапок с номером месяца и года. Подробная информация по настройкам NLog.config доступна в документации по библиотеке NLog.

Note

Если меняются настройки логирования клиентских приложений (Tessa Application, TessaClient, TessaAdmin), то необходимо приложение переопубликовать для распространения данных настроек на всех пользователей.

При возникновении каких-либо проблем в TESSA, можно изучить следующие логи:

• Серверные логи:

  • Логи web-сервера

    В файле C:\inetpub\wwwroot\tessa\web\NLog.config (для linux - /home/tessa/tessa/web/NLog.config) указывается расположение логов и уровень логирования. По умолчанию файл log.txt расположен в этой же папке.

  • Логи сервиса Chronos

    В файле Chronos\NLog.config указывается расположение логов и уровень логирования. По умолчанию файл log.txt расположен в этой же папке.

  • События журнала Windows

• Клиентские логи

  • Логи Applications Manager

    В файле NLog.config рядом с выполняемыми файлами TessaAppLauncher.exe (располагается в папке установки, по умолчанию %ProgramFiles(x86)%\Syntellect\Tessa Applications\) и TessaAppManager.exe (при первичной установке располагается в папке установки, по умолчанию %ProgramFiles(x86)%\Syntellect\Tessa Applications\app, если были обновления Tessa Applications, то в папке профиля пользователя %APPDATA%\tessa\appmanager) указывается расположение логов. Там же определяется уровень логирования (по умолчанию логируются только ошибки). По умолчанию логирование настроено в текстовые файлы и журнал приложений Windows. Текстовые файлы: %APPDATA%\tessa\logs\AppManager.txt, %APPDATA%\tessa\logs\AppLauncher.txt.

  • Логи TessaClient

    Настройка расположения папки для загруженных приложений производится в конфигурационном файле %appdata%\tessa\settings\application_catalogs.xml в параметре t:AppPath, по умолчанию указана папка %localappdata%\tessa. В файле %localappdata%\tessa\applications\tessa\tessaclient\NLog.config указывается расположение логов. По умолчанию файл log.txt расположен в этой же папке.

  • Карточки ошибок

    В TessaClient в представлении Администратор → Прочее → Ошибки можно посмотреть некоторые ошибки системы, получаемые пользователями.

История действий

Просмотр истории действий в Tessa доступен только для администраторов системы (т.е. уровень доступа сотрудника - “Администратор”, см. Создание карточки сотрудника).

По умолчанию история действий фиксируется по всем типам карточек и всем изменениям в объектах приложения TessaAdmin. Отключить данную настройку для какого либо типа карточки можно в TessaAdmin, найдя нужную карточку и сняв флаг “Фиксировать действия” (более подробно описано в разделе Создание нового типа карточки).

Просмотр журнала

Просмотреть журнал (т.е. полный список записей о всех событиях) можно на вкладке “Администратор”, представление Прочее → История действий:

По умолчанию записи отсортированы по дате/времени события. В данном представлении можно выполнить поиск по параметрам (нажав на кнопку с изображением лупы), например - просмотр информации о входе в систему любых сотрудников за конкретную дату:

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

Дважды кликнув на нужной строке в представлении, откроется карточка записи в истории.

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

Дважды кликнув на значении в поле “Объект” в новой вкладке будет открыта та карточка, в которой были произведены описанные изменения.

С клиента на сервер любой запрос приходит в форме реквеста различных типов. Реквест в бинарном виде сохраняется в карточке события. На вкладке “Системная информация” можно посмотреть этот реквест в десериализованном виде:

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

Просмотр истории действий по карточке

Из любой карточки в системе (карточка документа, карточка роли, карточка какого-либо справочника, карточка настроек и т.д.) можно просмотреть список всех событий по ней. Открыв нужную карточку, на левой панели системы выбираем Системные → История действий:

В новой вкладке будет открыта история действий по данной карточке:

С помощью поисковых параметров (нажав на изображение лупы) в данном списке можно выполнить поиск нужных записей.

Для просмотра подробной информации по событию необходимо дважды кликнуть по нужной строке, в новой вкладке будет открыта карточка записи в истории. Описание карточки “Запись в истории” см. в предыдущем разделе.

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

События истории действий

В истории действий фиксируются события, описанные ниже. Для каждой записи в истории фиксируется:

• Объект - объект, в котором были выполнены действия. Если изменения были в карточке, то двойным кликом по ссылке можно открыть указанную карточку;

• Тип - тип карточки или объекта, где было выполнено действие;

• Идентификатор сессии - id сессии, в которой было выполнено действие;

• Действие - событие, которое было выполнено;

• Сотрудник - сотрудник выполнивший действие;

• Дата/время события;

• Описание изменений - подробное описание изменений.

Список возможных событий (описание событий сгруппировано по типу):

Все карточки

• Восстановление карточки из корзины - восстановление удаленной карточки.

• Изменение карточки - запись о внесении каких-либо изменений в любую карточку.

• Импорт карточки - импорт любой карточки в систему (через TessaAdmin или TessaClient).

• Открытие карточки - открытие какой-либо карточки (а также при обновлении уже открытой карточки).

• Открытие файла - открытия приложенного к какой-либо карточке файла (в том числе просмотр файла с помощью области предпросмотра).

• Создание карточки - создание новой карточки любого типа.

• Удаление карточки - запись об удалении карточки с указанием способа удаления (с или без возможности восстановления).

• Удаление карточки из корзины - удаление карточки из представления “Удаленные карточки” или в случае удаления карточки сразу без возможности восстановления (доступно только для Администраторов).

• Экспорт - экспорт карточки.

Сотрудник (карточка сотрудника)

• Вход в систему - вход сотрудника в систему. Объект - карточка сотрудника.

• Выход из системы - выход сотрудника из системы.

• Закрытие сессии администратором - закрытие сессии администратором.

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

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

• Выделение зарезервированного номера - выделение номера из последовательности (например, при создании/сохранении новой карточки, или при ручном выделении нового номера в карточке документа).

• Выделение незарезервированного номера - выделение незарезервированного номера (при импорте карточки).

• Выделение очередного номера - выделение номера карточки без резервирования (с помощью дополнительных расширений).

• Дерезервирование номера - удаление резерва номера в последовательности (например, когда новая карточка с выделенным (зарезервированным) номером была закрыта без сохранения).

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

• Резервирование номера - информация о резервировании номера в последовательности (номер резервируется до сохранения карточки документа).

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

Настройки сервера (действия в TessaAdmin)

• Изменение библиотеки (схема) - создание новой или переименование библиотеки в схеме данных.

• Изменение библиотеки локализации - создание новой библиотеки, переименование библиотеки или любые изменения в строках библиотеки (включая удаление строк).

• Изменение миграции (схема) - создание, переименование или изменение миграции в схеме данных.

• Изменение представления - переименование или внесение изменений в представление, включая редактирование прав доступа.

• Изменение процедуры (схема) - создание, переименование или изменение процедуры в схеме данных.

• Изменение рабочего места - переименование или внесение изменений в рабочее место, включая редактирование прав доступа.

• Изменение таблицы (схема) - создание, переименование или изменение таблицы в схеме данных.

• Изменение типа карточки - переименование или внесение изменений в тип карточки.

• Изменение функции (схема) - создание, переименование или изменение функции в схеме данных.

• Импорт представления - импорт представления (через TessaAdmin или с помощью утилиты tadmin).

• Импорт рабочего места - импорт рабочего места (через TessaAdmin или с помощью утилиты tadmin).

• Создание представления - создание нового представления.

• Создание рабочего места - создание нового рабочего места.

• Создание типа карточки - создание нового типа карточки.

• Удаление библиотеки (схема) - удаление библиотеки из схемы.

• Удаление библиотеки локализации - удаление библиотеки локализации.

• Удаление миграции (схема) - удаление миграции из схемы.

• Удаление представления - удаление представления.

• Удаление процедуры (схема) - удаление процедуры из схемы.

• Удаление рабочего места - удаление рабочего места.

• Удаление таблицы (схема) - удаление таблицы из схемы.

• Удаление типа карточки - удаление типа карточки.

• Удаление функции (схема) - удаление функции из схемы.

Прочее

• Ошибка - запись о создании новой карточки ошибки (список карточек можно посмотреть на вкладке Администратор → Прочее → Ошибки). Фиксируются следующие виды ошибок: ошибки при скачивании приложений в Tessa Applications, ошибки расчёта ролей, ошибки конвертации файлов (для предпросмотра в лёгком клиенте), ошибки бизнес-процессов Workflow Engine. Также тут могут фиксироваться какие-то дополнительные ошибки в проектных расширениях.

Очистка журнала

Очистка журнала истории действий выполняется плагином сервиса Chronos. Период очистки журнала задается в параметре Maintenance.RemoveActionHistoryOlderThanDays в конфигурационном файле, который расположен в папке сервиса: Chronos\app.json (более подробно в разделе Настройка плагинов Chronos). По умолчанию очищаются все записи истории, давность которых превышает 180 дней.

Период запуска плагина определяется в конфигурационном файле DailyExtensionsScheduler.xml, который расположен в папке сервиса: Chronos\Plugins\Tessa\configuration. По умолчанию запуск ежедновно в 12:00 am. Описание формата для указания периода запуска плагина можно посмотреть по ссылке.

Note

Конфигурационный файл DailyExtensionsScheduler.xml отвечает не только за очистку истории действий, но и за: удаление старых карточек из корзины; удаление старых карточек ошибок; удаление повисших активных операций; удаление старых скомпилированных представлений для PostgreSQL.

Роли

Общая информация

Роли используются для отправки заданий и для назначения прав доступа.

Для каждой роли в системе создается отдельная карточка. В системе TESSA предусмотрено несколько типов ролей:

• Сотрудник - карточка сотрудника;

• Подразделение - в составе роли подразделения указываются сотрудники. Можно создать любую древовидную структуру подразделений, указывая “Родительское подразделение” в карточке подразделения;

• Статическая роль - статическая роль, в состав которой добавляются нужные сотрудники. Может использоваться для настройки прав доступа или отправки заданий на всех сотрудников роли;

• Контекстная роль - роль, зависящая от контекста карточки. Роль не содержит в себе сотрудников, а вычисляет их в момент обращения к контекстной роли. Например, в типовом решении есть настроенные контекстные роли: Руководитель Инициатора (сотрудник, являющийся руководителем подразделения, в которое входит Инициатор процесса); Автор документа (сотрудник, указанный в карточке документа в поле “Автор”) и т.д.

  Note

  Некоторые факты о контекстной роли: при отправке задания на контекстную роль, система автоматически создает временную роль, куда включает вычисленных по SQL запросу контекстной роли сотрудников; при попытке пользователем создания карточки, система в правилах доступа не учитывает контекстные роли (т.к. пока нет карточки - нет контекста); нельзя предоставлять доступ к представлениям и отчетам для контекстных ролей (т.к. нет контекста карточки).

• Метароль - роль, автоматически создаваемая генератором метаролей по заданному запросу. Пример генератора метаролей, входящий в типовую конфигурацию - “Агрегатные роли” - для каждого подразделения, имеющего дочерние подразделения, автоматически создается метароль с названием Имя_подразделения (все). В роль входят все сотрудники текущего подразделения, а также все сотрудники всех дочерних подразделений. Можно создать свои генераторы метаролей (более подробно о генераторе ролей можно посмотреть в Руководстве разработчика).

• Динамическая роль - роль, автоматически пересчитываемая по указанному SQL запросу плагином сервиса Chronos. Например, роль “Все сотрудники”.

Note

Подробней о пересчёте метаролей и динамических ролей см. далее в разделе Пересчёт ролей.

Также в системе существует еще один тип роли - Временная роль. Данный тип роли не отображается в представлении Роли на рабочем месте Администратор. Такие роли создаются (в момент отправки задания на контекстную роль или в момент отправки задачи, назначенной на группу сотрудников, перечисленных в исполнителях самой задачи) и удаляются автоматически, используются в конкретных заданиях. Более подробно в Руководстве разработчика.

Просмотреть список всех карточек ролей можно из рабочего места Администратора, представление – Роли:

Создание новой роли

Создать новую роль в системе можно с помощью правого меню системы: Создать карточку –> Роли –> выбрать тип создаваемой роли, или с помощью кнопки с изображением карандаша на панели инструментов представления “Роли” - будет создана карточка с тем типом роли, какой сейчас выбран в представлении:

Note

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

Создание карточки нового сотрудника описано в разделе Создание карточки сотрудника.

Загрузить большое количество Сотрудников, Подразделений и Статических ролей в TESSA можно с помощью синхронизации с Active Directory / LDAP, а с помощью утилиты tadmin можно загрузить Сотрудников и Подразделения.

Пересчёт ролей

Пересчёт состава роли выполняется для динамический ролей и метаролей сервисом Chronos с заданным в карточке роли периодом.

Метароли автоматически создаются/пересчитываются с помощью генератора метаролей. Карточки генераторов метаролей можно найти на рабочем месте Администратор → Прочее → Генераторы метаролей.

В карточке динамической роли и генератора метаролей есть следующие настройки пересчёта:

• Период в секундах - частота пересчёта роли, указывается, если не заполнено поле “Выражение Cron”. Пересчёт будет выполнен при запуске сервиса Chronos и далее с указанной частотой.

• Выражение Cron - расписание запуска пересчёта, указывается, если не заполнено поле “Период в секундах”. Более подробно описание формата Cron можно посмотреть по ссылке.

• Запланировать пересчёт при запуске сервиса Chronos - если пересчёт запланирован по выражению Cron, то при запуске или перезапуске сервиса Chronos пересчёт выполняется сразу же только в том случае, если включена эта опция. Если пересчёт выполняется по указанному периоду, то при запуске сервиса пересчёт выполняется, независимо от этой опции.

  Например, выражение Cron может быть “в начале каждого часа с 8 утра до 8 вечера каждого дня”. Если сервис Chronos запущен в 13:15, то первый пересчёт произойдёт в 14:00, если флаг не выставлен. С установленным флагом пересчёт будет сразу же, а потом по расписанию, т.е. в 14:00, в 15:00 и т.д.

• Кнопка Пересчитать роль сейчас/Пересчитать генератор метаролей сейчас - рассчитывает динамическую роль/метароли в текущий момент. Расчёт может занять какое-то время, в зависимости от данных в БД, от сложности SQL запроса в роли, от нагрузки системы и т.п.

  Кнопку можно нажать и при параллельно работающем сервисе Chronos, и без него. Если Chronos параллельно считает какую-то другую роль, то расчёт по кнопке будет запущен после того, как Chronos закончит работу.

  Как и в случае расчёта в Chronos, в представлении “Администратор → Прочее → Активные операции” будет отображена операция с типом «Расчёт ролей» и с названием, например, «Динамическая роль: Все сотрудники».

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

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

Note

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

Замещения

Особенности работы замещений

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

• Каждый сотрудник может самостоятельно настроить себе заместителей (см. Руководство пользователя).

• Замещение может быть постоянное или на указанный период.

• Заместитель на период замещения получает доступ ко всем заданиям указанной роли - как к новым, так и старым заданиям, в том числе взятым в работу основным исполнителем.

• Заместитель в системе может работать параллельно с замещаемым сотрудником.

• Заместитель получает почтовые уведомления по всем новым задания замещаемого сотрудника.

• Если заместитель взял задание в работу, то оно становится не доступно основному исполнителю.

• Замещение может быть только на роль, при этом указать можно любой тип роли (сотрудник, подразделение, статическая роль, контекстная, динамическая, метароль).

• Заместитель получает все права доступа замещаемой роли, в том числе права доступа к представлениям, права на чтение/редактирование карточек, расширенные права доступа, права на отчеты, права, выдаваемые этапом маршрута и т.д.

• Замещения во временной роли “Исполнители задания” (например, когда отправляется одна общая типовая задача на несколько сотрудников) не пересчитываются. Т.е. если добавить заместителя после отправки такой задачи, то заместитель не увидит этого задания. Ему будут доступны только новые такие задания. Аналогична и обратная ситуация в такой временной роли: при окончании срока замещения, заместитель автоматически из этой роли не удалится.

• Замещения во временных ролях, создаваемых по контекстным ролям, работают без каких-либо особенностей, т.е. аналогично другим типам ролей.

• Замещения не наследуются. Если, например, настроена следующая связка замещений: Сотрудник 1 → Сотрудник 2 → Сотрудник 3, то Сотрудник 1 получит права только Сотрудника 2, но не получит прав Сотрудника 3. Права Сотрудника 3 будут только у Сотрудника 2.

Добавление заместителей

Добавление заместителей доступно для следующих типов ролей:

• Сотрудник;

• Департамент;

• Статическая роль.

Note

Рекомендуется использовать Карточка “Мои замещения” для настройки замещений, где можно настроить замещения в том числе по контекстным и динамическим ролям.

Note

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

Для каждой роли можно указать заместителей, которые, в случае отсутствия замещаемого сотрудника, смогут выполнить за него задания. Для добавления заместителей в карточке роли (Сотрудник, Департамент или Статическая роль) в области Заместители нажать на кнопку Добавить:

В открывшемся окне указать заместителя и срок замещения:

• Заместитель – сотрудник, кому станут доступны задания текущего сотрудника/департамента/роли;

• Замещаемый пользователь – замещаемый сотрудник. Если в данном поле указан сотрудник, то все задания этого сотрудника (Новые и взятые В работу) будут доступны заместителю. Если поле оставить пустым, то заместителю будут доступны только Новые задания сотрудника/департамента/роли (задания, взятые В работу каким-либо сотрудником, не будут доступны заместителю).

• Замещение доступно – флаг для включения/отключения замещения;

• Постоянное замещение – флаг выставляется, если текущее замещение не ограничено сроком;

• Начало/Окончание замещения – срок замещения указывается, если это не постоянное замещение.

Таким образом, для каждой роли можно добавить несколько заместителей. Для удаления заместителя – выбрать заместителя и нажать кнопку Удалить в области Заместители.

При добавлении заместителя в колонке Активно по умолчанию установлено “нет”. Периодический сервис на сервере приложений (Chronos) в указанные сроки замещения добавляет заместителя в состав роли. При этом в поле “Пользователи и заместители” этот пользователь появляется, а в таблице с замещениями колонка “Активно” переключается на “да”. Сервис Chronos обрабатывает роли с периодичностью несколько минут, поэтому замещение включается (“Активно” переключается на “да”) спустя некоторое время.

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

Important

Задания, которые были отправлены на временную роль “Исполнители задания” (т.е. роль, сформированную при отправке одной задачи на несколько исполнителей) не будут доступны заместителям, т.к. список заместителей для таких задач рассчитывается в момент отправки задачи. Однако, новые задачи, отправляемые на роль “Исполнители задания” (где в составе роли и текущий сотрудник) будут доступны указанным заместителям.

Note

Заместитель помимо прав на исполнение заданий получит все права доступа замещаемого сотрудника/роли (т.е. права на просмотр отчетов, создание/редактирование карточек, просмотр реестров и т.д.). Таким образом, если замещение назначено на роль, то заместитель получит права, доступные для данной роли. Если замещение назначено на сотрудника, то заместитель получит права, доступные только данному сотруднику (исключая права, назначенные на роли, в которые входит этот сотрудник).

Карточка “Мои замещения”

Для каждого пользователя системы настраивать замещения можно с помощью карточки “Мои замещения” (дополнительная вкладка в карточке сотрудника):

Note

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

В карточке для заполнения доступны следующие поля:

• Кто может редактировать - можно указать сотрудников, кому будет доступно редактирование заместителей текущего сотрудника;

• Заместители - раздел для добавления заместителей. Для добавления новой строки нажать на кнопку “Добавить”, откроется форма добавления замещения:

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

  • Все статические роли - замещение на задания, назначенные на любые статические роли, в которые входит текущий сотрудник;

  • Все роли и подразделения - замещение на все задания, назначенные на текущего сотрудника и на все типы ролей, в которые входит сотрудник;

  • Все подразделения - замещение на все задания, назначенные на подразделения, в которые входит текущий сотрудник;

  • Лично я - замещение на все задания, назначенные на текущего сотрудника;

Note

При указании в поле “Список ролей” значений Лично я, Все роли и подразделения или <ФИО сотрудника> - заместитель помимо прав на исполнение заданий получит все права доступа замещаемого сотрудника/роли (т.е. права на просмотр отчетов, создание/редактирование карточек, просмотр реестров и т.д.). Таким образом, если замещение назначено на роль, то заместитель получит права, доступные для данной роли. Если замещение назначено на сотрудника, то заместитель получит права, доступные только данному сотруднику (исключая права, назначенные на роли, в которые входит этот сотрудник).

• Заместители – список сотрудников, кому будут доступны все задания указанных ролей текущего сотрудника;

• Замещение доступно – флаг для включения/отключения замещения;

• Постоянное замещение – флаг выставляется, если текущее замещение не ограничено сроком;

• Начало/Окончание замещения – срок замещения указывается, если это не постоянное замещение.

Таким образом, для сотрудника можно добавить несколько заместителей на разные роли:

Заместителям будут доступны как новые задания, так и задания, взятые в работу основным исполнителем.

Important

Задания, которые были отправлены на временную роль “Исполнители задания” (т.е. роль, сформированную при отправке одной задачи на несколько исполнителей) не будут доступны заместителям, т.к. список заместителей для таких задач рассчитывается в момент отправки задачи. Однако, новые задачи, отправляемые на роль “Исполнители задания” (где в составе роли и текущий сотрудник) будут доступны указанным заместителям.

Календарь

Общие понятия

Календарь в TESSA используется для расчёта относительных сроков исполнения заданий.

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

• Длительность, рабочие дни или Срок, рабочие дни

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

• Дата выполнения

  Если указывается конкретная дата выполнения, то в этом случае календарь не используется. Пользователь может указать любую дату, включая праздничные дни и даты, выходящие за пределы периода действия календаря (что такое “период действия” описано ниже).

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

Для отражения момента времени в календаре используется специальное понятие кванта времени. Существует два типа квантов времени - рабочий и не рабочий.

• Рабочий квант - длится 15 минут. На такие кванты разбит весь рабочий день.

• Нерабочий квант - длится всё время с момента конца предыдущего рабочего кванта и до момента начала следующего рабочего кванта.

Таким образом - настройка календаря сводится к настройке последовательностей рабочих и не рабочих квантов. Для удобства управления этим процессом существует специальная карточка настроек календаря.

Настройка календаря

Открыть карточку настроек календаря можно из правого меню → Настройки → Календарь.

Календарь оперирует датами во временной зоне объекта, для которого выполняются расчёты. Например, для расчёта сроков по календарю некоторого сотрудника считается, что все даты записаны в часовом поясе этого сотрудника (см. Временные зоны).

Исключения

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

Добавление исключения выглядит следующим образом:

Note

При добавлении исключений не учитываются указанные в карточке календаря начало и окончание рабочего дня, поэтому при добавлении выходного дня (субботы или воскресенья) как рабочего, исключение надо выставлять с учетом рабочего времени, т.е. добавить две строки исключений: первая с, например, 9:00 до 13:00, вторая - с 14:00 до 18:00, тогда данный выходной день будет считаться 8-ми часовым рабочим днем.

Период действия календаря

В этом блоке заполняется период, для которого рассчитывается календарь. Календарь будет рассчитан с 00:00:00 даты начала и по 23:59:59 даты конца.

Warning

Указывайте тот период, для которого заполнена таблица “Исключения”.

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

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

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

Рабочий день и обеденный перерыв

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

Расчёт календаря и проверка ошибок

В нижней части карточки календаря находятся две кнопки:

• Пересчитать календарь – вызывает перерасчёт календаря с учётом всех данных, указанных в карточке.

• Проверить целостность – вызывает проверку календаря на наличие ошибок.

Important

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

Note

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

Временные зоны

Общие понятия

Для организации возможности функционирования системы в разных часовых поясах существуют настройки временных зон. Предположим, что у нас есть исполнитель в Новосибирске (UTC+7) и отправим ему задание из Москвы. Т.е. разница с Москвой +4 часа - когда в Москве полдень, в Новосибирске 16:00.

• Пусть в Москве у нас сейчас 12:00 10 января и мы отправляем задание длительностью 4 часа.

• Система получает временную зону исполнителя, определяет текущее время во временной зоне исполнителя (16.00 10-ое января) и обращается к календарю.

• Зная текущее время исполнителя, можно корректно определить время для завершения задания, и оно будет 11:00 11-го января (2 рабочих часа 10-го января и 2 рабочих часа 11-го января)

• После всех вычислений останется только записать в задании дату завершения 4.00 11-го января по UTC.

Особенности работы

• Календарь не привязан к какой-то конкретной временной зоне. Значения для начала и конца рабочего времени, а также для обеда, хранятся без смещений. Т.е. при рабочем дне с 9.00 до 18.00 и обедом с 13.00 до 14.00, в календаре лежат кванты 9.00 - 9.15, 9.15 - 9.30 и т.д..

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

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

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

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

Note

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

Note

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

Note

Так же при отправке задания с указанием плановой даты, появилась возможность трактовать эту дату, как дату во времени исполнителя или же автора задания. Подробнее об этом можно прочитать в “Руководстве разработчика” в разделе Плановая дата завершения задания во временной зоне автора или исполнителя.

Карточка настройки временных зон

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

Открыть карточку настройки временных зон можно из правого меню - Настройки → Временные зоны. Карточка доступна только администраторам системы.

Карточка настройки временных зон содержит в себе:

• Настройку, запрещающую/разрешающую редактирование временных зон в ролях.

• Справочник временных зон - таблица со списком доступных временных зон.

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

Запрет редактирования временных зон в ролях

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

Временная зона по умолчанию

Зона с идентификатором “0” в списке временных зон является временной зоной “По умолчанию”. Её нельзя удалить или поменять ей “Идентификатор зоны” и “Отображаемое значение”. Можно лишь изменить “Код зоны” и “Смещение”. Эта зона будет использована в тех случаях, если временную зону определить не удалось. Например, когда не заполнено поле в роли или генератор метаролей не предоставил информацию о временной зоне.

Также, при установке “чистой” системы из сборки, эта зона прописана для всех ролей, которые присутствуют в системе. Смещение зоны “По умолчанию” можно задать при установке через скрипты “Setup.bat”, “setup.sh” и т.д.. Или же можно поменять смещение в временной зоне “По умолчанию” - уже после установки системы, зайдя в карточку настройки временных зон.

Добавление и редактирование временных зон

Двойным нажатием левой кнопки мыши на любую из строк в таблице временных зон, можно поменять её параметры.

Доступны для изменения следующие параметры:

• “Идентификатор зоны” - уникальный идентификатор, по которому сопоставляются со справочником временные зоны, указанные в ролях, заданиях и записях истории заданий.

• “Код зоны” - алиас, который описывает временную зону.

• “Отображаемое значение” - универсальное отображаемое имя.

• “Смещение” - время, на которое временная зона отличается от UTC.

• “Отрицательное направление сдвига” - признак того, что “Смещение” относительно UTC направлено в отрицательную сторону.

Note

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

Note

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

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

Служебные тайлы

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

• “Заполнить временные зоны” - временные зоны будут удалены и заполнены в соответствии с настройками ОС на сервере приложений.

• “Установить зону “По умолчанию”” - устанавливает для всех ролей временную зону “По умолчанию”, указанную в справочнике.

• “Обновить связи” - проверяет и исправляет, если необходимо, временные зоны, проставленные за счёт иерархии наследования временных зон между подразделениями, сотрудниками и статическими ролями.

• “Обновить смещения” - проверяет и исправляет смещения в ролях, согласно справочнику из карточки временных зон.

Временные зоны в ролях

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

Note

При изменении временной зоны в роли, на которую назначалось задание, временная зона в задании остаётся неизменной.

Note

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

Ниже описаны особенности настройки временных зон в разных типах ролей:

• Сотрудник

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

  

• Подразделение

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

  

• Статическая роль

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

  

  Note

  Сотрудники, состоящие в составе статической роли, не наследуют временную зону от неё.

• Динамическая роль

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

  

• Метароль

  В карточке метароли есть поле с временной зоной, но указать его вручную нельзя. Кроме того, также, как и в динамической роли, наследование временной зоны - не предполагается. Временной зоной в метаролях управляет их генератор. Для указания временной зоны - необходимо, чтобы генератор метаролей вернул нужную временную зону в результатах запроса. Например, как в генераторе для “Агрегатных ролей”.

  

  Note

  Колонка с идентификатором временной зоны должна идти пятой и может иметь любой алиас. Если колонки с идентификатором временной зоны не будет, то считается, что метароль имеет временную зону “По умолчанию”.

• Контекстная роль

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

• Роль задания

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

  

Наследование временных зон

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

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

• При наследовании в подразделениях - наследуется временная зона родительского подразделения. Если нет родителя - подтянется зона “По умолчанию”.

• При наследовании в роли сотрудника - наследуется временная зона подразделения, в которое входит сотрудник.

• При наследовании в статических ролях - наследуется временная зона родительской статической роли. Если нет родителя - подтянется зона “По умолчанию”.

Note

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

Note

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

Работа с удаленными карточками

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

Карточка хранится в корзине 30 дней, а затем удаляется специальным плагином Chronos. Период хранения карточки можно настроить в файле “Chronos\app.json”, параметр Maintenance.RemoveDeletedCardsOlderThanDays (см. Настройка плагинов Chronos).

Период запуска плагина определяется в конфигурационном файле DailyExtensionsScheduler.xml, который расположен в папке сервиса: Chronos\Plugins\Tessa\configuration. По умолчанию запуск ежедновно в 12:00 am. Описание формата для указания периода запуска плагина можно посмотреть по ссылке.

Note

Конфигурационный файл DailyExtensionsScheduler.xml отвечает не только за очистку удалённых карточек, но и за: удаление старых записей в истории действий; удаление старых карточек ошибок; удаление повисших активных операций; удаление старых скомпилированных представлений для PostgreSQL.

Warning

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

Просмотреть список всех удаленных в системе карточек можно из представления Удаленные карточки, расположенного в разделе Прочее на вкладке Администратор:

Открыв карточку, открывается информация по удаленной карточке:

На вкладке “Карточка” указана основная информация по удаленной карточке (номер, тип, идентификатор, а также приложенные файлы). На вкладке “Задания” - список сотрудников/ролей, на которых были назначены какие-либо задания по данной удаленной карточке. На вкладке “Системная информация” можно посмотреть структуру карточки.

Note

Вносить какие-либо изменения в удаленную карточку невозможно.

По удаленной карточке доступны следующие действия:

• Просмотр исходной карточки - для просмотра самой карточки можно нажать сочетание клавиш [Ctrl] + [Enter] или кнопку в левом меню системы - Просмотр:

  

  В новой вкладке на чтение будет открыта карточка. Для возврата к удаленной карточке можно также нажать сочетание клавиш [Ctrl] + [Enter].

• Восстановить - восстановить карточку можно с помощью сочетания клавиш [Ctrl] + [Z] или нажав на кнопку Восстановить в левом меню системы. Карточка будет восстановлена в системе и доступна для пользователей.

  Note

  Если при удалении в карточке были какие-то активные процессы/задания, то при восстановлении карточка будет в том же виде, как перед удалением - с теми же заданиями и активными этапами процесса.

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

• Удалить - для окончательного удаления карточки нажать сочетание клавиш [Ctrl] + [D] или кнопку Удалить в левом меню системы.

  Warning

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

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

Файловые хранилища в TESSA используются для хранения всех файлов, прикладываемых к карточкам. Могут использоваться следующие типы хранилищ:

• База данных (только при использовании СУБД MS SQL) - хранение файлов непосредственно в базе данных;

• Файловая папка - хранение файлов в папке (предпочтительно - сетевой).

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

Note

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

Important

Для хранения файлов не рекомендуется использовать хранилище в БД, т.к. размеры бэкапов при этом будут слишком велики, а также скорость работы с файлами в БД заметно ниже скорости работы с файлами через файловую папку. Хранение файлов в БД оправдано только в случае, если используется полнотекстовый поиск в MS SQL. Подробно настройка полнотекстового поиска (и, соответственно, файлового хранилища в этом случае) описана в Руководстве по установке Tessa.

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

В карточке настроек сервера в таблице указываются следующие параметры файловых хранилищ:

• ID - идентификатор хранилища;

• Название - название хранилища;

• Местоположение - расположение хранилища:

  • если установлен флаг “База данных”, то указывается имя строки подключения из конфигурационного файла (значение default определяет, что будут использоваться настройки соединения по умолчанию);

  • если флаг “База данных” не установлен, то необходимо указать полный путь к файловой папке;

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

• База данных - флаг устанавливается, если хранилище соответствует базе данных, а не файловой папке;

  Warning

  СУБД PostgreSQL не поддерживает хранение файлов в базе.

• Обратная совместимость - флаг устанавливается в случае, если хранилище на файловой системе уже существовало в версии платформы 1.20 или раньше:

  • если флаг установлен, то подпапки с файлами всех карточек расположены в базовой папке (см. поле “Местоположение”);

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

Important

Не рекомендуется устанавливать флаг “Обратная совместимость” для новых установок системы.

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

Кэш файлов

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

Конвертация файлов для предпросмотра выполняется плагином сервиса Chronos. Более подробно, как настроить конвертацию файлов для предпросмотра, описано в Руководстве по установке Tessa.

Открыть карточку кэша файлов можно из правого меню системы → Настройки → Кэш файлов.

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

• Удалить старые файлы из кэша - удалить все файлы, к которым не было обращений за последние 10 дней.

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

Note

В кэше файлов автоматически удаляются все файлы, к которым не было обращения более 10 дней.

За очистку файлов из кэша отвечает тот же плагин, который выполняет конвертацию файлов - FileConverterPlugin.xml (все плагины сервиса Chronos расположены по пути Chronos\Plugins\Tessa\configuration). В конфигурационном файле сервиса Chronos\app.json есть следующие параметры для плагина по очистке кэша:

• FileConverter.CacheCleanPeriod - период запуска очистки кэша. По умолчанию очистка выполняется каждые 12 часов.

• FileConverter.OldestPreviewFilePeriod - срок, по истечении которого, неиспользуемые файлы из кэша будут удалены. По умолчанию очищаются все файлы, к которым не было обращений более 10 дней.

Лицензии и сессии

Параметры текущей используемой лицензии вы можете посмотреть в приложении TessaAdmin на вкладке “Информация”.

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

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

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

Карточка лицензии

Открыть карточку настроек лицензий можно из правого меню → Настройки → Лицензии.

Карточка содержит в себе следующие настройки:

• Конкурентные лицензии – общее количество/количество занятых конкурентных лицензий для TessaClient и web-клиента. Конкурентные лицензии задействуются, когда какой-либо пользователь заходит в TessaClient/web-клиент (пользователь, для которого не выписана персональная лицензия) и проявляет какую-либо активность в течение последнего часа. Если активности в течение последнего часа нет, то лицензия не освобождается, но при этом учитывается при подсчёте как свободная. Когда пользователь из приложения выходит (или в web-клиенте нажимает Выйти из учетной записи) - лицензия освобождается. При отсутствии свободных конкурентных лицензий новый сотрудник не сможет запустить TessaClient;

  Note

  Если все конкуретные лицензии заняты сотрудниками с уровнем доступа “Пользователь” и, при этом они все активны, то, несмотря на отсутствие свободных лицензий, доступ в систему для одного сотрудника с уровнем доступа “Администратор” все равно гарантирован.

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

  Note

  Tessa Applictions также использует конкурентную/персональную лицензию, однако кратковременно: открывает сессию, занимает лицензию, выполняет необходимые действия, закрывает сессию, освобождая лицензию. Использует в следующие моменты: при запуске, при обновлении списка серверов, при запуске приложения (для проверки наличия обновлений).

• Мобильное согласование - сотрудники, кому будут высылаться расширенные уведомления с возможностью согласовать/не согласовать документ или завершить задачу. Настройка работы мобильного согласования описана в Руководстве по установке TESSA. То, как можно использовать данный модуль, описано в Руководстве пользователя TESSA. В типовой поставке модуль работает для следующих типов заданий: Согласование, Подписание, Типовая задача.

Note

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

Добавить сотрудников в список можно путем перечисления фамилий, или же путем выбора роли, нажав на кнопку “Добавить сотрудников по ролям”. В открывшемся окне указать одну или несколько ролей. Для выбора доступны Метароли, Департаменты, Статические и Динамические роли:

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

Warning

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

Note

После изменения настроек необходимо перезапустить веб-сервис web и сервис Chronos.

Замена лицензии

Лицензия - это файл с расширением *.tlic, который хранится на сервере приложений TESSA.

Для замены лицензии на новую необходимо:

1. На сервере приложений TESSA в файле app.json в папке веб-сервиса web найти строку вида "LicenseFile": "@*.tlic",

   Note

   Указанный путь к файлу app.json актуален при типовой установке платформы.

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

2. Скопируйте новый файл лицензии на сервер и укажите путь к новому файлу лицензии, или замените старый.

   Note

   Для редактирования файла app.json требуются права администратора.

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

3. Для сервиса Chronos также необходимо заменить файл лицензии или указать путь к новой лицензии в конфигурационном файле app.json.

4. Поле этого перезапустите пул приложений tessa.

Управление сессиями

Список всех открытых сессий можно посмотреть из рабочего места Администратор, представление Активные сессии:

В списке отображена информация о всех подключенных пользователях с указанием типа лицензии, типа входа пользователя и запущенного приложения (TessaClient, TessaAdmin, Web-клиент). У администратора есть возможность закрыть сессию, выбрав в представлении строку и нажав на левой панели системы кнопку “Закрыть сессию”.

В колонке “Используется” отображается информация о том, для какой сессии лицензия фактически занята. Однако, если пользователь бездействует более часа его лицензия может быть системой автоматически отобрана в случае, если другой пользователь пытается зайти в систему и нет реально свободных лицензий. Не используйте представление “Активные сесии” для расчётов лицензий.

Сессии закрываются в случае закрытия приложения TessaClient пользователем (для web-клиента - при нажатии Выйти из учетной записи). Иногда, например, при сбоях в канале связи, сессия может не закрыться при закрытии приложения. Тогда эта сессия будет удалена спустя 8 дней после её открытия.

Время жизни сессии - 7 дней. За один час до истечения 7 дней (т.е. спустя 6 дней и 23 часа после открытия сессии) TESSA незаметно для пользователя открывает новую сессию и закрывает текущую (в случае, если это толстый клиент). Если в течение этого часа открыть новую сессию так и не получится (например, если пользователь перестал входить в домен или администратор сменил пароль), то пользователю будет выдано окно для ввода логина/пароля.

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

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

Note

Количество открытых сессий никак не связано с количеством свободных лицензий, т.к. при подсчёте количества лицензий система считает в том числе и занятые, но бездействующие последний час сессии. Более подробно о лицензиях в предыдущем разделе - Лицензии и сессии.

Обновление до новой сборки платформы

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

Подробное описание состава поставки можно посмотреть в Руководстве по установке СЭД TESSA.

Подготовка к обновлению

Перед выполнением обновления платформы необходимо:

1. Попросить всех пользователей завершить работу с системой.

2. Остановить сервис кроноса Syntellect Chronos, убедившись, что отправлены все оповещения по почте (или можно удалить неотправленные оповещения, очистив таблицу Outbox в базе данных).

3. Остановить веб-сервис web.

4. Сделать резервную копию базы данных и папки с файлами.

5. Сделать резервную копию папок с приложениями TessaAdmin, TessaClient, с веб-сервисом web, с сервисом Chronos (чтобы потом можно было найти старые конфигурационные файлы и файл лицензии).

Обновление типового решения

Специалисту, осуществляющему обновление, необходимо прочитать ReleaseNotes.txt (из папки сборки), а именно: пункты (1) для версий сборки, на которую выполняется обновление, а также тех версий, которые были пропущены. Например, при обновлении с версии 2.2 сразу на 2.4 надо прочитать пункты и для сборки 2.3 (ниже в том же файле ReleaseNotes.html) и для сборки 2.4. Пункты содержат важную информацию по обновлению.

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

Выполнение обновления:

1. Распаковать установочный архив tessa-3.x.x.

2. Заменить полностью файлы веб-сервиса: из папки сборки Services скопировать всё содержимое в папку сервиса (обычно это папка C:\inetpub\wwwroot\tessa).

3. Проверить настройки пула приложений и сервиса web (можно также проверить включенные компоненты), следуя Руководству по установке и используя информацию из файла ReleaseNotes.txt:

   • Скопировать файл лицензии в папку с файлом app.json и подпапкой web.

   • Настроить конфигурационный файл app.json. В том числе проверить путь к файлу лицензии, значение параметра TokenSignature (из старого конфигурационного файла) вставить в параметр SignatureKey.

   • Убедиться, что в дополнительных настройках веб-сервиса web отключён флаг Разрешить 32-разрядные приложения:

     

     

4. Запустить веб-сервис web.

5. Обновить конфигурацию можно одним из следующих способов:

   С помощью выполнения bat файла Upgrade.bat (из установочного архива), в этом случае можете переходить к следующему пункту, минуя подпункты ниже.

   Вручную, выполнив действия, описанные ниже.

   • Выполнить скрипт Fixes/Migration-3.x-pre.sql для тех версий, на которые выполняется обновление (скрипты находятся в папке Fixes установочного архива). Скрипты могут отсутствовать, если их выполнение не требуется.

   • Обновить схему данных:

     • Запустить приложение Applications\SchemeEditor.

     • Открыть в SchemeEditor существующую базу TESSA.

       

     • Если система предложит обновить структуру базы данных, то согласиться с обновлением и сохранить [Ctrl]+[S].

     • Открыть новую версию схемы, которая находится в папке Configuration\Scheme установочного архива.

       

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

       

     • Сохранить новую схему в существующую базу TESSA

       

       Important

       Если при сохранении возникнут ошибки, попробовать перед сохранением выполнить ConstraintsOff.sql, а после сохранения выполнить ConstraintsOn.sql. Оба скрипта находятся в папке Fixes.

   • Выполнить скрипты Fixes\Migration-3.x.sql. Например, при обновлении с версии 2.2 на версию 2.4 требуется выполнить скрипты Migration-2.3.sql и Migration-2.4.sql в указанном порядке.

   • Открыть новый TessaAdmin (запустить с ключом /a:https://имя_сервера/папка_tessa).

     Note

     В соответствии с ReleaseNotes.txt сотрудник Admin автоматически получает следующие параметры входа: логин admin, пароль admin (изменения вносит выполненный ранее скрипт миграции).

     Раздел “Локализация” - импортировать библиотеки локализации (из папки сборки Configuration\Localization), сохранить, дождаться сохранения и повторно открыть TessaAdmin.

   • В разделе “Карточки” импортировать типы карточек, файлов, заданий (из папки Configuration\Types), нажать “Сохранить всё”.

   • Далее импортировать карточки, отмеченные в ReleaseNotes.txt как добавленные (из подпапок папки сборки - Configuration\Cards\*). Для загрузки отдельных файлов необходимо использовать кнопку “+”:

     

   • Раздел “Представления” - импортировать новые версии представлений (из папки Configuration\Views). Для уже существующих представлений не надо ставить при импорте флаги “Удалить перед импортом…” и “Заменить разрешения…”, а для новых добавляемых представлений надо поставить только флаг “Заменить разрешения” (т.к. для некоторых из представлений должна быть указана роль “Все сотрудники”).

   • Раздел “Рабочие места” - импортировать рабочие места (из папки Configuration\Workplaces). Аналогично, не надо ставить при импорте флаги “Удалить перед импортом…” и “Заменить разрешения…”.

6. Опубликовать новые версии TessaAdmin, TessaClient и Tessa Applications.

   Можно воспользоваться бат-файлами publish_admin_demo.bat, publish_client_demo.bat и publish_appmanager_demo.bat (из папки Applications), предварительно указав в них актуальный путь к веб-сервису web.

7. Для новых пользователей следует устанавливать сразу новую версию Tessa Applications, установочные файлы находятся в папке Setup. Перед установкой необходимо прочитать readme.txt.

8. Обновить сервис Syntellect Chronos:

   • Скопировать новый сервис Chronos (папка Chronos) на место старого.

   • Задать правильные параметры в конфигурационном файле app.json, который находится в папке рядом с Chronos.exe.

     В том числе вставить значение параметра SignatureKey такое же, как в файле app.json в папке веб-сервиса. Не забыть скопировать рядом файл лицензии и указать путь до него в этом же app.json.

   • Запустить сервис Syntellect Chronos и, если в папке сервиса появится файл log.txt, проверить что он не содержит сообщений об ошибках.

     Note

     Установка и настройка кроноса описаны в разделах 5 и 6 Руководства по установке (сервис устанавливать заново не надо, достаточно остановить его до обновления и запустить после) .

9. Открыть TessaClient и проверить результат обновления.

Обновление кастомизированного решения

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

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

Important

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

1. В файле ReleaseNotes.html внимательно прочитайте пункты (1) для версий сборки, на которую вы обновляетесь, или которые вы пропустили. Например, при обновлении с версии 2.2 сразу на 2.4 надо прочитать пункты и для сборки 2.3 (ниже в том же файле ReleaseNotes.html) и для сборки 2.4. Пункты содержат важную информацию по обновлению.

2. Если схема данных была доработана согласно рекомендациям, т.е. в отдельной библиотеке схемы, то достаточно скопировать свою библиотеку в папку Configuration/Scheme/Partitions в новой сборке, и уже оттуда обновить схему через приложение SchemeEditor.

3. Если по каким-то причинам потребовалось изменить файлы основной схемы или библиотеки типового решения, то потребуется вручную объединить xml-файлы в папке Configuration/Scheme. Для этого можно воспользоваться средствами репозиториев (Git, Mercurial и др.), а также утилитами построчного сравнения файлов (такими как KDiff3).

   Important

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

4. После обновления схемы и выполнения скриптов, когда потребуется запустить TessaAdmin, понадобится заменить те представления, которые поменялись в новых сборках (согласно ReleaseNotes.html).

   При этом, для упрощения сравнения можно создать копию вашего представления с другим алиасом (в контекстном меню на представлении есть функция “Дублировать”). После этого импортируйте представление из сборки. Далее, запустив вторую копию приложения TessaAdmin, вы сможете одновременно на экране открыть обе версии представления (новую из сборки и вашу, изменённую, с другим алиасом).

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

5. Аналогично обновляются рабочие места. Если вы изменяли типовые рабочие места “Пользователь” и “Администратор”, и они были изменены в рамках сборки, то вы можете сначала создать копию рабочего места (пункт “Дублировать” в контекстном меню), потом импортировать с заменой рабочее место из сборки, и затем, посредством drag&drop, перетащить узлы с папками и представлениями из копии в новую версию рабочего места.

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

6. И аналогично обновляются типы карточек и заданий (типы файлов обычно не изменяются, если это отдельно не описано в пунктах (1) файла ReleaseNotes.html). Создаются копии типов, потом новые типы импортируются с заменой, и контролы/блоки вместе со всеми настройками переносятся из копии в новую сборку.

7. При обновлении программных расширений следует учитывать, что из папки Source сборки потребуется обновить все сборки типового решения, т.е. папки Source\Extensions\Tessa.Extensions.Default.***, включая (обязательно!) файлы проектов .csproj. В вашем репозитории такие папки надо сначала удалить (со всеми сделанными изменениями), потом скопировать в репозиторий папки из сборки.

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

   Warning

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

   Папки Tessa.Extension.Client, Tessa.Extension.Server, Tessa.Extension.Server.Web, Tessa.Extension.Shared, Tessa.Extension.Chronos (находящиеся в папке Source\Extensions), а также папки с примером модулей Source\Modules\Tessa.Module.\*** обновлять не требуется, кроме тех случаев, когда в пунктах (1) файла ReleaseNotes.html явно приведены рекомендации по обновлению (это бывает редко, и такие изменения незначительны). Поэтому в этих сборках можно добавлять или удалять любой код без опасения, что в дальнейшем потребуется выполнять merge.

   Папку Bin\packages можно не обновлять, и её содержимое также можно не добавлять в репозиторий, т.к. необходимые зависимости будут восстановлены из серверов NuGet при наличии доступа к сети. Однако, папка должна быть создана (хотя бы как пустая папка) для успешной сборки проектов.

   В Visual Studio в окне Solution Explorer в контекстном меню на корневом элементе дерева нажмите Manager NuGet Packages for Solution. Перейдите на вкладку Updates и обновите NuGet-пакеты с именами, содержащими “Tessa” или “Chronos”, до версии вашей сборки. Например, если у вас сборка 3.1.0, то обновляйте NuGet-пакеты до версии 3.1.0, а не до последней доступной версии 3.1.1 (например).

8. После обновления расширений их можно проверить, собрав solution в Release, затем скопировав расширения сервера в папку веб-сервиса web, расширения клиента в приложения TessaClient и TessaAdmin (и опубликовав их), а плагины Chronos скопировав в папку Chronos\Plugins\НазваниеПапкиПроекта (по вопросам создания такой папки обратитесь к файлу Tessa.Extensions.Chronos\readme.txt).

   Если в ваших проектах есть ссылки на NuGet-пакеты сторонних библиотек, то скопируйте их файлы .dll из папки сборки проектов bin\Release в папку веб-сервиса web, или в папку с плагинами Chronos, или в папку с утилитой tadmin (в зависимости от того, в какие сервисы вы копируете .dll).

Important

Не забывайте выполнять бэкап базы данных перед выполнением обновления.

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

Экспорт конфигурации веб-сервиса

В сборке в папке с проектами расширений “Source” добавлены файлы Export.bat и export.sh, которые позволяют на ОС Windows и Linux соответственно выполнить полный экспорт конфигурации с карточками из веб-сервиса (т.е. из базы данных) по аналогии с тем, как устроена папка “Configuration” в сборке. Такую папку совместно со скриптами Setup.bat/setup.sh и Upgrade.bat/upgrade.sh можно использовать для создания или обновления инсталляции системы для проектной конфигурации, скопированной из инсталляции, для которой выполнялся экспорт.

Внутри файла Export.bat на Windows или export.sh на Linux укажите параметры для экспорта:

Параметр	Описание
Address	Адрес веб-сервиса.
Login	Логин для подключения к веб-сервису. Если логин и пароль пустые, то используется автоматическая Windows-аутентификация или Kerberos-аутентификация от имени учётной записи, от которой запущен скрипт.
Password	Пароль для подключения к веб-сервису.
CheckTimeout	Время проверки подключения к веб-сервису и к базе данных в секундах.
Database	Имя базы данных для строки подключения или пусто, если используется имя, указанное в строке.
Connection	Имя строки подключения к БД из файла app.json.
Configuration	Путь к папке, в которую будет экспортирована конфигурация. Если папка уже существует, то конфигурация будет обновлена.
Tools	Путь к папке, в которой расположена утилита tadmin.

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

1. Проверьте строку подключения к базе данных в файле app.json в папке с утилитой tadmin. База данных требуется для запросов на списки экспортируемых карточек. Сами команды экспорта выполняются полностью через веб-сервис.

2. Проверьте адрес подключения и логин/пароль в файле скрипта в переменных Address, Login, Password соответственно. Укажите пустые логин/пароль, если при подключении к веб-сервису должна быть выполнена автоматическая Windows-аутентификация или Kerberos-аутентификация от имени учётной записи, от которой запущен скрипт.

3. Скопируйте папку с утилитой tadmin в папку относительно скрипта:

   1. папку Tools скопируйте в Source\Tools для Windows-версии скрипта;

   2. папку linux/tools скопируйте в Source/tools для Linux-версии скрипта;

   3. также вы можете не копировать папку, а указать путь к папке в файле скрипта в переменной Tools, в т.ч. абсолютный путь или путь относительно текущей папки %CurrentDir% на Windows или $CurrentDir на Linux.

4. Перед запуском скрипта на Linux необходимо указать ему права для запуска (на Windows не требуется). Выполните команду в терминале: chmod 755 export.sh

При запуске скрипт отобразит указанные в нём переменные и предложит нажать любую клавишу, чтобы запустить экспорт. [Ctrl]+[C] завершает скрипт.

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

По завершению экспорта будет выведено сообщение:

Миграция базы данных и файлов

Миграция базы данных

Миграция базы данных позволяет перенести базу вместе с данными как для той же СУБД (например, с одного сервера Microsoft SQL Server на другой), так и между разными СУБД (из MSSQL в PostgreSQL и обратно). Ниже описаны действия, которые необходимо выполнить для миграции.

Important

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

Подготовка к миграции

Перед выполнением миграции базы необходимо:

1. Попросить всех пользователей завершить работу с системой.

2. Остановить сервис кроноса Syntellect Chronos.

3. Сделать резервную копию исходной базы данных.

4. Сделать резервную копию папки с веб-сервисом web, с сервисом Chronos (чтобы потом можно было найти старые конфигурационные файлы).

5. Создать новую пустую базу данных в целевой СУБД.

Выполнение миграции

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

В конфигурационном файле Tools\app.json в группе настроек ConnectionStrings укажите подключение к исходной (default) и целевой (migration) базам данных:

Для подключения к SQL Server с использованием Windows аутентификации:

 "Server=.\\SQLEXPRESS; Database=tessa; Integrated Security=true; Connect Timeout=200; pooling='true'; Max Pool Size=200; MultipleActiveResultSets=true;"

Для подключения к SQL Server с использованием пользователя SQL Server:

 "Server=.\\SQLEXPRESS; Database=tessa; Integrated Security=false; User ID=sa; Password=master; Connect Timeout=200; pooling='true'; Max Pool Size=200; MultipleActiveResultSets=true;"

Для подключения к PostgreSQL с использованием Windows аутентификации:

 [ "Host=localhost; Database=tessa; Integrated Security=true; Pooling=true; MaxPoolSize=100", "Npgsql" ]

Для подключения к PostgreSQL с использованием пользователя PostgreSQL:

 [ "Host=localhost; Database=tessa; User ID=postgres; Password=Master1234; Pooling=true; MaxPoolSize=100", "Npgsql" ]

В примере ниже настроена миграция из базы MSSQL tessa в базу PostgreSQL tessa:

"ConnectionStrings": {
    "default": "Server=\\SQLEXPRESS; Database=tessa; Integrated Security=false; User ID=sa; Password=Master1234; Connect Timeout=200; pooling='true'; Max Pool Size=200; MultipleActiveResultSets=true;",
    "migration": [ "Host=localhost; Database=tessa; User ID=postgres; Password=Master1234; Pooling=true; MaxPoolSize=100", "Npgsql" ]
},

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

В файле app.json (при установке по умолчанию он расположен в папке c:\inetpub\wwwroot\tessa\app.json) в группе настроек ConnectionStrings для строки default указываем те же параметры, что указали в конфигурационном файле утилиты tadmin в строке migration.

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

"ConnectionStrings": {
    "default": [ "Host=localhost; Database=tessa_migr; User ID=postgres; Password=Master1234; Pooling=true; MaxPoolSize=100", "Npgsql" ]
},

Warning

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

Для миграции воспользуемся Migrate.bat, который входит в сборку. При запуске bat файла будет предложено указать адрес подключения, или нажмите клавишу [Enter], чтобы использовать адрес по умолчанию:

Далее будет предложено указать имя целевой базы данных, или нажмите клавишу [Enter], чтобы использовать базу, указанную в конфигурационном файле утилиты tadmin. Указание имени базы работает аналогично скрипту установки Setup.bat: если имя не указать, то оно берётся из конфигурационного файла и база НЕ создаётся (т.е. пустая база должна быть предварительно создана на нужном сервере), а если указать, то база будет создана самим скриптом (со всеми настройками по умолчанию).

Далее проверяем параметры и, нажав на клавишу [Enter], соглашаемся на выполнение миграции:

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

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

Note

Подробное описание доступных параметров утилиты tadmin см. в разделе Команды для миграции данных.

Далее необходимо настроить подключение сервиса Chronos к новой базе. В конфигурационном файле Chronos\app.json в группе настроек ConnectionStrings аналогично настраиваем подключение к новой базе (в нашем примере это подключение к базе tessa сервера PostgreSQL):

"ConnectionStrings": {
    "default": [ "Host=localhost; Database=tessa_migr; User ID=postgres; Password=Master1234; Pooling=true; MaxPoolSize=100", "Npgsql" ]
},

Проверка работы системы на новой базе

Запустите сервис Syntellect Chronos. Убедитесь, что в лог файле сервиса Chronos\log.txt нет ошибок. Если в нём есть ошибки по выполнению запросов для динамических ролей и метаролей, то вам надо переписать эти запросы под новую СУБД.

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

Миграция файлов

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

Note

СУБД PostgreSQL не поддерживает хранение файлов в базе.

Important

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

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

Для выполнения миграции предварительно в карточке настроек сервера (TessaClient, запущенный от имени Администратора, правая панель → Настройки → Настройки сервера) надо добавить новое хранилище данных и сделать его по умолчанию. Более подробно см. в разделе Настройки сервера.

Например, перенесем файлы, из базы данных в папку (т.е. файловое хранилище с id = 1 - это исходное, а хранилище id=2 - целевое):

Миграция файлов выполняется с помощью консольной утилиты tadmin, расположенной в подпапке Tools папки сборки. Необходимо в консоли, запущенной из данной папки выполнить команду MigrateFiles, указав в параметрах id исходного и целевого хранилищ. В нашем примере команда будет следующая:

tadmin MigrateFiles /from:1 /to:2

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

Note

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

Note

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

Более подробно все параметры данной команды описаны в разделе Команды для миграции данных.

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

Все файлы из исходного файлового хранилища в процессе миграции были удалены.

Для того чтобы убедиться в корректности выполненной миграции:

• Проверьте, что в исходном файловом хранилище удалены все файлы:

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

  • если исходное хранилище было в базе данных, выполните запрос на базе select count(*) from FileContent, он должен вернуть ноль.

• Запустите приложение TessaClient и убедитесь, что приложенные к карточкам файлы доступны.

Обслуживание базы данных

Перестроение индексов

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

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

Warning

Скрипт выполняется длительное время и “парализует” работу системы. Поэтому его следует вызывать ночью или на выходных, когда пользователи не работают в системе и все вычислительные мощности сервера СУБД SQL Server могут быть выделены для перестроения индексов.

DECLARE @TableName varchar(255)
DECLARE TableCursor CURSOR FOR

SELECT table_name FROM information_schema.tables
WHERE table_type = 'base table'

OPEN TableCursor

FETCH NEXT FROM TableCursor INTO @TableName

WHILE @@FETCH_STATUS = 0
BEGIN

DBCC DBREINDEX(@TableName,' ',90)

FETCH NEXT FROM TableCursor INTO @TableName

END

CLOSE TableCursor

DEALLOCATE TableCursor 

Статистика по таблицам

Администратор системы может выполнить запрос SQL, чтобы получить подробный отчёт по таблицам и материализованным представлениям по таким показателям, как распределение свободного и занятого места для индексов и всей таблицы (здесь и далее под “таблицей” подразумевается, как собственно таблица, так и материализованное представление).

Отчёт содержит следующие колонки:

• object_id – идентификатор таблицы в метаинформации SQL, который можно использовать для получения дополнительной информации из системных таблиц sys.***.

• name – имя таблицы.

• type – тип объекта (U – таблица, V – представление).

• total_rows – общее количество строк в таблице.

• total_space – общий размер таблиц в КиБ (1 КиБ = 1024 байт), включая незадействованное на страницах место. Складывается из общего используемого места used_space и общего неиспользуемого места unused_space.

• used_space – общее используемое место в КиБ.

• unused_space – общее неиспользуемое место в КиБ.

• index_space – общее место в КиБ, занимаемое страницами с индексами.

• data_space – общее место в КиБ, занимаемое страницами с данными.

• is_heap – признак того, что таблица является heap’ом, т.е. не содержит кластерного индекса. Значение “0” определяет наличие кластерного индекса, а значение “1” - его отсутствие.

• partitions – количество партиций (разделов), которые используются таблицей. Значение будет больше “1” только для тех таблиц, для которых явно задана схема партиционирования в SQL. Платформа TESSA не поддерживает создание и редактирование партиций штатными средствами, но платформа совместима со схемами партиционирования, заданными в SQL.

• indexes – общее количество страниц, занимаемых индексами.

Результат запроса:

Текст запроса SQL:

SELECT 
      o.[object_id]
    , name = s.name + '.' + o.name
    , o.[type]
    , i.total_rows
    , total_space = CAST(i.total_pages * 8. / 1024 AS DECIMAL(18,2))
    , used_space = CAST(i.used_pages * 8. / 1024 AS DECIMAL(18,2))
    , unused_space = CAST((i.total_pages - i.used_pages) * 8. / 1024 AS DECIMAL(18,2))
    , index_space = CAST(i.inx_pages * 8. / 1024 AS DECIMAL(18,2))
    , data_space = CAST(data_pages * 8. / 1024 AS DECIMAL(18,2))
    , is_heap
    , i.[partitions]
    , i.[indexes]
FROM sys.objects o
JOIN sys.schemas s ON o.[schema_id] = s.[schema_id]
JOIN (
    SELECT
          i.[object_id]
        , is_heap = MAX(CASE WHEN i.index_id = 0 THEN 1 ELSE 0 END)
        , total_pages = SUM(a.total_pages)
        , used_pages = SUM(a.used_pages)
        , inx_pages = SUM(a.used_pages - CASE WHEN a.[type] !=1 THEN a.used_pages WHEN p.index_id IN(0,1) THEN a.data_pages ELSE 0 END) 
        , data_pages = SUM(CASE WHEN a.[type] != 1 THEN a.used_pages WHEN p.index_id IN (0,1) THEN a.data_pages END)
        , total_rows = SUM(CASE WHEN i.index_id IN (0, 1) AND a.[type] = 1 THEN p.[rows] END)
        , [partitions] = COUNT(DISTINCT p.partition_number)
        , [indexes] = COUNT(DISTINCT p.index_id)
    FROM sys.indexes i
    JOIN sys.partitions p ON i.[object_id] = p.[object_id] AND i.index_id = p.index_id
    JOIN sys.allocation_units a ON p.[partition_id] = a.container_id
    WHERE i.is_disabled = 0
        AND i.is_hypothetical = 0
    GROUP BY i.[object_id]
) i ON o.[object_id] = i.[object_id]
WHERE o.[type] IN ('V', 'U')
    AND o.is_ms_shipped = 0
ORDER BY i.total_pages DESC