Чтобы оставаться конкурентоспособным, бизнесу приходится осваивать новые каналы продаж. При этом e-commerce-процессы становятся все сложнее, и нередко возникают задачи, под которые не существует готовых решений. Одну из таких задач поставили перед нами — разработать интеграцию между сайтом комплексного поставщика офисных и бизнес-товаров «Комус» и NDA B2B-площадкой.

Ранее мы уже создавали для «Комуса» 1С-шину, которая обеспечивает интеграцию каталога компании с партнёрскими площадками — подробнее об этом можно прочитать здесь. Однако для новой задачи этот инструмент оказался непригоден: типы передаваемых данных и требования к их структуре на B2B-платформе существенно отличаются.

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

Почему нельзя просто взять и использовать единый набор API

Интегрируемый сервис — это B2B-площадка, где компании заказывают товары у подключенных поставщиков. В случае с «Комусом» заказ оформляется не на самой платформе: пользователей перенаправляют в личный кабинет на сайте komus.ru, а после оформления система автоматически возвращает их обратно на B2B-сервис.

Вся информация о заказе — его состав, сумма, статус и изменения — отображается уже на стороне партнёрской площадки. Поэтому необходимо было обеспечить корректную и стабильную передачу данных о созданных заказах и выставленных счетах с сайта «Комуса» на интегрируемую B2B-платформу.

Задача кажется простой:


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

Оптимальным решением стало создание микросервиса, который поэтапно собирает данные из разных источников, консолидирует и нормализует их, преобразуя в единый JSON-файл по требованиям площадки. Передача происходит практически в режиме реального времени.

Сложности реализации интеграции

1. Нетипичная защита пользовательских данных.
Заказчик заранее позаботился о безопасности персональных данных клиентов и реализовал собственную систему защиты. Это сделало использование стандартных методов REST API гораздо сложнее, чем, например, при интеграции 1С и Битрикс24. Кроме того, учетные данные пользователей должны оставаться зашифрованными и недоступными для просмотра в интерфейсе микросервиса.

2. Отсутствие прямого доступа к порталу-приемнику.
Передачу данных можно было тестировать только совместно с разработчиками B2B-площадки. Поэтому важно было заранее отловить большинство возможных ошибок аналитически и на этапе внутреннего тестирования, чтобы минимизировать участие внешних специалистов.

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

Почему выбрали 1С

В качестве платформы для разработки микросервиса выбрали 1С — и вот почему:

  1. Эффективная консолидация данных.
    1С позволяет собрать и объединить информацию из сайта заказчика, прокси- и почтовых серверов, а также из системы учета изменений заказов. Все данные приводятся к единому формату, устраняются дубли и противоречия, после чего сведения передаются на B2B-площадку.

  2. Полноценный документооборот.
    После нормализации данные автоматически «раскладываются» по документам внутри 1С, что обеспечивает прозрачный учет. Если в дальнейшем потребуется формировать финансовые отчеты или внедрить дополнительный контроль, доработка системы пройдет быстро и с минимальными затратами.

  3. Резервное хранение и надежное восстановление.
    Все обработанные данные сохраняются в базе микросервиса 1С. Это позволяет быстро восстановить информацию при утере данных в одном из источников и использовать те же сведения для аналитики и отчетности.

  4. Минимальные затраты на поддержку.
    Переобучение сотрудников не требуется — интерфейс 1С знаком операторам. Гибкая система прав доступа защищает пользовательские данные от несанкционированного просмотра и извлечения.

  5. Разделение логики и простота отладки.
    Все инструменты синхронизации данных сосредоточены в конфигурации 1С. Это позволяет быстро выявлять и устранять проблемы, а также вести удобное логирование. При этом процессы на стороне сайта заказчика остаются неизменными.

Выбранная архитектура упрощает сложные процессы, повышает устойчивость к ошибкам и делает систему легко адаптируемой под будущие изменения. 1С выступает не просто как инструмент интеграции, а как «мозговой центр», управляющий качеством и логикой данных. Использование встроенных объектов метаданных значительно снизило стоимость разработки по сравнению с реализацией прямой интеграции.

Архитектура и реализация 1С-микросервиса

Разработанный нами 1С-микросервис стал центральным элементом интеграции и отвечает за автоматизированный контроль качества данных. Он валидирует, объединяет и передает информацию, поступающую из четырех различных источников.

После того как заказ создаётся на сайте «Комус», сведения о нём автоматически попадают в 1С, где система инициирует формирование счёта на стороне сайта.

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

Затем микросервис нормализует объединенную информацию, формирует единый JSON-файл и отправляет его по API в базу данных B2B-площадки.

Если оператор вручную обновляет сведения о заказе — например, изменяет статус, — система фиксирует эти изменения, обновляет сводный JSON и повторно отправляет актуальные данные на партнёрскую площадку.

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

Кроме того, реализован двухуровневый механизм защиты от дублирования заказов. При получении файлов с сайта «Комус» микросервис сравнивает дату и точное время предыдущего обращения, добавляя таймштамп в параметры запроса. Затем выполняется дополнительная проверка внутри базы 1С. Благодаря этому дубли исключаются как в микросервисе, так и на принимающей B2B-площадке.


Выбранная архитектура не только закрыла текущие потребности, но и заложила фундамент для дальнейшего масштабирования. Микросервис не создает нагрузки на систему-источник и демонстрирует высокую пропускную способность. Благодаря чётко проработанному техническому заданию от заказчика, решение удалось реализовать с нуля всего за 176 часов — включая незапланированные правки. Прогноз из ТЗ полностью совпал с реальными сроками разработки.

Что помогло уложиться в сроки

1. Точные требования вместо «сделайте, чтобы работало».
Заказчик предоставил конкретные параметры API и четко описал логику работы микросервиса, что позволило избежать двусмысленных формулировок и постоянных уточнений.

2. Модульный подход.
Каждый компонент — парсинг почты, работа с прокси, авторизация на сайте, маппинг данных — проектировался как отдельный блок-конструктор, заранее спланированный для интеграции в общую систему.

3. Тестирование «на лету».
Мы не дожидались совместных сессий и проводили собственное тестирование, интерпретируя результаты и устраняя ошибки самостоятельно. К команде B2B-площадки обращались только в исключительных случаях.

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

1. «Предугадать ошибку — значит наполовину её устранить»

Совет: тестируйте даже те сценарии, которые, как кажется, никогда не произойдут. Они всё равно произойдут.

Как это помогло нам: аналитическое моделирование и разбор потенциальных ошибок до начала совместных тестов сократили время на поиск проблем примерно на 40% по сравнению с традиционным подходом.

2. «1С — это не просто учёт, а швейцарский нож»

Совет: максимально используйте встроенные механизмы платформы и проверенные временем библиотеки — например, регламентные задания и HTTP-коннектор. Это надёжно, быстро и экономит часы разработки.

Пример: авторизация на сайте заказчика реализована через Punch-out и требует нестандартных решений. В микросервисе мы использовали HTTP-коннектор 1С — он показал себя значительно эффективнее самописного соединения.

3. «Документация — как инструкция IKEA: если она есть, собрать можно даже без шестигранника»

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

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

4. «Интеграция — это марафон, а не спринт»

Совет: заранее закладывайте время на:
• нюансы работы с чужим API — процесс становится проще, если есть postman-коллекция рабочих запросов (в нашем случае это значительно ускорило интеграцию);
• обучение сотрудников — даже знакомая система вызывает вопросы при новых сценариях работы.

Итог: 176 часов включили не только чистое время разработки, но и запас на непредвиденные корректировки. Это позволило завершить проект без перерасхода ресурсов и с идеально предсказуемым результатом.

Несколько слов от заказчика

ИНТЕРВОЛГА предложила достаточно простое, но в то же время эффективное решение для нетривиальной задачи по интеграции с партнерской B2B-площадкой. Требовалось найти способ передавать разрозненные данные из одной системы в другую, делать это безопасно, без сбоев и вмешательства в работу обоих сайтов. Разработанный 1С-микросервис стабильно собирает информацию из разных источников, приводит ее к правильному виду и отправляет на портал — стабильно и практически в режиме realtime.

Отдельно хотим отметить четкое соблюдение дедлайна и понимание наших внутренних процессов. Решение не только закрывает текущие потребности, но и дает возможность развивать сервис. Спасибо ИНТЕРВОЛГЕ за профессиональный подход.

Вместо послесловия

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

Что дал бизнесу созданный 1С-микросервис:

  • стабильную и предсказуемую передачу данных без ручного контроля;

  • защиту информации от потерь и ошибок при сбоях;

  • возможность быстро адаптироваться к новым требованиям и изменениям бизнес-процессов.

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

Ваша задача тоже напоминает квест «Собери и отправь данные из нескольких источников, но ничего не сломай»? Заполните форму на сайте — наш эксперт свяжется с вами, и мы найдем правильное решение для вашего бизнеса.

Комментарии (3)


  1. mixsture
    17.10.2025 14:54

    Разработанный нами 1С-микросервис

    вот я бы поспорил с "микро".
    Во-первых, движок 1с довольно тяжелый сам по себе. А "микро" часто подразумевает очень быстрые ответы, с чем прям не очень.
    Во-вторых, под "микро" обычно подразумевают архитектуру, где каждая часть очень узконаправленна. А у вас тут явно объединены много функций.

    P.S. выбор 1с как инструмента интеграции странный. Тут же не видно классической предметной области, на которой 1с раскрывается: документы и аналитика над ними. В других языках есть куда более удобный инструментарий для работы с json/http и это намного легковеснее и без лицензий.


    1. ASenchenko
      17.10.2025 14:54

      Где-то вот здесь:

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

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


  1. ASenchenko
    17.10.2025 14:54

    Присоединюсь к предыдущему.

    Вы абсолютно зря назвали новую систему "микросервисом". Вы просто развернули отдельный B2B инстанс, интегрированный с остальными системами.

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

    Но это не "микро"