Top.Mail.Ru
Меню
Каталог Программы 1С Опыт и отзывы Услуги Компания Интересное Контакты

Ускорение работы правил обмена XML

Основатель и генеральный директор компании MoscowSoft, Сорокин Сергей
Сорокин Сергей, Генеральный директор MoscowSoft  08.04.2026 Актуальность проверена: 08.04.2026   5 мин.
Подобрать перенос данных 1С

Специализируемся на переносах данных 1С с 2015г.

Подобрать перенос данных 1С >>

Интеграция 1С с маркетплейсами

Специализируемся на интеграциях 1С с маркетплейсами с 2021г.

Изучить продукты >>

Содержание

Когда обмениваешься данными через XML по стандартным правилам (КД 2), часто замечаешь: выгрузка или загрузка идёт долго, особенно если набор данных большой. Но на самом деле многое в наших руках. Главное – оптимизировать логику выгрузки и загрузки с умом. Ниже разберём практические приёмы, которые помогут сильно ускорить обмен XML. Статья будет спокойной и живой, без шаблонных фраз. Подробно расскажем о фильтрации, кэшировании, настройках и других важных моментах. Поговорим простым языком, но очень профессионально.

Фильтрация и отбор данных

Первое и самое очевидное правило – не выгружайте лишнее. Экспортируйте только то, что точно нужно. Например, если план обмена передаёт документы за конкретный период, поставьте фильтр по дате ( Где Дата >= НачалоПериода И Дата < КонецПериода ). Если нужна только часть справочника – тоже добавьте условие. Любая невыметенная строка в результате XML создаёт работу. Именно это и тормозит. Поэтому при разработке правил заранее формируйте запросы или условия фильтрации: не через алгоритм после, а сразу на этапе ПВД или запроса. Это позволит выгрузить только релевантные объекты и сократить объём XML. Например, в ПВД в обработчике «ПередВыгрузкой» можно убрать те объекты, которые сейчас не нужны, чтобы они не запрашивались вообще. Используйте флаги в настройках плана обмена: если свойство не важно на другом конце, снимите галку «Выгружать объекты свойств источника».

Другими словами: не выгружайте лишнее. Каждая лишняя запись в выгрузке – это работа системы. В самом начале, при настройке ПВД/ПКО, задавайте фильтры: дата, группа, статус – что угодно, что сокращает объём. На этапе выгрузки не заставляйте пользователей потом вручную править XML – лучше сразу уйдёт много пустых операций. К тому же в обработчиках Конвертации можно обрубить ненужные ветки: если вы в «ПослеВыгрузки» понимаете, что объект не нужен в обмене, просто не вызывайте ВыгрузитьПоПравилу для него. Поверьте, это может сэкономить много времени. Важный момент: сокращайте объём XML-сообщения по максимуму. Чем короче файл – тем быстрее он обрабатывается и переносится.

Быстрый поиск и индексы

Второй важный момент – поиск нужных объектов. Если при загрузке вы ищете объекты не по ключу (например, по коду или UUID), включите «быстрый поиск» по полям. В настройках свойств конвертации для нужных реквизитов поставьте галочку «Поиск». Это заставит платформу использовать индексированные поля. Без этого платформа перебирает всё и медленно ищет нужное по «рубанку». С быстрым поиском запрос выполняется за доли секунды. То же касается запросов в ПКО: используйте индексы на таблицы значений для хранения кэша, которые создаете самостоятельно. Если делаете запросы через «Запрос» – правильно рассчитывайте ключи. Проще говоря: давайте системе меньше работы. И нет, отказ от полнотекстового или статистического поиска не обязательно – оптимизация тут в грамотно выбранных ключах.

Кэширование данных

Третий трюк – кэшируйте результаты. Если конвертация часто обращается к одним и тем же данным, не выполняйте каждый раз полный запрос. Например, при загрузке документов коды контрагентов, складов и других справочных объектов могут повторяться. Выполните один запрос на все нужные элементы (например, табличную часть или массив из нескольких ссылок) и сохраните результат в структуре или глобальном объекте. Потом в цикле берите готовые значения из кэша, а не ходите на сервер 50 раз. Не делайте запрос внутри каждого «Для каждого элемента» без необходимости. Лучше один раз получить все товары или расчётные типы и хранить их в словаре: так вы многократно сэкономите время. Кэширование особенно актуально, когда обмен идёт большим пакетом.

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

Свойства объектов и вложенные данные

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

Проверьте настройки ПКО: там есть флажки типа «Выгружать объекты свойств источника по ссылке». Также обратите внимание на галку «Не запоминать выгруженные объекты». Включение этого флага избавит от накладных расходов по отслеживанию того, что уже выгружено, что тоже ускоряет процесс. Записи регистров все равно не являются ссылочным объектов. Для их ПКО обязательно всегда надо включать флаг Не запоминать выгруженные объекты.

Флаги загрузки и перезапись

На приёмнике тоже можно оптимизировать. Главная настройка – «Не перезаписывать существующие элементы». Если в вашей целевой базе уже есть большинство данных (или вы уверены, что нужно только добавить новые), поставьте этот флажок. Тогда при загрузке платформа просто пропустит объекты с совпадающим GUID (не станет их искать и обновлять). Это экономит уйму времени, особенно если данных много.

Разбиение обмена на этапы

Иногда частота обновлений и объём данных заставляют разбить процесс. Планируйте обмен поэтапно. Например, сначала синхронизируйте НСИ и классификаторы (справочники, настройки), убедитесь, что всё в приёмнике создано правильно. Затем загружайте остатки и базовые склады. Только потом передавайте документы (создание и исправления). Да, это дольше настраивать, но зато намного быстрее по факту: маленькими порциями XML обрабатывается проще, и можно быстрее обнаружить узкие места. Подход «сначала одна очередь, потом другая» очень помог многим. И на каждый этап можно ставить разные фильтры и ограничения. Главное – чтобы логика была понятна. Это как строить дом: сначала фундамент, потом стены, потом кровля – всё по порядку.

Отладка алгоритмов обмена и замер производительности

Наконец, не забывайте измерять скорость. Включите режим отладки алгоритмов правил обмена или используйте Сообщить() в ключевых местах правил. Стандарты позволяют вывести время работы алгоритма (хорошо помогает «замер производительности» в конфигураторе). Так вы увидите, какая именно операция «жрёт» время – например, запрос в цикле, долгий поиск по справочнику или спуск рекурсией. После замера можно локализовать узкое место. Повторяйте: измерили – поработали – снова измерили. И не поленитесь заглянуть в лог обмена: там тоже отображаются длительные запросы. Помните, что без замеров мы гадаем вслепую. А так – знаем точно, где копать дальше.

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

Готовые правила обмена

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

Выбрать перенос данных 1С >>

Правильный порядок правил выгрузки данных

Сначала разберём зависимость объектов. Если вы выгружаете несколько таблиц или справочников, у которых есть ссылки друг на друга, нужно расставить правила обмена в правильном порядке. Представьте: у вас есть справочники «Пользователи» и «ФизическиеЛица», и может оказаться, что один ссылается на другой (например, у пользователя хранится физлицо). Тогда в выгрузке сначала поставьте «ФизическиеЛица», а уже потом «Пользователей». Так справочник-источник будет создан раньше, чем зависимый от него. Этот же принцип действует для других групп объектов: сначала те, на которые опираются, потом – те, кто ссылается. В результате отладка пройдет в разы быстрее – потому что не возникнет ошибок «ссылки на несуществующий объект». (Да, это старый добрый приём – сначала фундамент, потом стены. Поверьте, порядок записи очень важен.)

Отбор данных одним запросом

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

Запрос = Новый Запрос("ВЫБРАТЬ Ссылка ИЗ Справочник.СправочникГрузить");
Выборка = Запрос.Выполнить().Выбрать();

Так вы сразу получите все нужные ссылки. А дальше – в цикле просто проходите результат. Действительно часто помогает: количество переходов к базе сильно уменьшается. Подумайте: одно чтение всех данных или миллион мелких – что быстрее? Именно поэтому сразу загружаем всё нужное, а не строим запросы в каждом шаге. (И не пытайтесь «обойти» это, говоря «мой код и так быстрый» – нет, именно запрос выигрывает время.)

Только изменённые объекты

Переходим к настройкам на приёмнике. В конфигураторе есть чудесная галочка «Записывать только изменённые объекты». Она работает как фильтр на импорт: если объект в базе-приёмнике не менялся с момента последней синхронизации, то при загрузке из файла обмена он просто не тронется. Экономия налицо – платформа не переписывает старые данные. Установите эту галку в модуле менеджера обмена – и будете приятно удивлены, насколько быстрее станут проходить загрузки. По сути, это и есть то самое «не перезаписывать существующие», только понятнее для новичка. Такой режим особенно полезен, если вы делаете периодическую синхронизацию: передавайте в файл обмена только добавленное или изменённое, а импорт настройте так, чтобы переписывались только эти свежие записи. Результат – минимальное количество изменений и максимум скорость.

Оптимизированная запись объектов

Ещё один тюнинг в КД 2 – режим оптимизированной записи объектов. В администрировании обмена (обычно в меню настроек конвертации или в свойствах ПКО) есть такой флаг. Включение его существенно уменьшает обращения к базе при сохранении объектов. Простыми словами, платформа группирует операции или использует более быстрые механизмы сохранения. Как итог – те же 100 документов сохранятся заметно быстрее, чем при обычной «менеджерской» записи. Этот режим как раз и придуман для ускорения массовой загрузки: включил – и «под капотом» пошла оптимизация. Мы его рекомендуем в обязательном порядке – поверьте, разница в крупных обменах сразу ощутима.

Запись регистров пакетами

Последний «рекомендуемый штрих» – работа с регистрами. В настройках обмена можно отметить опцию «Записывать регистры наборами записей» (или похожая фраза). Если её включить, то при загрузке регистров сведений данные будут записываться блоками, а не «строкой за строкой». Это очень важно: обычный режим вызывает Менеджер записи на каждую строку регистра, что очень медленно. А пакетный режим формирует один большой запрос на изменения нескольких строк сразу. На практике это даёт приличный выигрыш – особенно на больших объёмах. В документации такую запись рекомендуют как «ускоренную заливку» регистров. В общем, поставили галку – и процесс мигом пошёл.

Обмен через СОМ-подключение к базе-приемнику

Ещё есть интересный вариант: обмен через COM. Если базы (источника и приёмника) находятся на одном компьютере или в одной локальной сети, можно использовать технологию COM-соединения для передачи. Она позволяет не писать XML в файл вообще, а передавать данные напрямую через интерфейс – и этот обмен очень шустрый. Естественно, для этого обе базы должны быть под Windows, и в них должна быть включена соответствующая обработка (например, «Универсальный обмен данными»). Если вы когда-нибудь видели, как быстро проходит обмен V8→V8 через COM, то поймёте – иногда это лучшая «оптимизация». Но будьте внимательны: этот метод не годится, если базы далеко или у одной из них Linux.

Итог

Итак, мы прошлись по главным приёмам: фильтрация, порядок правил, единые запросы, кэширование, специальные флаги и режимы. Вопрос остаётся открытым: что окажется самым «узким горлышком» в вашем конкретном обмене? Иногда кажется, что всё настроено верно, а скорость всё равно страдает – и тут может помочь какой-то неожиданный лайфхак. Подумайте, с чего начать у себя. Может, стоит экспериментировать: сначала фильтровать выборку, а потом включить оптимизированную запись? Или наоборот – забить на фильтры и сделать кэширование запросов? Главное – не останавливайтесь на одном варианте.

Пишите в комментариях, какие методы вам помогли. Может, у вас уже есть свой уникальный трюк? И помните, оптимизация конвертации – творческий процесс: порой самый простой совет даёт самый большой эффект. Разгоните обмен по полной!

MoscowSoft логотип

Подпишитесь на телеграм-канал MoscowSoft!
QR-код (ссылка приглашение) в канал MoscowSoft

https://t.me/MoscowSoft

Публикуем:
- инструкции и советы по разработке на 1С;
- рекомендации по интеграции 1С;
- бесплатно делимся своими обработками;
- публикуем секретные спецпредложения только для подписчиков.

Возврат к списку