Микросервис на 1С для нетиповой интеграции сайта с B2B-сервисом

• Почему нельзя просто взять и использовать один набор API
• Выбор платформы для микросервиса
• Архитектура и реализация 1С-микросервиса
  • 1. «Предугадать ошибку — уже половина решения»
  • 2. «1С — это еще и швейцарский нож»
  • 3. «Документация — как инструкция IKEA: если она есть, собрать можно даже без шестигранника»
  • 4. «Интеграция — это марафон, а не спринт»
• Несколько слов от заказчика
• Вместо послесловия

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

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

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

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

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

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

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

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

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

Чем осложнялась реализация этой интеграции:

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

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

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

Выбор платформы для микросервиса

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

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

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

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

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

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

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

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

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

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

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

3. Полученный счет микросервис обрабатывает и обогащает данными из него сформированный заказ на сайте.

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

5. Когда оператор вручную вносит изменения в данные о заказе, например, меняет статус, микросервис обрабатывает эти данные и также обогащает ими сводный JSON. Система получает сигнал об изменениях и инициирует повторную отправку на B2B-площадку.

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

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

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

Что позволило уложиться в такие сроки:

• Четкие требования от заказчика, фраза «сделайте, чтобы все работало» была заменена на конкретные параметры API и логику работы микросервиса.

• Модульный подход: каждый компонент (парсинг почты, работа с прокси, авторизация на сайте, маппинг данных) разрабатывался как LEGO-блок — отдельно, но с пониманием, куда его потом прикрепить.

• Тестирование «на лету»: мы не ждали совместного тестирования, проводили собственные тесты и интерпретировали полученные результаты, лишь иногда обращаясь к коллегам на «той стороне».

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

1. «Предугадать ошибку — уже половина решения»

Совет: всегда тестируйте сценарии, которые «никогда не произойдут». Они обязательно произойдут.

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

2. «1С — это еще и швейцарский нож»

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

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

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

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

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

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

Совет: заложите время на:

• «танцы с бубном» вокруг чужого API. Процесс можно существенно упростить, если разработчики внешнего сервиса предоставят postman-коллекцию рабочих запросов, как это произошло в этом проекте.

• обучение сотрудников — даже самый простой интерфейс может вызвать вопросы.

Итог: 176 часов — это не только время на разработку, но и запас на «непредвиденное».

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

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

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

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

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

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

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

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

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

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

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