Решение Коллегии Евразийской экономической комиссии от 27.01.2015 № 5

«Об утверждении Правил электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли»

КОЛЛЕГИЯ ЕВРАЗИЙСКОЙ ЭКОНОМИЧЕСКОЙ КОМИССИИ

РЕШЕНИЕ

от 27 января 2015 г. № 5

ОБ УТВЕРЖДЕНИИ ПРАВИЛ ЭЛЕКТРОННОГО ОБМЕНА ДАННЫМИ В ИНТЕГРИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ ВНЕШНЕЙ И ВЗАИМНОЙ ТОРГОВЛИ

В рамках реализации Концепции создания Интегрированной информационной системы внешней и взаимной торговли Таможенного союза, утвержденной Решением Межгосударственного Совета Евразийского экономического сообщества от 19 ноября 2010 г. № 60, и в соответствии с пунктами 3 и 30 Протокола об информационно-коммуникационных технологиях и информационном взаимодействии в рамках Евразийского экономического союза (приложение № 3 к Договору о Евразийском экономическом союзе от 29 мая 2014 года) Коллегия Евразийской экономической комиссии решила:

1. Утвердить прилагаемые Правила электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли.

2. Настоящее Решение вступает в силу по истечении 30 календарных дней с даты его официального опубликования.

ПРАВИЛА ЭЛЕКТРОННОГО ОБМЕНА ДАННЫМИ В ИНТЕГРИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ ВНЕШНЕЙ И ВЗАИМНОЙ ТОРГОВЛИ

I. Общие положения

1. Настоящие Правила определяют основные принципы и механизмы электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли (далее — интегрированная система).

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

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

4. Понятия, используемые в настоящих Правилах, означают следующее:

«MIME» (Multipurpose Internet Mail Extensions) — спецификация для кодирования и форматирования информации для ее передачи внутри текстовых данных;

«SOAP» (Simple Object Access Protocol) — протокол обмена сообщениями в распределенной вычислительной среде;

«UUID» (Universally Unique Identifier) — универсальный уникальный идентификатор;

«UTC» (Coordinated Universal Time) — стандарт всемирного координированного времени;

«URI» (Uniform Resource Identifier) — формат унифицированной идентификации ресурсов;

«XML» (eXtensible Markup Language) — рекомендованный Консорциумом Всемирной паутины (W3C) расширяемый язык разметки;

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

«инициатор» — участник электронного обмена данными, инициирующий транзакцию общего процесса;

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

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

«респондент» — участник электронного обмена данными, обменивающийся сообщениями с инициатором в рамках выполнения транзакции общего процесса;

«сообщение» — формализованная информация, передаваемая от отправителя к получателю с помощью информационно-телекоммуникационной сети;

«транзакция общего процесса» — элементарное информационное взаимодействие между двумя участниками, которое осуществляется каждым участником в рамках своей операции общего процесса;

«участник общего процесса» — участник электронного обмена данными в рамках общего процесса;

«участник электронного обмена данными» — Комиссия, уполномоченный орган, участвующий в электронном обмене данными.

Понятия «доверенная третья сторона», «национальный сегмент государства-члена», «интеграционный сегмент Комиссии», «общий процесс в рамках Союза» и «уполномоченный орган» используются в настоящих Правилах в значениях, определенных Протоколом об информационно-коммуникационных технологиях и информационном взаимодействии в рамках Евразийского экономического союза (приложение № 3 к Договору о Евразийском экономическом союзе от 29 мая 2014 года).

5. Электронный обмен данными в интегрированной системе осуществляется между национальными сегментами государств-членов, а также между национальными сегментами государств-членов и интеграционным сегментом Комиссии в соответствии с приложением № 3 к Договору о Евразийском экономическом союзе от 29 мая 2014 года, иными международными договорами и актами, составляющими право Союза, предусматривающими обмен информацией в электронной форме.

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

а) государственные информационные системы государств-членов и информационные системы уполномоченных органов;

б) информационные системы Комиссии.

7. Государственные информационные системы государств-членов, участвующие в электронном обмене данными с информационными системами других государств-членов и Комиссии, логически входят в состав национальных сегментов государств-членов.

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

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

Основной функцией интеграционного шлюза интеграционного сегмента Комиссии является маршрутизация сообщений.

10. В состав национальных сегментов государств-членов и интеграционного сегмента Комиссии входят сервисы доверенной третьей стороны, обеспечивающие легализацию, гарантии доверия и правомерность применения цифровых подписей (электронных подписей) при электронном обмене данными, осуществляемом с помощью средств интегрированной системы. Реализация сервисов доверенной третьей стороны осуществляется с учетом Концепции использования при межгосударственном информационном взаимодействии сервисов и имеющих юридическую силу электронных документов, утвержденной Решением Совета Евразийской экономической комиссии от 18 сентября 2014 г. № 73.

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

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

II. Процедуры электронного обмена данными

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

Процедуры электронного обмена данными на транспортном уровне обеспечивают доставку данных от системы одного участника до системы другого участника посредством транспортных протоколов доставки данных, таких как HTTP, SMTP, MQ, FTP и др.

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

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

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

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

14. Электронный обмен данными между интеграционными шлюзами на технологическом уровне выполняется посредством сообщений в формате SOAP.

Требования к структуре и формату сообщений, а также порядок обмена сообщениями на технологическом уровне устанавливаются в соответствии с разделами IV и V настоящих Правил.

15. При выполнении процедур электронного обмена данными на прикладном уровне при реализации общих процессов структура и формат данных прикладного уровня, а также порядок такого обмена устанавливаются в соответствии с разделами V и VI настоящих Правил и технологическими документами, регламентирующими информационное взаимодействие при реализации средствами интегрированной информационной системы общих процессов, перечень которых утвержден Решением Коллегии Евразийской экономической комиссии от 6 ноября 2014 г. № 200 (далее — технологические документы, регламентирующие информационное взаимодействие).

III. Ответственность за выполнение процедур электронного обмена данными

16. В зону ответственности национального сегмента государства-члена входит участок передачи данных от интеграционного шлюза национального сегмента государства-члена до системы участника электронного обмена данными включительно.

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

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

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

IV. Структура и формат сообщений

1. Общие требования

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

19. Сообщение в формате SOAP, передаваемое между интеграционными шлюзами на технологическом уровне, оформляется в соответствии со спецификацией SOAP 1.2 и состоит из блока заголовков (soap:Header) и блока содержимого (soap:Body).

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

22. Сообщение может содержать одно двоичное вложение или более. Двоичные вложения могут быть внедрены в блок содержимого сообщения в формате Base64 (согласно RFC 4648) или оформлены в виде отдельных MIME-частей.

23. При передаче двоичных вложений в виде отдельных MIME-частей внутри блока содержимого сообщения создается ссылка на MIME-часть согласно спецификации XML-binary Optimized Packaging.

24. MIME-части сообщения используются исключительно для оптимизации процессов передачи сообщения. Обработка сообщения должна осуществляться согласно модели обработки XOP спецификации XML-binary Optimized Packaging.

25. Рекомендуется оформлять двоичные вложения в виде MIME-частей в том случае, если размер двоичного вложения превышает 2 Мб.

26. При формировании сообщения и содержимого всех его блоков должна использоваться кодировка UTF-8.

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

1 — реквизит является обязательным, повторений не допускается;

n — реквизит является обязательным, должен повторяться n раз, при этом n > 1;

0..1 — реквизит является опциональным, повторений не допускается;

0..* — реквизит является опциональным, может повторяться без ограничений;

0..m — реквизит является опциональным, может повторяться не более m раз, при этом m > 1;

1..* — реквизит является обязательным, может повторяться без ограничений;

n..* — реквизит является обязательным, должен повторяться не менее n раз, при этом n > 1;

n..m — реквизит является обязательным, должен повторяться не менее n раз и не более m раз, при этом n > 1, m > n.

Символом «@» обозначается атрибут элемента XML. Элементы XML специальными символами не обозначаются.

2. Структура блока заголовков

28. Блок заголовков содержит заголовки в соответствии со спецификацией WS-Addressing 1.0 — Core, а также специализированные заголовки интегрированной системы.

29. Блок заголовков включает в себя следующие заголовки:

а) wsa:To — заголовок, содержащий сведения о получателе;

б) набор заголовков, идентифицирующих отправителя:

wsa:ReplyTo — заголовок, содержащий логический адрес отправителя, на который должно быть направлено сообщение-ответ;

wsa:From — заголовок, содержащий логический адрес отправителя, на который не может быть направлено сообщение-ответ;

wsa:FaultTo — заголовок, содержащий логический адрес отправителя, на который должны быть направлены технологические сообщения об ошибках;

в) wsa:MessageID — заголовок, содержащий идентификатор сообщения;

г) wsa:RelatesTo — заголовок, содержащий ссылочный идентификатор сообщения;

д) wsa:Action — заголовок, идентифицирующий содержимое сообщения;

е) int:ProcedureID — заголовок, идентифицирующий экземпляр процедуры общего процесса;

32. Заголовок wsa:ReplyTo предназначен для обеспечения возможности формирования получателем сообщения-ответа для отправителя. Логический адрес отправителя указывается в элементе wsa:Address заголовка wsa:ReplyTo.

33. Заголовок wsa:From предназначен для передачи сведений об отправителе исходного сообщения. Логический адрес, идентифицирующий отправителя, указывается в элементе wsa:Address заголовка wsa:From.

34. Если заголовок wsa:From не заполнен, отправитель идентифицируется по заголовку wsa:ReplyTo.

35. Заголовок wsa:FaultTo предназначен для обеспечения возможности передачи технологических сообщений об ошибках на логический адрес, отличный от того, который указывается в поле wsa:ReplyTo. Логический адрес, используемый отправителем для приема технологических сообщений об ошибках, указывается в элементе wsa:Address заголовка wsa:FaultTo.

Если заголовок wsa:FaultTo не заполнен, технологические сообщения об ошибках направляются участнику электронного обмена данными, в адрес которого должно быть направлено сообщение-ответ (wsa:ReplyTo/wsa: Address).

36. Заголовок wsa:MessageID предназначен для уникальной идентификации отдельных экземпляров сообщений. Заголовок wsa:MessageID обязателен для заполнения.

Значения идентификаторов сообщений должны быть глобально уникальными и представлять собой UUID согласно спецификации RFC 4122.

37. Заголовок wsa:RelatesTo предназначен для организации цепочек сообщений.

Заголовок wsa:RelatesTo должен содержать значение заголовка wsa:MessageID исходного сообщения. При этом заголовок wsa:MessageID должен заполняться новым значением.

38. Заголовок wsa:Action предназначен для информирования участников электронного обмена данными о семантике данных, передаваемых в теле сообщения. Заголовок wsa:Action обязателен для заполнения.

39. Заголовок int:ProcedureID предназначен для уникальной идентификации экземпляра процедуры общего процесса, в рамках выполнения которой отправлено сообщение. Заголовок используется для целей мониторинга электронного обмена данными при реализации общих процессов.

Заголовок int:ProcedureID формируется в соответствии со структурой, приведенной в таблице 3, и схемой данных согласно приложению № 2.

Значение заголовка представляет собой строку, состоящую из компонентов, разделенных символом «/». Каждый компонент представляет собой UUID согласно спецификации RFC 4122.

Строка заголовка int:ProcedureID формируется в соответствии со следующими правилами:

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

если участник общего процесса инициирует вложенную процедуру, к значению заголовка int:ProcedureID добавляется символ «/» и новый компонент UUID, идентифицирующий вложенную процедуру;

при электронном обмене сообщениями между участниками общего процесса в рамках одной процедуры (вложенной процедуры) значение заголовка int:ProcedureID такими участниками не меняется.

40. Заголовок int:ConversationID предназначен для уникальной идентификации экземпляра транзакции общего процесса, в рамках реализации которой отправлено сообщение.

Заголовок int:ConversationID формируется в соответствии со структурой, приведенной в таблице 4, и схемой данных заголовка в соответствии с приложением № 2 к настоящим Правилам.

Значение идентификатора экземпляра транзакции общего процесса должно быть уникальным и представлять собой UUID согласно спецификации RFC 4122.

41. Служебный заголовок интеграционной платформы интегрированной системы int:Integration обеспечивает идентификацию сообщения в пределах интеграционной платформы интегрированной системы и формируется (заполняется) компонентами уровня интеграционной платформы интегрированной системы.

42. Служебный заголовок интегрированной системы int:Integration формируется в соответствии со структурой, приведенной в таблице 5, и схемой данных заголовка int:Integration в соответствии с приложением № 2 к настоящим Правилам.

43. Для идентификации сообщения внутри интеграционной платформы интегрированной системы используется технологический идентификатор сообщения int:TrackID.

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

Значение технологического идентификатора является уникальным и представляет собой UUID согласно RFC 4122.

44. Элемент int:AcceptTime содержит дату и время приема сообщения интеграционной платформой интегрированной системы. Значение элемента формируется при приеме сообщения и в дальнейшем не меняется при передаче сообщения. Время должно быть указано в формате всемирного координированного времени (UTC) с указанием часового пояса.

3. Формирование логических адресов участников электронного обмена данными

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

46. Формат логического адреса участника электронного обмена данными определяется в соответствии со спецификацией RFC 3986 и состоит из следующих компонентов:

а) фиксированный префикс «EAEU://»;

б) компоненты адреса, разделенные символом «/».

47. Компонентами адреса являются:

а) идентификатор сегмента;

б) идентификатор пространства логических адресов участников электронного обмена данными;

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

а) CP (Common Process) — пространство логических адресов участников общего процесса;

б) CA (Competent Authority) — пространство логических адресов, используемых для идентификации органов государственной власти государств-членов либо уполномоченных ими организаций, а также Комиссии;

в) SR (SeRvice) — пространство логических адресов, используемых для идентификации компонентов интеграционной платформы интегрированной системы, информационных систем Комиссии, функциональных и обеспечивающих подсистем интегрированной системы.

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

Идентификатор участника общего процесса для пространства CP состоит из следующих компонентов, разделенных символом «/»:

код общего процесса;

кодовое обозначение участника общего процесса;

идентификатор органа государственной власти государства-члена либо уполномоченной им организации.

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

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

53. Идентификаторы органов государственной власти государства-члена либо уполномоченных ими организаций заполняются в соответствии с перечнем органов государственной власти государств-членов и перечнем уполномоченных ими организаций, которые ведутся Комиссией совместно с уполномоченными органами в порядке, определяемом Коллегией Комиссии.

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

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

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

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

Для целей однозначной идентификации интеграционных шлюзов при реализации электронного обмена данными за интеграционным шлюзом в пространстве SR закрепляется идентификатор gate.

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

4. Особенности формирования прикладных сообщений

57. Прикладное сообщение представляет собой сообщение, в блоке содержимого которого передаются данные прикладного уровня.

58. При формировании блока заголовков прикладного сообщения, передаваемого в рамках реализации общего процесса, заголовки wsa:From и wsa:FaultTo формироваться не должны.

59. Заголовок wsa:Action прикладного сообщения, передаваемого в рамках реализации общего процесса, заполняется унифицированным идентификатором ресурса (URI), состоящим из следующих компонентов, разделенных символом «/»:

а) фиксированный префикс «int://»;

б) идентификатор CP;

в) компоненты сведений о содержимом сообщения.

60. Компоненты сведений о содержимом сообщения указываются в следующем порядке:

а) код общего процесса, определенный в правилах информационного взаимодействия для каждого общего процесса;

б) версия общего процесса, определенная в правилах информационного взаимодействия для каждого общего процесса;

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

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

д) код сообщения общего процесса, определенный в соответствующем регламенте информационного взаимодействия.

61. Порядок использования заголовков wsa:MessageID и wsa:RelatesTo для прикладных сообщений, передаваемых в рамках реализации общего процесса, зависит от порядка выполнения транзакций общего процесса и приводится в разделе VI настоящих Правил.

62. Прочие заголовки блока заголовков прикладного сообщения, передаваемого в рамках реализации общего процесса, должны заполняться в соответствии с правилами, приведенными в подразделе 2 раздела IV настоящих Правил.

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

Пример прикладного сообщения приведен в приложении № 3.

5. Особенности формирования служебных сообщений

64. К классу служебных сообщений относятся:

а) технологические сообщения об ошибке;

б) служебные сообщения интегрированной системы.

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

Технологическое сообщение об ошибке представляет собой SOAP-сообщение Fault, оформленное согласно спецификации SOAP 1.2. Пример технологического сообщения об ошибке приведен в приложении № 3 к настоящим Правилам.

66. Заголовок wsa:To технологического сообщения об ошибке должен быть заполнен значением wsa:FaultTo/wsa:Address исходного сообщения, если данный заголовок присутствовал в исходном сообщении, либо значением wsa:ReplyTo/wsa:Address, если заголовок wsa:FaultTo/wsa:Address в исходном сообщении отсутствовал.

67. Для идентификации отправителя технологического сообщения об ошибке должен использоваться заголовок wsa:From.

68. Заголовок wsa:RelatesTo технологического сообщения об ошибке должен содержать атрибут int:RelatesAction типа xs:anyURI. Указанный атрибут должен содержать значение заголовка wsa:Action сообщения, на которое формируется данное технологическое сообщение об ошибке. Схема данных атрибута int:RelatesAction приведена в приложении № 2 к настоящим Правилам.

69. Заголовки wsa:ReplyTo и wsa:FaultTo для технологических сообщений об ошибке формироваться не должны.

70. Заголовок wsa:Action технологического сообщения об ошибке должен содержать одно из следующих значений:

а) для технологических сообщений об ошибках, предусмотренных спецификацией WS-Addressing 1.0 — Binding, — значение http://www.w3.org/2005/08/addressing/fault;

б) для прочих технологических сообщений об ошибках — значение http://www.w3.org/2005/08/addressing/soap/fault.

71. Прочие заголовки блока заголовков технологического сообщения об ошибке должны заполняться согласно правилам, приведенным в подразделе 2 раздела IV настоящих Правил.

72. Блок содержимого технологического сообщения об ошибке должен содержать элементы, набор которых представлен в таблице 7.

Таблица 7

73. Элемент soap:Code/soap:Value должен заполняться согласно требованиям спецификации SOAP 1.2.

74. Элемент soap:Code/soap:Subcode/soap:Value должен содержать код ошибки.

Перечень типовых кодов ошибок и правила использования кодов спецификации WS-Addressing 1.0 — Binding представлены в таблице 8.

75. Элемент soap:Text должен содержать текстовое описание ошибки.

Каждый элемент soap:Text должен содержать языковой идентификатор xml:lang, формируемый согласно спецификации XML 1.0.

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

В технологическом сообщении об ошибке должен присутствовать хотя бы один элемент soap:Text, содержимое которого представлено на русском языке, а языковой идентификатор xml:lang должен содержать значение ru.

76. Необязательный элемент soap:Detail должен содержать информацию, детализирующую ошибку.

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

вкладываемое сообщение обрамляется тегами CDATA согласно правилам спецификации XML 1.0;

полученная на первом шаге конструкция вкладывается в элемент int:ProblemMessage;

полученная на втором шаге конструкция вкладывается в элемент soap:Detail.

Схема данных заголовка элемента int:ProblemMessage приведена в приложении N 2 к настоящим Правилам.

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

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

Элемент wsa:Action служебного сообщения интегрированной системы должен заполняться унифицированным идентификатором ресурса (URI), состоящим из следующих компонентов, разделенных символом "/":

фиксированный префикс "int://";

идентификатор SR;

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

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

V. Порядок электронного обмена сообщениями

1. Сценарий передачи сообщения

78. Сегменты интегрированной системы должны поддерживать следующий унифицированный сценарий передачи сообщения:

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

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

в) интеграционным шлюзом получателя выполняются обработка сообщения и передача сообщения получателю;

г) получателем выполняется обработка сообщения.

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

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

81. Положения разделов V и VI настоящих Правил определяют унифицированный порядок электронного обмена данными между участниками электронного обмена данными без учета национальной специфики.

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

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

2. Формирование сообщений в национальных форматах

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

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

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

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

3. Передача сообщений интеграционными шлюзами

87. Для обеспечения совместимости способов обмена и форматов данных технологического уровня интеграционные шлюзы должны обеспечивать соблюдение правил, определенных спецификацией WS-I Basic Profile Version 2.0 (WS-I Basic Profile Version 2.0. Final Material. 2010-11-09. http://www.ws-i.org/Profiles/BasicProfile-2.0.html).

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

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

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

4. Обработка сообщения получателем

91. Обработка сообщения выполняется получателем в соответствии со следующими типовыми стадиями:

а) технологический контроль сообщения;

б) структурный контроль блока содержимого;

в) форматно-логический контроль блока содержимого;

г) обработка данных блока содержимого.

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

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

93. Структурный контроль блока содержимого заключается в проверке его структуры на соответствие установленным структурам данных (контроль по XSD-схеме).

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

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

Уведомление получателя о возникших ошибках стадий структурного контроля блока содержимого, форматно-логического контроля блока содержимого и обработки данных блока содержимого осуществляется в порядке и способами, которые определены в разделе VI настоящих Правил.

VI. Порядок информационного взаимодействия при реализации общих процессов

1. Транзакции общего процесса

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

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

98. В рамках транзакций общего процесса осуществляется обмен сообщениями по типовым шаблонам, описание которых приведено в подразделах 4 - 9 настоящего раздела.

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

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

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

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

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

Описание сигналов-подтверждений и сигналов-исключений приведено в подразделе 3 настоящего раздела.

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

При повторной отправке сообщения должен формироваться новый идентификатор сообщения wsa:MessageID.

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

102. Для обеспечения связи между сообщениями внутри транзакций у всех сообщений общего процесса, за исключением сообщения, инициирующего транзакцию общего процесса, заполняется поле wsa:RelatesTo.

Поле wsa:RelatesTo содержит идентификатор сообщения wsa:MessageID, полученного участником общего процесса на предыдущем этапе выполнения транзакции общего процесса (рисунок 1).

<pre class="legal-pre">┌───────────┐                                                 ┌───────────┐
│:инициатор │                                                 │:респондент│
└─────┬─────┘                                                 └─────┬─────┘</pre>

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

2. Параметры транзакции общего процесса

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

«Время для подтверждения получения»;

«Время для подтверждения принятия в обработку»;

«Время для ответа»;

«Количество повторов».

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

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

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

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

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

107. Параметр «Время для ответа» задает максимальный промежуток времени между отправкой сообщения общего процесса (сообщения-запроса) инициатором и временем получения им от респондента сообщения-ответа с информацией, представляющей результат обработки сообщения-запроса (сообщения-ответа).

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

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

109. Параметр «Количество повторов» задает максимальное количество повторов отправки сообщения общего процесса.

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

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

3. Сигналы-подтверждения и сигналы-исключения

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

Сигналы-подтверждения и сигналы-исключения формируются в соответствии с описанием структуры и реквизитного состава согласно приложению № 5 и схемой данных согласно приложению № 6.

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

114. Сигнал-подтверждение «Получено» посылает получатель сообщения общего процесса в тот момент, когда выполнена стадия структурного контроля блока содержимого.

При формировании заголовка wsa:Action, идентифицирующего содержимое сообщения общего процесса, для сигнала-подтверждения «Получено» используется код сообщения P.MSG.RCV. Остальные компоненты сведений о содержимом сообщения указываются в соответствии с правилами формирования заголовка wsa:Action для прикладных сообщений.

115. Сигнал-подтверждение «Принято в обработку» посылает получатель сообщения общего процесса перед выполнением стадии обработки данных блока содержимого.

При формировании заголовка wsa:Action, идентифицирующего содержимое сообщения общего процесса, для сигнала-подтверждения «Принято в обработку» используется код сообщения P.MSG.PRS. Остальные компоненты сведений о содержимом сообщения указываются в соответствии с правилами формирования заголовка wsa:Action для прикладных сообщений.

116. Ситуации, когда получатель сообщения направляет отправителю сигнал-исключение «Ошибка» независимо от используемого шаблона транзакции, возникают в следующих случаях:

а) получатель принял сообщение общего процесса, которое не ожидал получить при выполнении транзакции общего процесса;

б) получатель обнаружил ошибки при проведении структурного контроля блока содержимого либо форматно-логического контроля блока содержимого;

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

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

полученное сообщение является сообщением общего процесса либо сигналом-подтверждением и при этом не относится к выполняемым получателем транзакциям;

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

В указанных случаях кодовому обозначению ошибки контроля (поле sgn:Code) сигнала-исключения «Ошибка» присваивается значение (код) «Common:UnexpectedMessage».

118. В случае обнаружения получателем ошибки при проведении структурного контроля блока содержимого кодовому обозначению ошибки контроля (поле sgn:Code) сигнала-исключения «Ошибка» присваивается значение (код) «Common:DataError».

119. В случае обнаружения получателем ошибки при проведении форматно-логического контроля сообщения общего процесса кодовому обозначению ошибки контроля (поле sgn:Code) сигнала-исключения «Ошибка» присваивается значение кода правила, при проверке которого возникла ошибка, согласно регламенту информационного взаимодействия.

120. В случае возникновения ситуации, когда на стадии обработки данных блока содержимого возникла неустранимая ошибка, которая не позволяет выполнить обработку данных, кодовому обозначению ошибки контроля (поле sgn:Code) сигнала-исключения «Ошибка» присваивается значение (код) «Common:FatalError».

Перечень неустранимых ошибок определяется участником общего процесса самостоятельно.

121. При формировании заголовка wsa: Action, идентифицирующего содержимое сообщения общего процесса, для сигнала-исключения «Ошибка» используется код сообщения P.MSG.ERR. Остальные компоненты сведений о содержимом сообщения указываются в соответствии с правилами формирования заголовка wsa:Action для прикладных сообщений.

4. Транзакция по шаблону «Взаимные обязательства»

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

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

123. Инициатор отправляет респонденту сообщение-запрос в рамках транзакции общего процесса.

Респондент должен отправить сообщение-ответ до истечения времени, определенного как время для ответа.

В процессе выполнения транзакции общего процесса оба участника общего процесса должны отправлять друг другу сигналы-подтверждения «Получено» и «Принято в обработку».

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

инициатор отправляет в адрес респондента сообщение-запрос и ждет подтверждения получения запроса до истечения времени, определенного как время для подтверждения получения;

респондент принимает сообщение-запрос и отправляет инициатору сигнал-подтверждение «Получено»;

инициатор после обработки принятого им от респондента сигнала-подтверждения «Получено» ждет подтверждения принятия в обработку информации, содержащейся в сообщении-запросе, до истечения времени, определенного как время для подтверждения обработки;

респондент проводит контроль данных, содержащихся в сообщении-запросе, в соответствии с регламентом информационного взаимодействия и подтверждает принятие в обработку полученной им информации, посылая инициатору сигнал-подтверждение «Принято в обработку»;

инициатор после обработки полученного им от респондента сигнала-подтверждения «Принято в обработку» ждет получения сообщения-ответа с информацией до истечения времени, определенного как время для получения ответа;

респондент обеспечивает обработку принятого сообщения-запроса и отправляет инициатору сообщение-ответ, после чего ждет подтверждения инициатором получения сообщения-ответа до истечения времени, определенного как время для подтверждения получения;

инициатор принимает сообщение-ответ с информацией и как получатель информации подтверждает получение ответа, посылая респонденту сигнал-подтверждение «Получено»;

респондент после обработки принятого им от инициатора сигнала-подтверждения «Получено» ждет подтверждения принятия в обработку информации, содержащейся в сообщении-ответе, до истечения времени, определенного как время для подтверждения обработки;

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

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

Последовательность выполнения транзакции общего процесса по шаблону «Взаимные обязательства» представлена на рисунке 2.

<pre class="legal-pre">┌───────────┐                                                 ┌───────────┐
│:инициатор │                                                 │:респондент│
└─────┬─────┘                                                 └─────┬─────┘</pre>

                           Сообщение-запрос
      ├────────────────────────────────────────────────────────────>│

5. Транзакция общего процесса по шаблону «Вопрос/ответ»

125. Транзакция общего процесса по шаблону «Вопрос/ответ» выполняется путем представления запроса информации, которая имеется у респондента и может быть представлена немедленно (например, запрос фиксированного набора данных из базы данных или статической информации (каталога)).

Инициирование транзакции общего процесса осуществляется путем отправления сообщения общего процесса, представляющего форму запроса информации.

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

Если время для ответа истекло, инициатор должен повторно отправить сообщение общего процесса столько раз, сколько определено параметром транзакции «Количество повторов», или сигнализировать об ошибке, если исчерпано количество повторов.

126. В процессе выполнения транзакции общего процесса по шаблону «Вопрос/ответ» реализуется следующая последовательность обмена сообщениями:

инициатор отправляет в адрес респондента сообщение-запрос;

респондент принимает запрос;

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

инициатор принимает сообщение-ответ, при этом транзакция считается завершенной;

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

Последовательность выполнения транзакции общего процесса по шаблону «Вопрос/ответ» представлена на рисунке 3.

<pre class="legal-pre">┌───────────┐                                                 ┌───────────┐
│:инициатор │                                                 │:респондент│
└─────┬─────┘                                                 └─────┬─────┘</pre>

                           Сообщение-запрос
      ├────────────────────────────────────────────────────────────>│

6. Транзакция общего процесса по шаблону «Запрос/ответ»

127. Транзакция общего процесса по шаблону «Запрос/ответ» выполняется путем представления запроса информации, которая должна быть динамически сформирована (собрана) на стороне респондента и поэтому не может быть предоставлена немедленно.

Инициирование транзакции осуществляется инициатором путем отправления сообщения-запроса респонденту.

Респондент должен отправить сообщение-ответ до истечения времени, определенного как время для ответа.

Если время для ответа истекло, инициатор должен заново инициировать транзакцию столько раз, сколько определено параметром «Количество повторов», или сигнализировать об ошибке, если исчерпано количество повторов.

128. Транзакции «Запрос/ответ» выполняются с обеспечением или без обеспечения гарантированности доставки.

129. Последовательность выполнения транзакции общего процесса по шаблону «Запрос/ответ» без обеспечения гарантированности доставки аналогична последовательности выполнения транзакции по шаблону «Вопрос/ответ».

130. В процессе выполнения транзакции общего процесса по шаблону «Запрос/ответ» с обеспечением гарантированности доставки реализуется следующая последовательность обмена сообщениями:

инициатор отправляет в адрес респондента сообщение-запрос и ждет подтверждения получения запроса до истечения времени, определенного как время для подтверждения получения;

респондент принимает сообщение-запрос и как получатель информации (если параметрами транзакции установлена необходимость подтверждения получения) отправляет инициатору сигнал-подтверждение «Получено»;

инициатор после обработки принятого им от респондента сигнала-подтверждения «Получено» (если параметрами транзакции установлена необходимость подтверждения получения) ждет подтверждения принятия в обработку информации, содержащейся в сообщении-запросе, до истечения времени, определенного как время для подтверждения обработки;

респондент проводит контроль данных, содержащихся в сообщении-запросе, в соответствии с регламентом информационного взаимодействия и подтверждает принятие в обработку полученной им информации, посылая инициатору сигнал-подтверждение «Принято в обработку»;

инициатор после обработки полученного им от респондента сигнала-подтверждения «Принято в обработку» ждет получения ответа до истечения времени, определенного как время для получения ответа;

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

инициатор принимает сообщение-ответ, при этом транзакция считается завершенной;

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

Последовательность выполнения транзакции общего процесса по шаблону «Запрос/ответ» с обеспечением гарантированности доставки представлена на рисунке 4.

<pre class="legal-pre">┌───────────┐                                                 ┌───────────┐
│:инициатор │                                                 │:респондент│
└─────┬─────┘                                                 └─────┬─────┘</pre>

                           Сообщение-запрос
      ├────────────────────────────────────────────────────────────>│

      │             Сигнал-подтверждение "Получено"                 │
      │<─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┬── ─ ─ ─ ─ ─ ─ │
<pre class="legal-pre">      │                                             │               │
      │                                             │               │
      │      ┌────────────────────────────────────\─┘               │
      │      │Необходимость формирования сигнала  │                 │
      │      │определяется параметрами транзакции │                 │
      │      └────────────────────────────────────┘                 │
      │                                                             │
      │       Сигнал-подтверждение "Принято в обработку"            │</pre>
      │< ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│
<pre class="legal-pre">      │                                                             │
      │                     Сообщение-ответ                         │</pre>
      │<────────────────────────────────────────────────────────────┤
      │                                                             │

7. Транзакция общего процесса по шаблону «Запрос/подтверждение»

131. Транзакция общего процесса по шаблону «Запрос/подтверждение» выполняется, если инициатор запрашивает информацию, которая требует только подтверждения (например, запрос статусной информации).

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

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

132. Респондент может потребовать, чтобы инициатор транзакции общего процесса после получения им сообщения-ответа отправил сигнал-подтверждение «Получено» до истечения времени, определенного как время для подтверждения получения.

133. Транзакция общего процесса по шаблону «Запрос/подтверждение» выполняется с обеспечением или без обеспечения гарантированности доставки.

134. Последовательность выполнения транзакции общего процесса по шаблону «Запрос/подтверждение» без обеспечения гарантированности доставки аналогична последовательности выполнения транзакции общего процесса по шаблону «Вопрос/ответ».

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

инициатор отправляет в адрес респондента сообщение-запрос;

респондент принимает сообщение-запрос;

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

инициатор принимает сообщение-ответ и как получатель информации подтверждает получение сообщения-ответа, отправляя респонденту сигнал-подтверждение «Получено»;

после получения респондентом от инициатора сигнала-подтверждения «Получено» транзакция общего процесса считается завершенной;

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

Последовательность выполнения транзакции общего процесса по шаблону «Запрос/подтверждение» с обеспечением гарантированности доставки представлена на рисунке 5.

<pre class="legal-pre">┌───────────┐                                                 ┌───────────┐
│:инициатор │                                                 │:респондент│
└─────┬─────┘                                                 └─────┬─────┘</pre>

                           Сообщение-запрос
      ├────────────────────────────────────────────────────────────>│

8. Транзакция общего процесса по шаблону «Оповещение»

136. Транзакция общего процесса по шаблону «Оповещение» выполняется путем отправки данных инициатором без получения сообщения-ответа от респондента.

Транзакция общего процесса по шаблону «Оповещение» выполняется, если инициатор должен проинформировать респондента о необратимом состоянии (например, об изменении статуса рассматриваемой заявки). Поскольку оповещение является официальным действием, инициатор должен требовать отправки респондентом сигнала-подтверждения «Получено» до истечения времени, определенного как время для подтверждения получения.

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

137. В процессе выполнения транзакции общего процесса по шаблону «Оповещение» реализуется следующая последовательность обмена сообщениями:

инициатор отправляет в адрес респондента сообщение-уведомление, содержащее информацию прикладного уровня;

респондент принимает сообщение-уведомление и как получатель информации подтверждает получение сообщения-уведомления, посылая инициатору сигнал-подтверждение «Получено»;

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

Последовательность выполнения транзакции общего процесса по шаблону «Оповещение» представлена на рисунке 6.

<pre class="legal-pre">┌───────────┐                                                 ┌───────────┐
│:инициатор │                                                 │:респондент│
└─────┬─────┘                                                 └─────┬─────┘</pre>

                          Сообщение-уведомление
      ├────────────────────────────────────────────────────────────>│

9. Транзакция общего процесса по шаблону «Распространение информации»

138. Транзакция общего процесса по шаблону «Распространение информации» выполняется путем отправки данных инициатором без получения сообщений-ответов или сигналов-подтверждений от респондента. При этом респондент может формировать и отправлять инициатору сигналы-исключения либо технологические сообщения об ошибке.

139. Транзакция общего процесса по шаблону «Распространение информации» выполняется путем отправки инициатором в адрес респондента сообщения-уведомления, содержащего информацию прикладного уровня (рисунок 7).

После отправки такого сообщения транзакция общего процесса считается завершенной.

<pre class="legal-pre">┌───────────┐                                                 ┌───────────┐
│:инициатор │                                                 │:респондент│
└─────┬─────┘                                                 └─────┬─────┘</pre>

                          Сообщение-уведомление
      ├────────────────────────────────────────────────────────────>│

<pre class="legal-pre">      │                                                             │

      │                                                             │

      │                                                             │

      │                                                             │</pre>

VII. Принципы обеспечения информационной безопасности

140. Государства-члены и Комиссия самостоятельно обеспечивают информационную безопасность при передаче и обработке сведений в пределах зоны своей ответственности в соответствии с требованиями нормативных правовых актов и технических документов государств-членов и Комиссии.

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

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

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

1. Понятия, используемые в настоящем документе, означают следующее:

«API» — Application programming interface — набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах;

«MIME» — спецификация для кодирования и форматирования информации для ее передачи внутри текстовых данных;

«MQMD» — заголовок транспортного сообщения, содержащий основные реквизиты транспортного сообщения;

«MQRFH2» — заголовок транспортного сообщения, содержащий дополнительные реквизиты транспортного сообщения;

«канал» — однонаправленное сетевое соединение, предназначенное для передачи сообщений между менеджерами очередей;

«менеджер очередей» — программный компонент, предоставляющий сервисы очередей сообщений посредством API;

«очередь» — именованное хранилище сообщений, управляемое посредством менеджера очередей;

«транспортное сообщение» — совокупность элементов информации, оформленных в соответствии с требованиями транспортного протокола.

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

Правила именования объектов программного обеспечения MQ приведены в пунктах 12 - 18 настоящего документа.

3. Допускается использование любого из имеющихся программных интерфейсов к программному обеспечению MQ (MQI, AMI, JMS и т.д.).

В настоящем документе для обозначения служебных структур и констант программного обеспечения MQ используются наименования, соответствующие программному интерфейсу MQI. При использовании других API-интерфейсов наименования структур и констант могут отличаться.

4. На транспортном уровне интеграционные шлюзы обмениваются между собой транспортными сообщениями в формате программного обеспечения MQ, оформляемыми в соответствии с пунктами 8 - 11 настоящего документа.

5. Для транспортного сообщения устанавливается предельный размер 100 Мб. В случае если при оформлении транспортного сообщения выяснится, что размер транспортного сообщения превышает указанный предельный размер, интеграционным шлюзом должна быть прекращена обработка такого сообщения. При этом отправитель уведомляется интеграционным шлюзом о невозможности доставки такого сообщения путем формирования и отправки технологического сообщения об ошибке с кодом «int:InternalError».

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

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

8. Требования к заполнению полей MQMD приведены в таблице 1.

Поля MQMD, не указанные в таблице 1, при заполнении должны иметь значения по умолчанию (должны использоваться значения из структуры MQMD_DEFAULT).

9. В транспортное сообщение включается сообщение унифицированной структуры, оформленное согласно требованиям раздела IV Правил электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли, утвержденных Решением Коллегии Евразийской экономической комиссии от ________ N ______.

10. Если сообщение унифицированной структуры содержит MIME-части, то для идентификации наличия двоичного вложения в группе заголовков MQRFH2 в папке должен присутствовать заголовок «contentType», который должен иметь строковое значение «Multipart/Related; boundary=<идентификатор границы MIME-блока>;».

11. Если сообщение унифицированной структуры передается в формате SOAP-сообщения без MIME-частей, то в группе заголовков MQRFH2 в папке должен присутствовать заголовок «contentType», который должен иметь строковое значение «application/soap+xml».

12. На интеграционных шлюзах должны быть настроены менеджеры очередей программного обеспечения MQ, наименования которых должны удовлетворять шаблону <Идентификатор сегмента>.IIS.QM.

13. Идентификаторы сегмента интегрированной системы должны заполняться в соответствии с перечнем, приведенным в таблице 2.

14. Менеджеры очередей должны быть объединены между собой парами каналов типа «sender»/«receiver», наименование которых подчиняется следующим шаблонам:

а) для канала типа «sender» — шаблону IDLocal/IDRemote, где IDLocal — идентификатор локального сегмента, IDRemote — идентификатор сегмента, к которому выполняется подключение. Например, имя канала между менеджерами очередей EEC.IIS.QM и BY.IIS.QM — EEC/BY;

б) для канала типа «receiver» — шаблону IDRemote/IDLocal, где IDRemote — идентификатор сегмента, со стороны которого выполняется подключение, IDLocal — идентификатор локального сегмента. Например, имя канала между менеджерами очередей EEC.IIS.QM и KZ.IIS.QM — KZ/EEC.

15. Для обеспечения постоянной работы каналов сообщений у создаваемых каналов типа «sender» для параметра Disconnect Interval (интервал отключения) должно быть установлено значение «0».

16. Для приема сообщений от интеграционных шлюзов смежных сегментов на каждом менеджере очередей должна быть создана локальная очередь сообщений с именем GATEWAY.INT.IN.

17. На каждом менеджере очередей должны быть созданы определения удаленных очередей (remote queue definition) для очередей GATEWAY.INT.IN на интеграционных шлюзах смежных сегментов.

Наименование определения удаленной очереди должно подчиняться шаблону IDRemote.QName, где IDRemote — код сегмента удаленного менеджера, Qname — имя очереди на удаленном менеджере. Например, для очереди GATEWAY.INT.IN на менеджере очередей EEC.IIS.QM наименование определения удаленной очереди — EEC.GATEWAY.INT.IN.

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

Приложение № 2 к Правилам электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли

СХЕМА ДАННЫХ СПЕЦИАЛИЗИРОВАННЫХ ЭЛЕМЕНТОВ И АТРИБУТОВ, ИСПОЛЬЗУЕМЫХ ПРИ ФОРМИРОВАНИИ СООБЩЕНИЙ В ИНТЕГРИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ ВНЕШНЕЙ И ВЗАИМНОЙ ТОРГОВЛИ

<xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns:int=«urn:EEC:Interaction:vl.0» targetNamespace=«urn:EEC:Interaction:vl.0» elementFormDefault=«qualified» attributeFormDefault=«unqualified»> <xs:element name=«ProcedureID» type-«xs:string»> xs:annotation xs:documentationЗаголовок-идентификатор экземпляра процедуры общего процесса</xs:documentation> </xs:annotation> </xs:element> <xs:element name=«ConversationID» type=«xs:anyURI»> </xs:annotation> xs:documentationЗаголовок-идентификатор экземпляра транзакции общего процесса</xs:documentation> </xs:annotation> </xs:element> <xs:element name=«Integration»> </xs:annotation> xs:documentationСлужебный блок интеграционной платформы интегрированной системы</xs:documentation> </xs:annotation> xs:complexType xs:sequence <xs:element name=«TrackID» type=«xs:anyURI»> xs:annotation xs:documentationТехнологический уникальный идентификатор ЭС</xs:documentation>

                                <xs:annotation><br>
                         </xs:element><br>
                         <xs:element name="AcceptTime" type="xs:dateTime"><br>
                                <xs:annotation><br>
                                        <xs:documentation>Дата и время приема ЭС

                                </xs:annotation>
                          </xs:element>
                   </xs:sequence>
            </xs:complexType>
   </xs:element>
   <xs:element name="ProblemMessage" type="xs:string">
            <xs:annotation>
                     <xs:documentation>Контейнер для передачи внутри Fault сообщений, вызвавших

ошибку.</xs:documentation> </xs:annotation> </xs:element> <xs:attribute name=«RelatesAction» type=«xs:anyURI»> xs:annotation xs:documentationАтрибут, использующийся в составе элемента wsa:RelatesTo для идентификации сообщения, на которое сформирован Fault</xs:documentation> </xs:annotation> </xs:attribute> </xs:schema>

Приложение № 3 к Правилам электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли

ПРИМЕРЫ СООБЩЕНИЙ

Пример прикладного сообщения, формируемого отправителем:

<soap: Envelope xmlns:soap=«http://www.w3.org/2003/05/soap-envelope» xmlns:wsa=«http://www.w3.org/2005/08/addressing» xmlns:int=«urn:EEC:Interaction:vl.0»> soap:Header wsa:ToEAEU://EEC/CP/P.SP.03/P.ACT.001</wsa:To> wsa:ReplyTo wsa:AddressEAEU://RU/CP/P.SP.03/P.SP.03.ACT.002</wsa:Address> </wsa:ReplyTo> wsa:Action int://CP/P.SP.03/0.1/P.SP.03.PRC.001/P.SP.03.TRN.002/P.CC.04.MSG.003 </wsa:Action> wsa:MessageIDurn:uuid:eaddf37f-70db-45ee-9a08-542d2c5589c3</wsa:MessageID> int:ProcedureID urn:uuid:f8a30dda-8443-4ef9-a367-c36fa39ee1f1/urn:uuid:9273bfae-5269-4e0c-83f0- 8ce8b7cd75f6 </int:ProcedureID> int:ConversationID urn:uuid:f8a30dda-8443-4ef9-a367-c36fa39ee1f1 </int:ConversationID> </soap:Header> soap:Body <!-данные прикладного уровня, структура которых определена технологическими документами, регламентирующими информационное взаимодействие --> </soap:Body> </soap:Envelope>

Пример технологического сообщения об ошибке:

<soap:Envelope xmlns:soap=«http://www.w3.org/2003/05/soap-envelope» xmlns:wsa=«http://www.w3.org/2005/08/addressing» xmlns:int=«urn:EEC:Interaction:v1.0»> soap:Header wsa:ToEAEU://RU/CP/P.SP.03/P.SP.03.ACT.002</wsa:To> wsa:From wsa:AddressEAEU://EEC/SR/gate</wsa:Address> </wsa:From> wsa:Actionhttp://www.w3.org/2005/08/addressing/soap/fault</wsa:Action> wsa:MessageIDurn:uuid:9219a798-a7b2-4e28-8241 -0e5816c3f7b3</wsa:MessageID> <wsa:RelatesTo int:RelatesAction=«int://CP/P.SP.03/0.1/P.SP.03.PRC.001/P.SP.03.TRN.002/P.CC.04.MSG.003»> urn:uuid:eaddf37f-70db-45ee-9a08-542d2c5589c3 </wsa:RelatesTo> int:ProcedureID urn:uuid:f8a30dda-8443-4ef9-a367-c36fa39ee1f1/urn:uuid: 9273bfae-5269-4e0c-83f0- 8ce8b7cd75f6 </int:ProcedureID> <int: ConversationID> urn:uuid:f8a30dda-8443-4ef9-a367-c36fa39ee1f1 </int:ConversationID> int:Integration int:TrackIDurn:uuid:5fbc4b5a-2937-483e-91ea-45a056938a4e</int:TrackID> int:AcceptTime2015-05-31T09:30:10+03:00</int:AcceptTime> </int:Integration> </soap:Header> soap:Body soap:Fault soap:Code <soap: Value>soap: Receiver</soap:Value> soap:Subcode soap:Valueint:IntenalError</soap:Value> </soap:Subcode> </soap:Code> soap:Reason <soap:Text xml:lang=«ru»>Внутренняя ошибка преобразования

                int://CP/P.SP.03/0.1/P.SP.03.PRC.001/P.SP.03.TRN.002/P.CC.04.MSG.003
            </wsa:Action>
            <wsa:MessageID>urn:uuid:eaddf37f-70db-45ee-9a08-542d2c5589c3</wsa:MessageID>
            <int:ConversationID>
                  urn:uuid:f8a30dda-8443-4ef9-a367-c36fa39ee1f1
            </int:ConversationID>
    </soap:Header>
    <soap:Body>
                    <!-данные прикладного уровня, структура которых определена

технологическими документами, регламентирующими информационное взаимодействие --> </soap:Body> </soap:Envelope> ]]></int:ProblemMessage> </soap:Detail> </soap:Fault> </soap:Body> </soap:Envelope>

и взаимной торговли

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

б) преобразование сообщения интеграционным шлюзом;

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

е) возникновение тайм-аута при доставке сообщения;

ж) возникновение ошибки контроля структуры и правил заполнения заголовков сообщения.

2. Интеграционный шлюз должен обеспечивать передачу диагностической информации об обрабатываемых сообщениях в интеграционный сегмент Евразийской экономической комиссии (далее — Комиссия):

б) при сохранении диагностической информации в журнале интеграционного шлюза.

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

б) при заполнении логического адреса получателя сообщения указывается значение «EAEU://EEC/SR/JOURNAL/PUT»;

в) при заполнении элемента wsa:Action указывается значение «int://SR/UTIL/JOURNAL/SYNC/PUT»;

г) при описании блока содержимого служебного сообщения используются пространства имен, приведенные в таблице 1. Блок содержимого служебного сообщения должен содержать элементы, приведенные в таблице 2.

Таблица 2

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

5. Интеграционным сегментом Комиссии может инициироваться запрос диагностической информации от интеграционного шлюза интеграционной платформы интегрированной системы.

6. Запрос диагностической информации интеграционным сегментом Комиссии осуществляется в соответствии со следующими требованиями:

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

б) при заполнении логического адреса получателя сообщения указывается значение «EEU://КОД_СЕГМЕНТА/SR/JOURNAL/GET»;

в) при заполнении элемента wsa:Action указывается значение «int://SR/UTIL/JOURNAL/SYNC/GET»;

г) блок содержимого служебного сообщения содержит элементы, приведенные в таблице 3.

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

а) если в запросе заполнен элемент MessageID, должна быть найдена вся информация о сообщениях с аналогичным MessageID. При этом, если флаг в элементе FindRelates установлен в значение «true», должны быть найдены записи журнала, у которых поле RelatesTo равно элементу MessageID запроса;

б) если в запросе заполнен элемент TrackID, должна быть найдена вся информация о сообщениях с аналогичным TrackID.

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

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

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

4. Структура и реквизитный состав сигнала-подтверждения «Принято в обработку» приведены в таблице 4.

5. Структура и реквизитный состав сигнала-исключения «Ошибка» приведены в таблице 5.

<xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns:sgn=«urn:EEC: signal:v1.0» targetNamespace=«urn:EEC:signal:v1.0»elementFormDefault=«qualified» attributeFormDefault=«unqualified»> <xs:simpleType name=«EDocIdType»> xs:annotation <хs:documentation>Идентификатор документа</xs: documentation> </xs:annotation> <xs:restriction base=«xs:token»> <xs:pattern value=«[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0 -9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}»/> </xs:restriction> </xs:simp1eType> <xs:simpleType name=«DateTimeType»> xs:annotation xs:documentationДата по григорианскому календарю и время в формате стандарта ISO 8601</xs:documentation> </xs:annotation> <xs:restriction base=«xs:dateTime»/> </xs:simpleType> <xs:simpleType name=«ErrorCodeType»> xs:annotation xs:documentationКодовое обозначение ошибки< /xs:documentation> </xs:annotation> <xs:restriction base=«xs:token»> <xs:minLength value=«1»/> <xs:maxLength value=«255»/> </xs:restriction> </xs:simpleType> <xs:simpleType name=«StringType»> xs:annotation <хs:documentation>Произвольная информация в текстовой форме</хs:documentation> </xs:annotation> <xs:restriction base=«xs:string»/> </xs:simpleType> <xs:complexType name=«DeliveryReceiptType»> xs:annotation xs:documentationТип сигнала-подтверждения «Получено»</xs:documentation> </xs:annotation> xs:sequence <xs:element name=«SignalId» type=«sgn:EDocIdType»/> <xs:element name=«DateTime» type=«sgn:DateTimeType»/> </xs:sequence> </xs:complexType> <xs:element name=«DeliveryReceipt» type=«sgn:DeliveryReceiptType»> xs:annotation xs:documentationСигнал-подтверждение «Получено» </xs:documentation> </xs:annotation> </xs:element> <xs:complexType name=«ProcessingReceiptType»> xs:annotation xs:documentationТип сигнала-подтверждения «Принято в обработку»</xs:documentation> </xs:annotation> xs:sequence <xs:element name=«SignalId» type=«sgn:EDocIdType»/> <xs:element name=«DateTime» type=«sgn:DateTimeType»/> </xs:sequence> </xs:complexType> <xs:element name=«ProcessingReceipt» type=«sgn: ProcessingReceiptType»> xs:annotation xs:documentationСигнал-подтверждение «Принято в обработку»</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name=«ValidationErrorType»> xs:annotation xs:documentationТип сигнала-исключения «Ошибка </xs:documentation> </xs:annotation> xs:sequence <xs:element name=»SignalId» type=«sgn:EDocIdType»> xs:annotation xs:documentationИдентификатор сигнала-исключения</хs:documentation> </xs:annotation> </xs:element> <xs:element name=«DateTime» type=«sgn:DateTimeType»> xs:annotation xs:documentationДата и время </xs:documentation> </xs:annotation> </xs:element> <xs:element name=«Error» type=«sgn:ErrorType» maxOccurs=«unbounded»> xs:annotation xs:documentationСведения об ошибке</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name=«ErrorType»> xs:annotation xs:documentationТип ошибки</xs:documentation> </xs:annotation> xs:sequence <xs:element name=«Code» type=«sgn:ErrorCodeType»> xs:annotation xs:documentationКодовое обозначение ошибки контроля</xs:documentation> </xs:annotation> </xs:element> <xs:element name=«Description» type=«sgn:StringType»> xs:annotation xs:documentationОбозначение ошибки контроля в текстовой форме</xs:documentation> </xs:annotation> </xs:element> <xs:element name=«Details» type=«sgn:StringType» minOccurs=«0»> xs:annotation xs:documentationДетализированные сведения об ошибке</xs:documentation> </xs:annotation> </xs:element> <xs:element name=«EDocId» type=«sgn:EDocIdType» minOccurs=«0»> xs:annotation xs:documentationИдентификатор документа, в котором возникла ошибка</xs:documentation> </xs:annotation> </xs:element> <xs:element name=«Reference» type=«sgn:StringType» minOccurs=«0»> xs:annotation xs:documentationСтрока символов, позволяющая однозначно локализовать элемент в документе, вызвавший ошибку </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:element name=«ValidationError» type=«sgn:ValidationErrorType»> xs:annotation xs:documentationСигнал-исключение «Ошибка контроля»</xs:documentation> </xs:annotation> </xs:element> </xs:schema>