Ошибка при валидации xml

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

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

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

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

Не обязательно осуществлять валидацию сообщений в следующих случаях:

  1. Если сообщение передается от одного компонента к другому внутри композитного приложения, то необходимости валидации нет: это наше приложение, мы его полностью контролируем.
  2. Во внутренних сервисах или других контролируемых нами приложениях валидация обычно не требуется, но может быть реализована. В случае, если внутренний сервис осуществляет обработку данных, вводимых пользователями, то валидация необходима.

В данной заметке мы рассмотрим некоторые приемы валидации сообщений, а так же способы обработки ошибок, возникающих при проверке некорректных сообщений.

Валидация сообщений по схеме

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

Существует два подхода при описании контрактов сервисов:

  • строго-типизированный сервис;
  • слабо-типизированный сервис.

Рассмотрим особенности валидации по схеме при использовании каждого из данных подходов.

Строго-типизированный сервис

При использовании данного подхода мы подробно определяем все ограничения на каждый компонент структуры данных. Пример для пластиковой карты:

<xsd:complexType name=«tCreditCard»>

  <xsd:sequence>

    <xsd:element name=«cardType» type=«tCardType»/>

    <xsd:element name=«cardHolderName» type=«tCardHolderName»/>

    <xsd:element name=«cardNumber» type=«tCardNumber» />

    <xsd:element name=«expiryMonth» type=«tExpiryMonth»/>

    <xsd:element name=«expiryYear» type=«tExpiryYear»/>

    <xsd:element name=«securityNo» type=«tSecurityNo» />

  </xsd:sequence>

</xsd:complexType>

<xsd:simpleType name=«tCardType»>

  <xsd:restriction base=«xsd:string»>

    <xsd:enumeration value=«MasterCard»/>

    <xsd:enumeration value=«Visa»/>

   </xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name=«tCardHolderName»>

  <xsd:restriction base=«xsd:string»>

    <xsd:maxLength value=«32»/>

  </xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name=«tCardNumber»>

  <xsd:restriction base=«xsd:integer»>

    <xsd:pattern value=«[0-9]{16}»/>

  </xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name=«tExpiryMonth»>

  <xsd:restriction base=«xsd:integer»>

    <xsd:minInclusive value=«1»/>

    <xsd:maxInclusive value=«12»/>

  </xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name=«tExpiryYear»>

  <xsd:restriction base=«xsd:integer»>

    <xsd:minInclusive value=«2010»/>

    <xsd:maxInclusive value=«9999»/>

  </xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name=«tSecurityNo»>

  <xsd:restriction base=«xsd:integer»>

    <xsd:pattern value=«[0-9]{3}»/>

  </xsd:restriction>

</xsd:simpleType>

В данном примере мы проверяем следующие условия:

  • тип карты: Visa или MasterCard;
  • номер: 16 цифр;
  • месяц, до которого действует карта, от 1 до 12;
  • год, до которого действует карта, от 2010 до 9999;
  • код безопасности: 3 цифры.

Данный подход снижает масштабируемость, например, уже будет сложно добавить обработку карт American Express, т.к. такие карты имеют 15-значный номер и 4-х значный код безопасности. Так же каждый год придется обновлять ограничение на ExpiryYear, т.к. год должен находиться в будущем.

Слабо-типизированный сервис

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

Пример:

<xsd:complexType name=«tCreditCard»>

  <xsd:sequence>

    <xsd:element name=«cardType» type=«xsd:string»/>

    <xsd:element name=«cardHolderName» type=«xsd:string»/>

    <xsd:element name=«cardNumber» type=«xsd:integer»/>

    <xsd:element name=«expiryMonth» type=«xsd:integer»/>

    <xsd:element name=«expiryYear» type=«xsd:integer»/>

    <xsd:element name=«securityNo» type=«xsd:integer»/>

  </xsd:sequence>

</xsd:complexType>

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

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

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

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

Несколько советов при реализации валидации по схеме:

  • входящий документ нужно валидировать как можно раньше;
  • валидацию исходящего документа желательно разместить непосредственно перед вызовом внешнего сервиса;
  • если речь идет о валидации ответа от разрабатываемой системы, то нужно понимать, что если мы получили корректный входящий документ (а мы его валидировали) и у нас правильно реализована логика его обработки, то наш ответ так же должен быть корректным.

Использование Schematron для валидации

При использовании Schematron валидация осуществляется следующим образом: вводится ряд утверждений (assertions), если все они исполняются, то документ считается корректным. Утверждения вводятся с помощью XPath-выражений, что позволяет задавать условия, которые в принципе нельзя задать, используя схему, например:

  • если тип карты — American Express, то длина номера — 15 символов, иначе — 16;
  • если тип карты — American Exptess, то длина кода безопасности — 4 символа, иначе — 3;
  • дата окончания действия карты (месяц и год) должна быть больше текущей (т.е. в будущем).

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

Пример: проверка того, что тип карты указан как Visa или MasterCard:

<?xml version=«1.0» encoding=«UTF-8»?>

<schema xmlns=«http://www.ascc.net/xml/schematron»>

  <ns uri=«http://rubiconred.com/obay/ebm/UserAccount» prefix=«ebm»/>

  <ns uri=«http://rubiconred.com/obay/xsd/cmn» prefix=«cmn»/>

  <pattern name=«Check Credit Card Type»>

    <rule context=«/ebm:updateCreditCard/cmn:creditCard»>

      <assert test=«cmn:cardType=’MasterCard’ or cmn:cardType=’Visa’»>

        Credit Card must be MasterCard or Visa

      </assert>

    </rule>

  </pattern>

</schema>

Рассмотрим составные части Schematron-файла.

Утверждения (assertions) задаются в элементах assert. Важный атрибут утверждения — test — определяет XPath-выражение, которое может вернуть true или false. Если тестовое выражение возвращает true, то утверждение считается имеющим силу (met). Если возвращается false, то фиксируется ошибка валидации и содержимое элемента assert возвращается в качестве сообщения о данной ошибке.

Правила (rules). Утверждения определяются внутри правил. Правило содержит атрибут context, который включает в себя XPath-выражение, выбирающее узлы из валидируемого документа, к которым будут применяться утверждения. Для каждого узла будут применены правила, описанные в соответствующем элементе rule.

Пример:

<rule context=«/emb:updateCreditCard/cmn:creditCard»>

:

</rule>

в результате обработки выражения /emb:updateCreditCard/cmn:creditCard будет возвращен один единственный узел:

<cmn:creditCard>

  <cmn:cardType>MasterCard</cmn:cardType>

  <cmn:cardHolderName>John Smith</cmn:cardHolderName>

  <cmn:expiryMonth>10</cmn:expiryMonth>

  <cmn:expiryYear>2013</cmn:expiryYear>

  <cmn:securityNo>5285</cmn:securityNo>

</cmn:creditCard>

к которому и будет применено правило.

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

Можно использовать относительный контекст, например, мы хотим определить правило валидации кредитной карты, независимо от операции в которой карта используется. Для этого нужно определить правило с использованием XPath выражения, возвращающего creditCard независимо от операции, например так:

<rule context=«//cmn:creditCard»>

:

</rule>

Паттерны (patterns). Правила определяются внутри паттерна. Каждый паттерн содержит одно или более связанных правил. Элемент pattern содержит единственный атрибут — name, задающий в свободной форме описание правил, содержащихся внутри паттерна.

<pattern name=«Check Credit Card Type»>

:

</pattern>

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

Пространства имен (namespaces). Пространства имен описываются с помощью элемента ns. Элемент ns содержит два атрибута: uri — урл, задающий пространство имен и prefix — соответствующий префикс. Используются аналогично атрибуту xmlns схемы.

<ns uri=«http:// rubiconred.com/obay/xsd/cmn» prefix=«cmn»/>

Затем можно в правилах и утверждениях использовать префикс cmn.

Схема (schema) — корневой элемент для Schematron, определен в пространестве имен http://www.ascc.net/xml/schematron.

<?xml version=«1.0» encoding=«UTF-8»?>

<schema xmlns=«http://www.ascc.net/xml/schematron»>

:

</schema>

Примеры

Валидация в зависимости от содержимого нескольких полей:

<rule context=«cmn:CreditCard»>

  <assert test=«((cmn:cardType=’MasterCard’ or cmn:cardType=’Visa’) and

                string-length(cmn:cardNumber) = ’16’) or

                (cmn:cardType=’American Express’ and

                string-length(cmn:cardNumber) = ’15’)»>

     Invalid Card Number.

  </assert>

</rule>

Правило можно переписать красивее — использовать возможности XPath при определении правил:

<rule context=«cmn:creditCard[cmn:cardType=’MasterCard’]»>

  <assert test=«string-length(cmn:cardNumber) = ’16′»>

    Mastercard card number must be 16 digits.

  </assert>

  <assert test=«string-length(cmn:securityNo) = ‘3’»>

    Security code for Mastercard must be 3 digits.

  </assert>

</rule>

Можно использовать функции, появившиеся в XPath 2.0:

<ns uri=«http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20» prefix=«xp20»/>

<assert test=«xp20:matches(cmn:cardNumber, ‘[0-9]{16}’)»>

  Mastercard number must be 16 digits.

</assert>

Валидация дат. Пример проверки того, что указанная дата больше текущей:

cmn:expiryYear > xp20:year-from-dateTime(xp20:current-dateTime()) or

(cmn:expiryYear= xp20:year-from-dateTime(xp20:current-dateTime()) and

cmn:expiryMonth>=xp20:month-from-dateTime(xp20:current-dateTime()) )

Проверка на присутствие элемента:

<rule context=«//cmn:creditCard[cmn:cardType=’American Express’]»>

  <assert test=«cmn:securityNo»>

    Security No must be specified

  </assert>

</rule>

Проверка на присутствие элемента и, если он присутсвует, на исполнение каких-то правил:

<rule context=«//cmn:creditCard[cmn:cardType=’American Express’]»>

  <assert test=«cmn:securityNo and string-length(cmn:securityNo)>0″>

    Security No must be specified

  </assert>

</rule>

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

Пример возврата ошибки валидации с помощью Schematron:

<env:Fault>

  <faultcode>env:Server</faultcode>

  <faultstring>: Schematron validation fails with error

    <ns1:ValidationErrors>

      <error>Security code for Mastercard must be 3 digits.</error>

      <error>Credit Card has expired.</error>

    </ns1:ValidationErrors>

  </faultstring>

  <faultactor/>

  <detail>

    <exception/>

  </detail>

</env:Fault>

Использование бизнес-правил для валидации

Одним из методов реализации валидации является определение правил валидации как бизнес-правил. Это позволяет определить правила валидации один раз и затем использовать в нескольких сервисах. В свою очередь правила могут быть выставлены как веб-сервис, что позволяет легко использовать их из ESB или BPEL-процессов. Сами правила могут быть реализованы, например с помощью Oracle Business Rules, а для выставления их в качестве веб-сервиса может использоваться BPEL-обертка или соответствуюшее Java API.

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

Возврат ошибок валидации из синхронного сервиса

Необходим механизм возврата информации об ошибках валидации потребителям сервиса, желательно с подробной информацией о том, какое именно поле сообщения некорректно.

Для синхронного сервиса механизм возврата основан на использовании SOAP Fault. SOAP Fault содержит 4 раздела:

  1. faultcode: высокоуровневый указатель на причину ошибки. SOAP 1.1 определяет следующие faultcode:
    — VersionMistmatch,
    — MustUnderstand,
    — Client
    — Server.

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

  2. faultstring: должен содержать понятное человеку описание причины возникновения ошибки.
  3. faultactor: описывает в какой точке пути обработки сообщения произошла ошибка. Если ошибка происходит в конечной точке обработки сообщения, то значение данного параметра можно оставить пустым.
  4. detail: опциональный элемент, который используется для предоставления дополнительной информации об ошибке. Необходимо заполнять только если faultstring содержит не всю подробную информацию о причинах ошибки.

SOAP Fault’ы добавляются как дополнительные элементы fault в определение операции (элемент operation) WSDL-файла. Элемент fault имеет два атрибута: name — задает код ошибки и message — содержит дополнительную информацию об ошибке и возвращается внутри элемента soap:detail.

Пример:

<operation name=«updateCreditCard»>

  <input message=«tns:updateCreditCard»/>

  <output message=«tns:updateCreditCardResponse»/>

  <fault name=«tns:invalidCreditCard» message=«tns:invalidCreditCardFault»/>

</operation>

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

SOAP 1.1 допускает создание своих кодов ошибок реализуемое через т.н. dot-notation: client.invalidCreditCard в пространстве имен http://schemas.xmlsoap.org/soap/envelope/. Однако это ведет к колизиям и создает проблемы интероперабельности, следовательно не является совместимым с WS-I Basic Profile. Нужно избегать таких решений.

Вместо этого необходимо определять коды ошибок в своих собственных пространствах имен. Например, можно определить свой код ошибки invalidCreditCard в том же пространстве имен, что и сервис userManagement.

Важно: Хотя определение своих кодов ошибок в своих пространствах имен и является совместимым с WS-I Basic Profile, WS-I BP рекомендует использовать стандартные коды ошибок SOAP 1.1, а информацию о конкретной ошибке передавать в поле detail.

Возврат ошибок валидации из асинхронного сервиса

Асинхронный сервис не может ничего вернуть потребителю в ответе, т.к. взаимодействие с асинхронным сервисом строится на основе двух однонаправленных сообщений: первое содержит оригинальный запрос, второе — обратный вызов от сервиса, содержащий результат его работы.

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

В большинстве случаев можно считать наименование операции эквивалентом кода ошибки, а содержимое соответствующего сообщения может использоваться для передачи подробной информации об ошибке (например fault string и detail). Пример определения сервиса обработки кредитной карточки как асинхронного:

<porttype name=«UserAccount»>

  <operation name=«updateCreditCard»>

    <input message=«tns:updateCreditCard «/>

  </operation>

</portType>

<porttype name=«UserAccountCallback»>

  <operation name=«updateCreditCardCallback»>

    <input message=» tns:updateCreditCardCallback «/>

  </operation>

  <operation name=«invalidCreditCard»>

    <input message=«tns:invalidCreditCard»/>

  </operation>

</portType>

Соображения о многоуровневой валидации

При валидации существуют потенциальные проблемы, связанные с производительностью (очевидно, что процесс валидации требует времени), поэтому нужно внимательно прослеживать цепочки вызовов. Например, если мы используем сервис для валидации кредитных карт, а операция по карточке у нас проходит через цепочку сервисов, использующих данный сервис валидации, то получится, что он будет вызван N раз, хотя достаточно было бы одного раза.

Так же нужно внимательно управлять распространением ошибок и откатом транзакций (компенсациями). Например, в BPEL-процессе из сервиса A вызываютя сервисы B и C. Сервис B отработал корректно, а при вызове сервиса С произошла ошибка. В данном случае необходимо откатить изменения, сделанные в сервисе В.

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

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

Ресурсы

Статья написана на основе содержимого главы 13 — Building Validation Into Services книги Oracle SOA Suite Developer Guide.

Понравилось сообщение — подпишитесь на блог и Twitter

Источник

I have an xsd to validate an xml file, but I’m getting the error Invalid content was found starting with element 'user'. One of '{user}' is expected.

If I change the namespace declaration to xmlns:synchronisation="synchronisation" and put synchronisation:syncQueryMapping as the root tag, but keep the rest the same, it is validated, but I do not understand why this works, why it is necessary and why the rest of the tags don’t require it.

I can’t seem to understand & fix the issue, so any help would be greatly appreciated!

Thanks!

The xml file:

<?xml version="1.0" encoding="UTF-8"?>
<syncQueryMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="synchronisation"
    xsi:schemaLocation="synchronisation syncQueryMappingSchema.xsd">

    <user>
        <tableName></tableName>
        <nameColumn></nameColumn>
        <passwordColumn></passwordColumn>
    </user>
    <group>
        <tableName></tableName>
        <nameColumn></nameColumn>
    </group>
    <userGroupMapping>
        <tableName></tableName>
        <userNameColumn></userNameColumn>
        <groupNameColumn></groupNameColumn>
    </userGroupMapping>

</syncQueryMapping>

The xsd:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
    jaxb:version="1.0" targetNamespace="synchronisation" xmlns="synchronisation">

    <!-- JAXB Configuration -->
    <xs:annotation>
        <xs:appinfo>
            <jaxb:schemaBindings>
                <jaxb:package name="synchronisation.implementation" />
            </jaxb:schemaBindings>
        </xs:appinfo>
    </xs:annotation>

    <xs:complexType name="dbSyncUserType" >
        <xs:sequence>
            <xs:element type="xs:string" name="tableName" />
            <xs:element type="xs:string" name="nameColumn" />
            <xs:element type="xs:string" name="passwordColumn" />
            <xs:element type="xs:string" name="suspendStartDateColumn" minOccurs="0" />
            <xs:element type="xs:string" name="suspendEndDateColumn" minOccurs="0" />
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="dbSyncGroupType">
        <xs:sequence>
            <xs:element type="xs:string" name="tableName" />
            <xs:element type="xs:string" name="nameColumn" />
            <xs:element type="xs:string" name="typeColumn" minOccurs="0" />
            <xs:element type="typeColumnDataTypeType" name="typeColumnDataType" minOccurs="0" />
            <xs:element type="xs:string" name="typeValue" minOccurs="0" />
        </xs:sequence>
    </xs:complexType>

    <xs:simpleType name="typeColumnDataTypeType">
        <xs:restriction base="xs:string">
            <xs:enumeration value="INTEGER" />
            <xs:enumeration value="VARCHAR" />
        </xs:restriction>
    </xs:simpleType>

    <xs:complexType name="dbSyncUserTableJoinType">
        <xs:sequence>
            <xs:element type="xs:string" name="userKeyColumn" />
            <xs:element type="xs:string" name="mappingsForeignKeyColumn" />
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="dbSyncGroupTableJoinType">
        <xs:sequence>
            <xs:element type="xs:string" name="groupKeyColumn" />
            <xs:element type="xs:string" name="mappingsForeignKeyColumn" />
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="dbSyncUserGroupMappingJoinType">
        <xs:sequence>
            <xs:element type="dbSyncUserTableJoinType" name="userTable" />
            <xs:element type="dbSyncGroupTableJoinType" name="groupTable" />
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="dbSyncUserGroupMappingType">
        <xs:sequence>
            <xs:element type="xs:string" name="tableName" />
            <xs:element type="xs:string" name="userNameColumn" />
            <xs:element type="xs:string" name="groupNameColumn" />
            <xs:element type="dbSyncUserGroupMappingJoinType" name="join" minOccurs="0" />
        </xs:sequence>
    </xs:complexType>

    <!-- Root element -->
    <xs:element name="syncQueryMapping">
        <xs:complexType>
            <xs:sequence>
                <xs:element type="dbSyncUserType" name="user" />
                <xs:element type="dbSyncGroupType" name="group" />
                <xs:element type="dbSyncUserGroupMappingType" name="userGroupMapping" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>

asked Jan 21, 2013 at 10:08

m0rv4i's user avatar

m0rv4im0rv4i

4252 gold badges8 silver badges20 bronze badges

When you added xmlns="synchronisation" to your XML document you are specifying that all nested elements without a prefix belong to that namespace (syncQueryMapping and user).

<syncQueryMapping 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns="synchronisation"
    xsi:schemaLocation="synchronisation syncQueryMappingSchema.xsd">
    <user>
        ....

You need to add elementFormDefault="qualified" on the root element in your XML schema to indicate that all the elements in a XML document corresponding to this XML schema are namespace qualified.

<xs:schema 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
    jaxb:version="1.0" 
    targetNamespace="synchronisation" 
    xmlns="synchronisation"
    elementFormDefault="qualfied">

Without that specified in order for your XML document to be valid only the global elements should be namespace qualfied. This would mean you could not use a default namespace.

answered Jan 21, 2013 at 10:19

bdoughan's user avatar

bdoughanbdoughan

148k24 gold badges300 silver badges400 bronze badges

3

Источник

I have the following XML content:

<?xml version="1.0" encoding="UTF-8"?>
<success>
  <accessedResource>/bioportal/provisional</accessedResource>
  <accessDate>2013-04-23 20:50:58.139 PDT</accessDate>
  <data>
    <classBean>
      <id>http://purl.bioontology.org/ontology/provisional/9cc8b147-e193-4d23-a3a1-9da34eeeb5a9</id>
      <fullId>http://purl.bioontology.org/ontology/provisional/9cc8b147-e193-4d23-a3a1-9da34eeeb5a9</fullId>
      <label>OzbbBugGbIINcdpSY</label>
      <synonyms>
        <string>ux0fBN http://www.ggiodpc.com/www.6shpFpANPwYnffbs9P5rsRN67oJWDZuQ.com.php</string>
      </synonyms>
      <definitions>
        <string>ux0fBN http://www.ggiodpc.com/www.6shpFpANPwYnffbs9P5rsRN67oJWDZuQ.com.php</string>
      </definitions>
      <relations>
        <entry>
          <string>provisionalRelatedNoteId</string>
          <string>Note_3df7809d-aac8-4cf8-b320-f3eecceacd4e</string>
        </entry>
        <entry>
          <string>provisionalTermStatus</string>
          <null/>
        </entry>
        <entry>
          <string>provisionalCreated</string>
          <date>2013-04-09 20:06:23.79 PDT</date>
        </entry>
        <entry>
          <string>provisionalPermanentId</string>
          <null/>
        </entry>
        <entry>
          <string>provisionalRelatedOntologyIds</string>
          <list>
            <int>1057</int>
          </list>
        </entry>
        <entry>
          <string>provisionalSubmittedBy</string>
          <int>38382</int>
        </entry>
        <entry>
          <string>provisionalUpdated</string>
          <null/>
        </entry>
        <entry>
          <string>provisionalSubclassOf</string>
          <org.openrdf.model.URI>
            <uriString>http://purl.bioontology.org/ontology/RID/RID0</uriString>
            <localNameIdx>-1</localNameIdx>
          </org.openrdf.model.URI>
        </entry>
      </relations>
    </classBean>
  </data>
</success>

I want to validate it using the following XML Schema:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
           targetNamespace="http://bioontology.org/bioportal/classBeanSchema#"
           xmlns:c="http://bioontology.org/bioportal/classBeanSchema#">
    <xs:element name="success">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="c:accessedResource"/>
                <xs:element ref="c:accessDate"/>
                <xs:element ref="c:data"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <xs:element name="accessedResource" type="xs:string"/>
    <xs:element name="accessDate" type="xs:string"/>

    <xs:element name="data">
        <xs:complexType>
            <xs:all>
                <xs:element ref="c:list" minOccurs="0" maxOccurs="1"/>
                <xs:element ref="c:classBean" minOccurs="0" maxOccurs="1"/>
            </xs:all>
        </xs:complexType>
    </xs:element>
    <xs:element name="classBean">
        <xs:complexType>
            <xs:choice minOccurs="0" maxOccurs="unbounded">
                <xs:element ref="c:fullId" maxOccurs="1" minOccurs="0"/>
                <xs:element ref="c:id" maxOccurs="1" minOccurs="0"/>
                <xs:element ref="c:label" maxOccurs="1" minOccurs="0"/>
                <xs:element ref="c:relations" maxOccurs="1" minOccurs="0"/>
                <xs:element name="type" type="xs:string" maxOccurs="1" minOccurs="0"/>
            </xs:choice>
        </xs:complexType>
    </xs:element>

    <xs:element name="fullId" type="xs:string"/>
    <xs:element name="id" type="xs:string"/>
    <xs:element name="label" type="xs:string"/>

    <xs:element name="relations">
        <xs:complexType>
            <xs:sequence>
                <xs:element minOccurs="0" maxOccurs="unbounded" ref="c:entry"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

    <xs:element name="entry">
        <xs:complexType>
            <xs:sequence>
                <xs:choice minOccurs="0" maxOccurs="unbounded">
                    <xs:element name="string" type="xs:string"/>
                    <xs:element ref="c:list"/>
                </xs:choice>
                <xs:element minOccurs="0" ref="c:int"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

    <xs:element name="list">
        <xs:complexType>
            <xs:sequence>
                <xs:choice minOccurs="0" maxOccurs="unbounded">
                    <xs:element minOccurs="0" maxOccurs="unbounded" ref="c:classBean"/>
                    <xs:element minOccurs="0" maxOccurs="unbounded" name="string" type="xs:string"/>
                </xs:choice>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <xs:element name="int" type="xs:integer"/>

</xs:schema>

For the validation I use the following code snippet:

SchemaFactory schemaFactory =  SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema(schemaFile);
Validator validator = schema.newValidator();
validator.validate(xmlFile);

The following Exception is thrown, which indicates to me that the XML file is not valid given the Schema:

org.xml.sax.SAXParseException; systemId: file:/C:/xml.xml; lineNumber: 2; columnNumber: 10; cvc-elt.1: Cannot find the declaration of element 'success'.

I do not understand the message, since in line 2 i can find the ‘success’ element.
Can somebody help?

Источник

Ошибки валидации сайта — что это за ошибки и как их исправить

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

Валидация сайта

Но есть и другие факторы, которые могут и влияют на позиции сайта. И к ним относятся, в том числе, и технические факторы. Ну а к техническим относятся и валидация сайта. Так что же это такое?

Если простыми словами, то валидация сайта — это проверка кода сайта на техническое соответствие и ошибки. Ну например, вы забыли использовать закрывающий тег — /html. В последнем HTML5, визуально ничего не поменяется. Однако, это ошибка кода.

При написании кода, возможны и другие ошибки. И опять-таки, современный язык гипер разметки «стерпит» многое. Например, «забытие» закрывающего тега /head. И снова вы не увидите разницу. Но она есть))

Как оплатить услуги портала госзакупок Казахстана

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

В чем опасность?

Ну казалось-бы, ну и что тут такого? Да, нужно сказать, что зачастую такие ошибки не видимы. Точнее, невидимы человеком. А ведь страницы нашего сайта могут посетить не только люди, но и поисковые пауки, которые полностью просматривают сайт. И каждую ошибку, которую они находят на сайте, они передают на сервера поисковиков, таких как Яндекс или Гугл.

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

Да, надо признать, определенная пессимизация сайта из-за ошибок валидации, это довольно редкое явление. Но это вполне возможно, а значит, над валидацией обязательно нужно работать. А что для этого нужно сделать? Понятное дело, вначале ошибки нужно найти.

Но поскольку вручную это очень трудоёмкое и ненадежное дело, то для поиска ошибок, используются специальные сервисы, так называемые «Валидаторы».

Валидатор Markup Validation Service.

сервис Markup Validation Service

Этот сервис проверяет правильность кодов HTML и XHTML, которые являются основой большей части страниц при создании практически любого сайта и определяют его внутреннюю структуру. На этот сервис валидатора можно попасть, если пройти по ссылке http://validator.w3.org

Но здесь есть обязательное условие, которое также относится и к другим валидаторам: проверяемый сайт или его проверяемые страницы должны быть закачаны на хостинг. В противном случае, валидатор не будет «знать» адрес сайта и не сможет ничего проверить. Вот сейчас можно уже рассмотреть, как работать на этом валидаторе.

Ошибка при подключении к NCALayer. Убедитесь что программа NCALayer запущена — РЕШЕНИЕ В 2021 ГОДУ!

После захода на страницу этого сервиса, отобразиться вся его функциональная картинка. Но большая часть изображённого и написанного к основной проверке не относится и всё своё внимание надо обратить только на окно ввода адреса проверяемой страницы:

поле для ввода url

Вот именно с него и надо начинать.

Вообще-то, проверка валидации сайта чрезвычайно проста, как и весь наш бренный мир: в адресном окне сервиса надо написать адрес сайта, т.е. его URL и затем нажать «Check». После такого простого действия, валидатор «попыхтит» несколько секунд и выдаст следующее:

Валидатор не нашел ошибок в коде страницы

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

Но также может быть и такой нежелательный вариант:

предупреждение об ошибках в коде

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

Список ошибок найденных валидатором в коде страницы

Кроме того, валидатор не только перечислит найденные ошибки, но и точно покажет, на какой строке внутреннего кода эти ошибки расположены. Так что долго их искать не придётся. Здесь, ничего не преувеличивая, можно твёрдо сказать, что этот валидор работает прекрасно.

Но это ещё не всё: валидатор не только указывает местоположение обнаруженной ошибки кода, но и даёт достаточно полные рекомендации, каким образом можно устранить эти ошибки. Конечно, для этого не надо лениться и внимательно прочитать всё написанное.

В качестве краткого и обобщенного вывода, можно сказать следующее:

  1. данный сервис валидатора работает прекрасно и может очень быстро провести проверку сайта.
  2. Ну и небольшое, но очень приятное дополнение: валидация сайта производиться бесплатно.
  3. Сейчас можно перейти к следующему этапу: это проверка кода CSS.

Валидатор CSS Validation Service

CSS Validation Service

В общем это вторая функция вышеописанного сервиса, но она «заточена» не для проверки кода HTML и XHTML, а конкретно для проверки правильности кода стиля CSS, расположенного на внешней таблице. А чтобы попасть на страницу сервиса, надо пройти по ссылке http://jigsaw.w3.org/css-validator.

Кстати, здесь стоит отметить нечто приятное: проверка на этом сервисе абсолютно бесплатна. Так что не надо вытаскивать деньги из своего кошелька — пусть они лежат до нужного момента. Однако перейдём к методике работы на этом втором сервисе.

В общем-то вся работа на валидаторе CSS абсолютно идентична проверке на чистоту кода. Поэтому, приводить отдельную картинку адресной строки валидатора нет необходимости. Просто чуть ниже кратко рассмотрим непосредственно порядок самой проверки и всё.

Для этого надо в адресной строке записать URL таблицы CSS, типа «http://мой сайт/style.css» и после этого нажать кнопку с русской надписью «Проверить». Соответственно, этот валидатор тоже несколько секунд «попыхтит» и выдаст искомый результат:

ошибок в CSS не найдено

Это значит, что таблица CSS написана правильно и никаких ошибок в ней не обнаружено.

И здесь также есть приятная неожиданность: если прокрутить страницу несколько ниже, то там будет написан оптимизированный код для Вашей таблицы CSS, из которого убраны все лишние надписи и все теги кода будут расставлены в той последовательности, которая соответствует оптимальным рабочим требованиям всех поисковых систем. Остаётся только скопировать этот идеальный образец кода и вставить его в таблицу CSS.

Вполне может быть, что случиться и такой вариант:

Сервис валидации нашел ошибки в CSS

Это значит, что обнаружены какие-то ошибки в коде CSS, но пугаться этого совсем не стоит. Сразу внизу под этой красной строкой, валидатор точно укажет, какой тег написан неправильно. Остаётся только в таблице стиля найти эти теги и сделать нужные исправления.

подробная информация о найденных ошибках

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

Краткое резюме.

Выше были рассмотрены две самых основных и обязательных проверки валидации сайта. Без этих проверок даже не стоит открывать индексацию для поисковых систем в robots.txt В противном случае, сайт может быть проигнорирован для индексации поисковыми машинами и будет считаться неисправным с соответствующими санкциями.

Чтобы этого не произошло, надо затратить всего несколько минут, чтобы быть абсолютно спокойным и полностью уверенным в техническом состоянии своего сайта и всех его страниц. Конечно, необходимо ещё произвести дополнительные проверки ссылок и анкоров, видимости сайта на мобильных устройствах и параметры других кодов. Только тогда сайт можно считать готовым для его полного функционирования и для удачного и быстрого продвижению в ТОП.

Заранее хочется сказать, что все остальные проверки проходят также быстро и просто, как и рассмотренные выше — надо только внимательно прочитать порядок работы с валидатором.

Добавлено 19.04.2018г.

Распространенные ошибки валидности при проверке html кода

Решил дополнить статью ошибками HTML кода, которые часто встречаются на сайтах. Во всяком случае у меня их было много)). Сами ошибки валидатор подсвечивает желтым цветом.

1) Error: Character reference was not terminated by a semicolon.

1

Ошибка: символ не был прерван точкой с запятой — соответственно надо добавить.

2) Warning: Section lacks heading. Consider using h2-h6 elements to add identifying headings to all sections.

2

Предупреждение: Раздел не имеет заголовка. Рассмотрите возможность использования элементов h2-h6 для добавления идентифицирующих заголовков ко всем разделам. Тут все понятно, надо добавить хотя бы один подзаголовок. Это даже не ошибка, а рекомендация.

3) Error: Element noindex not allowed as child of element p in this context.

3

Ошибка: элемент noindex не разрешен как дочерний элемент элемента p в этом контексте. (Подавление дальнейших ошибок из этого поддерева.)
Решение простое, надо закомментировать тег ноиндекс, вид будет таким:

noindex

4) Error: The center element is obsolete.

4

Ошибка: тег «center» устарел — надо заменить, если речь про img то можно использовать атрибут align. Если что-то другое центрировали, то заменить на div.

5) An img element must have an alt attribute, except under certain

5

Ошибка: Элемент img должен иметь атрибут alt -тут все понятно, надо добавить атрибут альт, даже если он будет незаполненный, то ошибка уйдет.

6) The width attribute on the td element is obsolete. Use CSS instead.

Ошибка: Атрибут «width» на элементе «td» устарел

tab

7) The type attribute is unnecessary for javascript resources

6

Ошибка: атрибут type не нужен для ресурсов javascript. Решение просто удаляем все лишнее и оставляем только тег «script».

8) The align attribute on the img element is obsolete.

7

Ошибка: Атрибут align для элемента img устарел. Сделайте выравнивание изображений дивами.

9) Document type does not allow element «li» here; missing one of «ul», «ol», «menu», «dir» start-tag

Ошибка: Неправильное использование тега «li»: отсутствует тег «ul», «ol» . Нужно проверить вложенность элементов списка.

10) End tag for «div» omitted, but OMITTAG NO was specified

Ошибка: Не хватает закрывающего тега div. Решение — добавляем элемент

11) End tag for element «div» which is not open

Ошибка: закрывающий тег div лишний. Соответственно удаляем.

Жду ваших комментариев, а у вас на сайтах валидный код?

Источник: vachevskiy.ru

Что такое ошибки валидации и как их исправить: инструкция

Что такое ошибки валидации и как их исправить

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

Комплексный аудит сайта, что входит, как сделать

Ошибка валидации, что это такое?

Для написания страниц используется HTML – стандартизированный язык разметки, применяемый в веб-разработке. HTML, как любой другой язык, имеет специфические особенности синтаксиса, грамматики и т. д. Если во время написания кода правила не учитываются, то после запуска сайта будут появляться различные виды проблем. Если HTML-код ресурса не соответствует стандарту W3C, то он является невалидным, о чем мы писали выше.

Почему ошибки валидации сайта оказывают влияние на ранжирование, восприятие?

Наличие погрешностей в коде – проблема, с которой необходимо бороться сразу после обнаружения. Поисковые системы «читают» HTML-код, если он некорректный, то процесс индексации и ранжирования может быть затруднен. Поисковые роботы должны понимать, каким является ресурс, что он предлагает, какие запросы использует. Особо критичны такие ситуации для ресурсов, имеющих большое количество веб-страниц.

Как проверить ошибки валидации?

Как проверить ошибки валидации

Для этой работы используется либо технический аудит сайта, либо валидаторы, которые ищут проблемы автоматически. Одним из самых популярных является сервис The W3C Markup Validation Service, выполняющий сканирование с оглядкой на World Wide Web Consortium (W3C). Рассматриваемый валидатор предлагает три способа, с помощью которых можно осуществить проверку сайта:

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

После завершения проверки вы получите развернутый список выявленных проблем, дополненных описанием, ссылками на стандарты W3C. По ходу анализа вы увидите слабые места со ссылками на правила, что позволит самостоятельно исправить проблему.

Существуют другие сервисы, позволяющие выполнить проверку валидности кода:

  • Dr. Watson. Проверяет скорость загрузки страниц, орфографию, ссылки, а также исходный код;
  • InternetSupervision.com. Отслеживает производительность сайта, проверяет доступность HTML.

Плагины для браузеров, которые помогут найти ошибки в коде

Решить рассматриваемую задачу можно с помощью плагинов, адаптированных под конкретный браузер. Можно использовать следующие инструменты (бесплатные):

  • HTML Validator для браузера Firefox;
  • HTML Validator for Chrome;
  • Validate HTML для Firefox.

После проверки нужно решить, будете ли вы устранять выявленные ошибки. Многие эксперты акцентируют внимание на том, что поисковые системы сегодня уделяют больше внимания качеству внешней/внутренней оптимизации, контенту, другим характеристикам. Однако валидность нельзя оставлять без внимания, ведь если даже обнаруженные проблемы не будут мешать поисковым ботам, то они точно начнут раздражать посетителей сайта.

Как исправить ошибку валидации?

Как исправить ошибку валидации

В первую очередь нужно сосредоточить внимание на слабых местах, связанных с контентом – это то, что важно для поисковых систем. Если во время сканирования было выявлено более 25 проблем, то их нельзя игнорировать из-за ряда причин:

  • частичная индексация;
  • медленная загрузка;
  • баги, возникающие во время непосредственной коммуникации пользователя с ресурсом.

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

Технический и SEO-аудит

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

В заключение

На всех сайтах наблюдаются ошибки валидации – их невозможно искоренить полностью, но и оставлять без внимания не стоит. Например, если провести проверку сайтов Google или «Яндекс», то можно увидеть ошибки, однако это не означает, что стоит вздохнуть спокойно и закрыть глаза на происходящее. Владелец сайта должен ставить во главу угла комплексное развитие, при таком подходе ресурс будет наполняться, обновляться и «лечиться» своевременно. Если проблем мало, то можно попробовать устранить их своими силами или с помощью привлечения стороннего частного специалиста. В остальных случаях лучше заказать услугу у проверенного подрядчика.

Источник: vebrost.ru

Ошибка валидации

В этой теме 14 ответов, 5 участников, последнее обновление Андрей Ясевич 2 года/лет назад.

Просмотр 15 сообщений — с 1 по 15 (из 15 всего)
16.06.2019 в 17:03 #8028

  • Тема изменена 3 года/лет, 6 мес. назад пользователем ks2310.
Вложения:

You must be logged in to view attached files.
21.06.2019 в 10:04 #8086

Приложения в xml-схеме помечены как обязательные.

31.07.2019 в 11:09 #8480

Здравствуйте.
Образуем объект незавершенного строительства, состоящий из 6 контуров. Программа выдает ошибку:» учетный/порядковый номер контура» Подскажите, как исправить. Спасибо.

Вложения:

You must be logged in to view attached files.
31.07.2019 в 13:52 #8483

Обновите программу с сайта. Похоже, что данная ошибка уже была исправлена в программе.

11.08.2019 в 23:01 #8696

Добрый день!
Не проходит валидация xml в 06 версии. Ошибка в номере здания/контура.
В чем дело? не могу понять.

  • Ответ изменён 3 года/лет, 4 мес. назад пользователем margosay.
Вложения:

You must be logged in to view attached files.
12.08.2019 в 03:18 #8702

1. У вас номер образуемого здания проставлен. Номер проставляется либо кадастровый, либо если несколько зданий, то порядковый. Номер при образовании одного здания не проставляется.
2. Не указана система координат — она является обязательным атрибутом
3. Почему Вы делите здание на два отдельных контура? 2-й этаж здания это не контур. Читайте фз-218. Контур здания определяется как проекция на поверхность первого этажа всех внешних контуров верхних этажей. Контур здания делится, если у Вас два отдельных друг от друга контура.

В остальных случаях — фигура определяется проекцией с подписью этажности.
Надземный конструктивный элемент в виде например балконов не относится к отдельному контуру.
Надземный контур здания — это здание на колоннах, то есть первый этаж здания располагается выше уровня поверхности земли (под зданием — пустота, либо можно зарегистрировать другое здание, но это будет отдельный техплан).

12.08.2019 в 11:43 #8710

1.Не проходит ни с порядковым номером ни без него!
2. Насчет системы координат — ошибки не выходило при валидации. и что за новый формат СК? код субъекта и номер зоны..
3.В требованиях это написано и в разъяснениях Минэко. Что этажи — это контура

12.08.2019 в 12:11 #8711

Андрей, прошу поясните новшества в версии 6!
в сравнении с предыдущей — совершенно непонятно как работать в ней.

12.08.2019 в 17:44 #8716

Для этого откройте в программе справку (F1) и найдите раздел «Особенности формирования XML-файлов согласно схеме TP_v06». Там много чего разъяснено.

12.08.2019 в 22:32 #8722

Но мало что понятно.. к сожалению.
всегда читаю справку сначала.

13.08.2019 в 12:48 #8734

Тогда нужно присылать ваш xcn файл на почту с конкретным вопросом. Будем подсказывать.

12.02.2020 в 13:07 #12181

Добрый день.
Выдает ошибку при формировании конечного пакета. Ошибка возникает как при введенном порядковом номере сооружения (сооружение одно, номер 1), так и при оставлении поля пустым. Соответственно поле номеров контуров также выдает ошибку.
Прошу разобраться в ближайшее время.

Вложения:

You must be logged in to view attached files.
12.02.2020 в 15:23 #12185

План сооружения обязательный элемент в xml-файле согласно xml-схеме. Нужно хоть что-нибудь там привязать. Как правило, для сооружения можно повторить схему как план сооружения.

22.11.2020 в 14:39 #15008

Добрый день!
При формировании xml-файла технического плана на уточнение характеристик сооружения, состоящего из нескольких контуров программа выдает ошибку валидации: «Ошибка валидации, строка: 138, позиция: 24 —
У элемента Plans отсутствует дочерний элемент.
Путь, по которому в целевом файле выявлена ошибка: TP[1]/Construction[1]/Package[1]/ExistConstruction[1]/Plans[1]
Форма-таблица, которой соответствует ошибка: Сооружения/Cооружения(Constructions), запись(ряд) номер: 1». Прошу подсказать в чем ошибка и как правильно заполнить данные в программе. Файл техплана прилагаю.
Спасибо.

Вложения:

You must be logged in to view attached files.
23.11.2020 в 14:37 #15013

Планы (этажей/сооружения) для сооружений обязательный элемент, как и для зданий. Для сооружения можно еще раз привязать схему, если нету отдельных планов.

Просмотр 15 сообщений — с 1 по 15 (из 15 всего)

Для ответа в этой теме необходимо

Источник: ecp-shop.ru

Область применения электронной подписи (ЭП или ЭЦП) довольно широка. Например, многие специальные сервисы требуют верификации пользователя с её помощью: Госуслуги, онлайн-сервисы для управления средствами в банке, электронные площадки и другие. Поэтому любые технические неполадки, возникающие при использовании ЭЦП, могут вызвать различные серьёзные: от упущенной выгоды до материальных убытков.

Какие бывают ошибки

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

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

Рассмотрим неполадки подробнее и разберёмся, как их решать.

Сертификат не найден

Иногда при попытке подписать электронный документ с помощью ЭП пользователь может столкнуться с ошибкой «Не удалось найти ни одного сертификата, пригодного для создания подписи».

У подобных ошибок могут быть следующие причины:

  1. На компьютере не установлены корневые сертификаты Удостоверяющего Центра (УЦ), в котором была получена ЭП. Необходимо установить либо обновить корневой сертификат. Установка корневых сертификатов удостоверяющего центра подробно описана в нашей инструкции.
  2. На ПК не установлено ни одного личного сертификата ЭП. Для применения ЭП необходимы и личные сертификаты. Об их установке мы писали в другой статье.
  3. Установленные на компьютере необходимые сертификаты не валидны. Сертификаты отозваны или просрочены. Уточните статус сертификата в УЦ. Ошибка с текстом «Ваш сертификат ключа подписи включён в список отозванных» возникает, если у сертификата закончился срок действия или на ПК нужно обновить список сертификатов. В последней ситуации следует вручную загрузить перечень отозванных сертификатов.

Для установки списка отозванных сертификатов:

  • Откройте личный сертификат пользователя в окне Свойства браузера. Чтобы открыть его, наберите «Свойства браузера» в поисковой строке меню Пуск. Перейдите во вкладку Содержание и нажмите кнопку «Сертификаты».

    • личный сертификат1

  • Во вкладке Состав выберите из списка пункт «Точки распространения списков отзыва».
  • В блоке Имя точки распространения скопируйте ссылку на загрузку файла со списком отзыва.

    • Имя точки2

  • Скачайте по указанной ссылке файл. Нажмите по нему правой кнопкой мыши и выберите в контекстном меню «Установить список отзыва (CRL)».
  • Следуйте указаниям «Мастера импорта сертификатов».

Не виден сертификат на носителе

Как правило, причина такой проблемы — сбой в работе программных компонентов. Для её решения достаточно перезагрузить компьютер. Однако иногда этого бывает недостаточно, поэтому требуется переустановка драйверов или обращение в службу техподдержки.

К наиболее распространённым причинам такой проблемы относятся следующие случаи:

  1. Драйвер носителя не установлен или установлен некорректно. Для решения проблемы необходимо извлечь носитель электронной подписи из ПК и скачать последнюю версию драйвера носителя с официальных ресурсов. Если переустановка драйвера не помогла, подключите носитель к другому ПК, чтобы убедиться в исправности токена. Если токен определится другой системой, попробуйте удалить на неисправном компьютере драйвер носителя и установить его заново.
  2. Долгое опознание носителя. Для решения проблемы необходимо дождаться завершения процесса или обновить версию операционной системы.
  3. Некорректная работа USB-порта. Подключите токен к другому USB-порту, чтобы убедиться, что проблема не в носителе ЭП. Если система определила токен, перезагрузите компьютер. Если это не поможет, следует обратиться службу технической поддержки.
  4. Неисправность носителя. Если при подключении токена к другому компьютеру или USB-порту система не определяет его, значит, проблема в самом носителе. Устранение неисправности возможно в данном случае лишь одним путём — нужно обратиться в сервисный центр для выпуска нового носителя.

ЭП не подписывает документ

Причин у подобной проблемы множество. Каждый случай требует отдельной проверки. Среди самых распространённых можно выделить следующие неполадки:

  1. Закрытый ключ на используемом контейнере не соответствует открытому ключу сертификата. Возможно, был выбран не тот контейнер, поэтому следует проверить все закрытые контейнеры на компьютере. Если необходимый контейнер по тем или иным причинам отсутствует, владельцу придётся обращаться в удостоверяющий центр для перевыпуска ЭП.
  2. Ошибка «Сертификат недействителен» (certificate is not valid). Следует повторно установить сертификат ЭП по инструкциям УЦ в зависимости от используемого криптопровайдера — КриптоПро CSP, ViPNet CSP или другого.
  3. Сертификат ЭП определяется как непроверенный. В этом случае необходимо переустановить корневой сертификат удостоверяющего центра.
  4. Истёк срок действия криптопровайдера. Для решения этой проблемы необходим новый лицензионный ключ к программе-криптопровайдеру. Для его получения необходимо обращаться к специалистам УЦ или к ответственным сотрудникам своей организации.
  5. Подключён носитель с другим сертификатом. Убедитесь, что подключён правильный токен. Проверьте также, не подключены ли носители других сертификатов. Отключите другие носители в случае их обнаружения.

В момент подписания электронных документов или формирования запроса в различных может возникнуть ошибка «Невозможно создание объекта сервером программирования объектов».

подписания3

В этой ситуации помогает установка и регистрация библиотеки Capicom:

  1. Скачайте файл архива.
  2. Распакуйте и переместите файлы capicom.dll и capicom.inf в каталог syswow64, находящийся в корневой папке ОС.
  3. Откройте командную строку от имени администратора — для этого в меню Пуск наберите «Командная строка», нажмите по найденному приложению правой кнопкой мыши и выберите Запуск от имени администратора.

    4. «Командная строка»4

  4. Введите «c:windowssyswow64regsvr32.exe capicom.dll» (без кавычек) и нажмите ENTER. Должно появиться уведомление о том, что команда выполнена успешно.

    5. нажмите ENTER5

Выбранная подпись не авторизована

Подобная ошибка возникает при попытке авторизации в личном кабинете на электронных торговых площадках. Например, при входе на площадку ZakazRF отображается сообщение «Выбранная ЭЦП не авторизована».

площадку ZakazRF6

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

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

Часто задаваемые вопросы

Почему компьютер не видит ЭЦП?

Причина кроется в несовместимости программного обеспечения и физического носителя ЭЦП. Необходимо проверить версию операционной системы и переустановить её до нужной версии. Если токен повреждён, возможно, понадобится обратиться в удостоверяющий центр для перевыпуска электронной подписи.

О том, что делать, если компьютер не видит ЭЦП и о способах проверки настроек, мы подробно писали в нашей статье.

Почему КриптоПро не отображает ЭЦП?

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

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

Где на компьютере искать сертификаты ЭЦП?

Сертификат ЭЦП позволяет проверить подлинность подписи, содержит в себе срок её действия и информацию о владельце. Он автоматически загружается в папку с системными файлами. В операционной системе Windows от 7 версии и выше ЭЦП хранится по адресу:

C:UsersПОЛЬЗОВАТЕЛЬAppDataRoamingMicrosoftSystemCertificates. Вместо ПОЛЬЗОВАТЕЛЬ требуется указать наименование используемого компьютера.

Что такое сертификат ЭЦП и зачем он нужен мы рассказали в нашей статье.

Просмотров 1.9к. Опубликовано 19.12.2022
Обновлено 19.12.2022

Каждый сайт, который создает компания, должен отвечать принятым стандартам. В первую очередь затем, чтобы он попадал в поисковую выдачу и был удобен для пользователей. Если код страниц содержит ошибки, неточности, он становится “невалидным”, то есть не соответствующим требованиям. В результате интернет-ресурс не увидят пользователи или информация на нем будет отображаться некорректно. 

В этой статье рассмотрим, что такое валидность, какие могут быть ошибки в HTML-разметке и как их устранить.

Содержание

  1. Что такое HTML-ошибка валидации и зачем она нужна
  2. Чем опасны ошибки в разметке
  3. Как проверить ошибки валидации
  4. Предупреждения
  5. Ошибки
  6. Пример прохождения валидации для страницы сайта
  7. Как исправить ошибку валидации
  8. Плагины для браузеров, которые помогут найти ошибки в коде
  9. Коротко о главном

Что такое HTML-ошибка валидации и зачем она нужна

Под понятием  “валидация” подразумевается процесс онлайн-проверки HTML-кода страницы на соответствие стандартам w3c. Эти стандарты были разработаны Организацией всемирной паутины и стандартов качества разметки. Сама организация продвигает идею унификации сайтов по HTML-коду — чтобы каждому пользователю, вне зависимости от браузера или устройства, было удобно использовать ресурс.

Если код отвечает стандартам, то его называют валидным. Браузеры могут его прочитать, загрузить страницы, а поисковые системы легко находят страницу по соответствующему запросу. 

Чем опасны ошибки в разметке

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

К наиболее распространённым последствиям ошибок в коде HTML-разметки также относят сбои в нормальной работе сайта и помехи в продвижении ресурса в поисковых системах.

Рассмотрим несколько примеров, как ошибки могут проявляться при работе:

  • Медленно подгружается страница 

Согласно исследованию Unbounce, более четверти пользователей покидают страницу, если её загрузка занимает более 3 секунд, ещё треть  уходит после 6 секунд;

  • Не видна часть текстовых, фото и видео-блоков 

Эта проблема делает контент для пользователей неинформативным, поэтому они в большинстве случаев уходят со страницы, не досмотрев её до конца;

  • Страница может остаться не проиндексированной

Если поисковый робот распознает недочёт в разметке, он может пропустить страницу и прервать её размещение в поисковых системах;

  • Разное отображение страниц на разных устройствах

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

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

Как проверить ошибки валидации

Владельцы ресурсов используют 2 способа онлайн-проверки сайтов на наличие ошибок — технический аудит или использование валидаторов. 

Первый случай подходит для серьёзных проблем и масштабных сайтов. Валидаторами же пользуются ежедневно. Наиболее популярный — сервис The W3C Markup Validation Service. Он сканирует сайт и сравнивает код на соответствие стандартам W3C. Валидатор выдаёт 2 типа несоответствий разметки стандартам W3C: предупреждения и ошибки. 

Давайте рассмотрим каждый из типов чуть подробнее.

Предупреждения

Предупреждения отмечают незначительные проблемы, которые не влияют на работу ресурса. Они появляются из-за расхождений написания разметки со стандартами W3C. 

Тем не менее, предупреждения всё равно нужно устранять, так как из-за них сайт может работать медленнее — например, по сравнению с конкурентами с такими же сайтами.

Примером предупреждения может быть указание на отсутствие тега alt у изображения. 

Ошибки

Ошибки  —  это те проблемы, которые требуют обязательного устранения. 

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

Распространённым примером ошибки может быть отсутствие тега <!DOCTYPE html> в начале страницы, который помогает информации преобразоваться в разметку. 

Пример прохождения валидации для страницы сайта

Рассмотрим процесс валидации на примере сайта avavax.ru, который создали на WordPress.

пример ошибки валидации

В результате проверки валидатор выдал 17 замечаний. После анализа отчета их можно свести к 3 основным:

  1. атрибут ‘text/javascript’ не требуется при подключении скрипта;
  2. атрибут ‘text/css’ не требуется при подключении стиля;
  3. у одного из элементов section нет внутри заголовка h1-h6.

Первое и второе замечания генерирует сам движок WordPress, поэтому разработчикам не нужно их убирать. Третье же замечание предполагает, что каждый блок текста должен иметь заголовок, даже если это не всегда необходимо или видно для читателя. 

Решить проблемы с предупреждениями для стилей и скриптов можно через добавление кода в файл темы function.php.

Добавление кода в файл

Для этого на хук wp_loaded нужно повесить функцию output_buffer_start(), которая загрузит весь генерируемый код html в буфер. При выводе в буфер вызывается функция output_callback($tag), которая просматривает все теги, находит нежелательные атрибуты с помощью регулярных выражений и заменяет их пробелами. Затем на хук ‘shutdown вешается функция output_buffer_end(), которая возвращает обработанное содержимое буфера.

Для исправления семантики на сайте нужно использовать заголовки. Валидатор выдаёт предупреждение на секцию about, которая содержит фото и краткий текст. Валидатор требует, чтобы в каждой секции был заголовок. Для исправления предупреждения нужно добавить заголовок, но сделать это  так, чтобы его не было видно пользователям:

  1. Добавить заголовок в код:  <h3>Обо мне</h3>

Отключить отображение заголовка:

1 #about h3 {
2 display: none;
3 }

После этой части заголовок будет в коде, но валидатор его увидит, а посетитель — нет. 

За 3 действия удалось убрать все предупреждения, чтобы качество кода устроило валидатор. Это подтверждается зелёной строкой с надписью: “Document checking completed. No errors or warnings to show”.

Как исправить ошибку валидации

Всё зависит от того, какими техническими знаниями обладает владелец ресурса. Он может сделать это сам, вручную. Делать это нужно постепенно, разбирая ошибку за ошибкой. Но нужно понимать, что если при проверке валидатором было выявлено 100 проблем — все 100 нужно обязательно решить. 

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

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

Плагины для браузеров, которые помогут найти ошибки в коде

Для поиска ошибок валидации можно использовать и встроенные в браузеры плагины. Они помогут быстро находить неточности еще на этапе создания кода. 

Для каждого браузера есть свой адаптивный плагин:

  • HTML Validator для браузера Firefox;
  • HTML Validator for Chrome;
  • HTML5 Editor для Opera.

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

Коротко о главном

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

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

Работать необходимо сразу с двумя типами ошибок. Даже если предупреждение не приведет к неисправности сайта, оставлять без внимания проблемные блоки нельзя, так как это снизит привлекательность ресурса в глазах пользователя. Ошибки же могут привести к невозможности отображения блоков на сайте, понижению сайта в поисковой выдаче или полному игнорированию ресурса со стороны поискового бота.

Даже у крупных сайтов с миллионной аудиторией, например, Яндекс.Дзен или ВКонтакте, есть проблемы с кодом. Но комплексный подход к решению проблем помогает устранять серьёзные моменты своевременно. Нужно развивать сайт всесторонне, чтобы получить результат от его существования и поддержки. Если самостоятельно разобраться с проблемами не получается, не стоит “доламывать” — лучше обратиться за помощью к профессионалам, например, агентствам по веб-аудиту. 

Сведения приведены в документе Перечень типовых ошибок, возвращаемых участнику при работе в СМЭВ 3.0.

SMEV-100

1. Текст ошибки: Отсутствует ЭП-ОВ. 

Возникает на этапе проверки ЭЦП в рамках синхронной обработки xml-сообщения, принятого методом GetRequest, GetResponse, Ack.

Причина Пример
Запрос не подписан электронной подписью органа власти (ЭП-ОВ) (отсутствует или некорректно заполнен блок SenderInformationSystemSignature) 
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
     <soap:Body>
      <soap:Fault>
  <faultcode>soap:Server</faultcode>
       <faultstring>Отсутствует
  ЭП-ОВ</faultstring>
       <detail>
  <ns3:SignatureVerificationFault
  xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1"
  xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1"
  xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1">
  <Code>fed0:PRODUCTION_AREA:FED0_CORE2 :
  TR:SYNC:SPS:1</Code> 
  <Description>SMEV-100:Отсутствует
  ЭП-ОВ</Description>
  <ns3:SignatureVerificationFault>NoSignatureFound</ns3:SignatureVerificationFault>
  </ns3:SignatureVerificationFault>
       </detail>
      </soap:Fault>
     </soap:Body>
    </soap:Envelope>

Рекомендуется подписать сообщение ЭП-ОВ и повторить отправку. 

2. Текст ошибки: @signatureTypeAsString не соответствует подписанным данным.

Возникает на этапе проверки ЭЦП в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest, SendResponse.

 Причина  Пример
ЭП-СП не соответствует подписанным данным: данные изменены после подписания или допущены ошибки при формировании подписи 
<ns2:AsyncProcessingStatus>
<ns2:OriginalMessageId>0f952bd0-3868-11ea-b0b7-0050569445fb</ns2:OriginalMessageId>
<ns2:StatusCategory>requestIsRejectedBySmev</ns2:StatusCategory>
<ns2:StatusDetails>ЭП-СП не соответствует подписанным данным: ru.voskhod.crypto.exceptions.SignatureValidationException:
 Ошибка проверки ЭП: Нарушена целостность ЭП.</ns2:StatusDetails>
<ns2:SmevFault xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:type="ns3:SignatureVerificationFault">
<Code>fed0:P:FED0_ASYNC_CORE1:TR:ASYNC:SPS:2</Code>
<Description>SMEV-100:ЭП-СП не соответствует подписанным данным:
 ru.voskhod.crypto.exceptions.SignatureValidationException: Ошибка проверки ЭП: Нарушена целостность ЭП.</Description>
<ns3:SignatureVerificationFault>SignatureIsInvalid</ns3:SignatureVerificationFault></ns2:SmevFault>
</ns2:AsyncProcessingStatus>
ЭП-ОВ не соответствует подписанным данным: данные изменены после
подписания или допущены ошибки при формировании подписи 		 
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
       <soap:Body>
          <soap:Fault>
  <faultcode>soap:Server</faultcode>
             <faultstring>ЭП-ОВ не
  соответствует подписанным данным:
  ru.voskhod.crypto.exceptions.SignatureValidationException: Ошибка проверки
  ЭП: Нарушена целостность ЭП.</faultstring>
             <detail>
  <ns3:SignatureVerificationFault
  xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
  xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
  xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
  <Code>fed0:PRODUCTION_AREA:FED0_CORE1 :
  TR:SYNC:SPS:2</Code>
  <Description>SMEV-100:ЭП-ОВ не соответствует подписанным данным:
  ru.voskhod.crypto.exceptions.SignatureValidationException: Ошибка проверки
  ЭП: Нарушена целостность ЭП.</Description>
  <ns3:SignatureVerificationFault>SignatureIsInvalid</ns3:SignatureVerificationFault>
  </ns3:SignatureVerificationFault>
             </detail>
          </soap:Fault>
       </soap:Body>
    </soap:Envelope>

Рекомендуется проверить алгоритм подписи. Общая последовательность должна быть такой (на примере SendRequest):

  • каноникализация содержимого узла SenderProvidedRequestData;
  • нормализация;
  • расчет хэша;
  • формирование ЭП-ОВ:
    • запись cодержимого хэша в CallerInformationSystemSignatureSignatureSignedInfoDigestValue
    • каноникализация, нормализация элемента CallerInformationSystemSignatureSignatureSignedInfo
    • расчёт хэша элемента CallerInformationSystemSignatureSignatureSignedInfo
    • подпись хэша CallerInformationSystemSignatureSignatureSignedInfo
    • запись значения подписи в CallerInformationSystemSignatureSignatureSignatureValue
    • запись данных сертификата в CallerInformationSystemSignatureSignatureKeyInfoX509DataX509Certificate

3. Текст ошибки: Проверка подписи на вложении @id_вложения: @error.

Возникает на этапе проверки ЭЦП в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.

Причина  Пример
Неправильно подписано вложение или ошибка в структуре конверта СМЭВ 
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Body>
  <soap:Fault>
   <faultcode>soap:Server</faultcode>
   <faultstring>Проверка подписи на вложении zapros.jpg: Дайджест не прошел проверку!</faultstring>
   <detail>
    <ns3:SignatureVerificationFault 
xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2" 
xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2" 
xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
     <Code>fed0:PRODUCTION_AREA:FED0_CORE1 : TR:SYNC:SPS:7</Code>
     <Description>SMEV-100:Проверка подписи на вложении zapros.jpg:
 Дайджест не прошел проверку!</Description>
     <ns3:SignatureVerificationFault>SignatureIsInvalid</ns3:SignatureVerificationFault>
    </ns3:SignatureVerificationFault>
   </detail>
  </soap:Fault>
 </soap:Body>
</soap:Envelope>
 
 <ns2:AsyncProcessingStatus>
<ns2:OriginalMessageId>35861260-1599-11ea-b248-000c2904fa57</ns2:OriginalMessageId>
<ns2:StatusCategory>requestIsRejectedBySmev</ns2:StatusCategory>
<ns2:StatusDetails>Проверка подписи на вложении 35880e30-1599-11ea-b248-000c2904fa57:
 Дайджест не прошел проверку!</ns2:StatusDetails>
<ns2:SmevFault xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:type="ns3:SignatureVerificationFault">
<Code>tsmev3:P:TSMEV3_ASYNC_CORE2:TR:ASYNC:PP:SPS:7</Code>
<Description>SMEV-100:Проверка подписи на вложении 35880e30-1599-11ea-b248-000c2904fa57:
 Дайджест не прошел проверку!</Description>
<ns3:SignatureVerificationFault>SignatureIsInvalid</ns3:SignatureVerificationFault>
</ns2:SmevFault></ns2:AsyncProcessingStatus>

Рекомендуется проверить в каком формате электронная подпись добавлена в сообщение, а так же проверить структуру XML-сообщения на соответствие общим схемам СМЭВ с помощью инструмента «Проверки корректности xml-сообщения», размещенном на главной странице неавторизованной зоны ЛК УВ.

4. Текст ошибки: Проверка подписи на вложении @id_вложения: Ошибка получения дайджеста (OID) из подписи.

Возникает на этапе проверки подписи вложения на соответствие формату PKCS#7 в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.

 Причина Пример 
Подпись
вложенных файлов не удовлетворяет Профилю формата PKCS#7		 
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
     <soap:Body>
      <soap:Fault>
  <faultcode>soap:Server</faultcode>
       <faultstring>Проверка
  подписи на вложении zapros.jpg: Ошибка получения дайджеста (OID) из
  подписи.</faultstring>
       <detail>
  <ns3:SignatureVerificationFault
  xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
  xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
  xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
         <Code>tsmev3:PRODUCTION_AREA:TSMEV3_CORE2
  : TR:SYNC:SPS:8</Code>
  <Description>SMEV-100:Проверка подписи на вложении zapros.jpg:
  Ошибка получения дайджеста (OID) из подписи.</Description>
  <ns3:SignatureVerificationFault>SignatureIsInvalid</ns3:SignatureVerificationFault>
  </ns3:SignatureVerificationFault>
       </detail>
      </soap:Fault>
     </soap:Body>
    </soap:Envelope>

Рекомендуется проверить что подпись вложения удовлетворяет профилю формата PKCS#7 согласно п.6.3.1. Подписи в формате PKCS#7 и
Приложение В. Профиль формата PKCS#7, которому должны удовлетворять подписи вложенных файлов» Методических рекомендаций по работе с Единой системой межведомственного электронного взаимодействия.

5. Текст ошибки: Срок действия сертификата ЭП-* истёк. Сертификат действителен до @validUntil.

Возникает на этапе проверки ЭЦП в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest, SendResponse.







 Причина
 Пример




 Срок действия ЭП-ОВ истёк.
 <soap:Envelope xmlns:soap=»http://schemas.xmlsoap.org/soap/envelope/&quot;&gt;


 <soap:Body>
  <soap:Fault>
   <faultcode>soap:Server</faultcode>
   <faultstring>Срок действия сертификата ЭП-ОВ истёк. Сертификат действителен до 2014-12-03 12:21</faultstring>
   <detail>
    <ns3:SignatureVerificationFault 
xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1">
     <Code>fed0:PRODUCTION_AREA:FED0_CORE2 : TR:SYNC:SPS:4</Code>
     <Description>SMEV-100:Срок действия сертификата ЭП-ОВ истёк.
 Сертификат действителен до 2014-12-03 12:21</Description>
     <ns3:SignatureVerificationFault>CertificateIsExpired</ns3:SignatureVerificationFault>
    </ns3:SignatureVerificationFault>
   </detail>
  </soap:Fault>
 </soap:Body>
</soap:Envelope>






Срок действия ЭП-СП истёк.


<AsyncProcessingStatus><OriginalMessageId>4fd0f689-1d79-11e9-831b-00155d1c2b05</OriginalMessageId>
<StatusCategory>requestIsRejectedBySmev</StatusCategory>
<StatusDetails>Срок действия сертификата ЭП-СП истёк. Сертификат действителен до 2018-10-12 10:16</StatusDetails>
<SmevFault xsi:type="ns3:SignatureVerificationFault"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns2:Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:SPS:4</ns2:Code>
<ns2:Description>SMEV-100:Срок  действия сертификата ЭП-СП истёк. 
Сертификат действителен до 2018-10-12 10:16</ns2:Description>
<ns3:SignatureVerificationFault>CertificateIsExpired</ns3:SignatureVerificationFault>
</SmevFault></AsyncProcessingStatus>








Рекомендуется проверить сроки действия сертификата в блоке PersonalSignature.Заменить ЭП на действительную электронную подпись и повторить отправку сообщения.


6. Текст ошибки: Срок действия сертификата ЭП-* не начался. Сертификат действителен с @validSince


Возникает на этапе проверки ЭЦП в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest, SendResponse.






 Причина
 Пример




 Срок действия ЭП-ОВ не начался.
 <soap:Envelope xmlns:soap=»http://schemas.xmlsoap.org/soap/envelope/&quot;&gt;


 <soap:Body>
  <soap:Fault>
   <faultcode>soap:Server</faultcode>
   <faultstring>Срок действия сертификата ЭП-СП не начался. Сертификат действителен с 2022-06-01 09:00</faultstring>
   <detail>
    <ns3:SignatureVerificationFault

xmlns:ns3=»urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.3″


xmlns:ns2=»urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.3″

xmlns=»urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.3″>
     <Code>fed0:PRODUCTION_AREA:FED0_CORE2 : TR:SYNC:SPS:4</Code>
     <Description>SMEV-100:Срок действия сертификата ЭП-ОВ не начался.
 Сертификат действителен до 2014-12-03 12:21</Description>
     <ns3:SignatureVerificationFault>CertificateIsExpired</ns3:SignatureVerificationFault>
    </ns3:SignatureVerificationFault>
   </detail>
  </soap:Fault>
 </soap:Body>
</soap:Envelope>






Срок действия ЭП-СП не начался.


<AsyncProcessingStatus><OriginalMessageId>4fd0f689-1d79-11e9-831b-00155d1c2b05</OriginalMessageId>
<StatusCategory>requestIsRejectedBySmev</StatusCategory>
<StatusDetails>Срок действия сертификата ЭП-СП не начался. Сертификат действителен с 2022-06-01 09:00</StatusDetails>
<SmevFault xsi:type="ns3:SignatureVerificationFault"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns2:Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:SPS:4</ns2:Code>
<ns2:Description>SMEV-100:Срок  действия сертификата ЭП-СП не начался. 
Сертификат действителен до 2018-10-12 10:16</ns2:Description>
<ns3:SignatureVerificationFault>CertificateIsExpired</ns3:SignatureVerificationFault>
</SmevFault></AsyncProcessingStatus>









Рекомендуется обратиться в Удостоверяющий центр, выдавший сертификат.


7. Текст ошибки: Cертификат отозван. Код ответа в ГУЦ: @code


Возникает на этапе проверки сертификата ЭП-ОВ в ГУЦ в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest, SendResponse.






 Причина
 Пример




Возникла ошибка при проверке сертификата в ИС ГУЦ


<AsyncProcessingStatus><OriginalMessageId>03e1b072-1993-11e9-99c3-62fe784ec952</OriginalMessageId>
<StatusCategory>requestIsRejectedBySmev</StatusCategory>
<StatusDetails>Cертификат отозван. Код ответа в ГУЦ:14</StatusDetails>
<SmevFault xsi:type="ns3:SignatureVerificationFault" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns2:Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:GUTC:1</ns2:Code>
<ns2:Description>SMEV-100:Cертификат отозван. Код ответа в ГУЦ:14</ns2:Description>
<ns3:SignatureVerificationFault>CertificateIsExpired</ns3:SignatureVerificationFault>
</SmevFault></AsyncProcessingStatus>








Рекомендуется обратиться в Удостоверяющий центр, выдавший сертификат.


8. Текст ошибки: Технологический доступ к СМЭВ временно отозван в связи с нарушением установленного лимита обращений в систему.


Возникает на этапе проверки лимитов обращения к методам  Единого сервиса СМЭВ 3 в рамках синхронной обработки.






 Причина
 Пример




Превышены

допустимые лимиты по одному из методов Единого сервиса СМЭВ 3		


<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
       <soap:Body>
          <soap:Fault>
  <faultcode>soap:Server</faultcode>
  <faultstring>Технологический доступ к СМЭВ временно отозван, в
  связи с превышением норматива отправки сообщений в
  систему</faultstring>
             <detail>
  <ns3:SignatureVerificationFault
  xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
  xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
  xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
  <Code>LOCAL:DEV:localhost:TR:SYNC:RTR:1</Code>
  <Description>SMEV-100:Технологический доступ к СМЭВ временно
  отозван в связи с нарушением установленного лимита обращений в
  систему</Description>     
  <ns3:SignatureVerificationFault>SignatureIsInvalid</ns3:SignatureVerificationFault>
  </ns3:SignatureVerificationFault>
             </detail>
          </soap:Fault>
       </soap:Body>
    </soap:Envelope>








Рекомендуется Уменьшить интенсивность обращения к методам Единого сервиса СМЭВ 3 до рекомендованных. Значения лимитов по умолчанию зафиксированы в п. 5.4 Методических Рекомендаций СМЭВ.




SMEV-200





1. Текст ошибки: Превышен максимально допустимый суммарный размер присоединённых файлов и сообщения.




Возникает на этапе проверки размера сообщения в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse. 







 Причина


 Пример






Размер присоединённых файлов превысил 5 Мб при отправке через MTOM



<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
	<soap:Body>
	<soap:Fault>
	<faultcode>soap:Server</faultcode>
	<faultstring>Превышен максимально допустимый суммарный 
размер присоединённых файлов и сообщения.</faultstring>
	<detail>
	<ns3:AttachmentSizeLimitExceeded 
xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
	<Code>fed0:PRODUCTION_AREA:FED0_CORE2 : TR:SYNC:PP:2</Code>
	<Description>SMEV-200:Превышен максимально допустимый 
суммарный размер присоединённых файлов и сообщения.</Description>
	<ns3:PermittedTotalAttachmentSize>5242880</ns3:PermittedTotalAttachmentSize>
	<ns3:RealTotalAttachmentSize>6275349</ns3:RealTotalAttachmentSize>
	</ns3:AttachmentSizeLimitExceeded>
	</detail>
	</soap:Fault>
	</soap:Body>
	</soap:Envelope>









Рекомендуется проверить размер прикрепляемых файлов — суммарный размер вложений для передачи с помощью МТОМ с одним сообщением не должен превышать 5 Мб.




2. Текст ошибки: Количество ФТП-вложений превышает допустимое.




Возникает на этапе проверки количества ФТП-вложений в сообщении, принятого методом SendRequest либо SendResponse в рамках синхронной обработки.








 Причина


 Пример






Количество вложений в сообщении превысило лимит.




<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
	<soap:Body>
	<soap:Fault>
	<faultcode>soap:Server</faultcode>
	<faultstring>Количество ФТП-вложений превышает допустимое</faultstring>
	<detail>
	<ns3:AttachmentSizeLimitExceeded 
xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
	<Code>fed0:PRODUCTION_AREA:FED0_CORE2 : TR:SYNC:PP:2</Code>
	<Description>SMEV-200:Количество ФТП-вложений превышает допустимое</Description>
	<ns3:PermittedTotalAttachmentSize>10</ns3:PermittedTotalAttachmentSize>
	<ns3:RealTotalAttachmentSize>15</ns3:RealTotalAttachmentSize>
	</ns3:AttachmentSizeLimitExceeded>
	</detail>
	</soap:Fault>
	</soap:Body>
	</soap:Envelope>










Рекомендуется сократить количество вложений, передаваемых в сообщении, до разрешенного. Целевой лимит количества вложений указан в синхронном ответе в блоке PermittedTotalAttachmentSize.



SMEV-201





1. Текст ошибки: Некорректная информация о фтп вложениях; message id = @id_сообщения.




Возникает на этапе проверки файлов вложения в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse. 







 Причина


 Пример






1.Несоответствие заголовка и вложений

2. Вложение не загружено перед отправкой сообщения



<AsyncProcessingStatus>
	<OriginalMessageId>57a28db2-18d1-11e9-8037-0242ac110008</OriginalMessageId>
	<StatusCategory>requestIsRejectedBySmev</StatusCategory>
	<StatusDetails>Некорректная информация о фтп вложениях;
 message id = 57a28db2-18d1-11e9-8037-0242ac110008</StatusDetails>
	<SmevFault>
	<ns2:Code>LOCAL:P:localhost:TR:ASYNC:FS:2</ns2:Code>
	<ns2:Description>SMEV-201:Некорректная информация о фтп вложениях;
 message id = 57a28db2-18d1-11e9-8037-0242ac110008</ns2:Description>
	</SmevFault>
	</AsyncProcessingStatus>









Рекомендуется:


    

  • убедиться, что вложение было предварительно загружено на файловое хранилище СМЭВ;
    • 

  • проверить корректность указания в сообщении содержимого заголовка RefAttachmentHeader.
    • 




2. Текст ошибки: Ошибка СМЭВ. Обратитесь в службу технической поддержки.




Возникает на этапе проверки заголовков файлов вложения сообщения в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.







 Причина


 Пример






Несоответствие заголовка и вложений








<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
	<soap:Body>
		<soap:Fault>
		     <faultcode>soap:Server</faultcode>
		     <faultstring>Вложение [Id="otvet"] не имеет заголовка.</faultstring>
		     <detail>
		        <ns3:AttachmentContentMiscoordination
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2" xsi:type="SmevFault">
		         <Code>fed0:PRODUCTION_AREA:FED0_CORE2 : TR:SYNC:PP:4</Code>
		         <Description>SMEV-201:Ошибка СМЭВ. 
Обратитесь в службу технической поддержки.</Description>
		        </ns3:AttachmentContentMiscoordination>
		     </detail>
		</soap:Fault>
	</soap:Body>
</soap:Envelope>









Рекомендуется:





    

  • убедиться, что каждому AttachmentHeader в сообщении соответствует AttachmentContent;

    • 

  • убедиться, что количество заголовков равно количеству вложений;

    • 

  • убедиться, что содержимое элементов Id в AttachmentContent не дублируется».
    • 





SMEV-202





Текст ошибки: Квота на файловое хранилище для получателя превышена!

Возникает на этапе определения файловой квоты в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.








 Причина


 Пример






Закончился выделенный на файловом хранилище СМЭВ объем свободного места для ИС УВ-получателя сообщения с вложением в результате несвоевременного разбора входящей очереди сообщений. 






<AsyncProcessingStatus>
      <OriginalMessageId>54897fef-6bfc-11eb-ab7f-0a0027000002</OriginalMessageId>
      <StatusCategory>requestIsRejectedBySmev</StatusCategory>
      <StatusDetails>Квота на файловое хранилище для получателя превышена!</StatusDetails>
     <SmevFault xsi:type="ns3:QuoteLimitExceeded"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <ns2:Code>tsmev3:P:TSMEV3_ASYNC_CORE2:TR:ASYNC:PP:QT:1</ns2:Code>
 <ns2:Description>SMEV-202:Квота на файловое хранилище
 для получателя превышена!</ns2:Description>
 <ns3:RemainedTotalQuoteSize>3238634</ns3:RemainedTotalQuoteSize>
 <ns3:RealTotalAttachmentSize>12582912</ns3:RealTotalAttachmentSize>
      </SmevFault>
</AsyncProcessingStatus>









Рекомендуется повторить отправку сообщения с вложением через промежуток времени или обратиться к получателю сообщения через СЦ.



SMEV-206 







Текст ошибки: Количество символов в идентификаторе файла вложения превышает допустимое.


 Возникает на этапе валидации идентификатора файла вложения МТОМ в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.







 Причина


 Пример






Идентификатор файла МТОМ вложения, передаваемого в сообщении превышает 255 символов






<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
   <soap:Fault>
    <faultcode>soap:Server</faultcode>
    <faultstring>SMEV-206:Количество символов в идентификаторе
 файла вложения превышает допустимое</faultstring>
    <detail>
     <ns3:InvalidContent 
xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.3"
xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.3"
xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.3">
      <Code>CONNECTOR</Code>
      <Description>SMEV-206:Количество символов в идентификаторе файла
вложения превышает допустимое</Description>
     </ns3:InvalidContent>
    </detail>
   </soap:Fault>
  </soap:Body>
 </soap:Envelope>









Рекомендуется сформировать идентификаторы, передаваемые в тегах //AttachmentHeader/contentId и  //AttachmentContent/id, не превышающие размер в 255 символов.



SMEV-300





Текст ошибки: Недопустимый формат идентификатора сообщения. См. RFC-4122.




Возникает на этапе валидация идентификатора сообщения в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.







 Причина


 Пример






Формат идентификатора сообщения MessageID не соответствует стандарту RFC-4122.



<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
   <soap:Fault>
    <faultcode>soap:Server</faultcode>
    <faultstring>Недопустимый формат идентификатора сообщения. См. RFC-4122.</faultstring>
    <detail>
     <ns3:InvalidMessageIdFormat xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2" xsi:type="SmevFault">
      <Code>fed0:PRODUCTION_AREA:FED0_CORE1 : TR:SYNC:UNQ:1</Code>
      <Description>SMEV-300:Недопустимый формат идентификатора сообщения.
 См. RFC-4122.</Description>
     </ns3:InvalidMessageIdFormat>
    </detail>
   </soap:Fault>
  </soap:Body>
 </soap:Envelope>









Рекомендуется проверить корректность содержимого элемента MessageID. UUID необходимо генерировать по версии 1 (см. п. 4.2 «Algorithms for Creating a Time-Based UUID» RFC 4122 http://rfc.askapache.com/rfc4122/rfc4122.html#section-4.2). СМЭВ использует метку времени, содержащуюся в UUID, для проверки срока годности сообщения, к которому относится данный UUID. Для СМЭВ срок годности одного сообщения составляет 24 часа.



SMEV-301


Текст ошибки: Сообщение с идентификатором @messageId  было послано ранее.

Возникает на этапе валидации идентификатора сообщения в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.











 Причина


 Пример






Отправляется сообщение с MessageID, который уже отправлялся ранее.



<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
   <soap:Fault>
    <faultcode>soap:Server</faultcode>
    <faultstring>Сообщение с идентификатором 
23d023ab-20a0-11e9-a8e6-aaaaaa2cac00 было послано ранее.</faultstring>
    <detail>
     <ns3:MessageIsAlreadySent xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2" xsi:type="SmevFault">
      <Code>fed0:PRODUCTION_AREA:FED0_CORE1 : TR:SYNC:UNQ:3</Code>
	      <Description>SMEV-301:Сообщение с идентификатором
 23d023ab-20a0-11e9-a8e6-aaaaaa2cac00 было послано ранее.</Description>
     </ns3:MessageIsAlreadySent>
    </detail>
   </soap:Fault>
  </soap:Body>
 </soap:Envelope>











<AsyncProcessingStatus><OriginalMessageId>a95b71d6-1993-11e9-8758-3bde16b3418d</OriginalMessageId>
<StatusCategory>requestIsRejectedBySmev</StatusCategory>
<StatusDetails>Сообщение с идентификатором
 a95b71d6-1993-11e9-8758-3bde16b3418d было послано ранее.</StatusDetails>
<SmevFault><ns2:Code>LOCAL:P:localhost:TR:ASYNC:UNQ:3</ns2:Code>
<ns2:Description>SMEV-301:Сообщение с идентификатором 
a95b71d6-1993-11e9-8758-3bde16b3418d было послано ранее.</ns2:Description>
</SmevFault></AsyncProcessingStatus>









Рекомендуется сгенерировать новое значение для MessageID и повторить отправку.



SMEV-302





Текст ошибки: Timestamp идентификатора сообщения слишком давний.




Возникает на этапе валидации идентификатора сообщения в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.







 Причина


 Пример






Метка времени в идентификаторе сообщения MessageID более 24-х часов.



<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
   <soap:Fault>
    <faultcode>soap:Server</faultcode>
    <faultstring>Timestamp идентификатора сообщения слишком давний.</faultstring>
    <detail>
     <ns3:StaleMessageId xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1" 
xsi:type="SmevFault">
      <Code>fed0:PRODUCTION_AREA:FED0_CORE1 : TR:SYNC:UNQ:2</Code>
      <Description>SMEV-302:Timestamp идентификатора сообщения 
слишком давний.</Description>
     </ns3:StaleMessageId>
    </detail>
   </soap:Fault>
  </soap:Body>
 </soap:Envelope>









Рекомендуется проверить дату и время генерации метки времени. Сгенерировать MessageID с новой меткой времени.



SMEV-401





1. Текст ошибки: Не найден вид сведений.




Возникает на этапе проверки наличия вида сведений в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.











 Причина


 Пример






В блоке MessagePrimaryContent  указаны  корневой элемент или целевое пространство имен незарегистрированного в СМЭВ 3 Вида сведений или  текущее время отправления запроса не входит в срок действия ВС (с/по)


<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Body>
 <soap:Fault>
 <faultcode>soap:Server</faultcode>
 <faultstring>Не найден вид сведений.</faultstring>
 <detail>
 <ns3:BusinessDataTypeIsNotSupported
 xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
 <Code>fed0:PRODUCTION_AREA:FED0_CORE1 : TR:SYNC:BSV:1</Code>
 <Description>SMEV-401:Не найден вид сведений.</Description>
 <ns3:RootElementLocalName>DataRequestttttt</ns3:RootElementLocalName>
 <ns3:RootElementNamespaceURI>urn://qa/8.0.0</ns3:RootElementNamespaceURI>
 </ns3:BusinessDataTypeIsNotSupported>
 </detail>
 </soap:Fault>
 </soap:Body>
 </soap:Envelope>











 <st3:AsyncProcessingStatus>
      <st3:OriginalMessageId>18e1b148-00b4-11ec-914d-00059a3c7a00</st3:OriginalMessageId>
       <st3:StatusCategory>requestIsRejectedBySmev</st3:StatusCategory>
        <st3:StatusDetails>Не найден вид сведений</st3:StatusDetails>
	<st3:SmevFault xsi:type="sf3:BusinessDataTypeIsNotSupported"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<sb3:Code>PREPROCESSING</sb3:Code>
	<sb3:Description>SMEV-401: Не найден вид сведений.</sb3:Description>
	<sf3:RootElementLocalName>DataRequest22</sf3:RootElementLocalName>
	<sf3:RootElementNamespaceURI>urn://qa/1.0.0</sf3:RootElementNamespaceURI>
	</st3:SmevFault>
</st3:AsyncProcessingStatus>









Рекомендуется:



    

  •  определить контур СМЭВ, в который осуществляется обращение (разработческий, тестовый, продуктивный), для этого посмотреть вызываемый адрес сервиса и сопоставить с опубликованными в  Актуальных адресах СМЭВ3;
    • 

  •  найти на Технологическом портале зарегистрированный в соответствующем контуре(тестовом или продуктивном) Вид сведений. Сверить содержимое блока MessagePrimaryContent c эталонным сообщением, опубликованным в руководстве пользователя Вида сведений — проверить, правильно ли указаны корневой элемент и целевое пространство имен корневого элемента;
    • 

  •  проверить срок действия ВС в карточке.
    • 




2. Текст ошибки: Попытка отправить сообщение, не соответствующее типу вида сведений.




Возникает на этапе проверки наличия вида сведений в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.







 Причина


 Пример






В рамках метода SendRequest отправлено сообщение в блоке MessagePrimaryContent которого указан корневой элемент ответа или для сообщения, отправляемого по методу SendResponse, указан корневой элемент запроса.



<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
   <soap:Fault>
    <faultcode>soap:Server</faultcode>
    <faultstring>Попытка послать сообщение {urn://qa/8.0.0}DataRequest через метод sendResponse,
 в то время как этот тип сообщений зарегистрирован как REQUEST</faultstring>
    <detail>
     <ns3:BusinessDataTypeIsNotSupported
 xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
      <Code>fed0:PRODUCTION_AREA:FED0_CORE2 : TR:SYNC:RTR:7</Code>
      <Description>SMEV-401:Попытка отправить сообщение, не соответствующее типу вида сведений</Description>
      <ns3:RootElementLocalName>DataRequest</ns3:RootElementLocalName>
      <ns3:RootElementNamespaceURI>urn://qa/8.0.0</ns3:RootElementNamespaceURI>
     </ns3:BusinessDataTypeIsNotSupported>
    </detail>
   </soap:Fault>
  </soap:Body>
 </soap:Envelope>









Рекомендуется:





    

  •  для запроса, отправляемого методом SendRequest проверить, что в блоке MessagePrimaryContent вложенный элемент соответствует корневому элементу запроса в соответствии со схемой Вида сведений, опубликованной в руководстве пользователя;

    • 

  •  для ответа отправляемого методом SendResponse проверить, что в блоке MessagePrimaryContent вложенный элемент соответствует корневому элементу ответа в соответствии со схемой Вида сведений, опубликованной в руководстве пользователя.
    • 





SMEV-402





Текст ошибки: Входящая очередь запрошенного типа сообщений, принадлежащая пользователю  @CallerCertificate.getSubjectX500Principal().getName(X500Principal.RFC1779)  не зарегистрирована в СМЭВ.




Возникает на этапе обработка сообщения в рамках синхронной обработки xml-сообщения, принятого методом GetRequest, GetResponse.







 Причина


 Пример






1. Неверно указаны параметры фильтрации в тегах NamespaceURI и RootElementLocalName блока MessageTypeSelector  (в том числе, если указанный ВС не зарегистрирован в нужной среде).

2. Информационная система Участника не зарегистрирована в СМЭВ 3, либо ИС отсутствует в необходимой среде.



<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
   <soap:Fault>
    <faultcode>soap:Server</faultcode>
    <faultstring>Входящая очередь запрошенного типа сообщений,
 принадлежащая пользователю CN=АО РТ Лабс, C=RU, ST=50 Московская область,
 L=Химки, STREET="141400, Россия, Московская обл., 
г. Химки, ул. Пролетарская, д. 23, ком 101", O=АО РТ Лабс,
 OID.1.2.643.100.1=#120D31303335303039353637343530, 
OID.1.2.643.3.131.1.1=#120C303035303437303533393230,
OID.1.2.840.113549.1.9.2=Санити СМЭВ3 ИС01 не зарегистрирована в СМЭВ</faultstring>
    <detail>
     <ns3:UnknownMessageType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2" 
xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2" 
xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2"
 xsi:type="SmevFault">
      <Code>fed0:PRODUCTION_AREA:FED0_CORE2 : TR:SYNC:PP:12</Code>
      <Description>SMEV-402:Входящая очередь запрошенного типа сообщений,
 принадлежащая пользователю CN=АО РТ Лабс, C=RU, ST=50 Московская область,
 L=Химки, STREET="141400, Россия, Московская обл., г. Химки, ул. Пролетарская, 
д. 23, ком 101", O=АО РТ Лабс, OID.1.2.643.100.1=#120D31303335303039353637343530, 
OID.1.2.643.3.131.1.1=#120C303035303437303533393230,
OID.1.2.840.113549.1.9.2=Санити СМЭВ3 ИС01 
не зарегистрирована в СМЭВ</Description>
     </ns3:UnknownMessageType>
    </detail>
   </soap:Fault>
  </soap:Body>
 </soap:Envelope>









Рекомендуется:





    

  • проверить содержимое элементов NamespaceURI и RootElementLocalName блока MessageTypeSelector — целевое пространство имен и корневой элемент должны соответствовать зарегистрированному в СМЭВ 3 Виду сведений;
    • 

  • проверить зарегистрирован ли данный ИС в той среде СМЭВ 3, в которой идет обращение;
    • 

  • проверить зарегистрирован ли сертификат, которым подписано направленное сообщение, в соответствующей среде СМЭВ 3;
    • 

  • получить серийный номер сертификата, указанного в блоке  CallerInformationSystemSignature в элементе X509Certificate отправляемого сообщения (сохранить содержимое элемента с разрешением cer, открыть вкладку «Состав», получить значение из поля «Серийный номер»);
    • 

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

  • если заявка ранее не направлялась — зарегистрировать запрос через Ситуационный центр и после получения положительного решения по заявке повторить отправку сообщения.
    • 





SMEV-403





1. Текст ошибки: Сообщение содержит не все вложенные элементы. Блок @tagname отсутствует либо пуст.




Возникает на этапе синхронной валидации xml-сообщения, принятого методами SendRequest, SendResponse, GetRequest, GetResponse.








 Причина



		 Пример









		Отправляемое сообщение не соответствует схемам Единого сервиса





<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Body>
  <soap:Fault>
   <faultcode>soap:Server</faultcode>
   <faultstring>Сообщение содержит не все вложенные элементы.
 Блок MessagePrimaryContent отсутствует либо пуст.</faultstring>
   <detail>
    <ns3:InvalidContent xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
     <Code>fed0:PRODUCTION_AREA:FED0_CORE1 : TR:SYNC:PP:55</Code>
     <Description>SMEV-403:Сообщение содержит не все вложенные элементы.
 Блок MessagePrimaryContent отсутствует либо пуст.</Description>
    </ns3:InvalidContent>
   </detail>
  </soap:Fault>
 </soap:Body>
</soap:Envelope>









Рекомендуется:



    

  • выполнить проверку сообщения с помощью инструмента «Проверка корректности xml-сообщения» в ЛК УВ;
    • 

  • 
привести сообщение в соответствие схемам Единого сервиса — схемы опубликованы в Методических рекомендациях по работе со СМЭВ 3,  а также могут быть получены с помощью ссылок в конструкции import в описании сервиса (wsdl);
    • 

  • повторить отправку сообщения.
    • 




2. Текст ошибки: Сообщение содержит не все вложенные элементы. Один из блоков (MessagePrimaryContent, RequestRejected, RequestStatus) отсутствует либо пуст.




Возникает на этапе синхронной валидации xml-сообщения, принятого методами SendRequest, SendResponse.







 Причина


 Пример






Отправляемое сообщение не соответствует схемам Единого сервиса



<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
  <soap:Fault>
  <faultcode>soap:Server</faultcode>
  <faultstring>Сообщение содержит не все вложенные элементы. 
Один из блоков (MessagePrimaryContent, RequestRejected, RequestStatus)
 отсутствует либо пуст.</faultstring>
  <detail>
  <ns3:InvalidContent 
xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
  <Code>LOCAL:DEV:localhost : TR:SYNC:PP:55</Code>
  <Description>SMEV-403:Сообщение содержит не все вложенные элементы.
 Один из блоков (MessagePrimaryContent, RequestRejected, RequestStatus)
 отсутствует либо пуст.</Description>
  </ns3:InvalidContent>
  </detail>
  </soap:Fault>
  </soap:Body>
 </soap:Envelope>
 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Header/>
    <SOAP-ENV:Body>
       <SOAP-ENV:Fault>
          <faultcode>SOAP-ENV:Client</faultcode>
          <faultstring>Сообщение не соответствует схеме Единого сервиса:
 Один из блоков (MessagePrimaryContent, RequestRejected, RequestStatus)
отсутствует либо пуст</faultstring>
       </SOAP-ENV:Fault>
    </SOAP-ENV:Body>
 </SOAP-ENV:Envelope>









Рекомендуется:



    

  • выполнить проверку сообщения с помощью инструмента «Проверка корректности xml-сообщения» в ЛК УВ;
    • 

  • 
привести сообщение в соответствие схемам Единого сервиса — схемы опубликованы в Методических рекомендациях по работе со СМЭВ 3,  а также могут быть получены с помощью ссылок в конструкции import в описании сервиса (wsdl);
    • 

  • 
повторить отправку сообщения.
    • 




3. Текст ошибки: Метка времени сообщения  @timestamp не действительна.




Возникает на этапе синхронной валидации xml-сообщения, принятого методами  GetRequest, GetResponse, GetStatus, GetIncomingQueueStatistics.







 Причина


 Пример






Значение временной метки в сообщении отличается от текущего






<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body> 
       <soap:Fault> 
          <faultcode>soap:Server</faultcode> 
          <faultstring>Метка времени сообщения
 2014-02-11T17:10:03.616+04:00 не действительна</faultstring> 
          <detail> 
             <ns3:InvalidContent
 xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2"> 
                <Code>fed0:TEST_AREA:FED0_CORE1 : TR:SYNC:PP:3</Code> 
                <Description>SMEV-403:Метка времени сообщения
 2014-02-11T17:10:03.616+04:00 не действительна</Description> 
             </ns3:InvalidContent> 
          </detail> 
       </soap:Fault> 
    </soap:Body> 
 </soap:Envelope> 









Рекомендуется выполнить проверку значения времени в элементе Timestamp по методам Timestamp:



    

  • Метод GetRequestRequest : GetRequestRequest — MessageTypeSelector — Timestamp 
    • 

  • Метод GetResponseRequest : GetResponseRequest – MessageTypeSelector — Timestamp 
    • 

  • Метод GetStatus : GetStatusRequest — Timestamp 
    • 

  • Метод GetIncomingQueueStatisticsRequest : GetIncomingQueueStatisticsRequest — Timestamp 
    • 




Значение должно совпадать с текущим  (допустимая дельта — 30 минут).




4. Текст ошибки: Бизнес-данные сообщения не соответствуют схеме, зарегистрированной в СМЭВ. MessageId = @Message_Id




Возникает на этапе Асинхронная валидация xml-сообщения, принятого методом SendRequest либо SendResponse.







 Причина


 Пример






Отправляемое сообщение не соответствует схемам Вида сведений



<ns2:AsyncProcessingStatus>
<ns2:OriginalMessageId>704b80da-2268-11e9-afd2-02579a2b356e</ns2:OriginalMessageId>
<ns2:StatusCategory>requestIsRejectedBySmev</ns2:StatusCategory>
<ns2:StatusDetails>Бизнес-данные сообщения не соответствуют схеме, зарегистрированной в СМЭВ.
 MessageId = 704b80da-2268-11e9-afd2-02579a2b356e</ns2:StatusDetails>
<ns2:SmevFault xsi:type=""ns3:InvalidContent"" xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"">
<Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:BSV:3</Code>
<Description>SMEV-403:Бизнес-данные сообщения не соответствуют схеме, зарегистрированной в СМЭВ.
 MessageId = 704b80da-2268-11e9-afd2-02579a2b356e</Description>
<ns3:ValidationError errorPosition=""-1"">cvc-pattern-valid: Value '' is not facet-valid with respect to pattern
 '[A-Za-z0-9]{1,32}' for type 'documentseriesType'.</ns3:ValidationError>
<ns3:ValidationError errorPosition=""-1"">cvc-type.3.1.3: The value '' of element 
'tns:passportSeries' is not valid.</ns3:ValidationError>
<ns3:ValidationError errorPosition=""-1"">cvc-pattern-valid: Value '' is not facet-valid with respect to pattern 
'[A-Za-z0-9]{1,32}' for type 'documentnumberType'.</ns3:ValidationError>
<ns3:ValidationError errorPosition=""-1"">cvc-type.3.1.3: The value '' of element 'tns:passportNumber' 
is not valid.</ns3:ValidationError>
</ns2:SmevFault></ns2:AsyncProcessingStatus>









Рекомендуется:





    

  • скачать схемы Вида сведений в карточке на Технологическом портале;

    • 

  • 
выполнить валидацию содержимого блока MessagePrimaryContent отправляемого сообщения по схемам Вида сведения с помощью xml-валидаторов или сверить с эталонным сообщением, опубликованным в руководстве пользователя;

    • 

  • 
исправить ошибки и повторить отправку сообщения.
    • 





SMEV-405


Текст ошибки: Входящая очередь «наименование очереди» сообщений, принадлежащая пользователю «мнемоника ИС», не зарегистрирована в СМЭВ.

Возникает на этапе Проверка наличия очереди ИС в СМЭВ в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.







 Причина


 Пример






Очередь ИС не зарегистрирована в СМЭВ



<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Header/>
    <SOAP-ENV:Body>
       <SOAP-ENV:Fault>
          <faultcode>SOAP-ENV:Server</faultcode>
          <faultstring>SMEV-405: Входящая очередь testroiv08N03 сообщений, 
принадлежащая пользователю testroiv08, не зарегистрирована в СМЭВ</faultstring>
          <detail>
             <sf3:InvalidContent 
xmlns:sb3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.3"
 xmlns:sf3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.3">
                <sb3:Code>CONNECTOR</sb3:Code>
                <sb3:Description>SMEV-405: Входящая очередь testroiv08N03 сообщений,
 принадлежащая пользователю testroiv08, не зарегистрирована в СМЭВ</sb3:Description>
                <sf3:ValidationError errorPosition="0">SMEV-405: Входящая очередь testroiv08N03 сообщений,
 принадлежащая пользователю testroiv08, не зарегистрирована в СМЭВ</sf3:ValidationError>
             </sf3:InvalidContent>
          </detail>
       </SOAP-ENV:Fault>
    </SOAP-ENV:Body>
 </SOAP-ENV:Envelope>









Рекомендуется: 




    

  • убедиться, что сертификат, которым подписывается сообщение, зарегистрирован в СМЭВ;

    • 

  • проверить, что указанная в тексте ошибки мнемоника ИС и ее очередь (общая или выделенная — NodeId) была зарегистрирована в СМЭВ;

    • 

  • если были выявлены ошибки, исправить их (скорректировать мнемонику ИС, зарегистрировать ИС в СМЭВ, зарегистрировать сертификат, добавить выделенный узел ИС) и повторить попытку отправить запрос.
    • 





SMEV-406



Текст ошибки: Входящая очередь «мнемоника ИС_мнемоника узла» сообщений, принадлежащая пользователю «мнемоника ИС», деактивирована в СМЭВ.



Возникает на этапе проверки активации выделенного узла ИС в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.






 Причина
Пример 




Выделенный

узел (NodeId) ИС деактивирован		


<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
      <SOAP-ENV:Header/>
      <SOAP-ENV:Body>
         <SOAP-ENV:Fault>
  <faultcode>SOAP-ENV:Server</faultcode>
            <faultstring>SMEV-406:
  Входящая очередь testroiv08_N02 сообщений, принадлежащая пользователю
  testroiv08, деактивирована в СМЭВ</faultstring>
            <detail>
               <sf3:InvalidContent
  xmlns:sb3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.3"
  xmlns:sf3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.3">
  <sb3:Code>CONNECTOR</sb3:Code>
  <sb3:Description>SMEV-406: Входящая очередь testroiv08_N02
  сообщений, принадлежащая пользователю testroiv08, деактивирована в
  СМЭВ</sb3:Description>
  <sf3:ValidationError errorPosition="0">SMEV-406:
  Входящая очередь testroiv08_N02 сообщений, принадлежащая пользователю
  testroiv08, деактивирована в СМЭВ</sf3:ValidationError>
  </sf3:InvalidContent>
             </detail>
          </SOAP-ENV:Fault>
       </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>








Рекомендуется создать обращение через СЦ с просьбой активировать выделенный узел ИС, приложив логи запроса и ошибки, указав номер обращения в рамках которого производилась регистрация узла ИС.


SMEV-500


Текст ошибки: Превышение пороговой продолжительности обработки вызова.


Возникает на этапе проверки EOL сообщения в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.










 Причина
 Пример




 Истекло установленное отправителем время жизни  сообщения


<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
     <soap:Body>
      <soap:Fault>
  <faultcode>soap:Server</faultcode>
       <faultstring>Превышение
  пороговой продолжительности обработки вызова</faultstring>
       <detail>
        <ns3:EndOfLifeReached
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
  xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
  xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2"
  xsi:type="SmevFault">
  <Code>fed0:PRODUCTION_AREA:FED0_CORE2 :
  TR:SYNC:PP:3</Code>
  <Description>SMEV-500:Превышение пороговой продолжительности
  обработки вызова</Description>
  </ns3:EndOfLifeReached>
       </detail>
      </soap:Fault>
     </soap:Body>
    </soap:Envelope>








<ns2:AsyncProcessingStatus>
<ns2:OriginalMessageId>e35b183b-2093-11e9-a8e6-aaaaaa2cac00</ns2:OriginalMessageId>
<ns2:StatusCategory>cancelled</ns2:StatusCategory>
<ns2:StatusDetails>Превышение пороговой продолжительности обработки вызова</ns2:StatusDetails>
<ns2:SmevFault><Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:PP:3</Code>
<Description>SMEV-500:Превышение пороговой продолжительности обработки вызова</Description>
</ns2:SmevFault></ns2:AsyncProcessingStatus>








Рекомендуется установить новое значение для элемента EOL и повторить отправку сообщения.


SMEV-501


Текст ошибки: Сообщение @AckTargetMessage не найдено среди неподтверждённых.


Возникает на этапе обработки сообщения в рамках синхронной обработки xml-сообщения, принятого методом Ack.






 Причина
 Пример




Подтверждение

получения  сообщения  с указанным MessageId было выполнено ранее

или указанное значение MessageID некорректно		


<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
     <soap:Body>
      <soap:Fault>
  <faultcode>soap:Server</faultcode>
       <faultstring>Сообщение
  e8cd9dc6-22f2-11e9-a8e6-aaaaaa2cac00 не найдено среди
  неподтверждённых.</faultstring>
       <detail>
        <ns3:TargetMessageIsNotFound
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns=""urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2""
  xsi:type="SmevFault">
  <Code>fed0:PRODUCTION_AREA:FED0_CORE1 :
  TR:SYNC:DAS:4</Code>
         <Description>SMEV-501:Сообщение
  e8cd9dc6-22f2-11e9-a8e6-aaaaaa2cac00 не найдено среди
  неподтверждённых.</Description>
  </ns3:TargetMessageIsNotFound>
       </detail>
      </soap:Fault>
     </soap:Body>
    </soap:Envelope>








Рекомендуется:




    

  • убедиться что сообщение Ack отправлено в тот же контур СМЭВ 3 (разработческий, тестовый, продуктивный), в котором было получено сообщение GetRequest или GetResponse;
    • 

  • извлечь  значение MessageID из  полученного методом GetRequest или GetResponse сообщения;
    • 

  • в элементе AckTargetMessage сообщения AckRequest указать полученный MessageID и отправить в  адрес Единого сервиса.
    • 





SMEV-502


Текст ошибки: Не найден получатель по виду сведений.


Возникает на этапе обработки получателя сообщения по виду сведений в рамках синхронной обработки xml-сообщения, принятого методом SendRequest.






 Причина
 Пример




Неверно

указан код маршрутизации  либо его

формат.

 		


<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
    <soap:Fault>
 <faultcode>soap:Server</faultcode>
   <faultstring>Невозможно определить получателя для сообщения. 
Полное имя корневого элемента: {http://epgu.gosuslugi.ru/lk/order/event/3.1.1}
eventServiceRequest</faultstring>
      <detail>
       <ns3:RecipientIsNotFound
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2"
 xsi:type="SmevFault">
  <Code>fed0:PRODUCTION_AREA:FED0_CORE2 :
  TR:SYNC:RTR:4</Code>
         <Description>SMEV-502:Не найден получатель по виду сведений</Description>
  </ns3:RecipientIsNotFound>
       </detail>
      </soap:Fault>
     </soap:Body>
    </soap:Envelope>








Рекомендуется:


    

  • убедиться, что среди Поставщиков, получивших технологический доступ к Виду сведений, присутствует Поставщик с указанным в сообщении кодом маршрутизации;
    • 

  • в случае неверного кода маршрутизации исправить и повторить отправку запроса.
    • 



SMEV-503


Текст ошибки: Отправитель сообщения не зарегистрирован.


Возникает на этапе проверки регистрации отправителя сообщения в рамках синхронной обработки xml-сообщения, принятого методом SendRequest, SendResponse, GetRequest, GetResponse, Ack.






 Причина
 Пример




Информационная

система Участника не зарегистрирована в СМЭВ 3		


<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
     <soap:Fault>
  <faultcode>soap:Server</faultcode>
       <faultstring>Отправитель сообщения не зарегистрирован.</faultstring>
       <detail>
       <ns3:SenderIsNotRegistered
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1"
 xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1"
 xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"
 xsi:type="SmevFault">
  <Code>fed0:PRODUCTION_AREA:FED0_CORE2 :
  TR:SYNC:RTR:1</Code>
         <Description>SMEV-503:Отправитель сообщения
 не зарегистрирован.</Description>
  </ns3:SenderIsNotRegistered>
       </detail>
      </soap:Fault>
     </soap:Body>
    </soap:Envelope>








Рекомендуется:




    

  • получить серийный номер сертификата, указанного в блоке  CallerInformationSystemSignature в элементе X509Certificate отправляемого сообщения (сохранить содержимое элемента с разрешением cer, открыть вкладку «Состав», получить значение из поля «Серийный номер»);
    • 

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

  • если заявка ранее не направлялась — зарегистрировать запрос через Ситуационный центр и после получения положительного решения по заявке повторить отправку сообщения.
    • 





SMEV-504


Текст ошибки: Доступ запрещён.


Возникает на этапе проверки доступа отправителя к виду сведений в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.






 Причина
 Пример




ИС не

добавлена в СМЭВ 3 в качестве потребителя для запрашиваемого ВС		


<AsyncProcessingStatus>
<OriginalMessageId>9f5ac848-1fad-11e9-bd88-7901cd343bf5</OriginalMessageId>
<StatusCategory>requestIsRejectedBySmev</StatusCategory>
<StatusDetails>Доступ запрещён.</StatusDetails>
<SmevFault><ns2:Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:ACSM:1</ns2:Code>
<ns2:Description>SMEV-504:Доступ запрещён.</ns2:Description>
</SmevFault></AsyncProcessingStatus>








Рекомендуется:




    

  • получить серийный номер сертификата, указанного в блоке CallerInformationSystemSignature в элементе X509Certificate отправляемого сообщения (сохранить содержимое элемента с разрешением cer, открыть вкладку «Состав», получить значение из поля «Серийный номер»);
    • 

  • проверить корректность указания целевого пространства имен и корневого элемента Вида сведений (содержимое MessagePrimaryContent);
    • 

  • убедиться, что ранее был направлен запрос в Ситуационный центр на получение доступа к Виду сведений из п.2 для ИС, зарегистрированной в соответствующем контуре СМЭВ (разработческий, тестовый, продуктивный) из п.1;
    • 

  • если заявка ранее не направлялась — зарегистрировать запрос через Ситуационный центр и после получения положительного решения по заявке повторить отправку сообщения.
    • 







SMEV-505 




Текст ошибки: Превышение пороговой продолжительности обработки вызова.


Возникает при получении на коннекторе клиентов сообщения  ответа (SendResponseRequest), в рамках синхронной проверки.






 Причина
 Пример




Норматив

продолжительности подготовки сообщения-ответа превышен на n секунд m

миллисекунд . Значение норматива продолжительности N секунд.		


<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
      <SOAP-ENV:Header/>
      <SOAP-ENV:Body>
         <SOAP-ENV:Fault>
  <faultcode>SMEV-505</faultcode>
            <faultstring>Норматив
  продолжительности подготовки сообщения-ответа превышен на 726 секунд 322
  миллисекунд. Значение норматива продолжительности 25
  секунд.</faultstring>
            <detail>
               <sf3:EndOfLifeReached
  xmlns:sb3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.3"
  xmlns:sf3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.3">
  <sb3:Code>CONNECTOR</sb3:Code>
  <sb3:Description>Норматив продолжительности подготовки
  сообщения-ответа превышен на 726 секунд 322 миллисекунд. Значение норматива
  продолжительности 25 секунд.</sb3:Description>
  </sf3:EndOfLifeReached>
            </detail>
         </SOAP-ENV:Fault>
      </SOAP-ENV:Body>
   </SOAP-ENV:Envelope>








Рекомендуется обратить внимание на следующее: ответ на запрос по версии вида сведений не сможет  быть направлен с нарушением норматива продолжительности подготовки сообщения-ответа.


SMEV-600


Текст ошибки: Очередь, в которую должно быть отправлено сообщение, переполнена.


Возникает на этапе проверки квоты на количество сообщений в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest.










 Причина
 Пример




Ошибка

связана с ограничением на допустимое количество сообщений в очереди запросов

ИС-получателя сообщения и вызвана несвоевременным разбором входящей очереди

ИС получателя запроса. 		


<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Body>
         <soap:Fault>
 <faultcode>soap:Server</faultcode>
            <faultstring>Очередь,
 в которую должно быть отправлено сообщение, переполнена.</faultstring>
            <detail>          
  <ns3:DestinationOverflow
  xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
  xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
  xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2">
                   <Code>fed0:DEV:FED0_CORE2: TR:SYNC:PP:15</Code>
  <Description>SMEV-600:Очередь, в которую должно быть отправлено
  сообщение, переполнена.</Description>    
  <ns3:MessageBrokerAddress>unknown</ns3:MessageBrokerAddress>   
  <ns3:DestinationName>delivery.testfoiv._REQUEST_</ns3:DestinationName>       
  </ns3:DestinationOverflow>
           </detail>
        </soap:Fault>
     </soap:Body>
  </soap:Envelope>









<AsyncProcessingStatus>



<OriginalMessageId>e86b5350-1995-11e9-b078-0050568925e4</OriginalMessageId>
<StatusCategory>requestIsRejectedBySmev</StatusCategory>
<StatusDetails>Очередь, в которую должно быть отправлено сообщение,
 переполнена.</StatusDetails>
<SmevFault xsi:type="ns3:DestinationOverflow"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns2:Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:DAS:2</ns2:Code>
<ns2:Description>SMEV-600:Очередь, в которую должно быть отправлено сообщение,
 переполнена.</ns2:Description>
<ns3:MessageBrokerAddress>unknown</ns3:MessageBrokerAddress>
<ns3:DestinationName>delivery.FNS002_3S._REQUEST_</ns3:DestinationName>
</SmevFault></AsyncProcessingStatus>








Рекомендуется повторить отправку сообщения с вложением через промежуток времени или обратиться к получателю запроса  через СЦ.


SMEV-60


Текст ошибки: Ошибка СМЭВ. Обратитесь в службу технической поддержки.


Возникает на этапе проверки в рамках синхронной или асинхронной обработки xml-сообщения, принятого методами SendRequest, SendResponse, GetRequest, GetResponse, Ack.






 Причина
 Пример




1.

Некорректная структура сообщения

2. Отсутствует или некорректно заполнен элемент to сообщения-ответа.

3. Сообщение направлено неверным методом (например, если запрос направлен

по методу SendResponse)

4. Технологические работы в СМЭВ		


<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>                
  <soap:Fault>
  <faultcode>soap:Server</faultcode>                          
  <faultstring>Ошибка СМЭВ. Обратитесь в службу технической
  поддержки.</faultstring>
  <detail>
  <ns3:SMEVFailure
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2"
  xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2"
  xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2"
  xsi:type="SmevFault">
  <Code>fed0:PRODUCTION_AREA:FED0_CORE2 :
  TR:SYNC:RTR:10</Code>
  <Description>SMEV-60:Ошибка СМЭВ. Обратитесь в службу
  технической поддержки.</Description>
  </ns3:SMEVFailure>
  </detail>
  </soap:Fault>
   </soap:Body>
  </soap:Envelope>








Рекомендуется:


    

  • выполнить проверку сообщения с помощью инструмента «Проверка корректности xml-сообщения» в ЛК УВ;
    • 

  • в случае ошибок привести сообщение в соответствие схемам Единого сервиса — схемы опубликованы в Методических рекомендациях по работе со СМЭВ 3 (также могут быть получены с помощью ссылок в конструкции import в описании сервиса (wsdl)) и повторить отправку сообщения;
    • 

  • проверить, что сообщение направляется нужным методом (запрос — при помощи метода SendRequest, ответ — при помощи метода SendResponse);
    • 

  • для успешного инициирования процесса обмена, необходимо направлять запрос при помощи метода SendRequest, отправив запрос (SendRequestRequest), после чего запрос пройдет проверки и будет поставлен в очередь запросов поставщика ВС. Далее поставщик при помощи метода GetRequest совершает выборку запроса из очереди и формирует конверт SendResponseRequest;
    • 

  • убедиться, что в соответствующем контуре СМЭВ на момент отправки сообщения не проводились технологические работы (информация о работах публикуется в разделе «Новости».
    • 







Источник










XML документ с корректным синтаксисом называется «правильно сформированным» или «синтаксически верным».


«Валидный» XML документ кроме всего прочего должен соответствовать определенному типу документов.


Синтаксически верные XML документы


XML документ с корректным синтаксисом является «синтаксически верным».


Синтаксические правила были описаны в предыдущих главах:


    

  • XML документ должен иметь корневой элемент
    • 

  • XML элемент должен иметь закрывающий тег
    • 

  • XML теги регистрозависимы
    • 

  • XML элементы должны соблюдать последовательность вложенности
    • 

  • Значения XML атрибутов должны заключаться в кавычки
    • 




<?xml version="1.0" encoding="UTF-8"?>
<note>
   <to>Tove</to>
   <from>Jani</from>
   <heading>Напоминание</heading>
   <body>Не забудь про меня в эти выходные!</body>
</note>




Ошибки в XML документе остановят вас


Ошибки в XML документе остановят работу вашего XML приложения.


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


HTML браузеры отобразят HTML документ даже с ошибками (например, пропущенный закрывающий тег).


В случае XML ошибки недопустимы!


Валидные XML документы


Валидный XML документ не то же самое, что и синтаксически верный XML документ.


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


Второе правило — валидный XML документ должен соответствовать определенному типу документов.


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


Когда используют определения документа?


Определения документа — это самый простой способ предоставить рекомендации по допустимым элементам и атрибутам документа.


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


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


Когда не используют определения документа?


В действительности XML не требует определений документа.


Когда вы экспериментируете с XML или работаете с небольшими XML файлами, создание определений документа может стать лишней тратой времени.


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


Определения документа


С XML можно использовать различные типы определений документа:


    

  • Оригинальное определение типа документа (DTD)
    • 

  • Более новый тип определений, основанный на XML, — XML схема.
    • 



Проверка валидности XML документа


Для проверки валидности XML документов в сети Интернет существует множество программ и сайтов проверки XML документов.










Источник







  



                       
  





	









    
    
    
    



    

                
Понравилась статья? Поделить с друзьями:

        
        

























    








			

  • Ошибка при валидации csrf токена запрос отклонен
    • 

  • Ошибка при бэкапе биоса
    • 

  • Ошибка при активации фейстайм на айфоне
    • 

  • Ошибка при активации системы ps3 80029519
    • 

  • Ошибка при активации сим карты на госуслугах

    •