Оптимизация типовых обменов EnterpriseData. Делаем асинхронное проведение и дожидаемся ответа от приёмника
В статье показана пара приемов, позволяющих существенно снизить размер пакетов, а следовательно и нагрузку на оборудование при обменах в больших базах.
- Описание
- Подробнее
Описание
Лирическое отступление.
Лет десять назад я открыл для себя Конвертацию Данных 2.0. И до сих пор нежно люблю этот инструмент. Он одинаково хорошо подходит для регулярных обменов данными между конфигурациями 1С и реализации разовых выгрузок. Я даже реализовывал обработку данных в одной и той же конфигурации последовательно выгрузив их и загрузив обратно — просто это было быстрее написать, чем реализовывать обработкой с нуля…
Примерно в это же время фирма 1С выкатила новое решение — конвертацию данных 3.0 и XDTO пакет EnterpriseData. Отличная идея — выгружать данные в некий стандартный формат, чтобы затем можно было считывать из него в разные конфигурации-приёмники.
Я был среди первых слушателей курсов по этой технологии обменов и надеялся, что это предтеча появления полноценной шины данных. Даже спрашивал про это преподавателя курсов, а тот, в свою очередь, задавал этот вопрос разработчикам 1С (была у него такая возможность). К сожалению, таких планов у 1С не было. Шина впоследствии вышла, но типовые обмены EnterpriseData так и остались в парадигме "точка-точка". Впрочем, я отвлекся, вернемся к сути…
Суть проблемы.
Текущая технология обменов, хоть и использует новый формат данных, технологически напоминает старые добрые обмены КД 2. Одно из преимуществ таких обменов, если от базы-приёмника не получена "квитанция" о приёме очередного пакета данных, то источник заново выгружает ранее выгруженные данные и добавляет к ним новые. Таким образом достигается надёжность передачи данных, но этот способ имеет и недостатки — если за рабочий день в источнике создается (изменяется) несколько десятков тысяч документов, то просто не получается подобрать адекватное расписание для обменов. Пока база-приёмник записывает и проводит документы из очередного пакета, источник уже начинает выгрузку следующего (который, напомню, содержит данные предыдущего пакета плюс новые). Таким образом размер пакетов, а значит и время на их обработку, вырастает как снежный ком. Если задать в расписании выгрузки большой интервал, тоже ничего хорошего не происходит. За это время накапливается большое количество изменений и всё равно файл обмена будет занимать сотни мегабайт, а то и несколько гигабайт. Плюс, в 2025 году пользователи уже не хотят ждать данные даже один день.
Очевидным решением будет переход к обменам через шину данных. Такой подход позволяет добиться почти мгновенного появления данных в базах-приёмниках. Но переход на шину процесс не быстрый, а негатив пользователей надо гасить уже сейчас. Поэтому попробуем выжать максимум из существующих типовых обменов, при этом не затрачивая на задачу больших ресурсов (всё равно же шину внедрять).
Решение.
Решено было действовать в двух направлениях: 1. Сократить время выдачи "квитанции" от базы-приёмника. Тут напрашивалось решение — проводить документы асинхронно (ведь обмен, по сути, прошел, зачем задерживать загрузку следующего пакета?) 2. Сократить интервал выгрузки данных, но при этом заставить базу-источник ожидать "квитанцию", чтобы не выгружать повторно лишние данные.
Забегая вперед, скажу, что всё получилось. Уже несколько месяцев у нас работают обмены с расписанием "раз в 5 минут" на выгрузку и "раз в 100 секунд" на загрузку. Файлы обмена при этом редко превышают 10Мб, а чаще находятся в пределах 2-5Мб.
Технические детали.
Сперва я занялся асинхронным проведением и был удивлён тем, что в современных релизах БСП практически всё готово. Документы проводятся на последнем этапе, а сведения о том, какие документы нужно провести собраны в специальную таблицу. Беда лишь в том, что находится эта таблица в памяти. Поэтому решение здесь получилось простым — перехватываем процедуру проведения и выгружаем таблицу документов в заранее созданный справочник (либо регистр сведений, тут кому как удобнее). Завершаем обмен, проведение поручаем специально обученному регламентному заданию.
Итак, первым делом создаем два справочника — "ДополнительныеНастройкиУзловКорреспондента" для хранения настроек, и "ОчередьОтложенногоПроведения" для хранения очереди документов для отложенного проведения.
Справочник "ДополнительныеНастройкиУзловКорреспондента":

Описание реквизитов:
| Название колонки | Тип данных |
| УзелКорреспондента | План обмена ссылка |
| ИспользоватьОтложенноеПроведение | Булево |
| РазмерПорцииДокументовДляПроведения | Число (5,0) |
| ДожидатьсяЗагрузкиВыгруженногоПакета | Булево |
