Выпущен релиз СЭД TESSA 3.5 : часть 1

Выпущена платформа TESSA версии 3.5.0. Эта сборка одна из крупнейших, если не самая крупная, по числу изменений: около 150 улучшений и свыше 200 исправлений и оптимизаций.

В сборке есть и архитектурные изменения, и улучшения в бизнес-процессах, в маршрутах, в системе форумов, в web-клиенте, в элементах управления карточки, изменения API и различных средств автоматизации.

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

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

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

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

Архитектура

Для версии 3.5.0 мы переработали архитектуру TESSA и её приложений (включая desktop-клиенты), выполнив перенос кодовой базы TESSA на платформу с открытым исходным кодом
.NET Core 3.1: https://github.com/dotnet (за исключением слоя обратной совместимости и TessaHost)

  1. Каждое приложение, включая Tessa Applications, TessaClient, TessaAdmin и SchemeEditor, теперь содержит в своём составе всё, необходимое для запуска на любом компьютере с Windows 7 и старше, включая саму платформу .NET Core и её зависимости. В ряде случаев обновления для .NET Framework являлись блокирующим фактором для перехода на новую версию системы, и вместе с тем приложения и расширения TESSA не могли задействовать новые функции, рискуя обратной совместимостью со старыми версиями .NET. Это более неактуально. Администрирование рабочих станций упрощается, когда всё, что нужно, чтобы работать с desktop-клиентами TESSA — это установить msi-пакет.

  2. Приложения заметно быстрее запускаются, используя технологию предварительной компиляции ReadyToRun, и быстрее работают благодаря тому, что платформа .NET Core имеет множество оптимизаций по сравнению с .NET Framework и в части исполняющей среды с JIT-компилятором, и в части библиотек базовых классов, не в последнюю очередь благодаря сотрудничеству Microsoft с open source сообществом. Предлагаем вам оценить скорость работы .NET Core на примере TessaClient и других приложений TESSA.

  3. Снижаются требования к рабочим станциям для запуска desktop-клиента: для ОС
    Windows 7 SP1 требуется .NET Framework 4.0 или старше (в состав ОС входит версия
    .NET Framework 3.5); для ОС Windows 8.1/10 требования отсутствуют, т.к. минимально необходимая версия по умолчанию входит в состав ОС. Фактически установленная версия
    .NET Framework (скажем, 4.0, 4.6.2 или 4.8) не играет роли для функционирования приложений, поскольку .NET Framework используется во вспомогательном процессе TessaHost.exe для обеспечения обратной совместимости (подключения к серверам и запуск приложений TESSA прошлых версий), для взаимодействия с драйверами сканеров и для обращения к COM-компонентам обработчиков предпросмотра файлов. Эти задачи изолированы в отдельном процессе и не содержат бизнес-логики, они не критичны для функционирования приложений
    в целом.

  4. И проекты расширений, и ядро платформы используют последнюю версию языка C# 8.0 и имеют доступ ко всем библиотекам базовых классов .NET Core 3.1, включая расширенные асинхронные API, оптимизации Span<T> и Memory<T>, специфичные криптографические алгоритмы, отсутствующие в .NET Framework (например, AES GCM — Galois/Counter Mode) и др.

  5. Клиентские и серверные расширения могут ссылаться как на библиотеки .NET Framework в режиме совместимости (включая контролы WPF в библиотеках UI — они работают в .NET Core WPF), так и на библиотеки, таргетируемые на любые версии .NET Core и .NET Standard, что расширяет возможности по интеграции и преемственность кода.

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

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

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

  2. Приложения разделяются на 32-битные и 64-битные, тогда как раньше приложения поставлялись в форме AnyCPU — их разрядность зависела от разрядности ОС. Tessa Applications автоматически выбирает за пользователя разрядность приложения в соответствии с разрядностью его ОС и настройками в карточке сотрудника (см. ниже). Публиковать изменённые клиентские расширения также надо для приложений обеих разрядностей.

  3. Вследствие указанного выше архив со сборкой вырос в объёме до 1.2 Гб и для любой инсталляции, где выполняется публикация приложений, папка с файлами после установки будет занимать 1.4 Гб.

Кэширующий  сервер Redis

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

Для этого мы добавили поддержку кэширующего сервера Redis — программного продукта с открытым исходным кодом и множеством применений в Enterprise-решениях: https://redis.io/

Он синхронизирует работу серверов в кластере. Также с этой версии платформы упрощается интеграция с Redis в расширениях проектных решений.

Подробнее процесс настройки описан в руководстве по установке.

Сброс кэшей происходит автоматически при изменении конфигурации, но его также можно инициировать консольной командой tadmin InvalidateCache для всех кэшей или только для перечисленных:

./tadmin InvalidateCache -a:https://TESSA-SERVER -u:admin -p:admin

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

Ниже рассмотрим новые возможности Tessa Applications и особенности обновления на новую версию системы.

Менеджер приложений Tessa Applications

Tessa Applications теперь скачивает приложения и свои собственные обновления (подпапки appmanager, appmanager_update и др.) в неперемещаемую папку профиля AppData\Local\tessa для учётной записи пользователя.

В перемещаемом профиле в папке AppData\Roaming\tessa содержатся только файлы логов и настройки Tessa Applications и приложений:

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

Такое расположение папок доступно только для новой версии Tessa Applications, установленной через msi-пакет, причём менеджер приложений также должен быть обновлён до версии 3.5.0.

Во всплывающую подсказку на иконке приложения добавлены указание версии приложения, версии платформы, архитектуры (32-битная или 64-битная) и версии API менеджера приложений.

Со сборки 3.5.0 используется вторая версия API v2, которая не только более быстрая, но и позволяет подробно логировать всё взаимодействие между приложениями на уровне логирования Trace в файлах клиентских логов log.txt для TessaAppManager, TessaClient, TessaAdmin.

Версию можно проверить в «О программе» для TessaClient или на вкладке «Информация» для TessaAdmin.

При публикации приложений через параметр -publish укажите разрядность приложения -32bit или -64bit отдельным параметром. Приложения по-прежнему автоматически публикуются в скриптах Setup.bat/Upgrade.bat (и linux-версиях скриптов) через консольную команду
tadmin PackageApp:

./tadmin PackageApp ../../Applications/TessaClient/TessaClient.dll -b -64bit -api2 -out:app/
./tadmin PackageApp ../../Applications/TessaClient32/TessaClient.dll -b -api2 -out:app/
./tadmin ImportCards app -a:https://localhost -u:admin -p:admin -e
rm -rf app/

Узнать параметры опубликованного приложения и изменить их можно в карточке приложения.

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

Приложения TessaClient и Tessa Applications получили улучшенную иконку.

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

Загрузка приложений оптимизирована. Выполняется поиск файлов по хеш-сумме SHA256, которые уже были загружены в папки других приложений: например, TessaAdmin скачивается быстрее, если TessaClient уже запускался.

Система также учитывает файлы Tessa Applications в папке установки Program Files, поэтому если менеджер приложений версии 3.5.0 установлен через msi, то загрузка его опубликованной версии с сервера будет быстрой без необходимости загружать файлы по сети, а также заметно ускоряется загрузка любых приложений той же версии платформы с любых серверов.

Описанное верно и при работе с серверами предыдущих версий платформы. Например, у вас есть два сервера 2.7.12 (qa и prod).

  1. Tessa Applications 3.5.0 загрузит первое приложение — пусть это TessaClient с сервера qa, — с той же скоростью, что и раньше.

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

  3. После этого оба приложения с сервера prod пользователь откроет практически мгновенно — Tessa Applications скопирует все файлы из папок приложений с сервера qa, кроме, возможно, отличающейся библиотеки с расширениями размером в несколько килобайт.

Инсталлятор .msi получил ряд новых возможностей. Теперь он доступен в двух вариантах, в папках сборки Setup\ru-RU и Setup\en-US расположены:

  • Подпапка x64 — содержит 64-битную версию Tessa Applications, которая поддерживается только в 64-битных ОС, и её мы рекомендуем установливать в таких ОС.

  • Подпапка x86 c 32-битной версией Tessa Applications, которая может быть запущена на ОС любой разрядности.

Если на основном сервере опубликованы приложения Tessa Applications, то после запуска менеджера приложений выполняется его обновление с сервера в соответствии с разрядностью ОС, т.е. 32-битный Tessa Applications обновится до 64-битной редакции, если обратное не указано в карточке сотрудника в поле «Архитектура приложений».

Значение «Предпочитать 64-битные приложения» полезно при скачивании и запуске приложений из Tessa Applications версии 3.4.0 (см. ниже), который не сообщает разрядность ОС серверу.

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

Можно отключить обновление Tessa Applications с сервера, отмеченного как основной (звёздочкой в списке серверов). В этом случае не будет скачиваться опубликованная версия менеджера, а будет сохранена та, которая установлена вместе с .msi.

Настройку можно поменять позже в списке серверов:

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

Также в инсталлятор добавлен флажок «Сохранить существующие параметры подключения», установив который гарантируется, что файл application_catalogs.xml в профиле сотрудника не будет пересоздан в результате установки, включая список всех серверов и параметров подключения, путь к папке со скаченными приложениями, и текущий установленный у пользователя флажок по отключению установки обновлений, описанный выше.

Если вы установили флажок, то все прочие настройки на этом экране применяются только для новых пользователей на этом компьютере, у которых в профиле отсутствует файл application_catalogs.xml.

В файле "%appdata%\settings\application_catalogs.xml" указан путь к папке со скачиваемыми приложениями TessaClient, TessaAdmin и др.: t:AppPath="%localappdata%\tessa".

При обновлении с предыдущих версий Tessa Applications с включённым флажком «Сохранить существующие параметры подключения» предыдущая настройка с папкой "%appdata%\tessa" будет сохранена, поэтому приложения по-прежнему будут устанавливаться в перемещаемый профиль пользователя.

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

В инсталляторе можно выбрать, будет ли создан ярлык в меню «Пуск» или на рабочем столе. И появился режим «Запускать приложение при запуске Windows», который
включён по умолчанию.

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

Когда пользователю надо запустить приложение, он может сразу выбрать его в контекстном меню, или дважды кликнуть по «птичке», чтобы открыть окно менеджера приложений.

При включённом автозапуске в папке C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup создаётся ярлык для TessaAppLauncher.exe с ключом запуска /autostart. Вы можете отключить штатный автозапуск в инсталляторе и создать ярлык автозапуска любым другим способом.

Чтобы отключить автозапуск уже после того, как вы установили приложение — повторно запустите файл .msi, нажмите «Изменить» и выберите «Компонент будет полностью недоступен». При этом инсталлятор удалит ярлык и не повлияет на любые другие настройки.

Все перечисленные функции можно автоматизировать в командной строке или в файле
mst-трансформации при установке через доменные политики.

Подробнее по возможностям msi-инсталлятора и по настройкам Tessa Applications написано
в руководстве по установке.

Обратная совместимость

Для версии Tessa Applications 3.4.0 поддерживается запуск новых приложений 3.5.0 в режиме совместимости, используя старую версию API v1. При этом установка и запуск приложения происходят более медленно. В «О программе» доступна информация об использовании API v1.

Версии Tessa Applications 3.3.1 и более ранние не поддерживают подключение к серверу 3.5.0, поэтому запускать приложения они также не могут. Вы можете обновить Tessa Applications до версии 3.4.0 (если основной сервер у таких пользователей версии 3.4.0, 3.3.1 или более ранний) или до версии 3.5.0 (если основной сервер также версии 3.5.0 или более ранний — см. ниже).

Новый Tessa Applications не может подключаться к серверам со сборками 3.0.0 — 3.3.0, если сервер работает под управлением Windows, из-за ошибки в тех версиях сервера приложений. В ReleaseNotes доступна инструкция для создания патча, который необходимо применить на сервере, чтобы он был доступен из менеджера приложений версии 3.5.0, см. п.21 ReleaseNotes

Это не затрагивает версии серверов 2.x, 3.3.1 и 3.4.0.

Инструменты администратора

Приложение SchemeEditor, используемое для изменения схемы данных с прямым подключением к БД, теперь доступно только в 64-битной версии. Используйте приложение TessaAdmin для редактирования схемы на 32-битной ОС.

Приложение TokenEditor, позволявшее создавать ключ для подписи токена безопасности в конфигурационном файле app.json, заменено на консольные команды tadmin GetKey/SetKey. Инструкция по созданию ключей — в руководстве по установке.

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

На странице /check веб-сервиса выполняется проверка файла app.json на наличие ошибок и выводится информация по текущей конфигурации, которая также доступна в TessaAdmin на вкладке «Информация».

Для установки на Production сервере отключите доступ к этой странице, указав «HealthCheckIsEnabled»: false в файле app.json.

При установке на Linux поддерживается несколько инсталляций TESSA для одного сервера приложений, для этого в файле app.json укажите настройки PathBase и GuyFawkesAuth.

Каждая инсталляция будет иметь свой суффикс в адресе:

Также все настройки app.json описаны в руководстве по установке.

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

./tadmin ManageRoles SyncAllDeputies RecalcAllDynamicRoles RecalcAllRoleGenerators                 -a:https://localhost -u:admin -p:admin 

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

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

Флажок «Запланировать расчёт при запуске сервиса Chronos» удобен, когда расписание указано в виде строки Cron (например, каждую пятницу в 8 вечера), но при перезапуске сервиса Chronos нужно выполнить расчёт ещё раз.

Скрипты обновления сборки Upgrade.bat/upgrade.sh больше не спрашивают имя файловой папки, потому что при установке существующие настройки файлов сохраняются.

Но требуется задать:

  • Web service path — путь к папке веб-сервиса, обычно C:\inetpub\wwwroot\tessa для Windows или $HOME/tessa/web для Linux;
  • Chronos path — путь к папке сервиса Chronos, обычно C:\Tessa\Chronos для Windows или $HOME/tessa/chronos для Linux.

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

При установке на Windows веб-сервис может быть расположен в папке inetpub\wwwroot, защищённой UAC, поэтому скрипты Setup.bat/Upgrade.bat требуется запустить от имени администратора, или другим образом предоставить права к папке с файлом app.json веб-сервиса и Chronos.

Конфигурация

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

  1. Во всех файлах используется кодировка UTF-8 с указанием BOM (byte order mark).

  2. Во всех файлах задействованы переводы строк в Unix style: LF \n вместо CR LF \r\n.
    Экспорт может выполняться как через приложение TessaAdmin или tadmin на Windows, так и посредством tadmin на Linux, но файлы выгружаются идентичными с точки зрения репозиториев и с переводом строк LF, который одинаково читается всеми текстовыми редакторами на Linux и Windows (включая приложение «Блокнот»).

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

  4. В TessaAdmin для рабочего места не отображается свойство «Номер текущей ревизии», инкремент этого номера порождал изменения в экспортируемых файлах.

Для удобства сравнения файлов при обновлении конфигурации в вашем текущем репозитории используйте команду tadmin ConvertConfiguration с параметром -mode:LF, чтобы преобразовать переводы строк в Unix style:

./tadmin ConvertConfiguration -mode:LF C:\Projects\TessaDemo\Configuration

Аналогично, возможно обратное преобразование -mode:CRLF, а также преобразование к старым форматам типов и экземпляров карточек -mode:Downgrade: .jtype->.tct, .jcard->.card.

Продолжение следует…

Мы рассмотрели некоторые технические аспекты сборки и процесс обновления.

Полный список изменений доступен в документе ReleaseNotes.

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

Leave a Reply

Ваш адрес email не будет опубликован. Обязательные поля помечены *