Как вернуть ошибку из веб-сервиса 1С клиенту?

← На главную

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

Использование механизма SOAP Fault

Если ваша задача — соответствовать стандартам веб-сервисов, то самым прямым способом является генерация стандартного SOAP Fault. В платформе 1С для этого используется оператор ВызватьИсключение. Когда внутри функции веб-сервиса происходит исключительная ситуация, 1С автоматически упаковывает текст ошибки в стандартный ответ.

Рассмотрим, как это выглядит в коде:


Функция ПолучитьДоговор(КодДоговора)
    Если ПустаяСтрока(КодДоговора) Тогда
        ВызватьИсключение "Вы не можете передавать пустой код";
    КонецЕсли;

    // Логика получения данных
    Результат = НайтиДоговорВБазе(КодДоговора);
    Если Результат = Неопределено Тогда
        ВызватьИсключение "Код договора отсутствует в системе";
    КонецЕсли;

    Возврат Результат;
КонецФункции

Важно понимать: использование ВызватьИсключение приведет к тому, что клиентское приложение (будь то C#, Java или другая база 1С) получит стандартный SOAP-ответ с ошибкой. Однако стоит помнить, что 1С может дополнять текст ошибки информацией о модуле и строке кода, поэтому внутри сервиса рекомендуется перехватывать системные ошибки через Попытка...Исключение, чтобы возвращать клиенту только очищенный текст бизнес-ошибки.

Использование выходных параметров

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

Разберем логику такого подхода:

В структуре операции добавляем параметр КодОшибки или ОписаниеОшибки.
Если данные найдены, заполняем основной результат и оставляем параметр ошибки пустым.
Если данных нет, оставляем основной результат (например, base64Binary) пустым и заполняем описание ошибки.

Этот метод избавляет от необходимости парсить XML-тело Fault и делает процесс обработки предсказуемым.

Структурированный ответ через XDTO

Если ваш сервис сложный и требует передачи множества метаданных, оптимальным решением будет создание единого типа ответа, который всегда возвращается клиенту. Создайте в XDTO-пакете объект, содержащий поля:

Success (Boolean) — признак успешности операции.
ErrorMessage (String) — текст сообщения, если Success = Ложь.
Data (base64Binary) — сами бинарные данные, когда Success = Истина.

Такой подход является эталоном чистого проектирования API. Клиентское приложение сначала проверяет поле Success, и в зависимости от него либо забирает данные, либо выводит пользователю текст из ErrorMessage.

Заключение: что выбрать?

Проанализировав различные ситуации, мы можем сделать следующие выводы:

Если вам нужно быстрое решение, совместимое со стандартными механизмами интеграции — используйте ВызватьИсключение. Это позволит внешним системам автоматически распознать ошибку на уровне протокола.
Если важна чистота интеграции и вы проектируете крупное API — используйте типизированные структуры ответа через XDTO. Это позволит избежать лишней нагрузки на сеть и даст клиенту структурированную информацию об ошибке без необходимости обработки исключений.
Если есть возможность выбора технологии — рассмотрите переход на HTTP-сервисы. Они позволяют полноценно управлять HTTP-статусами (например, возвращать 404 для отсутствующих записей), что является современным стандартом для интеграций.

Помните, что выбор способа передачи ошибки зависит от того, насколько гибким должен быть ваш сервис для конечного разработчика, использующего его на стороне клиента.