Как реализовать интеграцию с 1С?

Интеграция с 1С на практике сводится к выбору одного из штатных протоколов, доступных в платформе. Самый гибкий вариант — HTTP-сервисы (для предприятий 8.3 и выше) или внешние компоненты через COM. Я обычно отдаю предпочтение HTTP-сервисам, потому что это современный REST-подход без привязки к Windows, легко потребляется из любого языка.

Разберем шаги на примере обмена заказами. Сначала в конфигураторе 1С создаем HTTP-сервис с именем cmd и шаблоном URL /orders. В модуле обработки GET-запроса пишем код, который возвращает список заказов в JSON:

Процедура ОбработкаHTTP(Запрос, Ответ) Экспорт
    Если Запрос.Метод = "GET" Тогда
        МассивДанных = ПолучитьСписокЗаказов(); // логика выборки
        Ответ.УстановитьТелоИзСтроки(JSON(МассивДанных));
    ИначеЕсли Запрос.Метод = "POST" Тогда
        // создание заказа по телу запроса
    КонецЕсли;
КонецПроцедуры

Внешняя система (Python, Java, .NET) стучится по адресу http://server/cmd/orders, передавая аутентификацию (Basic Auth или токен). Обязательно настраиваем CORS, если интеграция идет из браузера.

Второй популярный вариант — OData. 1С умеет публиковать метаданные в OData-формате, это удобно для быстрой интеграции с Power BI или Excel. Но OData не подходит для сложных транзакционных сценариев, где нужно подтверждать действие на стороне 1С.

Третий способ — файловые обмены (XML/JSON через FTP/SFTP/общие папки). Его используют, когда есть строгие требования по разделению сред (offline-обмен). Например, раз в минуту фоновое задание 1С читает файл из папки, обрабатывает и пишет файл-ответ. Тут важна идемпотентность: каждый файл должен иметь уникальный идентификатор, чтобы повторная загрузка не привела к дублям.

Критические вещи, которые надо учитывать:

• Версионирование схем. Разные контуры (бухгалтерия, зарплата) часто работают на разных релизах 1С. Держите структуру JSON/XML в отдельном репозитории и заливайте изменения через тикет-систему, иначе поля начнут расходиться.
• Обработка ошибок в 1С. Любое исключение в HTTP-сервисе падает в общее исключение с кодом 500. Ловите их в коде и возвращайте осмысленный JSON с кодом ошибки и текстом. Иначе интегратор будет гадать, что пошло не так.
• Таймауты и повторы. В 1С по умолчанию таймауты довольно большие. Если внешняя система отвечает медленно, вешайте регламентное задание, которое запускается с интервалом, а не держите постоянное соединение.
• Логирование. Каждый обмен записывайте в регистр сведений: когда, кто, какой метод, тело запроса/ответа (без sensitive-данных). Это спасет при разборе инцидентов.

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

Резюме: для middle-разработчика нормальная реализация — HTTP-сервисы с осмысленными ошибками, идемпотентными POST-запросами и мониторингом. Остальное — вариации, которые выбираются под инфраструктуру.