Библиотека технологии сервиса 1С: что это и зачем она нужна

Библиотека технологии сервиса (БТС) — это набор типовых подсистем от фирмы «1С», предназначенный для конфигураций, которые работают в модели сервиса (SaaS): разделение данных между абонентами, управление пользователями сервиса, очереди заданий, обмен сообщениями между менеджером сервиса и приложениями. Библиотека распространяется в виде файлов поставки и встраивается в конфигурацию механизмом сравнения и объединения.

БТС не является самостоятельной программой и не работает отдельно от прикладного решения. Она дополняет Библиотеку стандартных подсистем (БСП): если БСП отвечает за базовую функциональность любой конфигурации (пользователи, подключаемое оборудование, печать), то БТС закрывает задачи именно мультитенантной работы — когда одна информационная база обслуживает множество независимых организаций-абонентов, изолированных друг от друга.

Разработчик, внедряющий БТС, получает готовые механизмы вместо самостоятельной разработки разделения данных: общие реквизиты-разделители, подсистемы управления тарифами и подписками, интерфейсы взаимодействия с менеджером сервиса. Это существенно сокращает сроки вывода прикладного решения в облачную модель и снижает риск ошибок в критичной для безопасности части — изоляции данных абонентов.

Что такое БТС и какие задачи она решает

Основная задача библиотеки — обеспечить корректную работу прикладного решения в режиме «один экземпляр приложения — много абонентов». В такой модели данные каждого абонента физически хранятся в общей базе, но логически изолированы: пользователь одной организации не должен видеть документы, справочники и отчёты другой. БТС реализует эту изоляцию через механизм разделения данных платформы 1С:Предприятие и предоставляет прикладному разработчику готовый каркас.

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

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

Состав библиотеки: основные подсистемы

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

• Работа в модели сервиса — базовый блок: разделители данных, сеансовые механизмы установки и снятия разделения, программный интерфейс для работы с областями данных.
• Очередь заданий — планирование и выполнение фоновых заданий с учётом разделителей, ограничение конкурентного доступа, шаблоны заданий.
• Обмен сообщениями — каналы взаимодействия приложения с менеджером сервиса и между приложениями сервиса, версионирование интерфейсов сообщений.
• Управление пользователями в модели сервиса — роли абонентов, приглашение пользователей, связь пользователей сервиса с пользователями приложений.
• Тарификация — модели тарифов, подписки на услуги, учёт периодов действия тарифов, проверка доступности функциональности по тарифу.
• Выгрузка и загрузка данных областей — формирование выгрузки данных абонента и восстановление области из файла.
• Поставляемые данные — механизм доставки общих (неразделённых) данных от поставщика сервиса во все области абонентов.

Точный перечень подсистем зависит от версии библиотеки. Перед внедрением стоит свериться с документацией к конкретному релизу: состав и названия подсистем периодически уточняются, а часть функциональности может быть перенесена между БСП и БТС.

Как БТС связана с БСП и платформой

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

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

Сравнение библиотек

БСП (Библиотека стандартных подсистем)

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

БТС (Библиотека технологии сервиса)

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

Менеджер сервиса

Отдельная конфигурация для управления сервисом в целом: абоненты, тарифы, владельцы. Не встраивается в прикладное решение, а взаимодействует с ним через БТС.

Когда БТС действительно нужна, а когда избыточна

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

БТС избыточна для локальных (коробочных) внедрений, где одна база обслуживает одну организацию или группу связанных компаний. Внедрение библиотеки «на всякий случай» добавляет в конфигурацию сотни объектов метаданных, усложняет обновление и обновление поставки, увеличивает требования к квалификации разработчиков — без какой-либо отдачи.

Промежуточный случай — решение, которое сейчас локальное, но в перспективе должно стать сервисом. Здесь разумная стратегия — проектировать модель данных с учётом будущего разделения (не использовать константы для абонентских настроек, избегать общих нумераторов), но внедрять БТС непосредственно при переходе к SaaS, когда появится менеджер сервиса и реальные абоненты.

Маршрут решения

Как выбрать действие

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

База обслуживает одну организацию, облачная модель не планируетсяОграничьтесь БСП — внедрение БТС не даст преимуществ и усложнит сопровождение

Сервис планируется в перспективе, но сейчас решение локальноеПроектируйте данные с учётом будущего разделения, внедрение БТС отложите до перехода в SaaS

Как внедрить БТС в конфигурацию: порядок действий

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

1. Проверьте совместимость версий: какая версия БСП требуется для выбранной версии БТС, и совместима ли она с версией БСП вашей конфигурации.
2. Сделайте резервную копию информационной базы и выгрузку конфигурации. Объединение такого масштаба должно быть обратимым.
3. Изучите документацию к поставке: перечень подсистем, зависимости между ними, требования к переопределяемым модулям.
4. Выполните сравнение и объединение с файлом поставки БТС, выбирая только нужные подсистемы и их обязательные зависимости.
5. Заполните переопределяемые модули: укажите прикладные обработчики событий, параметры области данных, состав разделённых объектов.
6. Обновите конфигурацию базы данных, устраните ошибки компиляции модулей.
7. Проверьте работу в тестовой области: создание области, вход пользователя абонента, выполнение заданий очереди, обмен сообщениями с менеджером сервиса.

1. 1
   Проверить совместимость версий БТС и БСП по документации к поставке
2. 2
   Сделать резервную копию базы и выгрузку конфигурации
3. 3
   Выполнить сравнение и объединение с файлом поставки, выбрав нужные подсистемы
4. 4
   Заполнить переопределяемые модули прикладными обработчиками
5. 5
   Обновить конфигурацию базы данных и устранить ошибки компиляции
6. 6
   Протестировать создание области данных и работу абонента в тестовой среде

Проверка результата и типичные ошибки

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

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

Контрольные точки

Как проверить результат

Изоляция данных абонентов

Норма

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

Тревожный признак

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

Работа очереди заданий

Норма

Задания выполняются в контексте своей области с корректными параметрами

Тревожный признак

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

Обмен с менеджером сервиса

Норма

Сообщения о создании и настройке области обрабатываются без ошибок в журнале

Тревожный признак

Сообщения зависают в очереди или возвращают ошибки версий интерфейсов

Обновление библиотеки и ограничения

Обновление БТС выполняется тем же механизмом сравнения и объединения, но требует аккуратности: прикладной код, который вызывает программный интерфейс библиотеки, может зависеть от состава и сигнатур экспортных процедур. Перед обновлением изучите список изменений версии, после объединения — перепроверьте все места вызова API библиотеки и выполните полное тестирование разделённой работы.

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

Часто задаваемые вопросы

Можно ли использовать БТС без БСП?

Нет. Подсистемы БТС вызывают механизмы Библиотеки стандартных подсистем и опираются на её объекты. Сначала в конфигурацию внедряется совместимая версия БСП, затем поверх неё — БТС.

Подходит ли БТС для обычной локальной базы одной организации?

Технически внедрить можно, но практического смысла нет: библиотека решает задачи мультитенантной работы, которых в локальной базе не возникает. Для локального решения достаточно БСП.

Что такое область данных в терминах БТС?

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

Как БТС взаимодействует с менеджером сервиса?

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

Можно ли внедрить только часть подсистем БТС?

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

Что делать, если после обновления БТС перестали работать прикладные механизмы?

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