Ошибка при валидации по схеме 28 21. Региональная информационная система в сфере закупок Республики Саха (Якутия). Соображения о многоуровневой валидации

05.03.2013

Расшифровка наиболее часто возникающих ошибок при отправке данных на ООС:

Общие ошибки и ошибки, возникающие при отправке извещения о проведении открытого аукциона в электронной форме:

Некорректные данные. Ни для одной из организаций с кодом не зарегистрированы расчетный счет и/или лицевой счет и/или БИК . - ошибка означает, что данные о счетах, переданные на ООС, не зарегистрированы на официальном сайте ни на организацию заказчика, ни на организацию организатора.

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

Некорректные данные. Уполномоченный орган с кодом не имеет полномочий размещать заказ от имени заказчика с кодом . - вероятнее всего организация заказчика не является подведомственной организацией у организатора торгов. Проверка на ООС осуществляется по номеру СПЗ, поэтому вполне возможно, что просто неверно указан номер СПЗ у заказчика.

Некорректные данные. Код СПЗ организации [ххх] отсутствует в ООС. - значит это действительно так. Необходимо убедиться в правильности ввода данного кода СПЗ. Код СПЗ должен состоять из 11 цифр.

Ошибка валидации по схеме. 66:21 cvc-complex-type.2.4.a: Обнаружено недопустимое содержимое, начиная с элемента ’amount’. Ожидалось одно из ’{"?http://zakupki.gov.ru/oos/types/1":settlementAccount }’. - проблема связана с банковскими реквизитами. Возможно где-то на форме размещения заказа указан размер обеспечения/размер платы, срок и порядок внесения платы, но не выбраны реквизиты для внесения денежных средств.

Ошибка валидации по схеме. 41:31 cvc-complex-type.2.4.b: Неполное содержимое элемента ’customerRequirement’. Ожидалось одно из ’{"?http://zakupki.gov.ru/oos/types/1":deliveryPlace , "?http://zakupki.gov.ru/oos/types/1":deliveryTerm , " }’. - не заполнена информация об обеспечении заявки. Собственно во всех ответах от сайта содержащих текст примерно следующего содержания "Ожидалось одно из [...] ?http://zakupki.gov.ru/oos/types/1":guaranteeApp } " смысл тот же. Так же ООС указал на то что не заполнена информация о месте и сроках поставки товаров/работ/услуг, но эти данные не обязательны для заполнения. Ключевым является именно обеспечение заявки.

Ошибка валидации по схеме. 17:17 cvc-complex-type.2.4.b: Неполное содержимое элемента ’contactInfo’. Ожидалось одно из ’{"?http://zakupki.gov.ru/oos/types/1":orgFactAddress }’. - не указан адрес контактной организации.

Ошибка валидации по схеме. 48:8 cvc-complex-type.2.4.b: Неполное содержимое элемента ’EP’. Ожидалось одно из ’{"?http://zakupki.gov.ru/oos/types/1":code }’. - в передаваемом файле отсутствует информация о торговой площадке. Скорее всего данный атрибут просто не выбран на форме.

Ошибка валидации по схеме. 18:27 cvc-complex-type.2.4.a: Обнаружено недопустимое содержимое, начиная с элемента ’notificationCommission’. Ожидалось одно из ’{"?http://zakupki.gov.ru/oos/types/1":printForm , "?http://zakupki.gov.ru/oos/types/1":documentMetas , " }’. - собственно эта ошибка означет скорее всего, что не указана именно планируемая дата публикации извещения. Собственно во всех ответах от сайта содержащих текст примерно следующего содержания "Ожидалось одно из [...] ?http://zakupki.gov.ru/oos/types/1":publishDate } " смысл тот же.

Неполное содержимое элемента ’notificationCommission’. Ожидалось одно из ’{"?http://zakupki.gov.ru/oos/types/1":p1Date }’. - не указана дата и время окончания срока подачи заявок.

Некорректные данные пользователя. Password check for user with login has failed - данная ошибка говорит о неверном пароле на ООС для данного логина (user_login). Стоит убедиться в правильности введенных данных. На самом же деле эта ошибка, как правило, связана с проблемами на ООС, который по каким либо причинам "бракует" любые пароли (правильные и нет). Решается звонком на вторую линию техподдержки ООС и ожиданием. Иногда достаточно просто ожидания.

Удаленный сервер возвратил ошибку: (408,502,504) - Обычно мы тут не причем, но стоит убедиться, что на сервере есть доступ к ООС. Если с каналом связи все нормально, то просто ждем. Как правило это последствия регламентных работ на ООС.

Ошибка валидации по схеме. 68:23 cvc-complex-type.2.4.a: Обнаружено недопустимое содержимое, начиная с элемента ’fullName’. Ожидалось одно из ’{"?http://zakupki.gov.ru/oos/types/1":regNum }’. - либо организатора, либо у заказчика в системе WEB-Торги-КС отсутствует рег.номер СПЗ. Как правило у заказчика.

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

1. Ошибка(обязательно устранение): Ошибка валидации по схеме. 76:42 cvc-type.3.1.3: Значение ’ 03762000029’ элемента ’regNum’ недопустимо. 2. Ошибка(обязательно устранение): Ошибка валидации по схеме. 76:42 cvc-pattern-valid: Значение ’ 03762000029’ не является допустимым с учетом шаблона ’\d{1,11}’ для типа ’spzNumType’. - не верно указан номер СПЗ (должно быть 11 цифр без пробелов и прочих знаков)

Ошибка (обязательно устранение): Ошибка валидации по схеме. 76:22 cvc-complex-type.2.4.a: Обнаружено недопустимое содержимое, начиная с элемента ’docName’. Ожидалось одно из ’{"?http://zakupki.gov.ru/oos/types/1":sid , "?http://zakupki.gov.ru/oos/types/1":ordinalNumber }’. - ошибка возникает при отправке извещения о проведении открытого аукциона в электронной форме, возникает из-за того, что в одном из заполненных гридов с требованиями к закупке не указан порядковый номер строки.

Ошибка(обязательно устранение): Ошибка валидации по схеме. 8:28 cvc-pattern-valid: Значение ’ ’ не является допустимым с учетом шаблона ’\d{19} ’ для типа ’notificationNumberType’. 2. Ошибка(обязательно устранение): Ошибка валидации по схеме. 8:28 cvc-type.3.1.3: Значение ’ ’ элемента ’notificationNumber’ недопустимо. - ошибка возникает при отсутствии реестрового номера в извещении.

Ошибка(обязательно устранение): Ошибка валидации по схеме. 586:12 cvc-complex-type.2.4.a: Обнаружено недопустимое содержимое, начиная с элемента ’inn’. Ожидалось одно из ’{"?http://zakupki.gov.ru/oos/types/1":participantType }’. - ошибка возникает при отсутствии ТИПА ПОСТАВЩИКА в справочнике поставщиков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Credit Card must be MasterCard or Visa

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

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

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

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

MasterCard

John Smith

2013

5285

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

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

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

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

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

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

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

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

Примеры

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

Invalid Card Number.

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

Mastercard card number must be 16 digits.

Security code for Mastercard must be 3 digits.

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

Mastercard number must be 16 digits.

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

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()))

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

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

Security No must be specified

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

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

env:Server

: Schematron validation fails with error

Security code for Mastercard must be 3 digits.

Credit Card has expired.

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

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

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

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

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

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

faultstring : должен содержать понятное человеку описание причины возникновения ошибки.

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

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

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

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

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 ). Пример определения сервиса обработки кредитной карточки как асинхронного:

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

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

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

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

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

Понравилось сообщение -

Разбор ошибок валидации сайта

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

Что такое валидация сайта?

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

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

Возьмем первую попавшуюся страницу на моем сайте - Кодирование и декодирование base64 на Java 8. Забьем адрес страницы в валидатор и смотрим результат:

Errors found while checking this document as HTML 4.01 Transitional! Result: 105 Errors, 67 warning(s) Да уж, картина вырисовывается неприятная: больше сотни ошибок и 67 предупреждений – как вообще поисковики индексируют мой блог, и заходят люди? Но не будем огорчаться, а научимся проходить валидацию, справлять ошибки. Итак, первое предупреждение:

Unable to Determine Parse Mode! The validator can process documents either as XML (for document types such as XHTML, SVG, etc.) or SGML (for HTML 4.01 and prior versions). For this document, the information available was not sufficient to determine the parsing mode unambiguously, because: the MIME Media Type (text/html) can be used for XML or SGML document types No known Document Type could be detected No XML declaration (e.g ) could be found at the beginning of the document. No XML namespace (e.g ) could be found at the root of the document. As a default, the validator is falling back to SGML mode. Warning No DOCTYPE found! Checking with default HTML 4.01 Transitional Document Type. No DOCTYPE Declaration could be found or recognized in this document. This generally means that the document is not declaring its Document Type at the top. It can also mean that the DOCTYPE declaration contains a spelling error, or that it is not using the correct syntax. The document was checked using a default "fallback" Document Type Definition that closely resembles “HTML 4.01 Transitional”. Это одно и тоже. А исправляется просто: в самом начале страницы добавить тег:

Проверяем,что у нас получилось и видим, что одним этим тегом мы убрали 105 ошибок и 3 предупреждения! Теперь у нас осталось только 64 предупреждения. Начинаем разбирать их по одному.

Warning: The type attribute for the style element is not needed and should be omitted. From line 5, column 1; to line 5, column 23 /x-icon">↩↩↩↩↩A Это значит, что для элемента style не нужен атрибут type – это лишнее. На странице у нас два таких замечания. Аналогичное предупреждение и по JavaScript:

Warning: The type attribute is unnecessary for JavaScript resources. From line 418, column 1; to line 418, column 31 ↩↩$(doc Таких у нас 8 ошибок. Убираем данные атрибуты и ура – еще на 10 предупреждений меньше!

Error: CSS: background: The first argument to the linear-gradient function should be to top, not top. At line 39, column 61 0%,#E8E8E8 100%);↩ border-r Следующая ошибка - первый аргумент у linear-gradient должен быть to top, а не top. Исправлем. Далее ошибка:

Error: CSS: Parse Error. From line 65, column 13; to line 65, column 16 margin: 0 auto;↩padd Здесь у меня неверно закомментировано css. Надо просто убрать эту строку. Или закомментировать по-другому /* и */. Я так сделал, как привык так .

Error: CSS: @import are not allowed after any valid statement other than @charset and @import.. At line 88, column 74 0,600,700,300);↩@import url(// Теперь у нас идет ошибка импорта. Перенесем эти строчки в самое начало файла и она исчезнет.

Error: Bad value _blanck for attribute target on element a: Reserved keyword blanck used. From line 241, column 218; to line 241, column 295 cookies..php?id=98" target="_blanck" style="display: inline;">Здесь Далее не нравится значение атрибута target, нам сообщают, что надо использовать «blank» без нижнего подчеркивания спереди. Убираем.

Error: End tag li seen, but there were open elements. From line 379, column 2; to line 379, column 6

↩ ↩↩↩↩↩↩↩↩
↩