Об утверждении Правил электронного обмена данными в национальном сегменте Российской Федерации интегрированной информационной системы Евразийского экономического союза

МИНИСТЕРСТВО СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ ПРИКАЗ Москва 10 января 2018 г. № 1 Об утверждении Правил электронного обмена данными в национальном сегменте Российской Федерации интегрированной информационной системы Евразийского экономического союза Зарегистрирован Минюстом России 13 февраля 2018 г. Регистрационный № 50016 В соответствии с пунктом 1 Плана мероприятий по реализации Концепции создания национального сегмента Российской Федерации интегрированной информационной системы Евразийского экономического союза, утвержденного распоряжением Правительства Российской Федерации от 30 марта 2017 г. № 583-р, ПРИКАЗ Ы В А Ю: 1. Утвердить Правила электронного обмена данными в национальном сегменте Российской Федерации интегрированной информационной системы Евразийского экономического союза. 2. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации. Министр Н.А.Никифоров _________________ УТВЕРЖДЕНЫ приказом Министерства связи и массовых коммуникаций Российской Федерации от 10 января 2018 г. № 1 Правила электронного обмена данными в национальном сегменте Российской Федерации интегрированной информационной системы Евразийского экономического союза 1. Настоящие Правила определяют порядок электронного обмена данными в национальном сегменте Российской Федерации интегрированной информационной системы Евразийского экономического союза (далее соответственно - НС Российской Федерации, ИИС ЕАЭС). 2. Настоящие Правила применяются при разработке компонентов НС Российской Федерации, обеспечивающих электронный обмен данными (информационное взаимодействие) внутри НС Российской Федерации, а также НС Российской Федерации с национальными сегментами государств, являющихся членами Евразийского экономического союза (далее соответственно - государства-члены, ЕАЭС), и интеграционным сегментом Евразийской экономической комиссии (далее соответственно - ИС ЕАЭК, Комиссия). 3. Электронный обмен данными внутри НС Российской Федерации, а также НС Российской Федерации с национальными сегментами государств-членов и ИС ЕАЭС осуществляется в соответствии с настоящими Правилами и Протоколом об информационно-коммуникационных технологиях и информационном взаимодействии в рамках Евразийского экономического союза (приложение № 3 к Договору о Евразийском экономическом союзе от 29 мая 2014 г. опубликовано на официальном сайте ЕАЭС в информационно-телекоммуникационной сети "Интернет" (далее - официальный сайт ЕАЭС): "http://www.eaeunion.org"). 4. В НС Российской Федерации ИИС ЕАЭС включаются государственные информационные системы, участвующие в электронном обмене данными с информационными системами других государств-членов и Комиссии, и информационные системы, обеспечивающие информационное взаимодействие информационных систем уполномоченных органов Российской Федерации и информационных систем (далее - ИС) Комиссии в рамках ИИС ЕАЭС. 5. Электронный обмен данными в рамках НС Российской Федерации осуществляется с использованием единой системы межведомственного электронного взаимодействия версии 3.x (далее - СМЭВ3.х), доступ к которой осуществляется в порядке, установленном постановлением Правительства Российской Федерации от 8 сентября 2010 г. № 697 "О единой системе межведомственного электронного взаимодействия". 6. Передача данных в НС Российской Федерации посредством СМЭВ3.х обеспечивается взаимодействием ИС федеральных органов исполнительной власти, государственных внебюджетных фондов, исполнительных органов государственной власти субъектов Российской Федерации, органов местного самоуправления, государственных и муниципальных учреждений, многофункциональных центров, иных органов и организаций (далее - органы и организации), выступающих в роли участников взаимодействия и используемых при предоставлении государственных и муниципальных услуг и исполнении государственных и муниципальных функций в электронной форме. 7. В структуру НС Российской Федерации включается интеграционный шлюз НС Российской Федерации, обеспечивающий возможность информационного взаимодействия с интеграционным шлюзом Комиссии и другими внешними информационными системами, удостоверяющий центр НС Российской Федерации, доверенная третья сторона (далее - ДТС) НС Российской Федерации, СМЭВ3.х, ИС органов и организаций, портал внешнеэкономической информации. ____________ Собрание законодательства Российской Федерации, 2010, № 38, ст. 4823; 2011, № 24, ст. 3503; № 49, ст. 7284; 2013, № 45, ст. 5827; 2014, № 12, ст. 1303; № 42, ст. 5746; № 48, ст. 6862; № 48, ст. 6876; № 50, ст. 7113; 2016, № 34, ст. 5243. Распоряжение Правительства Российской Федерации от 30.03.2017 № 583-р "Об утверждении Концепции создания национального сегмента Российской Федерации интегрированной информационной системы Евразийского экономического союза" (Собрание законодательства Российской Федерации, 2017, № 15 (Часть VII), ст. 2254). 8. Функциями интеграционного шлюза НС Российской Федерации являются: 1) преобразование протоколов обмена и форматов данных НС Российской Федерации в протоколы обмена и форматы данных, применяемые в ИИС ЕАЭС; 2) преобразование протоколов обмена и форматов данных, применяемых в ИИС ЕАЭС, в протоколы обмена и форматы данных НС Российской Федерации; 3) маршрутизация сообщений. 9. Электронный обмен данными в НС Российской Федерации осуществляется в виде обмена электронными документами, который осуществляется согласно требованиям разделов II и III Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств - членов Евразийского экономического союза между собой и с Евразийской экономической комиссией, утвержденного Решением Коллегии Евразийской экономической комиссии от 28 сентября 2015 г. № 125 "Об утверждении Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств - членов Евразийского экономического союза между собой и с Евразийской экономической комиссией" (опубликовано на официальном сайте ЕАЭС: "http://www.eaeunion.org"). 10. ДТС НС Российской Федерации обеспечивает осуществление функций, предусмотренных пунктом 4.2.19.2.1 Технического задания на создание интегрированной информационной системы Евразийского экономического союза, утвержденного Решением Коллегии Евразийской экономической комиссии от 12 октября 2015 г. № 137 (опубликовано на официальном сайте ЕАЭС: "http://www.eaeunion.org"). 11. Обмен данными между участниками взаимодействия в НС Российской Федерации и интеграционным шлюзом НС Российской Федерации осуществляется путем передачи и приема сообщений. Сообщения НС Российской Федерации передаются в качестве файловых вложений в сообщениях, передаваемых и принимаемых участниками через СМЭВ3.х. 12. Требования к структуре и формату сообщений определены в приложении № 1 к настоящим Правилам, а также пунктами 14 и 15 Правил электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли, утвержденных Решением Коллегии Евразийской экономической комиссии от 27 января 2015 г. № 5 "Об утверждении Правил электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли" (опубликовано на официальном сайте ЕАЭС: "http://www.eaeunion.org"). 13. Правила формирования сообщений об ошибках и иных служебных сообщений при взаимодействии с интеграционным шлюзом НС Российской Федерации определены в приложении № 2 к настоящим Правилам. 14. Для передачи сообщений в НС Российской Федерации осуществляются следующие действия: 1) участник обмена электронными документами, который направляет или от имени которого направляется электронный документ (далее - отправитель), должен сформировать сообщение и с использованием СМЭВ3.х передать его в интеграционный шлюз НС Российской Федерации; 2) интеграционным шлюзом НС Российской Федерации выполняются обработка сообщения и передача сообщения через инфраструктуру интеграционной платформы ИИС ЕАЭС в интеграционный шлюз национального сегмента участника обмена электронными документами, которому отправлен электронный документ (далее - получатель). 15. При получении НС Российской Федерации сообщения через инфраструктуру интеграционной платформы ИИС ЕАЭС из интеграционного шлюза национального сегмента отправителя интеграционным шлюзом НС Российской Федерации выполняются обработка сообщения и передача сообщения получателю с использованием СМЭВ3.х. 16. В НС Российской Федерации передача сообщений выполняется с использованием специальных видов сведений СМЭВ3.х для получения и передачи сообщений в интеграционный шлюз НС Российской Федерации: 1) "Передача электронного сообщения ИИС ЕАЭС из ФОИВ в интеграционный шлюз национального сегмента Российской Федерации ИИС ЕАЭС" в соответствии с Руководством пользователя вида сведений, опубликованного на технологическом портале СМЭВ3.х: "https://smev3.gosuslugi.ru"; 2) "Передача электронного сообщения ИИС ЕАЭС из интеграционного шлюза национального сегмента Российской Федерации ИИС ЕАЭС в ФОИВ РФ", в соответствии с Руководством пользователя вида сведений, опубликованного на технологическом портале СМЭВ3.х: "https://smev3.gosuslugi.ru". 17. Правила использования видов сведений, формат сообщений и видов сведений СМЭВ3.х определены подпунктом 2.2. Методических рекомендаций по работе с единой системой межведомственного электронного взаимодействия версии 3.x, опубликованных на технологическом портале СМЭВ: "https://smev3.gosuslugi.ru". 18. Требования к правилам и сценариям обмена сообщениями в НС Российской Федерации определены в Разделе V Правил электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли, утвержденных вышеназванным Решением Коллегии Евразийской экономической комиссии от 27 января 2015 г. № 5 (опубликовано на официальном сайте ЕАЭС: "http://www.eaeunion.org"). 19. Информационное взаимодействие между участником и интеграционным шлюзом НС Российской Федерации при реализации общего процесса в рамках НС Российской Федерации осуществляется посредством транзакций общего процесса, в рамках которых осуществляется обмен сообщениями по типовым шаблонам: "Взаимные обязательства", "Вопрос/ответ", "Запрос/ответ", "Запрос/подтверждение", "Оповещение", "Распространение информации". ____________ Решение Коллегии Евразийской экономической комиссии от 27 января 2015 г. № 5 (опубликовано на официальном сайте ЕАЭС: "http://www.eaeunion.org"). 20. При выполнении транзакции общего процесса должно быть успешно обработано каждое из отправленных сообщений либо все изменения прикладного уровня в системах участников общего процесса, вызванные обработкой сообщений транзакции, должны быть отменены. 21. Перечень общих процессов установлен решением Коллегии Евразийской экономической комиссии от 14 апреля 2015 г. № 29 "О перечне общих процессов в рамках ЕАЭС и внесении изменения в Решение Коллегии Евразийской экономической комиссии от 19 августа 2014 г. № 132" (опубликовано на официальном сайте ЕАЭС: "http://www.eaeunion.org"). Требования к реализации общих процессов определены в Разделе VI Правил электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли, утвержденных Решением Коллегии Евразийской экономической комиссии от 27 января 2015 г. № 5 (опубликовано на официальном сайте ЕАЭС: "http://www.eaeunion.org"). ________________ ПРИЛОЖЕНИЕ № 1 к Правилам электронного обмена данными в национальном сегменте Российской Федерации интегрированной информационной системы Евразийского экономического союза Структура и формат сообщений в НС Российской Федерации ИИС ЕАЭС I. Требования к структуре и формату сообщений в НС Российской Федерации ИИС ЕАЭС 1. При описании структуры и формата сообщений используются пространства имен, приведенные в таблице 1, и спецификации, приведенные в таблице 2. Таблица 1 Перечень пространств имен документа |-------------------|---------------------------------------------| | Префикс | Адрес | |-------------------|---------------------------------------------| |int |urn:EEC:Interaction:v1.0 | |-------------------|---------------------------------------------| |soap |http://www.w3.org/2003/05/soap-envelope | |-------------------|---------------------------------------------| |wsa |http://www.w3.org/2005/08/addressing | |-------------------|---------------------------------------------| |хор |http://www.w3.org/2004/08/xop/include | |-------------------|---------------------------------------------| |xs |http://www.w3.org/2001/XMLSchema | |-------------------|---------------------------------------------| Таблица 2 Спецификации, используемые при описании структуры и формата сообщений |---|--------------------|----------------------------------------| | № |Краткое наименование| Полное наименование спецификации | |п/п| | | |---|--------------------|----------------------------------------| |1 |SOAP 1.2 |SOAP Version 1.2 Part 1: Messaging | | | |Framework (Second Edition). W3C | | | |Recommendation 27 April 2007. | | | |http://www.w3.org/TR/soap12-part1 | |---|--------------------|----------------------------------------| |2 |WS-Addressing 1.0 - |Web Services Addressing 1.0 - Core. | | |Core |W3C Recommendation 9 May 2006. | | | |http://www.w3.org/TR/ws-addr-core | |---|--------------------|----------------------------------------| |3 |WS-Addressing 1.0 - |Web Services Addressing 1.0 - SOAP | | |Binding |Binding. W3C Recommendation 9 May 2006. | | | |http://www.w3.org/TR/ws-addr-soap | |---|--------------------|----------------------------------------| |4 |XML-binary Optimized|XML-binary Optimized Packaging. W3C | | |Packaging |Recommendation 25 January 2005. | | | |http://www.w3.org/TR/2005/REC- | | | |xop10-20050125 | |---|--------------------|----------------------------------------| |5 |XML 1.0 |Extensible Markup Language (XML) 1.0 | | | |(Fifth Edition). W3C Recommendation | | | |26 November 2008. | | | |http://www.w3.org/TR/2008/REC-xml- | | | |20081126 | |---|--------------------|----------------------------------------| |6 |RFC 2045 |RFC 2045: Multipurpose Internet Mail | | | |Extensions (MIME) Part One: Format of | | | |Internet Message Bodies. | | | |http://tools.ietf.org/rfc/rfc2045.txt | |---|--------------------|----------------------------------------| |7 |RFC 3986 |RFC 3986. Uniform Resource Identifier | | | |(URI): Generic Syntax. | | | |http://tools.ietf.org/html/rfc3986 | |---|--------------------|----------------------------------------| |8 |RFC 4122 |RFC 4122. A Universally Unique | | | |IDentifier (UUID) URN Namespace. | | | |http://www.ietf.org/rfc/rfc4122.txt | |---|--------------------|----------------------------------------| |9 |RFC 4648 |RFC 4648: The Base16, Base32, and | | | |Base64 Data Encodings. | | | |http://tools.ietf.org/rfc/rfc4648.txt | |---|--------------------|----------------------------------------| 2. Сообщение в формате SOAP, передаваемое между интеграционными шлюзами на технологическом уровне, оформляется в соответствии со спецификацией SOAP 1.2 (пункт 1 таблицы 2) и состоит из блока заголовков (soap:Header) и блока содержимого (soap:Body). 3. Блок заголовков содержит технологическую информацию, необходимую для выполнения функций маршрутизации и обработки сообщения, а также для мониторинга электронного обмена данными. 4. Блок содержимого содержит прикладную либо технологическую информацию, к которой в том числе относятся технологические сообщения об ошибках. 5. Сообщение может содержать более одного двоичного вложения. Двоичные вложения могут быть внедрены в блок содержимого сообщения в формате Base64 согласно RFC 4648 (пункт 9 таблицы 2) или оформлены в виде отдельных MIME-частей. 6. При передаче двоичных вложений в виде отдельных MIME-частей внутри блока содержимого сообщения создается ссылка на MIME-часть согласно спецификации XML-binary Optimized Packaging (пункт 4 таблицы 2). 7. MIME-части сообщения используются исключительно для оптимизации процессов передачи сообщения. Обработка сообщения должна осуществляться согласно модели обработки ХОР спецификации XML-binary Optimized Packaging (пункт 4 таблицы 2). 8. Двоичные вложения необходимо оформлять в виде MIME-частей в том случае, если размер двоичного вложения превышает 2 мегабайт. 9. При формировании сообщения и содержимого всех его блоков должна использоваться кодировка UTF-8. 10. При представлении структуры сообщений в табличной форме в графе "Кратность" таблиц указываются обязательность элементов, а также максимальное количество экземпляров элемента: 1) 1 - реквизит является обязательным, повторений не допускается; 2) n - реквизит является обязательным, должен повторяться n раз, при этом n > 1. 11. Атрибуты элемента XML обозначаются символом "@". Элементы XML специальными символами не обозначаются. II. Структура блока заголовков 12. Блок заголовков содержит заголовки в соответствии со спецификацией WS-Addressing 1.0 - Core (пункт 2 таблицы 2)., а также специализированные заголовки интегрированной системы. 13. Блок заголовков включает в себя следующие заголовки: 1) wsa:To - заголовок, содержащий сведения о получателе; 2) wsa:ReplyTo - заголовок, содержащий адрес отправителя, на который должно быть направлено сообщение-ответ; 3) wsa:From - заголовок, содержащий адрес отправителя, на который не может быть направлено сообщение-ответ; 4) wsa:FaultTo - заголовок, содержащий адрес отправителя, на который должны быть направлены технологические сообщения об ошибках; 5) wsa:MessageID - заголовок, содержащий идентификатор сообщения; 6) wsa:RelatesTo - заголовок, содержащий ссылочный идентификатор сообщения; 7) wsa:Action - заголовок, идентифицирующий содержимое сообщения; 8) int:ProcedureID - заголовок, идентифицирующий экземпляр процедуры общего процесса; 9) int:ConversationID - заголовок, идентифицирующий экземпляр транзакции общего процесса; 10) int:Integration - служебный заголовок интеграционной платформы интегрированной системы. 14. Заголовок wsa:To используется при выполнении процедуры маршрутизации сообщения, обязателен для заполнения и должен содержать адрес получателя. 15. Заголовок wsa:ReplyTo предназначен для обеспечения возможности формирования получателем сообщения-ответа для отправителя. Адрес отправителя указывается в элементе wsa:Address заголовка wsa:ReplyTo. 16. Заголовок wsa:From предназначен для передачи сведений об отправителе исходного сообщения. Адрес, идентифицирующий отправителя, указывается в элементе wsa:Address заголовка wsa:From. 17. Если заголовок wsa:From не заполнен, отправитель идентифицируется по заголовку wsa:ReplyTo. 18. Заголовок wsa:FaultTo предназначен для обеспечения возможности передачи технологических сообщений об ошибках на логический адрес, отличный от того, который указывается в поле wsa:ReplyTo. Адрес, используемый отправителем для приема технологических сообщений об ошибках, указывается в элементе wsa:Address заголовка wsa:FaultTo. Если заголовок wsa:FaultTo не заполнен, технологические сообщения об ошибках направляются участнику электронного обмена данными, в адрес которого должно быть направлено сообщение-ответ (wsa:ReplyTo/wsa:Address). 19. Заголовок wsa:MessageID предназначен для идентификации отдельных экземпляров сообщений. Заголовок wsa:MessageID обязателен для заполнения. Значения идентификаторов сообщений должны быть глобально уникальными и представлять собой UUID согласно спецификации RFC 4122 (пункт 8 таблицы 2). 20. Заголовок wsa:RelatesTo предназначен для организации цепочек сообщений. Заголовок wsa:RelatesTo должен содержать значение заголовка wsa:MessageID исходного сообщения. При этом заголовок wsa:MessageID должен заполняться новым значением. 21. Заголовок wsa:Action предназначен для информирования участников электронного обмена данными о семантике данных, передаваемых в теле сообщения. Заголовок wsa:Action обязателен для заполнения. 22. Заголовок int:ProcedureID предназначен для идентификации экземпляра процедуры общего процесса, в рамках выполнения которой отправлено сообщение. Заголовок используется для целей мониторинга электронного обмена данными при реализации общих процессов и формируется в соответствии со структурой, приведенной в таблице 3, и схемой данных согласно приложению 2 к Правилам. Таблица 3 Структура заголовка int:ProcedureID |--------------------|----------------|---------------------------| | Элемент | Тип данных | Описание | |--------------------|----------------|---------------------------| |int:ProcedureID |xs:string |идентификатор экземпляра | | | |процедуры общего процесса | |--------------------|----------------|---------------------------| Значение заголовка представляет собой строку, состоящую из компонентов, разделенных символом "/". Каждый компонент представляет собой UUID согласно спецификации RFC 4122 (пункт 8 таблицы 2). Строка заголовка int:ProcedureID формируется в соответствии со следующими правилами: 1) начальное значение заголовка (первый компонент строки) присваивается участником общего процесса, инициирующим процедуру; 2) если участник общего процесса инициирует вложенную процедуру, к значению заголовка int:ProcedureID добавляется символ "/" и новый компонент UUID, идентифицирующий вложенную процедуру; 3) при электронном обмене сообщениями между участниками общего процесса в рамках одной процедуры (вложенной процедуры) значение заголовка int:ProcedureID не меняется. 23. Заголовок int:ConversationID предназначен для идентификации экземпляра транзакции общего процесса, в рамках реализации которой отправлено сообщение и формируется в соответствии со структурой, приведенной в таблице 4, и схемой данных заголовка в соответствии с приложением № 2 к Правилам. Таблица 4 Структура заголовка int:ConversationID |---------------------|--------------|----------------------------| | Элемент | Тип данных | Описание | |---------------------|--------------|----------------------------| |int:ConversationID |xs:anyURI |идентификатор экземпляра | | | |транзакции общего процесса | |---------------------|--------------|----------------------------| Значение идентификатора экземпляра транзакции общего процесса должно быть уникальным и представлять собой UUID согласно спецификации RFC 4122 (пункт 8 таблицы 2). 24. Служебный заголовок интеграционной платформы интегрированной системы int:Integration обеспечивает идентификацию сообщения в пределах интеграционной платформы интегрированной системы и формируется (заполняется) компонентами уровня интеграционной платформы интегрированной системы. 25. Служебный заголовок интегрированной системы int:Integration формируется в соответствии со структурой, приведенной в таблице 5. Таблица 5 Структура заголовка int:Integration |----------------|-------------------|--------------------------|---------| | Элемент | Тип данных | Описание |Кратность| |----------------|-------------------|--------------------------|---------| |int:Integration |int:IntegrationTyре|оборачивающий элемент | | | | |заголовка | | |-|--------------|-------------------|--------------------------|---------| | |int:TrackID |xs:anyURI |технологический | 1 | | | | |идентификатор сообщения | | |-|--------------|-------------------|--------------------------|---------| | |int:AcceptTime|xs:dateTime |дата и время приема | 1 | | | | |сообщения интеграционной | | | | | |платформой интегрированной| | | | | |системы | | |-|--------------|-------------------|--------------------------|---------| 26. Для идентификации сообщения внутри интеграционной платформы интегрированной системы используется технологический идентификатор сообщения int:TrackID, который однократно присваивается сообщению при его приеме интеграционной платформой интегрированной системы, и не должен меняться при передаче сообщения компонентами интеграционной платформы интегрированной системы. Значение технологического идентификатора является уникальным и представляет собой UUID согласно RFC 4122 (пункт 8 таблицы 2). 27. Элемент int:AcceptTime содержит дату и время приема сообщения интеграционной платформой ИИС ЕАЭС. Значение элемента формируется при приеме сообщения и в дальнейшем не меняется при передаче сообщения. В целях обеспечения взаимодействия национальных сегментов государств-членов время должно быть указано в формате всемирного координированного времени (UTC) с указанием часового пояса. __________________ ПРИЛОЖЕНИЕ № 2 к Правилам электронного обмена данными в национальном сегменте Российской Федерации интегрированной информационной системы Евразийского экономического союза Формирование сообщений об ошибке и иных служебных сообщений 1. В класс служебных сообщений включаются: а) технологические сообщения об ошибке; б) служебные сообщения интегрированной системы. 2. Технологическое сообщение об ошибке свидетельствует об ошибке, не позволяющей выполнить обработку и (или) передачу сообщения и не связанной с семантикой данных прикладного уровня. 3. Технологическое сообщение об ошибке представляет собой SOAP-сообщение Fault, оформленное согласно спецификации SOAP 1.2 (пункт 1 таблицы 2 Приложения № 1 к Правилам). 4. Заголовок wsa:To технологического сообщения об ошибке должен быть заполнен значением wsa:FaultTo/wsa:Address исходного сообщения, если данный заголовок присутствовал в исходном сообщении, либо значением wsa:ReplyTo/wsa:Address, если заголовок wsa:FaultTo/wsa:Address в исходном сообщении отсутствовал. 5. Для идентификации отправителя технологического сообщения об ошибке должен использоваться заголовок wsa:From. 6. Заголовок wsa:RelatesTo технологического сообщения об ошибке должен содержать атрибут int:RelatesAction типа xs:anyURI. Указанный атрибут должен содержать значение заголовка wsa:Action сообщения, на которое формируется данное технологическое сообщение об ошибке. 7. Заголовки wsa:ReplyTo и wsa:FaultTo для технологических сообщений об ошибке формироваться не должны. 8. Заголовок wsa:Action технологического сообщения об ошибке должен содержать одно из следующих значений: 1) для технологических сообщений об ошибках, предусмотренных спецификацией WS-Addressing 1.0 - Binding (пункт 3 таблицы 2 Приложения № 1 к Правилам), - значение http://www.w3.org/2005/08/addressing/fault; 2) для прочих технологических сообщений об ошибках - значение http://www.w3.org/2005/08/addressing/soap/fault. 9. Остальные заголовки блока заголовков технологического сообщения об ошибке должны заполняться согласно правилам, приведенным в подразделе 2 раздела IV Правил электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли, утвержденных Решением Коллегии Евразийской экономической комиссии от 27 января 2015 г. № 5 (опубликовано на официальном сайте ЕАЭС: "http://www.eaeunion.org"). 10. Блок содержимого технологического сообщения об ошибке должен содержать элементы, набор которых представлен в таблице 1. Таблица 1 |-----------------|------------------|---------------------|---------| | Элемент | Тип данных | Описание |Кратность| |-----------------|------------------|---------------------|---------| |soap:Fault |soap:Fault |оборачивающий элемент| | | | |блока | | |-|---------------|------------------|---------------------|---------| | |soap: Code |soap:faultcode |оборачивающий элемент| 1 | |-|-|-------------|------------------|---------------------|---------| | | |soap:Value |soap:faultcodeEnum|класс ошибки | 1 | |-|-|-------------|------------------|---------------------|---------| | | |soap:Subcode |soap:subcode |оборачивающий элемент| 1 | | | | | |кода ошибки | | |-|-|-|-----------|------------------|---------------------|---------| | | | |soap:Value |xs:QName |код ошибки | 1 | |-|-|-|-----------|------------------|---------------------|---------| | |soap:Reason |soap:faultreason |оборачивающий элемент| 1 | | | | |текстового описания | | | | | |ошибки | | |-|-|-------------|------------------|---------------------|---------| | | |soap:Text |soap:reasontext |блок текстового | 1..* | | | | | |описания ошибки | | |-|-|-|-----------|------------------|---------------------|---------| | | | |@xml:lang |- |языковой | 1 | | | | | | |идентификатор | | |-|-|-|-----------|------------------|---------------------|---------| | |soap:Detail |soap:detail |детализация ошибки | 0..1 | |-|---------------|------------------|---------------------|---------| 11. Элемент soap:Code/soap:Value должен заполняться согласно требованиям спецификации SOAP 1.2 (пункт 1 таблицы 2 Приложения № 1). 12. Элемент soap:Code/soap:Subcode/soap:Value должен содержать код ошибки. 13. Перечень кодов ошибок и правила использования кодов спецификации WS-Addressing 1.0 - Binding (пункт 3 таблицы 2 Приложения № 1 к Правилам) представлены в таблице 2. Таблица 2 |-------------|---------------------------|--------------------------------| | Класс | Код ошибки | Описание и особенности | | ошибки | | применения | |-------------|---------------------------|--------------------------------| |soap:Sender |wsa:InvalidAddressingHeader|используется согласно правилам, | | | |определенным спецификацией | | | |WS-Addressing 1.0 - Binding, | | | |со следующими ограничениями: | | | |1) значения Subsubcode не | | | |используются; | | | |2) ошибка типа | | | |wsa:DuplicateMessageID не | | | |формируется и не отправляется | |-------------|---------------------------|--------------------------------| |soap:Sender |wsa:MessageAddressingHeader|используется согласно правилам, | | |Required |определенным спецификацией | | | |WS-Addressing 1.0 - Binding | |-------------|---------------------------|--------------------------------| |soap:Sender |wsa:DestinationUnreachable |используется согласно правилам, | | | |определенным спецификацией | | | |WS-Addressing 1.0 - Binding | |-------------|---------------------------|--------------------------------| |soap:Sender |wsa:ActionNotSupported |используется согласно правилам, | | | |определенным спецификацией | | | |WS-Addressing 1.0 - Binding | |-------------|---------------------------|--------------------------------| |soap:Sender |int:InvalidHeader |отсутствует один или несколько | | | |специализированных заголовков | | | |интегрированной системы | |-------------|---------------------------|--------------------------------| |soap:Receiver|wsa:EndpointUnavailable |используется согласно правилам, | | | |определенным спецификацией | | | |WS-Addressing 1.0 - Binding, со | | | |следующим ограничением: при | | | |реализации электронного обмена | | | |данными в рамках общих процессов| | | |элемент wsa:RetryAfter | | | |использоваться не должен | |-------------|---------------------------|--------------------------------| |soap:Receiver|int:InternalError |при обработке сообщения | | | |произошла непредвиденная ошибка | |-------------|---------------------------|--------------------------------| |soap:Sender |int:DataError |полученные данные прикладного | | | |уровня имеют неверную структуру | |-------------|---------------------------|--------------------------------| 14. Элемент soap:Text должен содержать текстовое описание ошибки. 15. Каждый элемент soap:Text должен содержать языковой идентификатор xml:lang, формируемый согласно спецификации XML 1.0 (пункт 5 таблицы 2 Приложения № 1 к Правилам). 16. В случае если в технологическом сообщении об ошибке присутствует набор элементов soap:Text, каждый из указанных элементов должен содержать языковой идентификатор xml:lang, отличный от идентификаторов других элементов soap:Text. 17. В технологическом сообщении об ошибке должен присутствовать хотя бы один элемент soap:Text, содержимое которого представлено на русском языке, а языковой идентификатор xml:lang должен содержать значение ru. 18. Элемент soap:Detail является необязательным и, при его наличии, должен содержать элемент int:ProblemMessage с вложенным сообщением (включая блоки заголовка и содержимого), при обработке которого возникла ошибка, обрамленное тегами CDATA согласно правилам спецификации XML 1.0 (пункт 5 таблицы 2 Приложения № 1 к Правилам). 19. Служебные сообщения интегрированной системы используются для организации передачи данных между компонентами интегрированной системы. Заголовки блока заголовков служебного сообщения интегрированной системы должны заполняться согласно приложению № 1 к Правилам. 20. Элемент wsa:Action служебного сообщения интегрированной системы должен заполняться унифицированным идентификатором ресурса (URI), состоящим из следующих компонентов, разделенных символом "/": 1) фиксированный префикс "int://"; 2) идентификатор SR; 3) один или несколько компонентов, идентифицирующих содержимое служебного сообщения интегрированной системы. ________________