Ошибка при разборе или валидации содержимого файла - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

prog1Csww

19.07.22 — 09:47

Есть следующий формат файла для ЕИС Госзакупок.

Описан здесь

https://zakupki.gov.ru/epz/main/public/download/downloadDocument.html?id=36503

Получился такой файлик

<?xml version=»1.0″ encoding=»WINDOWS-1251″?>

<ФайлПакет ИдТрПакет=»37B62CBA-66A5-4722-A350-5AF49F97E111″ ИдФайл=»ON_NSCHFDOPPR_2ZK-CUS-03223001038_2ZK-SUP-00019150656_20220715_37B62CBA-66A5-4722-A350-5AF49F97E98E» ДатаВрФормир=»2022-07-19T00:00:01″ ТипПрилож=»УПДПрод» ВерсФорм=»1.00″ ИдОтпр=»2ZK-SUP-00019150656″ ИдПол=»2ZK-CUS-03223001038″>

<Документ>

<Контент>PNCk много букв base64 Pg==</Контент>

</Файл>

</Документ>

</ФайлПакет>

Но выдает ошибку

РДИК_ИК_0003. Ошибка валидации xml-документа «DP_PAKET»: cvc-datatype-valid.1.2.1: ‘PNCk много букв base64 Pg==’ is not a valid value for ‘base64Binary’.

Что означает эта ошибка?

Формировал base64Binary следующим кодом в 1С

ВременныйФайл = ПолеВвода3;

ЗаписьТекста = Новый ЗаписьТекста(ВременныйФайл, «CESU-8»);

ЗаписьТекста.Записать(ПолеВвода1);

ЗаписьТекста.Закрыть();

ДД_Файла = Новый ДвоичныеДанные(ВременныйФайл);

ПолеВвода2 = Base64Строка(ДД_Файла);

Потом ПолеВвода2 скопировал в тег «Контент» непосредственно в блокноте.

Как создать рабочий файлик чтобы хоть посмотреть как он выглядит?

prog1Csww

1 — 19.07.22 — 09:50

Есть наше обращение в техподдержку ЕИС Госзакупок. Может поможет чем…

Вопрос…

Работает ли загрузка документа приемки из файла?

Описание:

Здравствуйте.

1. Зашли в контракты

2. Для отправленного заказчику документа о приемке выбрали «Скачать архив документов»

3. В УПД из архива поменяли ГУИД в имени файла и в тексте xml документа тоже поменяли аттрибут Файл.

4. Поменяли порядковый номер документа и дату первичного документа в тексте xml файла.

5. Попытались загрузить.

6. Выдало ошибку РДИК_ИК_0003. Ошибка валидации xml-документа «DP_PAKET»: cvc-elt.1.a: Cannot find the declaration of element ‘Файл’.

Работает ли Ваша опция загрузки? Или наш подход в корне не верен и выгруженный из ЕИС но подредактированный файл нельзя подгрузить в ЕИС снова?

******************************* Ответ **************************************

Уважаемый пользователь!

Контроль РДИК_ИК_0003 возникает по причине не корректно сформированного транспортного пакета.

Загружается xml-файл (транспортный пакет), не соответствующий интеграционным схемам ЕИС.

Для успешной обработки необходимо передавать транспортный пакет (ФайлПакет) сформированный согласно схеме DP_PAKET_EIS_01_00.xsd.

В составе загружаемого в ЕИС транспортного пакета должны передаваться:

•УПД или УКД

•Приложение к документу, которое является составной и неотъемлемой частью УПД (титул продавца) или УКД (титул продавца) в схеме DP_PACKET_EIS_01_00

Сам пакет должен содержать:

•soap-оболочку (при загрузке xml-файла непосредственно в личном кабинете поставщика soap-оболочка не требуется)

•Шапка (ФайлПакет)

•Документ/Контент в base64 (содержит УПД или УКД)

•Прилож/Контент в base64 (содержит ФайлУПДПрод / ФайлУКДПрод)

УПД — Универсальный передаточный документ (титул Продавца). Интеграционная схема ON_NSCHFDOPPR_1_997_01_05_01_02

УКД — Универсальный корректировочный документ. Интеграционная схема ON_NKORSCHFDOPPR_1_996_03_05_01_01

Отметим, что передаваемые сведения должны иметь кодировку windows-1251 (В шапке ФайлПакет, Файл, ФайлУПДПрод/ФайлУКДПрод необходимо указывать <?xml version=»1.0″ encoding=»windows-1251″ ?>).

Структура документов указана в Схемах Эл. Акт. 12.2 и описана в Альбоме ТФФ Эл Акт 12.2 размещенных в открытой части ЕИС.

https://zakupki.gov.ru/epz/main/public/document/view.html?searchString=§ionId=432&strictEqual=false

prog1Csww

2 — 20.07.22 — 01:33

Вверх.

prog1Csww

3 — 20.07.22 — 07:20

Удалось победить первое препятствие

код обработки заменил на

ПотокВПамяти = Новый ПотокВПамяти();

Текст = Новый ЗаписьТекста(ПотокВПамяти, КодировкаТекста.UTF8, , Символы.ПС);

Текст.Записать(ПолеВвода1);

Текст.Закрыть();

ДвоичныеДанные = ПотокВПамяти.ЗакрытьИПолучитьДвоичныеДанные();

СтрокаФорматBase64 = Base64Строка(ДвоичныеДанные);

СтрокаФорматBase64 = СтрЗаменить(СтрокаФорматBase64, Символы.ВК, «»);

СтрокаФорматBase64 = СтрЗаменить(СтрокаФорматBase64, Символы.ПС, «»);

ПолеВвода2 = СтрокаФорматBase64;

И всё прошло. Но возникла новая проблема

ЕИС ругается на Element type «Р» must be followed by either attribute specifications, «>» or «/>».

Яндекс.Валидатор XML + XSD тоже выдает такую же ошибку причем пишет что сервис временно недоступен.

В XML видимых ошибок нет. Тег «Контент» можно декодировать на сайте http://base64.ru/

Иностранный валидатор XML + XSD https://www.freeformatter.com/xml-validator-xsd.html ошибок не выдает. Жду ответа от техподдержки ЕИСа.

Ryzeman

4 — 20.07.22 — 07:27

Ну, вообще тебе английским по-белому писало ошибку что в (0) что сейчас. В (0) была проблема с <Контент> как раз то, что ты не написал. В теле ожидалась строка base64Binary, у тебя там были какие-то недопустимые символы. В (3) у тебя где-то в XML незакрытый элемент <p>. То есть он буквально тебе пишет, что открытие тега <p> должно сопровождаться его закрытием. Посмотреть это можно в любой удобной гляделке XML — в браузере или notepad++ с компонентой для XML, например. Не видя что ты там формируешь что-то тебе ещё посоветовать невозможно.

Ryzeman

5 — 20.07.22 — 07:29

Вариант — у тебя где-то шифруется что то вроде <p или <p>, например, если ты код маркировки передаёшь — это возможно. Тогда надо символы < и > экранировать.

prog1Csww

6 — 20.07.22 — 09:51

(4) <?xml version=»1.0″ encoding=»WINDOWS-1251″?>

<Файл ИдФайл=»ON_NSCHFDOPPR_2ZK-CUS-03223001038_2ZK-SUP-00019150656_20220715_37B62CBA-66A5-4722-A350-5AF49F97E98E» ВерсФорм=»5.01″ ВерсПрог=»12.2″>

<СвУчДокОбор ИдОтпр=»2ZK-SUP-00019150656″ ИдПол=»2ZK-CUS-03223001038″>

<СвОЭДОтпр НаимОрг=»Федеральное казначейство» ИННЮЛ=»7710568760″ ИдЭДО=»2ZK»/>

</СвУчДокОбор>

<Документ КНД=»1115131″ Функция=»СЧФДОП» ПоФактХЖ=»Документ об отгрузке товаров (выполнении работ), передаче имущественных прав (документ об оказании услуг)» НаимДокОпр=»Счет-фактура и документ об отгрузке товаров (выполнении работ), передаче имущественных прав (документ об оказании услуг)» ДатаИнфПр=»15.07.2022″ ВремИнфПр=»01.44.16″ НаимЭконСубСост=»ИВАНОВА ОЛЬГА ВЛАДИМИРОВНА» СоглСтрДопИнф=»0000.0000.0000″>

<СвСчФакт НомерСчФ=»4″ ДатаСчФ=»20.07.2022″ КодОКВ=»643″>

<СвПрод>

<ИдСв>

<СвИП ИННФЛ=»123456789012″>

<ФИО Фамилия=»ИВАНОВА» Имя=»ОЛЬГА» Отчество=»ВЛАДИМИРОВНА»/>

</СвИП>

</ИдСв>

<Адрес>

<АдрРФ КодРегион=»99″ Город=»Г ИВАНОВО»/>

</Адрес>

<Контакт Тлф=»7 999 999 9999″ ЭлПочта=»hleb@mail.ru»/>

<БанкРекв НомерСчета=»99999999999999999999″>

<СвБанк НаимБанк=»ПАО СБЕРБАНК» БИК=»999999999″ КорСчет=»99999999999999999999″/>

</БанкРекв>

</СвПрод>

<СвПокуп ОКПО=»99999999″ ИнфДляУчаст=»0″ КраткНазв=»МБДОУ ДЕТСКИЙ САД»>

<ИдСв>

<СвЮЛУч НаимОрг=»МУНИЦИПАЛЬНОЕ БЮДЖЕТНОЕ ДОШКОЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ДЕТСКИЙ САД» ИННЮЛ=»9999999999″ КПП=»999999999″/>

</ИдСв>

<Адрес>

<АдрРФ Индекс=»999999″ КодРегион=»99″ Город=»ГОРОД ИВАНОВО» Улица=»УЛИЦА ИВАНОВА» Дом=»ДОМ 9″/>

</Адрес>

<Контакт Тлф=»8 999 999 99 99″ ЭлПочта=»dou@yandex.ru»/>

<БанкРекв НомерСчета=»99999999999999999999″>

<СвБанк НаимБанк=»УФК по Иваново» БИК=»999999999″ КорСчет=»99999999999999999999″/>

</БанкРекв>

</СвПокуп>

<ДопСвФХЖ1 НаимОКВ=»Российский рубль»>

<ИнфПродГосЗакКазн ДатаГосКонт=»14.06.2022″ НомерГосКонт=»999 999″/>

</ДопСвФХЖ1>

<ДокПодтвОтгр НаимДокОтгр=»Документ о приемке» НомДокОтгр=»2″ ДатаДокОтгр=»15.07.2022″/>

</СвСчФакт>

<ТаблСчФакт>

<СведТов НомСтр=»1″ НаимТов=»Хлеб пшеничный» ОКЕИ_Тов=»166″ КолТов=»4.8″ ЦенаТов=»100.33″ СтТовБезНДС=»481.58″ НалСт=»без НДС» СтТовУчНал=»481.58″>

<Акциз>

<БезАкциз>без акциза</БезАкциз>

</Акциз>

<СумНал>

<БезНДС>без НДС</БезНДС>

</СумНал>

<ДопСведТов ПрТовРаб=»1″ НаимЕдИзм=»Килограмм» КодТов=»10.71.11.110″/>

</СведТов>

<СведТов НомСтр=»2″ НаимТов=»Хлеб ржано-пшеничный» ОКЕИ_Тов=»166″ КолТов=»2.8″ ЦенаТов=»99″ СтТовБезНДС=»277.2″ НалСт=»без НДС» СтТовУчНал=»277.2″>

<Акциз>

<БезАкциз>без акциза</БезАкциз>

</Акциз>

<СумНал>

<БезНДС>без НДС</БезНДС>

</СумНал>

<ДопСведТов ПрТовРаб=»1″ НаимЕдИзм=»Килограмм» КодТов=»10.71.11.110″/>

</СведТов>

<ВсегоОпл СтТовБезНДСВсего=»758.78″ СтТовУчНалВсего=»758.78″>

<СумНалВсего>

<БезНДС>без НДС</БезНДС>

</СумНалВсего>

</ВсегоОпл>

</ТаблСчФакт>

<СвПродПер>

<СвПер СодОпер=»Работы выполнены в полном объеме» ДатаПер=»04.07.2022″>

<ОснПер НаимОсн=»Контракт» НомОсн=»999 9999″ ДатаОсн=»14.06.2022″ ДопСвОсн=»Реестровый номер в реестре контрактов: 9999999999999999999″/>

<ТранГруз/>

</СвПер>

</СвПродПер>

<Подписант ОблПолн=»5″ Статус=»4″ ОснПолн=»Должностные обязанности»>

<ИП ИННФЛ=»123456789012″>

<ФИО Фамилия=»ИВАНОВА» Имя=»ОЛЬГА» Отчество=»ВЛАДИМИРОВНА»/>

</ИП>

</Подписант>

</Документ>

</Файл>

prog1Csww

7 — 21.07.22 — 02:18

Ответ техподдержки

Уважаемый пользователь!

Несмотря на то, что в прологе титула продавца указана кодировка <?xml version=»1.0″ encoding=»WINDOWS-1251″?> сведения закодированы в UTF-8.

Просьба сведения, находящиеся в Документ/Контент, формировать в windows-1251, а затем кодировать в base64.

Также отметим, что в загружаемом транспортном пакете отсутствует приложение к титулу продавца (ФайлУПДПрод), которое является составной и неотъемлемой частью УПД (титул продавца) и передается в блоке Прилож/Контент.

Просьба корректно формировать загружаемый xml-файл.

ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку «Обновить» в браузере.

Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.

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

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

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

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

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

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

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

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

Интерфейс каждого сервиса определен в его 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»?>

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>

в результате обработки выражения /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>

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

</pattern>

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

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

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

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

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

</schema>

Примеры

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

<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 при определении правил:

Mastercard card number must be 16 digits.

</assert>

Security code for Mastercard must be 3 digits.

</assert>

</rule>

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

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

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

Security No must be specified

</assert>

</rule>

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

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>

</detail>

</env:Fault>

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

Одним из методов реализации валидации является определение правил валидации как бизнес-правил. Это позволяет определить правила валидации один раз и затем использовать в нескольких сервисах. В свою очередь правила могут быть выставлены как веб-сервис, что позволяет легко использовать их из 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.

Пример:

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

</operation>

</portType>

</operation>

</operation>

</portType>

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

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

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

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

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

Ресурсы

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

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

Источник

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

Источник

Яндекс.Аудитории позволяют создавать сегменты не только на основе данных из Яндекса, но и использовать собственные данные. Например, выгрузить список контактов из CRM или ID мобильных устройств. В этой статье поговорим о распространенных ошибках загрузки файлов.

Яндекс.Аудитории помогают настроить показы рекламных объявлений на собственную аудиторию в Яндекс.Директе, Яндекс.Дисплее и ADFOX. Можно задавать сегмент по существующей базе и персонализировать предложения — познакомить клиентов с новым товаром, запустить кросс-продажи или найти похожих клиентов с помощью технологии Look-alike.

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

Какие ошибки загрузки файлов встречаются

Встречаются две ошибки при загрузке списка с электронными адресами и телефонами:

Ошибка валидации заголовка в файле CRM сегмента;
Количество корректных уникальных элементов меньше, чем 1000.

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

Вторая ошибка более очевидна — загружаемый на сервер документ не соответствует требованием по количество контактов. Исправить проблем легко — нужно расширить число телефонов или эмейлов клиентов до 1 тысячи или более.

В любом случае — перед отправкой файла внимательно проверьте, соответствует ли документ основным рекомендациям Яндекса.

Какие требования Яндекс предъявляет к файлам

Требования к файлам Яндекс описал в официальной справке. Коротко перечислим их и мы:

Формат файла — CSV;
Максимальный размер — 1 Гб;
Требования к формату записей: в первой строке указываются названия полей, отделенные запятой;
Обязательные поля в записях: phone или email;
Количество записей — от 1000;
Кодировка файла — UTF-8 или Windows-1251.

Не забывайте, что в номере телефона нельзя использовать пробелы и дополнительные символы, а в поле email запрещается использовать прописные буквы — используйте только строчные.

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

Правильная таблица с контактами состоит из двух столбцов — phone и email. В номерах телефона запрещено использовать «+», пробелы и круглые скобки, а электронные адреса обязательно в нижним регистре.

Посмотрите на пример таблицы — два столбца с данными.

Список должен быть сохранен в формате CSV (разделители — запятые). Такой формат можно выбрать в Excel при сохранении файла.

Однако не все так просто — в Windows файл часто сохраняется по каким-то собственным правилам: в качестве разделителя вместо запятой ставится точка с запятой. Подмена настраивается на уровне операционной системы. Поэтому загрузка завершается неудачей — мы видим надпись «Ошибка валидации заголовка в файле CRM сегмента».

Как исправить ошибку валидации заголовка в файле CRM сегмента

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

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

В Windows 10: Настройка языка → Дата и время → Формат даты, времени и региона → Дополнительные параметры даты и времени → Изменение форматов даты, времени и чисел → Дополнительные параметры.
В Windows 7: Панель управления → Часы, язык и регионы → Изменение форматов даты, времени и чисел → Дополнительные параметры.

В поле Разделитель элементов списка вместо точки с запятой укажите запятую и примените настройки.

После сохранения вернитесь к исходному файлу с контактами и пересохраните файл в CSV формате еще раз. Если все хорошо, то загрузка списка на сервер Яндекса пройдет без ошибок.

Если же метод не помог и ошибка никуда не делась, то рекомендую открыть документ программой Notepad++ (или стандартным блокнотом Windows) и проверить корректность написания заголовков и разделителей столбцов.

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

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

Если все верно, то сохраняйте файл с данными и загрузите ещё раз в Аудитории. Уверен, что теперь все получится.

Загрузить список в формате XLSX получится?

К сожалению, нет. Формат файлов табличного типа XLSX не подойдет для загрузки контактов в Яндекс.Аудитории. Причины очевидны:

CSV — это стандарт сохранения табличной информации в текстовый файл с разделителями;
CSV не имеют ограничений по строкам, а вот Excel позволит записать не более 1 миллион строк данных;
Файлы в CSV могут быть открыты и прочитаны машинами, а также любым текстовым редактором, с XLSX такое невозможно;
CSV не могут содержать форматированные данные и прочую информацию помимо самих данных.

Заключение

Статья получилась объемной, поэтому в заключение выделю главные правила работы со списками в Яндекс.Аудиториях.

Внимательно проверяйте заголовки и разделители между значениями в строках;
Если список готовите в Excel, то для сохранения файла выберите формат CSV (разделители — запятые);
Проверьте настройки формата разделителя числа в вашей ОС, возможно операционная система по умолчанию проставляет точку с запятой;
Если проблема не решается — откройте файл блокнотом или Нотпадом и проверьте корректность оформление таблицы;
Для загрузки используйте формат CSV, а не XLSX.

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

Что важного в диджитал на этой неделе?

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

Узнать подробнее →

Статьи по теме:

Как убрать фон с картинки без специальных программ и навыков
Как установить Google Optimize с помощью Google Tag Manager
Как настроить расписание показов объявлений в Яндекс Директ
Какая поисковая система быстрее обрабатывает файл robots.txt
Как создать отчет по расписанию в Яндекс.Метрика и Google Analytics с отправкой по электронной почте

Метки #инструменты, #реклама

Источник

Нуф-Нуф

16.01.13 — 21:00

Вот таким кодом пробую прочитать ХМЛ

ЧтениеXML = Новый ЧтениеXML;

ЧтениеXML.ОткрытьФайл(адрес);

Пока ЧтениеXML.Прочитать() Цикл

КонеЦЦикла;

Валится при первой же попытке прочитать на

{Форма.Форма.Форма(162)}: Ошибка при вызове метода контекста (Прочитать)

Пока ЧтениеXML.Прочитать() Цикл

по причине:

Ошибка разбора XML: — [3,37]

Фатальная ошибка:

Specification mandate value for attribute addDa琀愀

SystemId: file://»адрес»

Вот сам ХМЛ

<?xml version=»1.0″ encoding=»unicode»?>

<form:Documents xmlns:form=»http://www.abbyy.com/FlexiCapture/Schemas/Export/FormData.xsd» xmlns:addData=»http://www.abbyy.com/FlexiCapture/Schemas/Export/AdditionalFormData.xsd»>

<_Счет-фактура:_Счет-фактура addData:ImagePath=»Счет-фактура_29.11.2012_16.pdf» xmlns:_Счет-фактура=»http://www.abbyy.com/FlexiCapture/Schemas/Export/Счет-фактура.xsd»>

<_Счет-Фактура>

<_DocNum>034</_DocNum>

<_DocDate>2012-11-29</_DocDate>

<_IssCompany>Общество с ограниченной ответственностью</_IssCompany>

<_IssINN>0000</_IssINN>

<_IssKPP>0000</_IssKPP>

<_DesCompany>Общество с ограниченной ответственностью</_DesCompany>

<_DestINN>0000</_DestINN>

<_DestKPP>0000</_DestKPP>

<_Barcode/>

<_FilePathName>0000</_FilePathName>

</_Счет-Фактура>

</_Счет-фактура:_Счет-фактура>

</form:Documents>

Нуф-Нуф

1 — 16.01.13 — 21:01

сам хмл в ИЕ открывается отлично

Нуф-Нуф

2 — 16.01.13 — 21:03

валится на второй попытке прочитать

Нуф-Нуф

3 — 16.01.13 — 21:07

удалил «addData:ImagePath=»Счет-фактура_29.11.2012_16.pdf»»

стал валится на следующем атрибуте «xmlns:_Счет-фактура=»http://www.abbyy.com/FlexiCapture/Schemas/Export/Счет-фактура.xsd»»

{Форма.Форма.Форма(162)}: Ошибка при вызове метода контекста (Прочитать)

Пока ЧтениеXML.Прочитать() Цикл

по причине:

Ошибка разбора XML: — [3,35]

Фатальная ошибка:

Specification mandate value for attribute xmlns

SystemId: file:////test1/IGabdrakhmanov/Счет-фактура_29.11.2012_16.xml

Нуф-Нуф

4 — 16.01.13 — 21:07

что это? косяк подготовки в хмл в стороннем ПО?

Займись делом

5 — 16.01.13 — 21:19

А каково содержание файла «Счет-фактура.xsd»? Ощущение, что какого-то параметра не хватает.

Нуф-Нуф

6 — 16.01.13 — 21:23

(5) хм. а как узнать содержание этого файла?

Займись делом

7 — 16.01.13 — 21:31

(6) Не обращай внимание на (5). Бред я там написал

ChMikle

8 — 16.01.13 — 21:32

(6) м.б. какие-то символы есть в этих строках, которые раньше узел закрывают ?

lefthander

9 — 16.01.13 — 21:35

(0) А что внутри цикла? Как вы узлы считываете?

Нуф-Нуф

10 — 16.01.13 — 21:36

оставил файл таким

<?xml version=»1.0″ encoding=»unicode»?>

<form>

<_Счет-фактура>

<_Счет-Фактура>

<_DocNum>034</_DocNum>

<_DocDate>2012-11-29</_DocDate>

<_IssCompany>Общество с ограниченной ответственностью</_IssCompany>

<_IssINN>0000</_IssINN>

<_IssKPP>0000</_IssKPP>

<_DesCompany>Общество с ограниченной ответственностью</_DesCompany>

<_DestINN>0000</_DestINN>

<_DestKPP>0000</_DestKPP>

<_Barcode/>

<_FilePathName>0000</_FilePathName>

</_Счет-Фактура>

</_Счет-фактура>

</form>

теперь валится на

{Форма.Форма.Форма(176)}: Ошибка при вызове метода контекста (Прочитать)

Пока ЧтениеXML.Прочитать() Цикл

по причине:

Ошибка разбора XML: — [10,9]

Фатальная ошибка:

error parsing attribute name

SystemId: file://»адрес»

Нуф-Нуф

11 — 16.01.13 — 21:36

(9) ничего. просто прочитать узел за узлом

lefthander

12 — 16.01.13 — 21:41

(11) попробуйте посмотреть, хоть в коде типовой, как это происходит.

У объекта ЧтениеXML много разных методов и свойств, одно из них значение, это как раз то куда выводятся значения узлов.

А у вас они куда выводятся?

В том виде как у вас ничего и не будет, кроме ошибок.

Нуф-Нуф

13 — 16.01.13 — 21:43

(12) для с чего это. у меня просто читаются узлы. самый простой код

Нуф-Нуф

14 — 16.01.13 — 21:43

валидатор на http://www.w3schools.com/xml/xml_validator.asp говорит

This page contains the following errors:

error on line 3 at column 181: xmlns:_?????°????????????_???????µ??: ‘http://www.abbyy.com/FlexiCapture/Schemas/Export/?????°????????????_???????µ??.xsd’ is not a valid URI

Нуф-Нуф

15 — 16.01.13 — 21:47

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

Нуф-Нуф

16 — 16.01.13 — 21:50

может есть какой-нить форум фанатов ХМЛ?

alexei366

17 — 16.01.13 — 21:51

Мож кодировку у ЧтенияXML поставить, хотя наврятли поможет

Займись делом

18 — 16.01.13 — 21:52

Вопрос: браузером xml открывает?

Займись делом

19 — 16.01.13 — 21:53

Посмотрел в Юникоде 琀愀 — символы китайского алфавита… или японского кто их разберёт. Если браузер тоже не открывает, попробуй удалить <?xml version=»1.0″ encoding=»unicode»?>

Займись делом

20 — 16.01.13 — 21:55

Вроде прочитал у меня (что он там начитал уже другой вопрос)

Нуф-Нуф

21 — 16.01.13 — 22:00

в браузере ИЕ открывается

Займись делом

22 — 16.01.13 — 22:05

В итоге помогло следующее:

Взять xml представленный в первом сообщении, кроме строки «<?xml version=»1.0″ encoding=»unicode»?>», сохранить с помощью блокнота в кодировке UTF-8.

Нуф-Нуф

23 — 16.01.13 — 22:13

(22) спасибо!!!

заменил строчку на <?xml version=»1.0″ encoding=»UTF-8″?> и пересохранил в формате UTF-8

Нуф-Нуф

24 — 16.01.13 — 22:24

Всем большое спасибо за помощь!

Сейчас меня спас код

Текст = Новый ТекстовыйДокумент;

Текст.Прочитать(адрес);

СтрокаТекста = Текст.ПолучитьТекст();

СтрокаТекста = СтрЗаменить(СтрокаТекста,»unicode», «UTF-8»);

Текст.УстановитьТекст(СтрокаТекста);

Текст.Записать(адрес, КодировкаТекста.UTF8);

Источник

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

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

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

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

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

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

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

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

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

<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 цифры.

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

Пример:

<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 для валидации

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

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

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

Credit Card must be MasterCard or Visa

</assert>

</rule>

</pattern>

</schema>

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

Пример:

</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>

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

</rule>

</pattern>

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

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

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

</schema>

Примеры

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

<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 при определении правил:

Mastercard card number must be 16 digits.

</assert>

Security code for Mastercard must be 3 digits.

</assert>

</rule>

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

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

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

Security No must be specified

</assert>

</rule>

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

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>

</detail>

</env:Fault>

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

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

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

faultcode: высокоуровневый указатель на причину ошибки. SOAP 1.1 определяет следующие faultcode:
— VersionMistmatch,
— MustUnderstand,
— Client
— Server.
Если ошибка в содержимом сообщения, полученного от клиента, и клиент должен исправить данную ошибку, то необходимо вернуть Client.
faultstring: должен содержать понятное человеку описание причины возникновения ошибки.
faultactor: описывает в какой точке пути обработки сообщения произошла ошибка. Если ошибка происходит в конечной точке обработки сообщения, то значение данного параметра можно оставить пустым.
detail: опциональный элемент, который используется для предоставления дополнительной информации об ошибке. Необходимо заполнять только если faultstring содержит не всю подробную информацию о причинах ошибки.

Пример:

</operation>

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

</operation>

</portType>

</operation>

</operation>

</portType>

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

Ресурсы

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

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

Источник