Интеграцию 1С с веб-приложением строят одним из трёх способов: через HTTP-сервисы 1С (собственный REST API на стороне конфигурации), через файловый обмен по расписанию или через шину с очередями сообщений. Выбор зависит от требуемой свежести данных, объёма обмена и того, можно ли дорабатывать конфигурацию. Независимо от способа, надёжность определяют три проектных решения: контракт данных с устойчивыми идентификаторами (GUID, а не коды и наименования), идемпотентная обработка сообщений и журнал обмена, по которому видна каждая ошибка.
Для большинства компаний в Казахстане 1С — основной учётный контур: номенклатура, цены, остатки, взаиморасчёты, документы. Веб-приложение живёт по другую сторону: каталог, личный кабинет, заказы, онлайн-оплаты. Интеграция нужна, чтобы эти два мира не расходились и чтобы менеджеры не переносили данные руками.
Типовые сценарии обмена: номенклатура, цены и остатки уходят из 1С на сайт; заказы, клиенты и статусы оплат возвращаются из веб-приложения в 1С; взаиморасчёты и документы отгрузки показываются в личном кабинете. У каждого потока свои требования к скорости: остатки желательно обновлять за минуты, а взаиморасчёты обычно достаточно синхронизировать раз в сутки.
Первый проектный вопрос — не «какой протокол», а «кто источник истины по каждой сущности». Обычно номенклатура и цены принадлежат 1С, онлайн-заказы и регистрации клиентов — веб-приложению, а итоговые взаиморасчёты — снова 1С. Пока это не зафиксировано, обсуждать транспорт рано: конфликты записи с двух сторон разрушат любую схему обмена.
Технически обмен строится на одном из четырёх механизмов. Они отличаются скоростью доставки данных, требованиями к доработке конфигурации и устойчивостью к недоступности одной из сторон.
На практике способы часто комбинируют: справочники и остатки — файловой выгрузкой или OData по расписанию, а заказы и статусы — через HTTP-сервисы в близком к реальному времени режиме. Это нормальная архитектура, а не компромисс.
Универсального ответа нет — есть набор критериев, по которым способ выбирается за одну проектную сессию. Ошибка на этом шаге дорогая: миграция с файлового обмена на событийную шину означает переписывание обеих сторон интеграции.
Практическое правило: выбирайте простейший механизм, который закрывает требования к свежести данных. Обмен через очереди ради «остатков раз в час» — избыточная сложность, которую потом придётся сопровождать.
Контракт данных — это зафиксированный до начала разработки ответ на четыре вопроса: какие сущности участвуют в обмене, какими полями, кто по каждой из них главный и как сущности идентифицируются. Транспорт заменить можно, сломанный контракт — только мигрировать с болью на обеих сторонах.
Идентификаторы — главный пункт. Устойчив только GUID ссылки 1С: код элемента меняется при перенумерации справочника, наименование правят руками, артикул дублируется. Веб-приложение должно хранить таблицу соответствий «GUID 1С — внутренний id» и сопоставлять записи только по ней.
В обратную сторону работает то же правило: заказ из веб-приложения приходит в 1С с внешним ключом, и 1С хранит его в реквизите документа. Тогда повторная передача того же заказа находит существующий документ, а не создаёт дубль.
Состав полей делайте минимально достаточным. Выгрузка «всего объекта на всякий случай» связывает системы жёстче, чем нужно: любая доработка справочника в 1С начинает ломать парсер на стороне веб-приложения. Версионируйте контракт явно — полем версии в сообщении или версией в адресе HTTP-сервиса.
Большинство инцидентов в интеграциях с 1С повторяются из проекта в проект. Их стоит закрывать проектно, до первого запуска в прод, а не по факту разбора инцидентов.
Отдельно про идемпотентность: сеть ненадёжна, и любое сообщение однажды придёт дважды — после таймаута, повтора очереди или ручного перезапуска обмена. Обработчик обязан быть устроен так, чтобы повторная доставка не создавала второй заказ и не задваивала движение по регистру. Это свойство закладывается в контракт (внешний ключ у каждого сообщения) и проверяется в QA умышленной повторной отправкой.
Интеграция без наблюдаемости — это обмен, который «вроде работает», пока бухгалтерия не находит расхождение месячной давности. Минимальный производственный уровень: у каждого сообщения есть статус (принято, обработано, ошибка), тело сообщения сохраняется в журнале обмена, а ошибки видны в мониторинге, а не только в логах сервера.
Ошибки обрабатывайте повторными попытками с нарастающим интервалом, а сообщения, не прошедшие все попытки, складывайте в отдельную очередь разбора. Так временная недоступность 1С — обновление конфигурации, ночной бэкап — не превращается в потерянные заказы: обмен догоняет сам, когда база снова доступна.
Помимо потока событий нужна периодическая сверка: раз в сутки сравнивать контрольные показатели двух систем — количество заказов за день, суммы, число активных позиций каталога. Сверка ловит то, что не поймал журнал: сообщения, которые не были отправлены вовсе.
Информационную базу нельзя выставлять в интернет напрямую. Стандартная схема: публикация через веб-сервер, перед ним — обратный прокси или API-шлюз, наружу открыты только конкретные адреса HTTP-сервисов, всё остальное закрыто. HTTPS обязателен, доступ — по ключу или токену с ротацией.
Для обмена заводится отдельный пользователь 1С с минимальными правами: только те объекты и операции, которые нужны интеграции. Учётная запись администратора в настройках обмена — типовая находка аудита и прямой путь к утечке всей базы.
Если веб-приложение и сервер 1С находятся в контролируемых контурах, соединяйте их VPN-туннелем или ограничением по IP — тогда публичная поверхность атаки сводится к нулю. Это дешевле и надёжнее, чем защищать открытый порт.
Интеграция 1С с веб-приложением — это в первую очередь проектная работа, и только потом код. Последовательность, которая защищает от переделок, выглядит так.
Сроки и стоимость такой интеграции зависят от состояния конфигурации, числа потоков данных и требований к свежести — оценка формируется после брифа за 1–2 дня. Команда InterLAB в Алматы проектирует и разрабатывает такие обмены как часть услуги интеграции корпоративных систем: от контракта данных и доработок на стороне 1С до журнала обмена и мониторинга.
Расскажите о продукте или проблеме. Предложим архитектуру, срок и стоимость первой версии за 1–2 дня.