Как исправить внутреннюю ошибку OData при записи в регистр сведений 1С?

← На главную

При работе с механизмом 1С OData программисты часто сталкиваются с малоинформативным сообщением: «Происходит внутренняя ошибка OData сервиса. Дополнительные сведения можно найти в технологическом журнале». Эта ошибка может возникать при выполнении POST или PATCH запросов, особенно если целевым объектом является независимый регистр сведений со сложной структурой измерений. В данной статье мы подробно разберем, как локализовать причину ошибки и правильно сформировать запрос для успешной записи данных.

Анализ чувствительности к регистру имен измерений

Первое, на что стоит обратить внимание — это строгое соответствие имен полей в запросе метаданным 1С. Рассмотрим ситуацию: если в конфигураторе измерение называется ФизЛицо, то в OData-запросе оно должно передаваться именно как ФизЛицо_Key. Использование варианта Физлицо_Key (с маленькой буквой «л») приведет к внутренней ошибке парсера.

Интересно, что требования к регистру у OData-интерфейса различаются для разных объектов: если реквизиты документов или справочников могут прощать ошибки в регистре, то измерения регистров сведений, формирующие ключ записи, требуют абсолютной точности. Проанализируем это поведение: платформа использует имена измерений для построения SQL-запроса к базе данных, и несоответствие имен приводит к невозможности сопоставить переданные данные со структурой таблицы.

Работа со ссылочными и составными типами: суффикс _Type

Одной из наиболее частых причин возникновения «Внутренней ошибки» является передача ссылочных данных без явного указания их типа. Когда мы записываем значение в измерение, имеющее тип «СправочникСсылка» или составной тип, недостаточно передать только GUID объекта. Рассмотрим правильный формат передачи данных в формате JSON:


{
    "Объект": "7f366b61-9eab-11e5-80c3-d485647b9a76",
    "Объект_Type": "StandardODATA.Catalog_ФизическиеЛица",
    "Вид": "10821bc3-f615-11df-8d81-003048dc4e8a",
    "Вид_Type": "StandardODATA.Catalog_ВидыКонтактнойИнформации",
    "Представление": "79022222222"
}

Разберем, почему это важно. Интерфейс OData в 1С требует явного указания метаданных для типов, которые не являются простыми (строка, число, булево). Суффикс _Type сообщает сервису, в какой таблице искать объект с указанным GUID. Если поле имеет составной тип и вы хотите записать в него пустое значение, используйте следующую конструкцию:


"ПолеСоставногоТипа": null,
"ПолеСоставногоТипа_Type": "StandardODATA.Undefined"

Особенности ключа записи регистра сведений

При работе с регистрами сведений важно помнить, что измерения образуют уникальный ключ записи. Рассмотрим особенности поведения платформы при попытке записи. Если вы пытаетесь изменить значение ресурса в уже существующей записи, вам следует использовать метод PATCH, обращаясь к конкретному ресурсу через ключ. Однако, если вы делаете POST запрос к сущности регистра, платформа пытается создать новую запись.

Выясним причину возможной ошибки 404 или 500 при POST запросе: если запись с таким набором измерений уже существует, платформа может выдать исключение. В таких случаях рекомендуется придерживаться следующего алгоритма:

Сначала выполнить DELETE запрос для удаления существующей записи по ее ключу.
Затем выполнить POST запрос для добавления новой записи.

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

Настройка технологического журнала для глубокой диагностики

Если визуальный анализ запроса не помогает, необходимо обратиться к технологическому журналу (ТЖ). Стандартных настроек ТЖ часто недостаточно, чтобы увидеть детали ошибки OData. Нам необходимо настроить файл logcfg.xml для сбора специфических событий.

Рассмотрим пример настройки logcfg.xml для отладки OData:


<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
  <log location="C:\Logs\OData" history="24">
    <event>
      <eq property="Name" value="SVROR"/>
    </event>
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <event>
      <eq property="Name" value="DBMSSQL"/>
    </event>
    <property name="All"/>
  </log>
</config>

Проанализируем эти события:

SVROR — это основной лог OData. Здесь фиксируются входящие запросы и ошибки их разбора.
EXCP — фиксирует все исключения, возникающие в процессе работы сервера.
DBMSSQL — позволит увидеть, не возникает ли ошибка на уровне СУБД (например, нарушение уникальности индекса), которая «маскируется» под внутреннюю ошибку сервиса.

Ошибки веб-сервера и форматирования данных

Иногда корень проблемы лежит за пределами кода 1С — в настройках публикации на веб-сервере (IIS или Apache). Разберем несколько критических моментов:

Кодировка и BOM: При отправке тела запроса в формате JSON убедитесь, что строка не содержит Byte Order Mark (BOM). Платформа 1С при чтении потока с BOM может выдать ошибку «Ошибка разбора XML» или «Attributes construct error», даже если вы передаете JSON. Используйте ИспользованиеByteOrderMark.НеИспользовать при формировании тела запроса.
Спецсимволы и пробелы: Лишние пробелы в именах полей или значениях могут привести к фатальной ошибке парсера. Тщательно проверяйте строку запроса перед отправкой.
Кэширование метаданных: Если вы недавно изменили состав регистра в конфигураторе, OData может работать по старой схеме. Помогает перезагрузка пула приложений в IIS или выполнение GET-запроса к /$metadata с заголовком Cache-Control: no-cache.

Комплексный пример кода для записи в регистр

Посмотрим на практический пример формирования POST запроса из самой 1С для записи в регистр сведений. Этот код учитывает необходимость типизации и корректную обработку соединения:


Соединение = Новый HTTPСоединение("myserver.com", , "odata_user", "password", , 30);

// Формируем структуру данных
Данные = Новый Структура;
Данные.Вставить("Физлицо", "abec57cb-3d10-11ef-ab92-00155d704702");
Данные.Вставить("Физлицо_Type", "StandardODATA.Catalog_ФизическиеЛица");
Данные.Вставить("Организация", "10821bc3-f615-11df-8d81-003048dc4e8a");
Данные.Вставить("Организация_Type", "StandardODATA.Catalog_Организации");
Данные.Вставить("НомерЛицевогоСчета", "123456789");

// Преобразуем в JSON
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, Данные);
СтрокаЗапроса = ЗаписьJSON.Закрыть();

// Подготовка и отправка запроса
ЗаголовокHTTP = Новый Соответствие;
ЗаголовокHTTP.Вставить("Content-Type", "application/json; charset=utf-8");

Запрос = Новый HTTPЗапрос("base_name/odata/standard.odata/InformationRegister_ЛицевыеСчетаРаботниковОрганизации", ЗаголовокHTTP);
Запрос.УстановитьТелоИзСтроки(СтрокаЗапроса, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать);

Ответ = Соединение.ВызватьHTTPМетод("POST", Запрос);

Если Ответ.КодСостояния <> 201 Тогда
    Сообщить("Ошибка: " + Ответ.ПолучитьТелоКакСтроку());
КонецЕсли;

В данном примере мы используем КодировкаТекста.UTF8 и явно отключаем BOM, что гарантирует корректное восприятие данных веб-сервером. Также обратите внимание на установку заголовка Content-Type, без которого сервер не поймет, как интерпретировать тело запроса.

Заключение

Для успешной борьбы с внутренними ошибками OData в 1С необходимо придерживаться системного подхода: проверять регистр имен полей, явно указывать типы для ссылочных данных через суффикс _Type и всегда иметь под рукой настроенный технологический журнал. Помните, что OData — это строгий протокол, который не прощает отклонений от структуры метаданных конфигурации.