1С обсуждения: где хранятся сообщения

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

Из-за такой архитектуры типовые приёмы вроде «найти сообщение запросом к базе» или «посмотреть переписку через СУБД» не работают. Чтобы определить, где физически лежат данные, сначала нужно выяснить, какой сервер взаимодействия используется: сервер 1С:Предприятия, внешний сервер на базе open-source решений (например, Ring/Elasticsearch-стек) или облачный сервис 1С:Диалог. От этого зависят и инструменты доступа, и процедуры резервного копирования, и возможности очистки истории.

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

Как устроено хранение сообщений в системе взаимодействия

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

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

Где хранятся сообщения при разных вариантах развёртывания

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

Встроенный сервер кластера 1С

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

Внешний сервер взаимодействия

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

Облачный вариант

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

Что всё-таки остаётся в информационной базе

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

Практическое следствие: перенос информационной базы через выгрузку в файл .dt не переносит сами сообщения. После загрузки копии базы на новом месте обсуждения будут либо пустыми, либо подключатся к тому же серверу взаимодействия и покажут ту же переписку — в зависимости от настроек подключения. Это частая причина «пропажи» истории при миграциях.

Как программно получить и выгрузить сообщения

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

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

ИдентификаторОбсуждения = Новый ИдентификаторОбсужденияСистемыВзаимодействия("...");
Обсуждение = СистемаВзаимодействия.ПолучитьОбсуждение(ИдентификаторОбсуждения);
Отбор = Новый ОтборСообщенийСистемыВзаимодействия;
Отбор.Обсуждение = Обсуждение.Идентификатор;
Сообщения = СистемаВзаимодействия.ПолучитьСообщения(Отбор);
Для Каждого Сообщение Из Сообщения Цикл
    // Сообщение.Текст, Сообщение.Дата, Сообщение.Автор
КонецЦикла;

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

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

Резервное копирование и восстановление обсуждений

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

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

Очистка истории и ограничения

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

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

Частые вопросы