← На главную

При настройке обмена данными между типовыми конфигурациями 1С:Управление торговлей 11 и 1С:Бухгалтерия предприятия 3.0 (особенно через универсальный формат Enterprise Data), технические специалисты часто сталкиваются с ситуацией, когда объем накопленных данных за несколько лет работы превращает первичную выгрузку в многочасовой процесс. Возникает закономерный вопрос: можно ли позволить пользователям продолжать работу в исходной базе (УТ), пока идет длительная загрузка и сопоставление объектов в принимающей базе (БП)?

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

Механизм регистрации изменений и параллельная работа

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

1. Регистрация новых изменений: Любое действие пользователя (создание нового документа или изменение старого справочника) фиксируется платформой 1С на соответствующем узле плана обмена.
2. Изоляция выгруженного файла: Файл, который уже сформирован и отправлен на загрузку в БП 3.0 (например, размером 375 МБ), является статичным. В нем зафиксированы состояния объектов именно на момент формирования файла.
3. Последующая актуализация: Все изменения, внесенные пользователями во время вашей 12-часовой загрузки в БП, «накапливаются» в очереди обмена. Они не попадут в текущую сессию загрузки, но будут переданы при следующем сеансе синхронизации.

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

Решение проблемы «Недостаточно памяти» при загрузке

Одной из главных проблем при работе с Enterprise Data является потребление ресурсов. Ошибка «Недостаточно памяти» возникает из-за того, что при чтении и разборе огромного XML-файла (или JSON) платформа пытается построить дерево объектов в оперативной памяти. Если сервер имеет всего 8 ГБ ОЗУ или используется 32-битная версия рабочего процесса rphost, падение системы практически неизбежно.

Рассмотрим по шагам, как оптимизировать этот процесс:

1. Увеличение ресурсов сервера: Для комфортной работы с базами объемом в сотни мегабайт (в формате обмена) рекомендуется иметь не менее 16-32 ГБ ОЗУ. Если это невозможно, необходимо убедиться, что используется 64-битный сервер 1С, способный адресовать больше памяти одному процессу.
2. Чанкинг (Разбиение выгрузки): Вместо попытки пропихнуть данные за 2 года одним файлом, разберем ситуацию по периодам. Разумнее выполнить несколько последовательных выгрузок: сначала справочники, затем остатки на начало года, а затем документы, разбитые по кварталам или месяцам. Это значительно снизит нагрузку на оперативную память в принимающей базе.
3. Оптимизация файла подкачки: В качестве временной меры можно существенно увеличить файл подкачки на сервере, где расположен rphost, однако это сильно замедлит процесс (загрузка может растянуться на сутки и более).

Техническая оптимизация загрузки в БП 3.0

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

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

Режим загрузки данных. Проверьте, что обмен идет в режиме загрузки. В коде это управляется свойством ОбменДанными.Загрузка = Истина. В этом режиме:

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

Этап сопоставления объектов

Самый трудоемкий этап — сопоставление данных (мэппинг). Рассмотрим подробнее, как облегчить этот процесс. Если БП 3.0 была абсолютно пустой («чистой»), то сопоставление пройдет автоматически по внутренним идентификаторам (GUID). Если же в БП уже велся какой-то учет, крайне важно настроить поля поиска.

Проанализируем типичные поля поиска для Enterprise Data:

• Для контрагентов: ИНН + КПП.
• Для номенклатуры: Артикул или Наименование + ЭтоГруппа.
• Для документов: Номер + Дата.

Выясним причину, по которой сопоставление может «висеть». Часто это происходит из-за поиска по неиндексированным полям или при попытке системы сопоставить тысячи записей за один проход в интерактивном окне. Если объектов более 50 000, старайтесь выполнять сопоставление порциями.

Завершение настройки и подтверждение обмена

После того как 12-часовая (или более) загрузка в БП завершится, критически важно выполнить «ответный ход»:

1. Выгрузите из БП файл с квитанцией (подтверждением получения).
2. Загрузите этот файл в УТ 11.

Зачем это нужно? Пока УТ 11 не получит подтверждение, что объекты успешно загружены в БП, она будет продолжать хранить информацию об их «изменении» в таблицах регистрации. Если вы не загрузите ответное сообщение, следующая выгрузка снова будет содержать те же самые 375 МБ данных плюс новые изменения, что опять приведет к ошибке памяти. Загрузка квитанции очищает таблицу регистрации на узле плана обмена.

Пример анализа состояния регистрации изменений:
Для контроля за тем, сколько данных «стоит в очереди» на выгрузку, программист может использовать обработку «Регистрация изменений для обмена». В ней наглядно видно количество объектов каждого типа, ожидающих отправки. Если после успешной загрузки в БП список не очистился — значит, номер сообщения обмена не синхронизировался, и это требует ручного вмешательства в номера принятых и отправленных сообщений на узлах обмена.

Резюме для технического специалиста

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

• Не блокируйте пользователей: Пусть работают в УТ, механизм планов обмена справится с актуализацией данных позже.
• Разбивайте данные: Первый перенос лучше делать помесячно.
• Следите за ресурсами: Если сервер падает с ошибкой памяти, проверьте разрядность rphost и объем ОЗУ.
• Очищайте регистрацию: Всегда дожидайтесь конца цикла (выгрузка -> загрузка -> подтверждение), чтобы не копить «хвосты» в таблицах регистрации изменений.