Как исправить ошибку APLM0007 при работе с API системы Меркурий (ВетИС)

← На главную

При интеграции учётных систем на платформе 1С с государственной информационной системой «Меркурий» (ВетИС.API) разработчики часто сталкиваются с ошибками валидации XML-пакетов. Одной из самых коварных является ошибка с кодом APLM0007 («Wrong application data format»), которая возникает при выполнении операции GetVetDocumentByUuidOperation. В этой статье мы подробно разберем, почему возникает эта проблема и как правильно сформировать запрос, чтобы сервер принял данные.

Анализируем причину возникновения ошибки APLM0007

Рассмотрим ситуацию: при отправке запроса на получение ветеринарного сопроводительного документа (ВСД) по его уникальному идентификатору через сервис ApplicationManagementService, система возвращает статус REJECTED. В теле ответа содержится следующее сообщение:


<apl:error code="APLM0007">
    Wrong application data format. Format validation failed due to XML Schema rules: 
    Invalid text '32B7-51B0-1049-409A-B31A-D185-2342-142C' in element: 'uuid'
</apl:error>

Проанализируем этот текст. Система сообщает, что данные в элементе uuid не соответствуют правилам XML-схемы (XSD). На первый взгляд кажется, что идентификатор скопирован верно прямо из веб-интерфейса «Меркурия». Однако именно здесь кроется главная ловушка. В публичном веб-интерфейсе для удобства чтения UUID часто отображается с разделителями через каждые 4 символа, но программный интерфейс API требует строгого соблюдения международного стандарта RFC 4122.

Правильное форматирование UUID для ВетИС.API

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

Рассмотрим правильную маску UUID:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (группы по 8, 4, 4, 4 и 12 символов соответственно).

В исходном запросе автора примера использовался формат 32B7-51B0-1049-409A-B31A-D185-2342-142C. Посчитаем символы: группы разделены по 4 знака. Это и есть нарушение схемы. Чтобы исправить это, нам необходимо перегруппировать символы. Для значения из примера правильный вид будет таким: 32b751b0-1049-409a-b31a-d1852342142c.

Важность регистра символов (Case Sensitivity)

Посмотрим на ещё одну важную деталь, которую часто упускают программисты 1С. В спецификациях ВетИС.API для типов данных, описывающих идентификаторы (например, base:Identifier), используются регулярные выражения. Чаще всего они ожидают символы только в нижнем регистре (строчные буквы a-f).

Использование заглавных букв (например, 32B7...) вместо строчных (32b7...) может привести к тому, что парсер на стороне сервера отклонит запрос ещё на этапе первичной проверки синтаксиса. Поэтому перед подстановкой значения uuid в XML-пакет, обязательно применяйте функцию приведения к нижнему регистру (в 1С это функция НРег() или Lower()).

Разбираем корректную структуру SOAP-запроса

Теперь, когда мы выяснили правила форматирования идентификатора, составим правильный блок данных для операции GetVetDocumentByUuidRequest. Обратите внимание на использование пространств имен (namespaces) — они должны соответствовать версии API 2.1.


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
                  xmlns:apl="http://api.vetrf.ru/schema/cdm/application" 
                  xmlns:apldef="http://api.vetrf.ru/schema/cdm/application/ws-definitions" 
                  xmlns:merc="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2" 
                  xmlns:bs="http://api.vetrf.ru/schema/cdm/base" 
                  xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2" 
                  xmlns:vd="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
   <soapenv:Header/>
   <soapenv:Body>
      <apldef:submitApplicationRequest>
         <apldef:apiKey>ваш_апи_ключ</apldef:apiKey>
         <apl:application>
            <apl:serviceId>mercury-g2b.service:2.1</apl:serviceId>
            <apl:issuerId>ваш_issuerId</apl:issuerId>
            <apl:issueDate>2023-10-27T10:00:00</apl:issueDate>
            <apl:data>
               <merc:getVetDocumentByUuidRequest>
                  <merc:localTransactionId>TX12345</merc:localTransactionId>
                  <merc:initiator>
                     <vd:login>логин_пользователя</vd:login>
                  </merc:initiator>
                  <!-- Правильный формат UUID: 8-4-4-4-12 и нижний регистр -->
                  <bs:uuid>32b751b0-1049-409a-b31a-d1852342142c</bs:uuid>
                  <!-- Обязательно указываем GUID площадки -->
                  <dt:enterpriseGuid>84ae2b80-2aa3-40e7-8969-4d616d91c2a5</dt:enterpriseGuid>
               </merc:getVetDocumentByUuidRequest>
            </apl:data>
         </apl:application>
      </apldef:submitApplicationRequest>
   </soapenv:Body>
</soapenv:Envelope>

Нюансы поля enterpriseGuid и права доступа

Проанализируем ситуацию, которая может возникнуть после того, как вы исправите формат uuid. Ошибка APLM0007 исчезнет, но вы можете получить пустой ответ или сообщение об отсутствии прав доступа. Это связано с полем dt:enterpriseGuid.

Для успешного выполнения запроса необходимо соблюдать следующие условия:

Связь площадки и документа: В поле enterpriseGuid должен быть указан идентификатор предприятия, которое является отправителем, получателем или перевозчиком данного ВСД.
Права пользователя: Пользователь, чей vd:login указан в блоке initiator, должен иметь права на просмотр документов по указанной площадке в системе «Меркурий.ХС».
UUID vs GUID: Не путайте эти понятия. uuid — это идентификатор конкретной версии документа (транзакции), а guid — это неизменный идентификатор самого объекта ВСД. Операция GetVetDocumentByUuid ищет именно конкретную версию.

Алгоритм исправления ошибки в коде 1С

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


Функция НормализоватьUUID(Знач ИсходныйТекст)
    // Убираем все лишние символы, оставляем только цифры и буквы
    ЧистыйТекст = "";
    Для Сч = 1 По СтрДлина(ИсходныйТекст) Цикл
        Символ = Сред(ИсходныйТекст, Сч, 1);
        Если (Символ >= "0" И Символ <= "9") Или (НРег(Символ) >= "a" И НРег(Символ) <= "f") Тогда
            ЧистыйТекст = ЧистыйТекст + Символ;
        КонецЕсли;
    КонецЦикла;
    
    // Если получили 32 символа, расставляем дефисы по стандарту 8-4-4-4-12
    Если СтрДлина(ЧистыйТекст) = 32 Тогда
        Результат = Сред(ЧистыйТекст, 1, 8) + "-" +
                    Сред(ЧистыйТекст, 9, 4) + "-" +
                    Сред(ЧистыйТекст, 13, 4) + "-" +
                    Сред(ЧистыйТекст, 17, 4) + "-" +
                    Сред(ЧистыйТекст, 21, 12);
        Возврат НРег(Результат); // Возвращаем в нижнем регистре
    КонецЕсли;
    
    Возврат НРег(ИсходныйТекст);
КонецФункции

Подведем итог. Ошибка APLM0007 — это строгий сигнал от XML-валидатора сервера о несоответствии типов данных. Для успешной работы с API Меркурия всегда приводите все идентификаторы к нижнему регистру и следите за корректной расстановкой дефисов в соответствии со стандартом RFC 4122. Это сэкономит время при отладке интеграции и обеспечит стабильную передачу данных.