В корпоративных системах на базе 1С интеграции почти всегда появляются постепенно. Сначала возникает один обмен с CRM, затем добавляется интеграция с системой бюджетирования, позже подключаются электронный документооборот, мобильные сервисы, аналитические системы и мастер-данные. Со временем оказывается, что система взаимодействует с внешними контурами не меньше, чем с собственными пользователями.
Пока таких интеграций немного, они редко вызывают заметные проблемы. На тестовых стендах объёмы данных небольшие, операции выполняются быстро, а проведение документов занимает считанные секунды. В этих условиях синхронная схема обмена, когда одна система вызывает сервис другой, выполняет операцию и получает результат, выглядит естественным и удобным архитектурным решением.
Такой подход понятен, быстро реализуется и хорошо работает на небольших объёмах данных, потому что повторяет привычную модель программирования, где функция вызывается и возвращает результат выполнения.
Однако по мере роста системы начинают проявляться ограничения такой архитектуры. Объёмы данных увеличиваются, операции занимают всё больше времени, а синхронные интеграционные вызовы начинают конкурировать с пользовательскими операциями за ресурсы базы данных. В результате интеграционные запросы всё чаще упираются в таймауты, проведение документов начинает удерживать блокировки, а сбои во внешних системах начинают напрямую влиять на стабильность учётного контура.
Со временем любые задержки во внешних системах начинают распространяться на учётный контур 1С, а интеграционные вызовы начинают напрямую влиять на проведение документов и общую производительность системы. Интеграция, которая изначально должна была просто передавать данные между системами, постепенно превращается в источник архитектурной зависимости, из-за которой сбой или замедление одного контура начинает отражаться на работе других.
Причина таких ситуаций обычно оказывается не в конкретной технологии обмена. В проектах можно встретить HTTP-сервисы, OData, файловые выгрузки, API внешних систем или брокеры сообщений, однако одинаковые проблемы возникают практически при любом из этих подходов. Настоящая причина чаще всего связана с архитектурной моделью взаимодействия систем — в частности, с тем, что приём данных и их обработка выполняются синхронно внутри одного интеграционного вызова.
В этой статье рассматривается практический шаблон построения устойчивых интеграций в 1С, основанный на разделении приёма сообщений и их обработки, использовании очереди входящих данных, поддержке идемпотентности операций и передаче больших объёмов данных порциями. Такой подход позволяет системам обмениваться данными без жёсткой синхронной зависимости и сохранять устойчивость интеграций по мере роста нагрузки и объёма данных.
Кейс №1. Блокировки при синхронной интеграции
Типичная ситуация возникает в интеграции между CRM и системой учёта на базе 1С, когда внешняя система создаёт заказы и передаёт их в учётный контур. Интеграция реализуется через HTTP-сервис: CRM отправляет данные заказа, 1С принимает их, создаёт документ и выполняет проведение, после чего CRM получает результат операции. Такая схема выглядит естественной, потому что она повторяет привычную модель программирования — вызов операции и получение результата выполнения.
На тестовом стенде такая интеграция обычно работает без заметных проблем. Однако в продуктивной системе ситуация начинает меняться. Проведение документа в большинстве конфигураций редко ограничивается простой записью данных, потому что в процессе проведения выполняются пересчёты регистров, проверки остатков, обновление взаиморасчётов, проведение связанных документов и другие операции бизнес-логики. Каждая такая операция выполняется внутри транзакции и удерживает блокировки в базе данных.
Когда CRM начинает отправлять несколько заказов одновременно, система оказывается вынуждена проводить несколько документов параллельно. В этот момент начинают возникать блокировки, которые начинают распространяться на другие операции системы. Пользователи начинают замечать, что проведение документов занимает больше времени, отчёты выполняются медленнее, а некоторые операции начинают ожидать освобождения блокировок. При анализе блокировок нередко выясняется, что значительная часть транзакций была инициирована не пользователями системы, а интеграционными вызовами.
Попытки решить проблему увеличением таймаута или ограничением количества интеграционных вызовов обычно дают лишь временный эффект. Основная причина заключается в том, что интеграционный сервис выполняет полноценную бизнес-операцию внутри синхронного HTTP-запроса, а значит удерживает транзакцию и ресурсы базы данных на протяжении всего времени обработки.
Чтобы устранить эту проблему, архитектуру интеграции пришлось изменить. HTTP-сервис перестал выполнять проведение документов и стал выполнять только одну задачу — приём данных и фиксацию интеграционного сообщения. Полученные данные начали записываться в регистр входящих сообщений, который фактически выполняет роль очереди интеграционных сообщений.
Каждая запись в таком регистре содержит тело сообщения, идентификатор внешней операции, тип сообщения и статус обработки. Наличие уникального идентификатора позволяет реализовать идемпотентность — если внешняя система по какой-то причине повторно отправит тот же запрос, система сможет обнаружить дубликат и не повторять операцию.
После записи сообщения HTTP-сервис сразу возвращает внешней системе подтверждение приёма данных. Это подтверждение означает не выполнение бизнес-операции, а только факт успешной фиксации сообщения в системе. С точки зрения внешней системы интеграционный вызов становится короткой и предсказуемой операцией, не зависящей от времени выполнения бизнес-логики.
Обработка сообщений переносится в отдельный механизм фоновой обработки. Фоновые задания периодически выбирают новые записи из регистра входящих сообщений, переводят их в состояние обработки и выполняют соответствующую бизнес-операцию — например создают и проводят документ заказ. После завершения операции статус записи изменяется на «обработано» или «ошибка», а информация о результате фиксируется в системе.
Такое разделение приёма сообщений и выполнения бизнес-операций даёт несколько важных архитектурных преимуществ.
Во-первых, интеграционный HTTP-сервис перестаёт удерживать транзакцию и блокировки в течение длительного времени, потому что его задача ограничивается записью сообщения.
Во-вторых, система получает возможность управлять уровнем параллелизма обработки — например ограничивать количество фоновых заданий, которые одновременно выполняют проведение документов.
В результате поток интеграционных сообщений перестаёт напрямую конкурировать с пользовательскими операциями за ресурсы базы данных. Проведение документов выполняется управляемо и постепенно, а интеграционные вызовы больше не становятся источником блокировок и деградации производительности системы. Интеграция превращается из синхронного вызова бизнес-операции в управляемый поток сообщений, который система может обрабатывать с контролируемой нагрузкой.
Кейс №2. Таймауты при передаче больших объёмов данных
Другой типичный сценарий проявляется при передаче больших объёмов данных. В одной из интеграций между 1С и системой бюджетирования Foresight необходимо было регулярно передавать фактические данные для анализа исполнения бюджета.
Первоначально интеграция была реализована через OData: внешняя система отправляла запрос к сервису 1С, после чего 1С формировала выборку данных из плана обмена и передавала её во внешнюю систему. На тестовом стенде такая схема выглядела рабочей, потому что объём данных был относительно небольшим, а выполнение запроса занимало считанные секунды.
Однако после запуска системы в промышленную эксплуатацию ситуация начала меняться. Объём фактических данных для бюджетирования быстро рос, а сами запросы становились всё тяжелее. Формирование выборки из плана обмена, сериализация данных и передача их по сети начали занимать значительно больше времени. Постепенно интеграционные вызовы стали регулярно упираться в таймауты HTTP-запросов. Попытки увеличить время ожидания лишь временно стабилизировали ситуацию, потому что рост объёма данных продолжался.
Следующей попыткой решения стала файловая выгрузка через объектное хранилище Amazon S3. В этой схеме 1С формировала файл выгрузки, загружала его в хранилище, а система бюджетирования периодически проверяла готовность файла и скачивала его после завершения выгрузки. Такой подход позволил устранить проблему таймаутов, потому что формирование и загрузка файла выполнялись асинхронно.
Однако вскоре проявилась другая архитектурная проблема. После формирования выгрузки данные удалялись из плана обмена, потому что считалось, что они уже переданы во внешнюю систему. Если файл по какой-то причине не был обработан системой бюджетирования — например из-за сбоя обработки, сетевой ошибки или некорректного формата данных — повторная передача данных становилась невозможной. Система оказывалась в ситуации, когда данные уже считались выгруженными, но фактически не были обработаны принимающей стороной.
В результате архитектуру интеграции пришлось изменить более принципиально. Основная идея заключалась в том, чтобы разделить формирование набора данных, передачу данных и подтверждение их обработки. Для этого данные из плана обмена сначала переносились в отдельный регистр сведений, который формировал фиксированный набор данных для выгрузки.
На этапе подготовки выгрузки система формировала новый сеанс передачи данных. Все записи, попадающие в выгрузку, копировались в регистр, где каждой записи присваивались два ключевых атрибута: идентификатор сеанса выгрузки и порядковый номер записи внутри этого сеанса. Нумерация позволяла сформировать детерминированный и неизменяемый порядок данных, который можно было использовать для порционной передачи.
После формирования набора данных внешняя система больше не запрашивала весь массив сразу. Вместо этого она отправляла запросы на получение данных порциями, указывая диапазон записей — например с 1 по 1000, затем с 1001 по 2000 и так далее. 1С возвращала соответствующий фрагмент данных из регистра выгрузки. Такой подход позволил передавать даже очень большие объёмы информации без риска таймаутов, потому что каждый отдельный запрос оставался небольшим и быстро выполнялся.
Ключевым элементом этой схемы стало подтверждение обработки данных. После успешной загрузки очередного диапазона записей система бюджетирования отправляла подтверждение, в котором указывался обработанный диапазон. Только после получения такого подтверждения соответствующие записи помечались как обработанные и могли быть очищены из регистра выгрузки.
Благодаря этому механизм передачи стал устойчивым к сбоям. Если в процессе обмена возникала ошибка или соединение разрывалось, внешняя система могла повторно запросить тот же диапазон данных. Поскольку записи в регистре сохранялись до подтверждения обработки, повторный запрос возвращал тот же набор данных, а значит операция становилась идемпотентной.
В результате интеграция перестала зависеть от размера передаваемых данных и ограничений сетевых таймаутов. Передача информации превратилась из единственного тяжёлого запроса в управляемый поток небольших операций, которые можно безопасно повторять и подтверждать. Такой подход позволил обеспечить устойчивость обмена даже при дальнейшем росте объёма данных и фактически сформировал универсальный механизм асинхронной передачи больших наборов информации между системами.
Универсальный механизм устойчивой интеграции
Оба рассмотренных кейса показывают, что устойчивость интеграции достигается не столько выбором конкретной технологии обмена, сколько архитектурной моделью взаимодействия систем. На практике надёжная интеграция почти всегда строится вокруг нескольких базовых принципов, которые позволяют системе работать устойчиво даже при росте нагрузки, объёма данных и числа интеграционных операций.
Первым и наиболее важным принципом является асинхронность взаимодействия. Приём данных не должен зависеть от выполнения тяжёлой бизнес-операции, потому что именно выполнение такой операции чаще всего занимает большую часть времени интеграционного запроса. Если интеграция построена синхронно, то внешний вызов фактически удерживает транзакцию системы до завершения всей бизнес-логики — создания документа, проведения, пересчёта регистров и других операций. В асинхронной модели эти этапы разделяются. Интеграционный сервис выполняет только приём и фиксацию сообщения, а сама бизнес-операция переносится в отдельный процесс обработки. Благодаря этому интеграционный вызов становится коротким и предсказуемым, а система перестаёт удерживать ресурсы базы данных внутри внешнего запроса.
Вторым ключевым элементом становится очередь сообщений. В 1С она может быть реализована через регистр сведений, справочник, внешний источник данных, однако архитектурная роль такого элемента всегда одна и та же — служить буфером между внешними системами и внутренней бизнес-логикой. Очередь позволяет системе быстро принимать входящие сообщения, не выполняя сразу всю обработку, и затем обрабатывать их постепенно через фоновые задания. Такой буфер решает сразу несколько задач: сглаживает пики нагрузки, позволяет контролировать уровень параллелизма обработки и предотвращает ситуацию, когда поток интеграционных запросов начинает конкурировать с пользовательскими операциями за ресурсы базы данных.
Третьим важным принципом становится идемпотентность операций. В распределённых системах невозможно гарантировать, что сообщение будет доставлено ровно один раз. Сетевые ошибки, повторные запросы или сбои во внешних системах могут привести к повторной отправке данных. Поэтому архитектура интеграции должна изначально предполагать возможность безопасного повторного выполнения операции. Обычно это достигается за счёт использования уникальных идентификаторов сообщений или операций внешней системы. При получении сообщения система проверяет, обрабатывалось ли оно ранее, и если сообщение уже присутствует в системе, повторная обработка не выполняется. Такой механизм делает интеграцию устойчивой к повторной доставке сообщений и предотвращает появление дублирующих документов или операций.
Для интеграций, связанных с передачей больших объёмов информации, важным принципом становится порционная передача данных. Попытка передать большой объём информации одним запросом почти всегда приводит к росту времени выполнения операции и повышает риск таймаутов. Поэтому более устойчивой архитектурой является разделение обмена на небольшие диапазоны записей. Система формирует стабильный набор данных и предоставляет внешнему контуру возможность забирать его частями. Каждая операция передачи остаётся небольшой и быстро выполняемой, а внешний контур может постепенно обрабатывать данные, не создавая резких пиков нагрузки.
Наконец, архитектура интеграции должна предусматривать контроль состояния обмена. Система должна иметь возможность видеть весь жизненный цикл интеграционного сообщения: когда оно было получено, было ли успешно обработано, завершилась ли операция с ошибкой и требуется ли повторная обработка. Обычно для этого в очереди сообщений или регистре обмена хранится статус записи, а также информация о времени обработки, количестве попыток и результате выполнения. Такой механизм делает интеграцию наблюдаемой: администраторы и разработчики могут быстро определить, на каком этапе произошла ошибка, и повторно запустить обработку сообщений без потери данных.
Если объединить все эти элементы, формируется универсальный архитектурный контур интеграции. Внешняя система передаёт сообщение, интеграционный сервис фиксирует его в очереди и возвращает подтверждение приёма. Далее фоновый процесс выбирает сообщения из очереди, выполняет бизнес-операцию и фиксирует результат обработки. Для исходящих данных система формирует стабильный набор записей, который внешние системы могут забирать порциями, подтверждая успешную обработку диапазонов. Благодаря такой архитектуре интеграции перестают зависеть от времени выполнения бизнес-операций, становятся устойчивыми к росту нагрузки и могут безопасно обрабатывать большие объёмы данных без риска таймаутов и потери информации.
Вступайте в нашу телеграмм-группу Инфостарт
