Как лучше организовать взаимодействие веб-портала с базой 1С для обмена данными и управляющими сигналами?

← На главную

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

Основной подход: HTTP-сервисы в 1С

Если мы хотим быстро и гибко организовать взаимодействие, HTTP-сервисы в 1С представляют собой наиболее современный и рекомендуемый подход. Они позволяют нам превратить 1С в полноценный бэкенд-движок, способный обрабатывать входящие HTTP-запросы и самостоятельно формировать ответы.

Гибкость и простота: HTTP-сервисы дают нам полный контроль над форматом данных (JSON, XML, простой текст) и структурой запросов. Это делает их очень гибкими и удобными для интеграции с веб-порталами, написанными на различных технологиях (PHP, JavaScript).
Ориентация на ресурсы и функции: В отличие от традиционных Web-сервисов (SOAP), HTTP-сервисы часто используются для реализации RESTful API, где мы оперируем ресурсами (например, "заказ", "клиент") или вызываем конкретные функции, что идеально подходит для нашей задачи получения управляющего сигнала.
Легкость реализации в 1С: Мы создаем HTTP-сервис как объект конфигурации в 1С. В модуле этого сервиса мы описываем обработчики для различных HTTP-методов (GET, POST, PUT, DELETE), что позволяет нам легко реагировать на запросы с веб-портала.
Публикация: Для того чтобы наш HTTP-сервис стал доступен извне, мы публикуем информационную базу 1С на веб-сервере (Apache или IIS). При публикации 1С автоматически генерирует необходимые файлы для взаимодействия.

Рассмотрим сценарий для нашей задачи:

Наш веб-портал отправляет HTTP-запрос (например, POST или GET) на опубликованный HTTP-сервис 1С. В теле запроса или в параметрах URL мы можем передать управляющий сигнал.


// Пример обработчика в модуле HTTP-сервиса 1С
Процедура ОбработатьЗапрос(Запрос)
    // Получаем тело запроса, если данные передаются в JSON
    ТекстЗапроса = Запрос.ПолучитьТелоКакСтроку();
    ДанныеЗапроса = JSON.Прочитать(ТекстЗапроса); // Предполагаем JSON

    // Извлекаем управляющий сигнал
    УправляющийСигнал = ДанныеЗапроса.УправляющийСигнал;

    // Выполняем действия в 1С
    // Например, вызываем функцию, которая формирует текстовый файл
    ИмяФайла = УправлениеФайлами.СформироватьТекстовыйФайл(УправляющийСигнал);

    // Подготавливаем ответ для веб-портала
    Ответ = Новый HTTPСервисОтвет(200); // 200 OK
    ОтветДанные = Новый Структура;
    ОтветДанные.Вставить("Статус", "Успех");
    ОтветДанные.Вставить("Сообщение", "Файл сформирован: " + ИмяФайла);

    // Если нужно отправить файл обратно, то здесь мы можем читать его и возвращать в теле ответа
    // Например, закодированный в Base64 или как прямую отдачу файла

    JSONЗапись = Новый ЗаписьJSON;
    JSONЗапись.УстановитьСтроку();
    ЗаписатьJSON(JSONЗапись, ОтветДанные);
    Ответ.УстановитьТелоИзСтроки(JSONЗапись.Закрыть(), КодировкаТекста.UTF8, "application/json");

    Запрос.ОтправитьОтвет(Ответ);
КонецПроцедуры

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

Решение проблемы CORS (Cross-Origin Resource Sharing)

Когда веб-портал (например, работающий на домене portal.com) пытается обратиться к нашему HTTP-сервису 1С, опубликованному на другом домене или порту (например, 1c.mydomain.ru), браузер может заблокировать такой запрос из-за политики безопасности под названием CORS. Чтобы решить эту проблему, нам необходимо настроить веб-сервер (Apache или IIS), на котором опубликована база 1С, или сам HTTP-сервис 1С для отправки специальных HTTP-заголовков в ответе.

Как настроить CORS:

Настройка на веб-сервере (Apache/IIS): Мы можем добавить заголовки Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers в конфигурацию веб-сервера. Это позволит браузеру понять, что сервер 1С разрешает кросс-доменные запросы с нашего веб-портала.
Настройка в HTTP-сервисе 1С: Мы можем вручную добавить эти заголовки в объект HTTPСервисОтвет перед его отправкой. Это дает нам более гранулярный контроль над CORS для каждого сервиса.
Использование "прокладки" (proxy): Если настройка веб-сервера или самого 1С вызывает сложности, мы можем использовать прокси-скрипт (например, на PHP или Node.js) на том же домене, что и наш веб-портал. Веб-портал будет обращаться к этому прокси-скрипту, а скрипт, в свою очередь, будет перенаправлять запрос на 1С, а затем возвращать ответ порталу. Такой подход обходит ограничения CORS, так как для браузера запрос остается внутри одного домена.

Пример добавления заголовка в 1С:


// Внутри обработчика HTTP-сервиса
Ответ = Новый HTTPСервисОтвет(200);
// Разрешить запросы со всех доменов (для отладки, в продакшене лучше указывать конкретные домены)
Ответ.Заголовки.Вставить("Access-Control-Allow-Origin", "*"); 
// Разрешить конкретные методы
Ответ.Заголовки.Вставить("Access-Control-Allow-Methods", "GET, POST, OPTIONS");
// Разрешить конкретные заголовки
Ответ.Заголовки.Вставить("Access-Control-Allow-Headers", "Content-Type");
// И т.д. для других заголовков CORS
// ...
Запрос.ОтправитьОтвет(Ответ);

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

Альтернативный подход: Web-сервисы (SOAP)

Помимо HTTP-сервисов, мы можем использовать Web-сервисы, основанные на протоколе SOAP и формате XML. Это более формализованный подход, который имеет свои особенности:

Строгая типизация данных: Web-сервисы используют описание WSDL (Web Service Definition Language), которое точно определяет доступные методы, их параметры и типы возвращаемых значений. Это может быть полезно для автоматической генерации клиентского кода на стороне веб-портала.
Ориентация на "действия": Web-сервисы традиционно ориентированы на вызов удаленных процедур (RPC - Remote Procedure Call), что хорошо подходит для выполнения конкретных функций в 1С, таких как "сформировать файл".
Более "тяжеловесный" протокол: SOAP-сообщения обычно содержат много метаданных в формате XML, что делает их более объемными по сравнению с JSON в HTTP-сервисах. Это может влиять на производительность при больших объемах данных.

Когда использовать Web-сервисы (SOAP)?

Если нам требуется очень формализованный и строго типизированный обмен данными, где важна автоматическая генерация клиентского кода на основе WSDL, Web-сервисы могут быть хорошим выбором. Однако для простых управляющих сигналов и большинства современных интеграций HTTP-сервисы с JSON обычно оказываются более гибкими и легкими в реализации.

Доступ к данным 1С через OData (REST-интерфейс)

Начиная с версии 8.3.5, платформа 1С предоставляет встроенную поддержку протокола OData (Open Data Protocol). Это мощный REST-интерфейс, который позволяет нам получать и изменять данные информационной базы 1С без написания дополнительного кода в конфигурации.

Автоматическая публикация: При публикации информационной базы на веб-сервере мы можем активировать поддержку OData, и платформа 1С автоматически создаст REST-интерфейс для доступа к объектам метаданных (справочникам, документам, регистрам и т.д.).
Простота запросов: Мы можем использовать стандартные HTTP-методы (GET, POST, PUT, DELETE) и синтаксис OData-запросов (например, для фильтрации, сортировки, выбора полей) для взаимодействия с данными.
Форматы JSON и XML: OData поддерживает оба формата для обмена данными, что делает его удобным для различных клиентов.

Когда использовать OData?

OData идеально подходит, если наша основная задача — это чтение и запись данных прикладного решения из внешнего приложения, а не вызов специфических функций или бизнес-процессов. Например, для создания личного кабинета, интернет-магазина или другого портала, который напрямую работает с объектами 1С (заказы, товары, контрагенты). OData позволяет нам избежать написания большого количества кода для CRUD-операций (Create, Read, Update, Delete) в 1С.

Для нашей первоначальной задачи (получение управляющего сигнала и формирование файла), OData менее подходит, так как он ориентирован на работу с *данными* как сущностями, а не на вызов *процедур*. Однако для будущего двустороннего обмена данными OData может стать ценным инструментом, дополняющим HTTP-сервисы.

Не рекомендуемые, но возможные методы

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

Прямое обращение к MySQL

Теоретически, мы можем организовать прямое взаимодействие 1С с базой данных MySQL веб-портала или наоборот. В 1С для этого можно использовать ODBC-драйверы.

Ограничения и риски:

Обход бизнес-логики 1С: При прямом обращении к базе данных мы полностью обходим всю бизнес-логику, которая реализована в 1С (контроль остатков, проведение документов, расчеты и т.д.). Это может привести к неконсистентности данных и ошибкам.
Зависимость от структуры БД: Любые изменения в схеме базы данных MySQL (например, добавление или удаление полей, изменение типов) немедленно нарушат нашу интеграцию.
Безопасность: Мы вынуждены предоставлять прямой доступ к базе данных, что является менее безопасным, чем контролируемый доступ через сервисы 1С.
Производительность и блокировки: При некорректной работе с базой данных могут возникать проблемы с производительностью и блокировки.

Когда может быть использовано?

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

COM-объекты

COM-соединение (Component Object Model) позволяет взаимодействовать с 1С из других приложений в среде Windows. В 1С v8.3 для этого используется объект V83.COMConnector.

Почему не рекомендуется для веб-интеграций:

Ограничение на платформу: COM работает только в операционной системе Windows, что делает его непригодным для кросс-платформенных веб-серверов или облачных решений.
Устаревший метод: COM считается устаревшим методом для веб-интеграций. Современные подходы через HTTP-сервисы гораздо более предпочтительны.
Модуль внешнего соединения: При работе через COM используется не обычный модуль приложения конфигурации, а модуль внешнего соединения, что может накладывать ограничения на доступность некоторого функционала.
Лицензирование: Каждое активное COM-соединение с 1С потребляет лицензию, что может быть дорого при высокой нагрузке на веб-портал.

Хотя COM может быть полезен для локальных интеграций между приложениями Windows, для веб-портала мы однозначно похороним этот метод и не будем его использовать.

Обмен файлами через FTP/общие папки

Одним из простейших, но наименее эффективных методов является обмен файлами через FTP-сервер или общую сетевую папку. В этом случае, управляющий сигнал или данные записываются в файл, который затем периодически отслеживается другой системой.

Механизм:

Веб-портал записывает файл с управляющим сигналом на FTP или в общую папку. В 1С настраивается регламентное задание (или внешняя служба, например, через Cron), которое периодически проверяет наличие новых файлов в этой папке. При обнаружении файла, 1С обрабатывает его содержимое и выполняет необходимые действия.

Недостатки:

Задержки: Обмен не происходит мгновенно, поскольку требуется периодическая проверка наличия файлов. Это неприемлемо, если нужен мгновенный отклик на нажатие кнопки на портале.
Отсутствие "мгновенного" сигнала: Для нашей задачи получения *сигнала* этот метод не подходит, так как он работает по принципу "запроса-ответа" или "отслеживания", а не по принципу "мгновенного уведомления".
Сложность обработки ошибок: Отслеживание состояния обмена и обработка ошибок становятся значительно сложнее.

Общие рекомендации и лучшие практики

При организации взаимодействия между веб-порталом и 1С мы рекомендуем следовать следующим принципам:

Планирование двустороннего обмена: Даже если сейчас нам нужен только односторонний сигнал, мы сразу должны предусмотреть возможность полноценного двустороннего обмена информацией. HTTP-сервисы и OData отлично подходят для этой цели.
Использование расширений: Для типовых конфигураций мы всегда стараемся реализовывать всю интеграционную логику в расширениях. Это позволяет нам не снимать конфигурацию с поддержки и облегчает ее обновление.
Уникальные идентификаторы: Мы обязательно используем уникальные идентификаторы (например, GUID) для сопоставления сущностей между веб-порталом и 1С.
Идемпотентность операций: Наши операции должны быть идемпотентными, то есть повторный вызов одной и той же операции с теми же параметрами не должен приводить к изменению состояния системы после первого успешного выполнения. Это важно для надежности обмена.
Управление нагрузкой (очереди, пакеты): Если ожидается большой объем обмена данными, мы можем использовать механизмы очередей или передачу данных пакетами, чтобы не перегружать системы.
Логирование и мониторинг: Обязательно реализуем логирование всех операций обмена и настраиваем мониторинг для быстрого выявления и устранения проблем.
Безопасность: Мы обеспечиваем безопасность обмена данными, используя HTTPS, аутентификацию (например, базовую аутентификацию, токены), и разграничиваем права доступа к сервисам 1С.
1С в облаке (1С:Фреш): Если наша 1С работает в облаке (например, 1cfresh), мы используем предоставляемый им REST API интерфейс, который, как правило, основан на протоколе OData и HTTP-сервисах. Облачная инфраструктура уже содержит необходимые средства для интеграции.

Пример кода для вызова функции в 1С с веб-портала (на PHP):

Предположим, у нас есть HTTP-сервис 1С, опубликованный по адресу https://1c.mydomain.ru/ws/signal_service/signal_method, который ожидает JSON-данные.


<?php
// URL нашего HTTP-сервиса 1С
$url = 'https://1c.mydomain.ru/ws/signal_service/signal_method';

// Данные, которые мы отправляем в 1С
$data = array(
    'УправляющийСигнал' => 'ФормироватьОтчетПоПродажам',
    'Параметры' => array(
        'ДатаНачала' => '2023-01-01',
        'ДатаОкончания' => '2023-01-31'
    )
);

// Кодируем данные в JSON
$jsonData = json_encode($data);

// Инициализируем cURL-сессию
$ch = curl_init($url);

// Настраиваем cURL-запрос
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST"); // Метод запроса POST
curl_setopt($ch, CURLOPT_POSTFIELDS, $jsonData); // Отправляем JSON-данные
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); // Возвращать результат в виде строки
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
    'Content-Type: application/json',
    'Content-Length: ' . strlen($jsonData)
));

// Если 1С требует базовую аутентификацию
// curl_setopt($ch, CURLOPT_USERPWD, "ИмяПользователя1С:Пароль1С");

// Выполняем запрос
$response = curl_exec($ch);

// Проверяем на ошибки
if (curl_errno($ch)) {
    echo 'Ошибка cURL: ' . curl_error($ch);
} else {
    // Декодируем ответ от 1С (если он в JSON)
    $result = json_decode($response, true);
    echo "Ответ от 1С:<br>";
    print_r($result);
}

// Закрываем cURL-сессию
curl_close($ch);
?>

В этом примере PHP-скрипт отправляет HTTP POST-запрос с JSON-телом на HTTP-сервис 1С. 1С обрабатывает этот запрос, выполняет необходимые действия и возвращает ответ, также в формате JSON.

Заключение

Выбор оптимального метода интеграции веб-портала с 1С во многом зависит от наших конкретных задач и требований к обмену данными. Для современной, гибкой и масштабируемой интеграции мы однозначно рекомендуем использовать HTTP-сервисы в 1С, дополняя их OData-интерфейсом для работы с данными. Мы всегда помним о необходимости реализации в расширениях, настройке CORS и обеспечении безопасности, чтобы наша интеграция была надежной и эффективной.