Интеграция и взаимодействие 1С
О чём этот блок
Прикладное решение на 1С:Предприятие редко живёт изолированно — обмен с банками, маркетплейсами, сайтом, другой учётной системой или собственным микросервисом — обычная задача. Интеграция здесь — обмен данными и вызов операций с сохранением целостности учёта внутри информационной базы.
Эта статья — хаб: как выбрать механизм и куда перейти за деталями. Пошаговые материалы — в статьях 128–134, 135–137, 138–139, 1310.
Маршрут "Интернет и API"
| Шаг | Статья | Содержание |
|---|---|---|
| 1 | JSON в интеграции | Поток, коллекции, XDTO |
| 2 | HTTP-сервисы | Публикация своего REST API |
| 3 | HTTP-запросы | Вызов внешних API из BSL |
| 4 | OData | Стандартный REST к объектам конфигурации |
| 5 | Web-сервисы SOAP | WSDL, XDTO, URL ws/ |
| 6 | Сеансы интернет-сервисов | Пул сеансов, IBSession |
| 7 | FTP и почта | Транспорт файлов и писем |
Маршрут "Компоненты, COM и файлы"
| Шаг | Статья | Содержание |
|---|---|---|
| 1 | Внешние компоненты | Native API, ККТ, драйверы |
| 2 | Automation и внешнее соединение | COM, V83.ComConnector |
| 3 | XML и XDTO | Сериализация, ZIP, клиент↔сервер |
Обмен между базами — маршрут ниже (135–137).
Маршрут "Данные и обмен между базами"
| Шаг | Статья | Содержание |
|---|---|---|
| 1 | Внешние источники данных | ODBC, ВИД, запросы к сторонней СУБД |
| 2 | Планы обмена и РИБ | Узлы, сообщения, распределённая ИБ |
| 3 | Универсальный обмен | XML, транзакции, EnterpriseData |
Роли — кто кого вызывает
| Роль 1С | Что делает | Типичные средства |
|---|---|---|
| Клиент API | Запрашивает данные у внешней системы | HTTP-запросы, SOAP-клиент, FTP, файловый обмен |
| Поставщик API | Отдаёт данные и команды наружу | HTTP-сервис, OData, Web-сервис |
| Участник обмена | Синхронизирует две базы 1С | планы обмена, РИБ, EnterpriseData |
Код обмена обычно выполняется на сервере 1С (фоновые задания, регламентные задания, обработчики HTTP-сервиса). Длительный HTTP-запрос из формы пользователя блокирует сеанс — тяжёлые вызовы выносят в фон.
Хорошая инженерная привычка: проектировать интеграцию как контракт + журнал + повтор. Контракт описывает формат данных, журнал фиксирует факт обмена и статус, повтор закрывает временные сбои сети.
Карта "задача → механизм"
| Задача | Механизм | Статья |
|---|---|---|
| REST API под свою логику | HTTP-сервис | HTTP-сервисы 1С |
| REST к объектам конфигурации | OData | OData в 1С |
| Вызов чужого REST/JSON | HTTP-запрос + JSON | HTTP-запросы из 1С, JSON в интеграции 1С |
| Две базы, одна конфигурация | РИБ | Планы обмена и РИБ 1С |
| Разные конфигурации / не 1С | План обмена + XML | Универсальный обмен данными 1С |
| Чтение таблиц PostgreSQL/SQL Server | Внешний источник данных | Внешние источники данных 1С |
| ККТ, сканер, драйвер | Внешняя компонента | Внешние компоненты 1С |
| SOAP, WSDL | Web-сервис | Web-сервисы 1С (SOAP) |
| Excel-макрос, COM | Automation / COMConnector | Automation и внешнее соединение 1С |
| XML-пакет, архив | XDTO, файловый обмен | XML и XDTO в интеграции 1С |
| FTP, почта | FTPСоединение, ИнтернетПочта | FTP и электронная почта в 1С |
Файлы, XML и обмен между базами
| Способ | Когда уместен |
|---|---|
| XML / JSON / CSV | Выгрузка прайсов, актов, обмен с гос. форматами |
| XLSX, табличные документы | Отчёты для пользователей; импорт через табличный документ или внешние обработки |
| План обмена, РИБ | Две (и более) информационные базы 1С с правилами отбора и трансформации |
| EnterpriseData | Унифицированный обмен между типовыми и смежными решениями 1С |
Встроенного чтения YAML в платформе нет — YAML применяют только если его парсят отдельной библиотекой или на стороне внешней системы.
COM (Excel, Word) — в основном на клиенте Windows; на Linux-сервере полагаться на COM нельзя.
Внешние источники и компоненты
- Внешние источники данных — доступ к таблицам сторонней СУБД через ODBC/драйвер (аналитика, разовые загрузки).
- Внешние компоненты (Native API) — драйверы ККТ, сканеров, спец. протоколы; см. Внешние компоненты 1С.
- Интеграционная шина заказчика (ESB, Kafka и т.д.) — 1С выступает узлом — HTTP, файлы, сообщения; универсального коннектора "ко всем шинам" в платформе нет.
Собственная СУБД базы 1С в продакшене — обычно MS SQL Server или PostgreSQL; это штатное хранение данных приложения, а не интеграция с внешним миром.
Синхронный и отложенный обмен
Синхронно — пользователь или код ждёт ответ HTTP в том же сеансе. Подходит для коротких проверок (остаток, статус платежа).
Отложенно — регламентное задание или фоновое задание формирует пакет, пишет в регистр/очередь и отправляет позже. Так делают обмен с ФНС, выгрузку на маркетплейс, повтор при недоступности API. Пользователь видит статус в документе, а не "зависший" интерфейс.
Безопасность и эксплуатация
- HTTPS, сертификаты, Basic/Bearer-токены — в настройках соединения и заголовках
HTTPЗапрос(HTTP-запросы из 1С). - Электронная подпись — для юридически значимого обмена (банк, ЭДО, отчётность).
- Журнал регистрации и собственные регистры сведений — фиксация пакетов, статусов, тел ошибок.
- Тест на копии базы и тестовых ключах API; смена контракта внешней системы — отдельная версия обработки обмена.
Типичные ошибки внедрения
- Долгий HTTP в модуле формы — блокировка UI; перенос на сервер и фон.
- Нет идемпотентности — повторная отправка создаёт дубликаты документов; нужны ключи обмена и проверка "уже загружено".
- Разные модели данных — сопоставление через таблицу соответствий (GUID, артикул, ИНН), а не "на глаз" по наименованию.
- Игнорирование версий API маркетплейсов и банков — ломается после обновления контрагента.
Смежные темы: запросы и СУБД, ошибки и транзакции, первая программа.
Мини-чеклист перед запуском в прод
- Определён формат входящих и исходящих данных (JSON/XML, обязательные поля, версии).
- Добавлены таймауты и ограничение повторов.
- Есть идемпотентный ключ, чтобы повтор не создавал дубликаты.
- Логируются запрос, ответ, код состояния и контекст документа.
- Подготовлен сценарий ручного восстановления для ошибочных пакетов.
Практика 15 минут
Смоделируйте простой интеграционный контур по HTTP-запросы из 1С:
- Функция отправки
HTTPЗапросс таймаутом. - Проверка
КодСостояния. - Логирование статуса и текста ошибки в журнал регистрации.
- Возврат вызывающему коду понятного результата (
Истина/Ложьили структура статуса).
Проверка себя
- Где в вашем обмене обеспечивается идемпотентность?
- HTTP-сервис или OData — что выберете для витрины справочников?
- Как вы поймёте, что пакет "потерялся", а не просто задержался?
Базовый разбор HTTP и HTTPS — HTTP как основа веб-интеграций.
Протокол OData в общем виде — OData — протокол открытых данных.