Короткий ответ: интеграцию сайта или CRM с 1С лучше проектировать не как один обмен, а как набор сценариев: заказ, клиент, остаток, цена, статус и документ. Для каждого сценария назначают источник данных, формат, частоту, правила повторной отправки и владельца ошибки.
Проблема начинается, когда экран рисуют раньше, чем договариваются о данных. Заказ уже виден на сайте, но неизвестно, кто назначает номер, что делать при таймауте 1С и как отличить повтор от нового заказа. Ниже — практическая схема для сайт и CRM.
Сначала опишите сквозные сценарии
Начните с пути пользователя: действие на сайте, запись в CRM, проверка и проведение в 1С, возврат статуса. Не переносите всю конфигурацию 1С в веб-систему. Опишите только данные и действия, которые нужны конкретному маршруту.
| Сценарий | Источник | Данные | Проверка |
|---|---|---|---|
| Заявка | Сайт/CRM | Контакт, состав, источник | Внешний id и отсутствие дубля |
| Заказ | Сайт до подтверждения, 1С после | Строки, цена, доставка | Повтор не создаёт второй заказ |
| Остаток | 1С | Товар, склад, дата | Понятна свежесть |
| Статус | 1С или процессный сервис | Код и отображение | Есть карта переходов |
До оценки полезно зафиксировать границы веб-разработки: что остаётся в 1С, что выполняется на сайте и где нужен промежуточный сервис.
Практичный первый шаг — разобрать один сквозной сценарий. Результатом должны быть карта данных, схема обмена и список неизвестных.
REST, HTTP-сервис или файл
Платформа 1С:Предприятие поддерживает REST-интерфейс прикладного решения, собственные HTTP-сервисы, JSON и файловый обмен. REST/OData удобен для согласованного доступа к объектам, собственный HTTP-сервис — для узкого прикладного контракта, файл — для редкого пакетного обмена. Выбор зависит от конфигурации, нагрузки, безопасности и владельца бизнес-логики.
| Подход | Уместен | Риск |
|---|---|---|
| REST/OData | Согласованный набор объектов | Сильная привязка к внутренней модели |
| HTTP-сервис | Заказ, статус, справочник | Нужна поддержка обработчиков |
| Файл | Ночной пакетный обмен | Задержка и сложнее повторы |
| Промежуточный сервис | Очереди и несколько систем | Новый компонент и ответственность |
Если пользователю нужен быстрый ответ, пакетный файл не заменит синхронный вызов. Если допустима задержка, не стоит связывать интерфейс с доступностью 1С.
Контракт данных важнее списка методов
Зафиксируйте обязательные поля, форматы дат, валюту, внешний идентификатор, пустые значения, удаление и версию контракта. Не отправляйте внутренние реквизиты 1С без проверки смысла: код, ссылка, номер и внешний id — разные сущности.
- ввести внешний id для каждой сущности;
- разделить справочники, команды и события;
- описать неизвестный статус и отмену;
- проверять бизнес-правила на обеих сторонах;
- не писать секреты и лишние персональные данные в логи.
Попросите пример успешного, пустого и ошибочного ответа: один happy path ещё не является готовой интеграцией.
Повторы и ошибки
Таймаут и временная недоступность можно повторить, а неверный товар, запрещённую операцию или конфликт статуса нужно передать на разбор. Нужны correlation id, внешний id, лимит повторов, задержка и безопасная идемпотентная обработка.
- сохранять путь сообщения;
- разделять временные и бизнесовые ошибки;
- не создавать дубль при повторе;
- показывать оператору следующий шаг;
- сверять ключевые заказы, суммы и статусы.
OWASP API Security Top 10 напоминает о рисках авторизации, чрезмерного доверия к внешним данным и небезопасного использования API. Ограничивайте ресурсы, проверяйте права и не публикуйте служебные методы наружу.
Синхронный обмен или очередь
Синхронный вызов удобен для мгновенной проверки, но связывает скорость интерфейса с 1С. Очередь полезна для повторной доставки и восстановления после сбоя. В интерфейсе важно различать «запрос принят» и «результат подтверждён».
| Проверка | Синхронно | Асинхронно |
|---|---|---|
| Ответ | Сразу или таймаут | Позже по состоянию |
| Сбой | Влияет на запрос | Задание остаётся |
| Повтор | Таймаут и idempotency key | Статус сообщения и попытки |
Приёмка интеграции
Проверьте успешный заказ, повтор, таймаут, неизвестную номенклатуру, изменение цены, отмену, права и ручную сверку. На каждый сценарий назначьте ожидаемое состояние сайта, CRM и 1С.
- описан маршрут от действия до записи;
- у сущностей есть внешний id;
- согласованы статусы, даты и суммы;
- есть журнал без секретов;
- есть инструкция запуска, отката и поддержки.
Что зафиксировать в техническом задании
В техническом задании отдельно зафиксируйте границы первой версии: какие объекты входят в обмен, какие операции выполняются автоматически, какие остаются ручными, кто видит ошибку и по какому признаку команда считает сценарий завершённым. Такой список помогает сравнить ожидания бизнеса с реальной архитектурой и не спрятать сложность интеграции за общим словом «синхронизация».
Полезно также записать ограничения: допустимую задержку, часы обслуживания 1С, максимальный размер пакета, требования к резервному ручному процессу и порядок изменения контракта. Если эти условия остаются «по умолчанию», они всё равно проявятся в эксплуатации — только уже как срочные исправления и спор о том, что именно считалось готовым.
Можно ли подключить сайт к 1С напрямую?
Решение зависит от сценария и конфигурации. Зафиксируйте источник истины, внешний id, права, повторы и ожидаемое состояние при ошибке. Сначала проверьте этот сценарий на одном реальном маршруте и зафиксируйте ожидаемый результат.
Как избежать дублей заказов?
Решение зависит от сценария и конфигурации. Зафиксируйте источник истины, внешний id, права, повторы и ожидаемое состояние при ошибке. Для предварительной оценки достаточно описать данные, роли и исключения без полной выгрузки системы.
Что подготовить до оценки интеграции?
Решение зависит от сценария и конфигурации. Зафиксируйте источник истины, внешний id, права, повторы и ожидаемое состояние при ошибке. Такой разбор лучше сохранить в техническом задании, чтобы команда одинаково понимала границы первой версии.
Нужен ли промежуточный сервис?
Решение зависит от сценария и конфигурации. Зафиксируйте источник истины, внешний id, права, повторы и ожидаемое состояние при ошибке. Эти условия стоит согласовать до разработки, а не переносить спор о них в момент приёмки.
Как принимать работу?
Решение зависит от сценария и конфигурации. Зафиксируйте источник истины, внешний id, права, повторы и ожидаемое состояние при ошибке. Если нужен разбор конкретного интеграционного контура, свяжитесь с Paladin Engineering.
Комментарии