Описываем типы запросной и ответных частей основной xsd-схемы

Запросная часть вида сведений

Первым шагом при разработке XSD-схемы (далее - схема) является определение пространства имен.

Необходимо сформировать уникальное пространство имен (target namespace). Если у ведомства – владельца ВС – уже есть зарегистрированные в СМЭВ ВС, то базовую часть URI пространства имен, относящуюся к ведомству, необходимо взять оттуда. При регистрации вида сведений уникальность будет проверена отдельно.

В нашем примере URI пространства имен в части ведомства будет urn://x-artefacts-oiv001.

ВС предназначен для работы с заявлениями на лицензии, поэтому добавляем к URI ведомства слово license – urn://x-artefacts-oiv001/license.

Пространство имен должно содержать номер версии ВС. Мы разрабатываем самую первую версию ВС, поэтому окончательный URI нашего пространства имен будет иметь вид - urn://x-artefacts-oiv001/license/1.0.0.

Теперь мы можем написать заголовок нашей схемы:

Схемы без указания target namespace запрещено использовать в СМЭВ. Поэтому добавляем в заголовок атрибут targetNamespace="urn://x-artefacts-oiv001/license/1.0.0".
   
Запрещено использование в схемах объявлений элементов в unqualified-форме. Поэтому в заголовке нашей схемы присутствует атрибут elementFormDefault="qualified". К атрибутам запрет unqualified-формы не относится, поэтому attributeFormDefault="unqualified".
 
Создадим два корневых элемента нашей схемы – запросную и ответную части вида сведений.
 
По традиции элемент запросной части называется request, а элемент ответной части – response.
 
А для того, чтобы показать, что наш Вид сведений имеет дело с лицензиями, добавим в названия обоих элементов слово license:
 

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

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

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

Предположим, что ответчик все обязательные атрибуты нового лицензиата будет получать из ЕГРЮЛ по ОГРН:

 

Поэтому мы оставляем в нашем запросе только ОРГН и наименование юридического лица – лицензиата.
  
Это конечные элементы в данной ветке схемы, поэтому им необходимо присвоить типы данных.
 
На данном этапе разработки ВС пусть это будут типы xs:string для обоих, хотя, например, у ОГРН есть определенные ограничения по длине и содержимому, но эти детали будут рассмотрены позже.
 
Для срока действия лицензии, как и для любого другого периода времени, необходимо указать даты начала и окончания действия этого периода:
   
 
Типы данных обоих дат – xs:date.
 

Схемы с заполненной запросной частью приведена в файле Request.xsd

Ответная часть вида сведений

Как уже было сказано ранее, в ответе на заявление на выдачу заявления мы возвращаем номер лицензии (тип данных xs:string) и дату выдачи лицензии (тип данных xs:date):     

   
Эти атрибуты ИС инициатора сможет сохранить в своей БД как альтернативный ключ лицензии, который потом сможет использовать для каких-либо операций с лицензией, например передать в заявлении на аннулирование лицензии, если у лицензиата возникнет такая потребность. Но при этом он уже должен будет воспользоваться другим ВС, который в нашем примере не рассматривается.
  
Информация о нарушениях сроков подачи заявлений (см. бизнес-правила в описании примера) должна передаваться потребителю ВС в разделе RequestRejected СМЭВ-конверта. А информация о том, что ведомство-ответчик приняло отрицательное решение по заявлению (по каким-либо причинам, описанным в нормативно-правовых актах ведомства) – в разделе RequestStatus СМЭВ-конверта. 
   
При подготовке схемы ответной части ВС не следует включать схему сообщения поля для статусов обработки заявления и ошибок, выявленных в процессе форматно-логического контроля запросов.
 
Для этих целей должны использоваться специальные поля конверта СМЭВ SendResponseRequest – RequestRejected для ошибок ФЛК и RequestStatus для состояний заявления:

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

Схема с запросной и ответной частями приведена в RequestResponse.xsd.