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

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

Логирование в 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 расположен в этой же папке.

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

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

  • Логи консольной утилиты tadmin

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

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

    В едином файле конфигурации app.json для web-сервиса TESSA C:\inetpub\wwwroot\tessa\app.json в поле Settings -> Webbi -> LogsPath, указывается строка с именем директории для хранения файлов журналов событий webbi. По умолчанию используется директория logs в рабочей директории webbi.

  • События журнала 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 в параметре AppPath, по умолчанию указана папка %localappdata%\tessa. В файле %localappdata%\tessa\applications\tessa\tessaclient\NLog.config указывается расположение логов. По умолчанию файл log.txt расположен в этой же папке.

  • Логи TessaAdmin

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

  • Логи Tessa Assistant

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

  • Логи Deski

    По умолчанию логи расположены в директории %localappdata%\tessa\deski\.deski_data\logs. Есть возможность переопределить дефолтную папку со служебными файлами Deski при помощи параметра командной строки -dir. Данный параметр позволяет указать путь, по которому Deski должен хранить всю свою информацию. Так же есть возможность использовать параметр -verbose для указания уровней логирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Note

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

Warning

После изменения параметра Maintenance.RemoveActionHistoryOlderThanDays не стоит вручную перезапускать Chronos в рабочее время, т.к. это увеличивает нагрузку на БД. Лучше дождаться самостоятельного запуска плагина в 12 am.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все карточки

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

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

  • информация об изменении строковых и коллекционных секций карточки, а также полей в этих секциях;
  • информация о создании, изменении, копировании, замене, удалении, восстановлении, импорте файла;
  • информация о создании, изменении, завершении задания;
  • общая информация о карточке, её типе, авторе, дате и времени создания и др.

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

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

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

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

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

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

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

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

• Вход в систему - вход сотрудника в систему. Если для сотрудника включена двухфакторная аутентификация, то событие записывается после прохождения второго фактора и открытия сессии. Объект - карточка сотрудника.

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

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

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

• Аутентификация успешна - запись об успешной аутентификации пользователя в системе (прохождения первого фактора аутентификации - пользователь корректно указал свои учётные данные, например, логин/пароль или логин/Kerberos и т.д.). В данной записи также есть информация о типе входа сотрудника, IP и имени компьютера, с которого производится вход в систему. Запись содержит частичную информацию, которая содержится в неподписанном сессионном токене пользователя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги

• Сохранение тега - добавление тега к карточке.

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

Токены доступа

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

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

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

Прочее

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

Роли

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

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

Для каждой роли в системе создается отдельная карточка. В системе 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 с периодом, заданным в настройках данного плагина. Вручную запустить пересчёт заместителей не получится, необходимо дождаться выполнения плагина, перезапустить сервис Chronos, или выполнить команду пересчёта ролей в консольной утилите tadmin.

Note

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

Замещения

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

В TESSA может использоваться как старая система замещения, так и новая система замещения.

Note

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

В данном разделе тезисно описаны особенности работы системы замещения.

• Каждый сотрудник может самостоятельно настроить себе заместителей (см. Руководство пользователя).
• Замещение может быть постоянное или на указанный период.
• Заместитель на период замещения получает доступ ко всем заданиям замещаемого - как к новым, так и старым, в том числе взятым в работу основным исполнителем.
• Заместитель получает все права доступа замещаемого, в том числе права доступа к представлениям, права на чтение/редактирование карточек, расширенные права доступа, права на отчеты, права, выдаваемые этапом маршрута и т.д.
• Заместитель в системе может работать параллельно с замещаемым сотрудником.
• Заместитель получает почтовые уведомления по всем новым задания замещаемого сотрудника.

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

  Note

  Есть возможность отобразить задания, которые взял в работу заместитель. Для этого необходимо в карточке (по которой пришло задание) нажать на кнопку показать скрытые задания. Так же в представлении Мои задания можно нажать кнопку Фильтр и добавить параметр Показывать задания, взятые в работу не мной и будут показаны задания, которые взял заместитель.

В TESSA по умолчанию установлена новая система замещения. Она не работает вместе со старой, а полностью заменяет собой старую систему замещения.

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

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

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

• В представлениях необходимо задействовать конструкцию с условием #if(DeputiesSettings.UseDeputyRoleSeparation). При использовании старой системы замещения условие вернёт true, а при использовании новой - вернёт false.
• В коде расширения необходимо выполнить Resolve объекта IDeputiesManagementSettingsProvider из контейнера Unity, чтобы получить объект с настройками через метод GetSettingsAsync, и в полученном объекте необходимо проверить значение свойства UseRoleDeputies. Если данное свойство имеет значение true, то используется таблица RoleDeputies и старая система замещения, в противном случае используется новая система замещения (без таблицы RoleDeputies).

Старая система замещений

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

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

Новая система замещения

Основные отличия новой системы замещения от старой:

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

2. Замещение рассчитывается на 2 уровня в глубь.

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

   • Замещаемый -> Заместитель 1 (без указания типов документов) -> Заместитель 2 (без указания типов документов);
   • Замещаемый -> Заместитель 1 (без указания типов документов) -> Заместитель 2* (по типам документов);
   • Замещаемый -> Заместитель 1 (по типам документов) -> Заместитель 2* (без указания типов документов);
   • Замещаемый -> Заместитель 1 (по типам документов) -> Заместитель 2* (по типам документов).

   В указанных примерах Заместитель 2 получит доступ ко всем заданиям Замещаемого, а Заместитель 2* получит доступ к заданиям с учетом настроенных типов документов для замещений.

3. Не используется таблица RoleDeputies для расчёта заместителей.

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

Настройка замещений пользователям

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

Note

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

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

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

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

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

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

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

Note

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

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

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

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

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

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

  Note

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

Кого я замещаю - таблица с замещаемыми сотрудниками.

Кого я замещаю по документам - таблица с сотрудниками, замещаемыми по документам.

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

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

Вложенная роль

Роли данного типа создаются автоматически в рамках работы плагина перерасчёта заместителей.

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

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

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

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

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

Отключение замещений

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

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

Типы ролей используют данную настройку следующим образом:

• Сотрудник - не использует данную настройку, замещения для сотрудников всегда функционируют.

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

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

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

  Note

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

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

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

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

Календари

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

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

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

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

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

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

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

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

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

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

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

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

Note

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

Карточка календаря

Найти карточки настроек календарей можно в представлении Администратор → Календари → Календари.

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

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

Исключения календаря

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

Note

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

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

Календарь будет рассчитан с 00:00:00 даты начала и по 23:59:59 даты конца.

Warning

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

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

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

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

Именованные диапазоны

Список диапазонов, для которых указано некоторое название. На расчёт не влияет, но в будущем будет использоваться для формирования визуального календаря. Заполняется вручную и посредством указания имени для интервала в скрипте из карточки способа расчёта календаря. При пересчёте удаляются все диапазоны, что не были добавлены вручную, и добавляются новые, сгенерированные на основе скрипта (см. Карточка способа расчёта календаря).

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

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

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

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

Important

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

Note

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

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

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

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

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

Карточка типа календаря

Найти типы календарей можно в представлении Администратор → Календари → Типы календарей.

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

• Название - название типа календаря.
• Описание - описание типа календаря.
• Количество часов в рабочем дне и Количество рабочих дней в неделе - используются для вычисления текстовых значений об оставшемся времени для задания или насколько задание просрочено.
• Способ расчёта календаря - ссылка на карточку способа расчёта календаря (см. Карточка способа расчёта календаря)
• Настройки по дням недели - настройка, характерная для типа календаря Рабочая неделя. В ней заполняются начало и конец рабочего дня, а также интервал обеденного перерыва по дням. Если создать карточку типа календаря, например, “Сутки через трое”, то для неё будут характерны другие настройки. В таблице для указания настроек по дням недели есть кнопка “Изменить выбранные”, которая позволяет указать одинаковые настройки для выбранных из таблицы дней недели.
• Исключения (см. Исключения типа календаря).

Note

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

Исключения типа календаря

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

Карточка способа расчёта календаря

Найти способы расчёта календарей можно в представлении Администратор → Календари → Способы расчёта календарей.

Содержит следующие поля:

• Название - название способа расчёта календарей.
• Описание - описание способа расчёта календарей.
• Скрипт расчёта - на основании скрипта расчёта происходит формирование набора рабочих и нерабочих квантов. В карточке Рабочая неделя (входящей в типовую поставку) предполагается, что работа ведётся 5/2, с 8-ми часовым рабочим днём и по расписанию из карточки типа календаря, к которому закреплена данная карточка способа расчета календаря (см. Карточка типа календаря).

Для расчёта календаря используется карточка типа календаря, которую можно получить в скрипте расчёта через объект контекста:

context.TypeCardObject

Далее происходит расчёт интервалов рабочего и нерабочего времени на основании настроек из карточки типа календаря, к которой был закреплен данный способ расчёта. В данном случае мы не опираемся на 15-ти минутные кванты, а просто задаём периоды рабочего и нерабочего времени. Полученные интервалы записываются в объект контекста:

context.Intervals

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

// Исключения из карточки Типа календаря
IEnumerable<IBusinessCalendarInterval> calendarTypeExclusions = null;

var calendarTypeExclusionsRows = context.TypeCardObject.Sections["CalendarTypeExclusions"].Rows;

if (calendarTypeExclusionsRows.Count > 0)
{
    calendarTypeExclusions =
        calendarTypeExclusionsRows.Select(p =>
            new BusinessCalendarInterval(
                p.Fields.Get<bool>("IsNotWorkingTime"),
                p.Fields.Get<DateTime>("StartTime"),
                p.Fields.Get<DateTime>("EndTime"),
                p.Fields.Get<string>("Caption")));
}

// Вольём исключения из типа календаря в интервалы из скрипта
if (calendarTypeExclusions != null)
{
    context.IntervalsProcessor.MergeIntervals(context.Intervals, calendarTypeExclusions);
}

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

Порядок применения интервалов:

1. Интервалы из скрипта
2. Интервалы исключений из типа календаря
3. Интервалы исключений из календаря

Note

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

Календари в карточках ролей

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

• Сотрудник
• Подразделение
• Статическая роль
• Динамическая роль

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

• Метароль

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

Note

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

• Умная роль

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

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

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

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

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

Note

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

• Вложенная роль

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

Календарь по умолчанию

Указывается в карточке настроек сервера. По умолчанию установлен календарь с числовым идентификатором "0".

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

Отображать оставшееся время для задания в астрономических днях

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

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

Наследование календарей

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

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

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

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

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

Note

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Note

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

Note

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

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

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

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

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

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

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

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

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

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

Note

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

Note

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

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

• Сотрудник

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

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

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

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

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

  Note

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

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

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

• Метароль

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

  Note

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

• Умная роль

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

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

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

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

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

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 определяет, что будут использоваться настройки соединения по умолчанию);

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

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

  Note

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

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

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

Настройки базы данных для истории действий

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

Important

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

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

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

• ID - идентификатор настройки;

• Название - название настройки (обязательно для заполнения и уникально);

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

• Описание - описание настройки.

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

Note

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

Кэш файлов

Кэш файлов используется для хранения PDF файлов, сгенерированных при просмотре файлов пакета MS Office и других офисных пакетов, поддерживаемых TESSA в 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/web-клиент.

  Note

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

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

  Note

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

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

Note

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

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

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

Warning

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

Note

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

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

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

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

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

   Note

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

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

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

   Note

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

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

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

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

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

Список всех открытых сессий можно посмотреть в представлении Администратор → Активные сессии:

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

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

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

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

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

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

Note

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

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

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

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

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

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

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

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

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

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

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

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

Специалисту, осуществляющему обновление, необходимо прочитать раздел документации История изменений (из папки сборки), а именно: пункты “Переход на новую сборку” для версий сборки, на которую выполняется обновление, а также тех версий, которые были пропущены. Например, при обновлении с версии 3.6 сразу на 4.1 надо прочитать пункты и для сборки 4.0, и для сборки 4.1. Пункты содержат важную информацию по обновлению.

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

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

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

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

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

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

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

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

     

     

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

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

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

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

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

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

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

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

       

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

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

       

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

       

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

       

       Important

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

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

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

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

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

   • Далее импортировать карточки, отмеченные в Истории изменений как добавленные (из подпапок папки сборки - 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 и CipherKey такие же, как в файле app.json в папке веб-сервиса. Не забыть скопировать рядом файл лицензии и указать путь до него в этом же app.json.

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

     Note

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

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

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

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

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

Important

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

1. В разделе документации История изменений внимательно прочитайте пункты “Переход на новую сборку” для версий сборки, на которую вы обновляетесь, или которые вы пропустили. Например, при обновлении с версии 3.6 сразу на 4.1 надо прочитать пункты и для сборки 4.0, и для сборки 4.1. Пункты содержат важную информацию по обновлению.

2. Перед манипуляциями по обновлению схемы данных необходимо выполнить процедуру обновления версии хранилища схемы. Для этого на схеме решения необходимо выполнить команду консольной административной утилиты tadmin SchemeUpdate или открыть схему через приложение SchemeEditor из новой сборки (в этом случае SchemeEditor сам предложит обновить версию хранилища открываемой схемы).

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

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

   Important

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

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

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

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

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

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

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

8. При обновлении программных расширений следует учитывать, что из папки 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.\*** обновлять не требуется, кроме тех случаев, когда в пунктах “Переход на новую сборку” раздела документации История изменений явно приведены рекомендации по обновлению (это бывает редко, и такие изменения незначительны). Поэтому в этих сборках можно добавлять или удалять любой код без опасения, что в дальнейшем потребуется выполнять 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 (например).

9. После обновления расширений их можно проверить, собрав 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-db.json
Configuration	Путь к папке, в которую будет экспортирована конфигурация. Если папка уже существует, то конфигурация будет обновлена
Tools	Путь к папке, в которой расположена утилита tadmin

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

1. Проверьте строку подключения к базе данных в файле app-db.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-db.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; Pooling=true; MaxPoolSize=100; MaxAutoPrepare=50; AutoPrepareMinUsages=20", "Npgsql" ]

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

 [ "Host=localhost; Database=tessa; User ID=postgres; Password=Master1234; Pooling=true; MaxPoolSize=100; MaxAutoPrepare=50; AutoPrepareMinUsages=20", "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-db.json (при установке по умолчанию он расположен в папке c:\inetpub\wwwroot\tessa\app-db.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-db.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 нет ошибок. Если в нём есть ошибки по выполнению запросов для динамических ролей и метаролей, то нужно переписать эти запросы под новую СУБД.

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

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

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

Note

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

Important

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

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

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

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

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

tadmin MigrateFiles /from:1 /to:2

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

Note

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

Note

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

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

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

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

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

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

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

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

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

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

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

После длительной работы системы или массового создания карточек (десятки тысяч карточек) основные индексы в таблицах фрагментируются. В т.ч. фрагментируются кластерные индексы по 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