ИПС "Әділет"

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

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

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

Председатель Коллегии
Евразийской экономической комиссии

В. Христенко

УТВЕРЖДЕНЫ
Решением Коллегии
Евразийской экономической комиссии
от 27 января 2015 г.№5

ПРАВИЛА
электронного обмена данными в интегрированной информационной
системе внешней и взаимной торговли
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.

Таблица 1

Перечень пространств имен документа

Префикс

Адрес

int	urn:EEC:Interaction:v1.0
soap	http://www.w3.org/2003/05/soap-envelope
wsa	http://www.w3.org/2005/08/addressing
xop	http://www.w3.org/2004/08/xop/include
xs	http://www.w3.org/2001/XMLSchema

Таблица 2

Спецификации, используемые при описании

структуры и формата сообщений

Краткое наименование

Полное наименование спецификации

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
WS-Addressing 1.0 – Core	Web Services Addressing 1.0 – Core. W3C Recommendation 9 May 2006. http://www.w3.org/TR/ws-addr-core
WS-Addressing 1.0 – Binding	Web Services Addressing 1.0 – SOAP Binding. W3C Recommendation 9 May 2006. http://www.w3.org/TR/ws-addr-soap
XML-binary Optimized Packaging	XML-binary Optimized Packaging. W3C Recommendation 25 January 2005. http://www.w3.org/TR/2005/REC-xop10-20050125
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
RFC 2045	RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. http://tools.ietf.org/rfc/rfc2045.txt
RFC 3986	RFC 3986. Uniform Resource Identifier (URI): Generic Syntax. http://tools.ietf.org/html/rfc3986
RFC 4122	RFC 4122. A Universally Unique IDentifier (UUID) URN Namespace. http://www.ietf.org/rfc/rfc4122.txt
RFC 4648	RFC 4648: The Base16, Base32, and Base64 Data Encodings. http://tools.ietf.org/rfc/rfc4648.txt

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

в соответствии со спецификацией SOAP 1.2 и состоит из блока заголовков (soap:Header) и блока содержимого (soap:Body).

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

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 – заголовок, идентифицирующий экземпляр процедуры общего процесса;

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

з) int:Integration – служебный заголовок интеграционной платформы интегрированной системы.

30. Заголовок wsa:To используется при выполнении процедуры маршрутизации сообщения.

Заголовок wsa:To обязателен для заполнения и должен содержать логический адрес получателя, сформированный в соответствии с правилами, приведенными в подразделе 3 настоящего раздела.

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

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.

Таблица 3

Структура заголовка int:ProcedureID

Элемент

Тип данных

Описание

int:ProcedureID

xs:string

идентификатор экземпляра процедуры общего процесса

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

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

со следующими правилами:

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

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

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

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

Заголовок int:ConversationID формируется в соответствии

со структурой, приведенной в таблице 4, и схемой данных заголовка

в соответствии с приложением № 2 к настоящим Правилам.

Таблица 4

Структура заголовка int:ConversationID

Элемент

Тип данных

Описание

int:ConversationID

xs:anyURI

идентификатор экземпляра транзакции общего процесса

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

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

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

с приложением № 2 к настоящим Правилам.

Таблица 5

Структура заголовка int:Integration

Элемент

Тип данных

Описание

Кратность

int:Integration		int:IntegrationType	оборачивающий элемент заголовка
	int:TrackID	xs:anyURI	технологический идентификатор сообщения	1
	int:AcceptTime	xs:dateTime	дата и время приема сообщения интеграционной платформой интегрированной системы	1

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

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

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

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

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

электронного обмена данными

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

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

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

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

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

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

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

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

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

Таблица 6

Перечень идентификаторов сегментов интегрированной системы

Назначение

Аббревиатура домена

интеграционный сегмент Комиссии

EEC

национальные сегменты

государств-членов

согласно стандарту ISO 3166-1 (alpha-2)

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

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

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

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

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

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

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

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

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

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

52. Идентификатор органа государственной власти

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

53. Идентификаторы органов государственной власти

государства-члена либо уполномоченных ими организаций заполняются в соответствии с перечнем органов государственной власти

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

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

55. Пространство 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:аnyURI. Указанный атрибут должен содержать значение заголовка 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

Состав блока содержимого технологического сообщения об ошибке

Элемент

Тип данных

Описание

Кратность

soap:Fault					soap:Fault	оборачивающий элемент блока
	soap:Code				soap:faultcode	оборачивающий элемент	1
		soap:Value			soap:faultcodeEnum	класс ошибки	1
		soap:Subсode			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

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

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

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

в таблице 8.

Таблица 8

Типовые коды ошибок

Класс

ошибки

Код ошибки

Описание и особенности применения

soap:Sender	wsa:InvalidAddressingHeader	используется согласно правилам, определенным спецификацией WS-Addressing 1.0 – Binding, со следующими ограничениями: значения Subsubcode не используются ошибка типа wsa:DuplicateMessageID не формируется и не отправляется
soap:Sender	wsa:MessageAddressingHeaderRequired	используется согласно правилам, определенным спецификацией 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	полученные данные прикладного уровня имеют неверную структуру

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 приведена в приложении № 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. Для целей упрощения обработки нештатных ситуаций в интеграционных шлюзах национальных сегментов государств-членов хранится диагностическая информация об обработке сообщений, которая передается в интеграционный шлюз интеграционного сегмента Комиссии в порядке согласно приложению № 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).

Рис. 1. Пример связывания сообщений общего процесса

в транзакциях общего процесса

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.

Рис. 2. Последовательность выполнения транзакции общего

процесса по шаблону "Взаимные обязательства"

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3. Последовательность выполнения транзакции общего процесса

по шаблону "Вопрос/ответ"

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

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

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

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

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

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

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

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

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

сигнал-подтверждение "Получено";

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

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

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

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

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

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

Рис. 4. Последовательность выполнения транзакции общего процесса

по шаблону"Запрос/ответ" с обеспечением

гарантированности доставки

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

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

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

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

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

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

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

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

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

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

респондент обеспечивает обработку принятого

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

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

после получения респондентом от инициатора

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

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

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

Рис. 5. Последовательность выполнения транзакции общего процесса

по шаблону "Запрос/подтверждение" с обеспечением гарантированности

доставки

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

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

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

Если респондент не отправил указанный сигнал-подтверждение

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

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

инициатор отправляет в адрес респондента

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

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

после получения инициатором от респондента

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

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

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

по шаблону "Оповещение"

9. Транзакция общего процесса по шаблону

"Распространение информации"

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

об ошибке.

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

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

Рис. 7. Последовательность выполнения транзакции общего процесса

по шаблону "Распространение информации"

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

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

государств-членов и Комиссии.

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

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

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

ПРИЛОЖЕНИЕ № 1
к Правилам электронного обмена
данными в интегрированной
информационной системе
внешней и взаимной торговли

ОПИСАНИЕ
протокола электронного обмена данными между интеграционными
шлюзами интегрированной информационной системы внешней и
взаимной торговли на транспортном уровне

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.

Таблица 1

Значения полей MQMD

Имя поля

Значение

Комментарий

Version	MQMD_VERSION_2	используется только вторая версия заголовков
MsgType	MQMT_DATAGRAM	обмен осуществляется только дейтаграммами
Expiry	144000	ограничение на истечение срока доставки сообщения – 4 часа
Persistence	MQPER_PERSISTENT	включен режим гарантированной доставки
Report	MQRO_EXPIRATION_WITH_FULL_DATA	запрашивается уведомление об истечении срока доставки сообщения
ReplyToQ	имя очереди получения ответов	используется для формирования и передачи транспортных уведомлений об ошибке
ReplyToQmgr	имя менеджера для получения ответов	используется для формирования и передачи транспортных уведомлений об ошибке

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

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

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

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

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

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

Таблица 2

Перечень идентификаторов сегментов интегрированной системы

Назначение

Аббревиатура домена

интеграционный сегмент Евразийской экономической комиссии

EEC

национальные сегменты

государств-членов

согласно стандарту ISO 3166-1 (alpha-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
к Правилам электронного обмена
данными в интегрированной
информационной системе
внешней и взаимной торговли

СХЕМА ДАННЫХ
специализированных элементов и атрибутов, используемых при
формировании сообщений в интегрированной информационной системе
внешней и взаимной торговли

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:int="urn:EEC:Interaction:v1.0"

targetNamespace="urn:EEC:Interaction:v1.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>

</xs:element>

<xs:element name="AcceptTime" type="xs:dateTime">

<xs:annotation>

<xs:documentation>Дата и время приема ЭС интеграционным шлюзом</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
к Правилам электронного обмена
данными в интегрированной
информационной системе
внешней и взаимной торговли

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

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

<?xml version="1.0" encoding="UTF-8"?>

<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:To>EAEU://EEC/CP/P.SP.03/P.ACT.001</wsa:To>

<wsa:ReplyTo>

<wsa:Address>EAEU://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:MessageID>urn: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>

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

<?xml version="1.0" encoding="UTF-8"?>

<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:To>EAEU://RU/CP/P.SP.03/P.SP.03.ACT.002</wsa:To>

<wsa:From>

<wsa:Address>EAEU://EEC/SR/gate</wsa:Address>

</wsa:From>

<wsa:Action>http://www.w3.org/2005/08/addressing/soap/fault</wsa:Action>

<wsa:MessageID>urn: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:TrackID>urn:uuid:5fbc4b5a-2937-483e-91ea-45a056938a4e</int:TrackID>

<int:AcceptTime>2015-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:Value>int:InternalError</soap:Value>

</soap:Subcode>

</soap:Code>

<soap:Reason>

<soap:Text xml:lang="ru">Внутренняя ошибка преобразования формата</soap:Text>

</soap:Reason>

<soap:Detail>

<int:ProblemMessage><![CDATA[

<?xml version="1.0" encoding="UTF-8"?>

<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:To>EAEU://EEC/CP/P.SP.03/P.ACT.001</wsa:To>

<wsa:ReplyTo>

<wsa:Address>EAEU://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: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>

ПРИЛОЖЕНИЕ 4
к Правилам электронного обмена
данными в интегрированной
информационной системе внешней
и взаимной торговли

ТРЕБОВАНИЯ
к порядку хранения диагностической информации и ее передачи из
интеграционных шлюзов национальных сегментов интегрированной
информационной системы внешней и взаимной торговли в
интеграционный сегмент интегрированной информационной системы
внешней и взаимной торговли

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

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

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

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

г) отправка сообщения доверенной третьей стороне;

д) получение сообщения от доверенной третьей стороны;

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

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

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

(далее – Комиссия):

а) при получении запроса от интеграционного сегмента Комиссии;

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

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

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

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

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

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

Таблица 1

Пространства имен документа

Префикс	Адрес
journ	urn:EEC:Interaction:v1.0:Service:Util:Journal
xs	http://www.w3.org/2001/XMLSchema

Таблица 2

Состав блока содержимого служебного

сообщения синхронизации диагностической информации

Элемент							Тип данных	Описание	Кратность
putJournal								оборачивающий элемент
	journ:Journal							оборачивающий элемент	1
		journ:Rec						оборачивающий элемент для записи журнала	0..n
			journ:MessageDetail					детализация сообщения	0..1
				journ:ProcessInfo				блок сведений об общем процессе – для общих процессов, для других сообщений заполняется Action	1
					journ:Code		xs:string	код общего процесса согласно регламенту информационного взаимодействия	1
					journ:Version		xs:string	версия общего процесса	1
					journ:ProcedureCode		xs:string	код процедуры согласно регламенту информационного взаимодействия	1
					journ:TransactionCode		xs:string	код транзакции общего процесса согласно регламенту информационного взаимодействия	1
					journ:MessageCode		xs:string	код сообщения согласно регламенту информационного взаимодействия	1
				journ:Action			xs:anyURI	заголовок wsa:Action, идентифицирующий содержимое сообщения	1
				journ:Routing				информация о маршруте сообщения	1
					journ:To		xs:anyURI	заголовок wsa:To, содержащий сведения о получателе	1
						@Segment	xs:string	сегмент получателя	1
					journ:ReplyTo		xs:anyURI	заголовок wsa:ReplyTo/wsa:Address, содержащий сведения о логическом адресе отправителя, на который должно быть направлено сообщение-ответ	0..1
					journ:From		xs:anyURI	заголовок wsa:From/wsa:Address, содержащий сведения о логическом адресе отправителя, на который не может быть направлено сообщение-ответ	0..1
					journ:FaultTo		xs:anyURI	заголовок wsa:FaultTo/wsa:Address, содержащий сведения о логическом адресе отправителя, на который должно быть направлено сообщение-ответ c ошибкой	0..1
					journ:FromSegment		xs:anyURI	сегмент-источник сообщения (заполняется на основе адреса From или ReplyTo)	1
				journ:MessageID			xs:anyURI	заголовок wsa:MessageID, содержащий идентификатор сообщения	1
				journ:RelatesTo			xs:anyURI	заголовок wsa:RelatesTo, содержащий ссылочный идентификатор сообщения	0..1
				journ:ConversationID			xs:anyURI	заголовок int:ConversationID, содержащий идентификатор экземпляра процедуры общего процесса	0..1
				journ:MessageType			xs:string	тип сообщения	1
				journ:Receipt				информация о квитанции доверенной третьей стороны	0..1
					journ:DocumentRef		xs:string	идентификатор электронного документа	1
					journ:ReceiptId		xs:string	идентификатор квитанции доверенной третьей стороны	1
					journ:IsValid		xs:boolean	результат проверки электронной цифровой подписи (электронной подписи) в электронном документе	1
					journ:ErrorCode		xs:string	код ошибки при проверке электронной цифровой подписи (электронной подписи) в электронном документе	0..1
					journ:ReasonText		xs:string	причина ошибки при проверке электронной цифровой подписи (электронной подписи) в электронном документе	0..1
			journ:OperationDt				xs:dateTime	дата операции	1
			journ:TrackID				xs:anyURI	технологический уникальный идентификатор сообщения	1
			journ:AcceptTime				xs:dateTime	дата и время приема сообщения интеграционным шлюзом	1
			journ:Source				xs:string	наименование системы – источника сообщения	1
			journ:Receiver				xs:string	наименование системы – приемника сообщения	1
			journ:Status				xs:string	статус обработки	1
			journ:Msg				xs:string	сообщение в точке журналирования	1
			journ:ErrorTxt				xs:string	ошибка обработки (при наличии)	0..1
			journ:ErrorCode				xs:string	код ошибки обработки	0..1
			journ:IDRef				xs:string	ссылочный идентификатор записи – обязателен при отправке в Комиссию	0..1
		journ:SourceSegment					xs:string	сегмент-источник журнала	1

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

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

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

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

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

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

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

Таблица 3

Состав блока содержимого служебного

сообщения запроса диагностической информации

Элемент		Тип данных	Описание	Кратность
getJournal			оборачивающий элемент
	journ:MessageID	xs:anyURI	идентификатор сообщения, которое должно быть найдено. Заполняется либо MessageID, либоTrackID	1
	journ:TrackID	xs:anyURI	технологический идентификатор сообщения, которое должно быть найдено. Заполняется либо MessageID, либо TrackID	1
	journ:FindRelates	xs:boolean	признак запроса связанных сообщений. Актуально при запросе по MessageID	1

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

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

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

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

ПРИЛОЖЕНИЕ 5
к Правилам электронного обмена
данными в интегрированной
информационной системе внешней
и взаимной торговли

ОПИСАНИЕ
структуры и реквизитного состава сигналов-подтверждений и
сигналов-исключений

1. При описании структуры и реквизитного состава

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

Таблица 1

Пространства имен

Префикс	Адрес
xs	http://www.w3.org/2001/XMLSchema
sgn	urn:EEC:signal:v1.0

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

Таблица 2

Базовые типы данных

Наименование	Описание
sgn:EDocIdType	идентификатор документа, являющийся UUID в соответствии со стандартом ISO/IEC 9834-8:2005. Строка символов с шаблоном [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}
sgn:DateTimeType	дата по григорианскому календарю и время в формате стандарта ISO 8601 "Data elements and interchange formats – Information interchange – Representation of dates and types"
sgn:ErrorCodeType	кодовое обозначение ошибки контроля. Строка от 1 до 255 символов
sgn:StringType	произвольная информация в текстовой форме. Строка произвольной длины

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

Таблица 3

Структура и реквизитный состав

сигнала-подтверждения "Получено"

Элемент		Тип данных	Описание	Кратность
sgn:DeliveryReceipt		sgn:DeliveryReceiptType	оборачивающий элемент сигнала-подтверждения "Получено"
	sgn:SignalId	sgn:EDocIdType	идентификатор сигнала	1
	sgn:DateTime	sgn:DateTimeType	дата и время формирования сигнала-подтверждения "Получено"	1

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

Таблица 4

Структура и реквизитный состав

сигнала-подтверждения "Принято в обработку"

Элемент

Тип данных

Описание

Кратность

sgn:ProcessingReceipt		sgn:ProcessingReceiptType	оборачивающий элемент сигнала-подтверждения "Принято в обработку"
	sgn:SignalId	sgn:EDocIdType	идентификатор сигнала	1
	sgn:DateTime	sgn:DateTimeType	дата и время формирования сигнала-подтверждения "Принято в обработку"	1

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

Таблица 5

Структура и реквизитный состав

сигнала-исключения "Ошибка"

Элемент

Тип данных

Описание

Кратность

sgn:ValidationError			sgn:ValidationError Type	оборачивающий элемент сигнала-исключения "Ошибка"
	sgn:SignalId		sgn:EDocIdType	идентификатор сигнала-исключения "Ошибка"	1
	sgn:DateTime		sgn:DateTimeType	дата и время формирования сигнала-исключения "Ошибка"	1
	sgn:Error		sgn:ErrorType	оборачивающий элемент	1..*
		sgn:Code	sgn:ErrorCodeType	кодовое обозначение ошибки	1
		sgn:Description	sgn:StringType	обозначение ошибки в текстовой форме	1
		sgn:Details	sgn:StringType	детализированные сведения об ошибке	0..1
		sgn:EDocId	sgn:EDocIdType	идентификатор документа, в котором возникла ошибка. Заполняется, если ошибка относится к конкретному документу и идентификатор документа удалось извлечь	0..1
		sgn:Reference	sgn:StringType	строка символов, позволяющая однозначно локализовать элемент, вызвавший ошибку	0..1

ПРИЛОЖЕНИЕ 6
к Правилам электронного обмена
данными в интегрированной
информационной системе внешней
и взаимной торговли

СХЕМА ДАННЫХ

сигналов-подтверждений и сигналов-исключений

<?xml version="1.0" encoding="UTF-8"?>

<!--

Структура и реквизитный состав сигналов-подтверждений и сигналов-исключений

-->

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

<xs: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:simpleType>

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

<xs:documentation>Произвольная информация в текстовой форме</xs: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>Идентификатор сигнала-исключения</xs: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>

Еуразиялық экономикалық қоғамдастықтың Мемлекетаралық Кеңесінің 2010 жылғы 19 қарашадағы № 60 шешімімен бекітілген Кеден одағының сыртқы және өзара саудасының интеграцияланған ақпараттық жүйесін құру тұжырымдамасын іске асыру мақсатында және Еуразиялық экономикалық одақ шеңберіндегі ақпараттық-коммуникациялық технологиялар мен ақпараттық өзара іс-қимыл туралы хаттаманың 3 және 30-тармақтарына сәйкес (2014 жылғы 29 мамырдағы Еуразиялық экономикалық одақ туралы шартқа № 3 қосымша) Еуразиялық экономикалық комиссия Алқасы шешті:

1. Қоса беріліп отырған Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу қағидалары бекітілсін.

2. Осы Шешім ресми жарияланған күнінен бастап күнтізбелік 30 күн өткен соң күшіне енеді.

Еуразиялық экономикалық комисиясы
Алқасының төрағасы	В. Христенко

Еуразиялық экономикалық комиссия Алқасының
2015 жылғы 27 қаңтардағы
№ 5 шешімімен
БЕКІТІЛГЕН

Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу ҚАҒИДАЛАРЫ

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) ұсынған белгілеудің кеңейтілген тілі;

"асинхронды өзара іс-қимыл" – жөнелтуші хабарды жібергеннен кейін оны алушының жауабын күтпестен бірдендеректерді электрондық алмасудың түрі;

"бастамашы" – электрондық деректерді алмасудың жалпы процесінің транзакциясына бастамашы болатын қатысушы;

"интеграциялық шлюз" – интеграцияланған жүйенің әрбір торабында өрістетілетін және мүше мемлекеттердің ұлттық сегменті мен Комиссияның интеграцияланған жүйесінің интеграцияланған платформасының ұштасуын қамтамасыз ететін бағдарламалық және аппараттық құралдардың кешені;

"жалпы процесс рәсімі" – жалпы процеске қатысушылар орындайтын және жалпы процесс шеңберінде нақты міндетті шешуге бағытталған өзара байланысты операциялардың жиынтығы;

"респондент" – жалпы процесс транзакциясын орындау шеңберінде бастамашымен хабарлар алмасатын электрондық деректер алмасуға қатысушы;

"хабар" – ақпараттық-телекоммуникация желісінің көмегімен жөнелтушіден алушыға берілетін нысандалған ақпарат;

"жалпы процесс транзакциясы" – әрбір қатысушы жалпы процестегі өз операциясы шеңберінде жүзеге асыратын, қос қатысушы арасындағы кәдімгі ақпараттық өзара іс-қимыл;

"жалпы процеске қатысушы" – жалпы процесс шеңберінде деректерді электрондық алмасуға қатысушы;

"деректерді электрондық алмасуға қатысушы" – Комиссия, деректерді электрондық алмасуға қатысатын уәкілетті орган;

Осы Қағидаларда "сенім білдірілген үшінші тарап, "мүше мемлекеттің ұлттық сегменті", "Комиссияның интеграциялық сегменті", "Одақ шеңберіндегі жалпы процесс" және "уәкілетті орган" ұғымдары Еуразиялық экономикалық одақ шеңберіндегі ақпараттық-коммуникациялық технологиялар және ақпараттық өзара іс-қимыл туралы хаттамада айқындалған мәндерінде пайдаланылады (2014 жылғы 29 мамырдағы Еуразиялық экономикалық одақ туралы шартқа № 3 қосымша).

5. Интеграцияланған жүйеде деректерді электрондық алмасу мүше мемлекеттердің ұлттық сегменттері арасында, сондай-ақ мүше мемлекеттердің ұлттық сегменттері мен Комиссияның интеграциялық сегменті арасында 2014 жылғы 29 мамырдағы Еуразиялық экономикалық одақ туралы шартқа № 3 қосымшаға, Одақ құқығын құрайтын электрондық нұсқада ақпарат алмасу көзделген өзге де халықаралық шарттар мен актілерге сәйкес жүзеге асырылады.

6. Интеграцияланған жүйе арқылы Одақ шеңберінде жалпы процестерді (бұдан әрі – жалпы процестер) іске асыру мақсатында деректерді электрондық алмасуға қатысушылар жүйелерінің мынадай түрлері арасында деректерді электрондық алмастыру қолдау тауып отырады:

а) мүше мемлекеттердің мемлекеттік ақпарат жүйелері және уәкілетті органдардың ақпарат жүйелері;

б) Комиссияның ақпарат жүйелері.

7. Басқа да мүше мемлекеттердің және Комиссияның ақпарат жүйелерімен деректерді электрондық алмасуға қатысатын мүше мемлекеттердің мемлекеттік ақпарат жүйелері логикалық түрде мүше мемлекеттердің ұлттық сегменттерінің құрамына кіреді.

8. Мүше мемлекеттердің ұлттық сегменттерінің интеграциялық шлюздері логикалық түрде интеграцияланған жүйенің интеграциялық платформасының құрамына кіре отырып,мүше мемлекеттердің аумақтарында орналасады және мұндай сегменттерді интеграцияланған жүйесінің интеграциялық платформасына қосудың бірыңғай нүктелері болып табылады.

9. Мүше мемлекеттердің ұлттық сегменттерінің интеграциялық шлюздерінің негізгі функциялары мүше мемлекеттердің ұлттық сегменттерінің алмасу хаттамалары мен деректер форматтарын интеграцияланған жүйеде қолданылатын алмасу хаттамалары мен деректер форматына өзгерту және хабарларды бағыттандыру болып табылады.

Комиссияның интеграциялық сегментінің интеграциялық шлюзінің негізгі функциясы хабарларды бағыттандыру болып табылады.

10. Мүше мемлекеттердің ұлттық сегменттерінің және Комиссияның интеграциялық сегментінің құрамына интеграцияланған жүйе құралдарының көмегімен жүзеге асырылатын деректерді электрондық алмасу кезінде заңдастыруды, сенім кепілдігін және цифрлық қолтаңбаны (электрондық қолтаңбаны) қолданудың құқықтылығын қамтамасыз ететін сенім білдірілген үшінші тараптың сервистері кіреді. Сенім білдірілген үшінші тараптың сервистерін іске асыру сервистердің мемлекетаралық ақпараттық өзара іс-қимылы кезінде пайдалану тұжырымдамасын және Еуразиялық экономикалық комиссия Кеңесінің 2014 жылғы 18 қыркүйектегі № 73 шешімімен бекітілген заңды күші бар нормативтік-техникалық құжаттарды ескере отырып жүзеге асырылады.

Сенім білдірілген үшінші тараптың сервистері уәкілетті органдармен келісу бойынша Комиссия қабылдайтын (бекітетін) және сервистердің мемлекетаралық ақпараттық өзара іс-қимылы кезінде және заңды күші бар электрондық құжаттардың пайдалану қағидаттарын белгілейтін нормативтік-техникалық құжаттарға сәйкес пайдаланылады.

11. Мүше мемлекеттердің ұлттық сегменттерінің ішінде деректерді беру кезінде ведомствоаралық ақпараттық өзара іс-қимыл жүйелері және жұмыс істеуі мүше мемлекеттердің заңнамасымен реттелетін мүше мемлекеттердегі деректер берудің өзге де жүйелері пайдаланылуы мүмкін.

II. Деректерді электрондық алмасу рәсімдері

12. Интеграцияланған жүйеде қатысушылар арасындағы деректерді электрондық алмасу мынадай логикалық: көліктік, технологиялық және қолданбалы деңгейлерде жүзеге асырылады.

Деректерді көліктік деңгейде электрондық алмасу рәсімдері HTTP, SMTP, MQ, FTP және басқалары сияқты деректерді жеткізудің көліктік протоколдары арқылы бір қатысушының жүйесінен басқа қатысушының жүйесіне деректер жеткізуді қамтамасыз етеді.

Деректерді технологиялық деңгейде электрондық алмасу рәсімдері деректерді көліктік деңгейде жеткізу протоколдары арқылы деректерді электрондық алмасуға қатысушылар арасында хабарлар алмасуды қамтамасыз етеді.

Деректерді қолданбалы деңгейде электрондық алмасу рәсімдері хабарлар арқылы деректерді электрондық алмасуға қатысушылар арасында электрондық құжаттар және электрондық құжат түрлерін (бұдан әрі – қолданбалы деңгейдің деректері) алмасуды қамтамасыз етеді.

13. Интеграцияланған шлюздер арасындағы деректерді көліктік деңгейде электрондық алмасу асинхронды орындалады.

Интеграцияланған шлюздер арасында деректерді көліктік деңгейде электрондық алмасу хаттамасының сипаттамасы №1 Қосымшада келтірілген. Бұл ретте мүше мемлекеттердің ұлттық сегменттері мен Комиссияның интеграциялық сегменті ішінде деректерді жеткізу хаттамалары үшін шектеу белгіленбеген.

14. Интеграцияланған шлюздер арасында деректерді технологиялық деңгейде электрондық алмасу SOAP форматындағы хабарлар арқылы орындалады.

Хабарлардың құрылымы мен форматына қойылатын талаптар, сондай-ақ хабарларды технологиялық деңгейде алмасу тәртібі осы Қағидалардың IV және V бөлімдеріне сәйкес белгіленеді.

15. Жалпы процестерді іске асыру кезінде деректерді қолданбалы деңгейде электрондық алмасу рәсімдерін орындау кезіндегі қолданбалы деңгей деректерінің құрылымы мен форматы, сондай-ақ мұндай алмасудың тәртібі осы Қағидалардың IV және V бөлімдеріне және жалпы процестердің интеграцияланған ақпараттық жүйесі құралдарымен іске асыру кезінде ақпараттық өзара іс-қимылды реттейтін, тізбесі Еуразия экономикалық комиссиясы Алқасының 2014 жылғы 6 қарашадағы № 200 шешімімен бекітілген (бұдан әрі – ақпараттық өзара іс-қимылды реттейтін технологиялық құжаттар) технологиялық құжаттарға сәйкес белгіленеді.

ІІІ. Деректерді электрондық алмасу рәсімдерін орындау жауапкершілігі

16. Мүше мемлекеттің ұлттық сегментінің жауапкершілік аймағына мүше мемлекеттің ұлттық сегментінің интеграцияланған шлюзінен қоса алғанда деректерді электрондық алмасуға қатысушыға дейінгі деректерді беру учаскесі кіреді.

Комиссияның интеграциялық сегментінің жауапкершілік аймағына осы сегменттің құрауыштары, сондай-ақ мүше мемлекеттердің ұлттық сегменттері мен Комиссияның интеграциялық сегменті арасындағы деректерді беру арналары кіреді.

17. Мүше мемлекеттер және Комиссия өз аймақтарының шегінде деректерді электрондық алмасуда жасалатын барлық операцияларға Қағидалардың тиісті бөлімдерінде белгіленетін көлемде жауапкершілікті болады.

Қолданбалы деңгейде ақпараттық өзара іс-қимыл рәсімдерін орындауды оған қатысушылар қамтамасыз етеді.

IV. Хабарлардың құрылымы мен форматы

1.Жалпы талаптар

18. Хабарлардың құрылымы мен форматын сипаттау кезінде 1-кестеде келтірілген атаулар кеңістігі, сондай-ақ, 2-кестеде келтірілген ерекшеліктер пайдаланылады.

1-кесте

Құжат атауы кеңістігінің тізбесі

Префикс	Мекенжай
int	urn:EEC:Interaction:v1.0
зоар	http://www.w3.org/2003/05/soap-envelope
wsa	http://www.w3.org/2005/08/addressing
хор	http://www.w3.org/2004/08/xop/include
хз	http://www.w3.org/2001/XMLSchema

2-кесте

Хабарлардың құрылымы мен форматын сипаттау кезінде пайдаланылатын ерекшеліктер

Қысқаша атауы	Ерекшеліктердің толық атауы
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
WS-Addressing 1.0–Core	Web Services Addressing 1.0 – Core. W3C Recommendation 9 May 2006. http://www.w3.org/TR/ws-addr-core
WS-Addressing 1.0–Binding	Web Services Addressing 1.0 – SOAP Binding. W3C Recommendation 9 May 2006. http://www.w3.org/TR/ws-addr-soap
XML-binary Optimized Packaging	XML-binary Optimized Packaging. W3C Recommendation 25 January 2005. http://www.w3.org/TR/2005/REC-xop10-20050125
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
RFC 2045	RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. http://tools.ietf.org/rfc/rfc2045.txt
RFC 3986	RFC 3986. Uniform Resource Identifier (URI): Generic Syntax. http://tools.ietf.org/html/rfc3986
RFC 4122	RFC 4122. A Universally Unique IDentifier (UUID) URN Namespace. http://www.ietf.org/rfc/rfc4122.txt
RFC 4648	RFC 4648: The Base16, Base32, and Base64 Data Encodings. http://tools.ietf.org/rfc/rfc4648.txt

19. Технологиялық деңгейде интеграцияланған шлюздер арасында SOAP форматында берілетін хабарлар SOAP 1.2 ерекшелігіне сәйкес ресімделдеді және тақырыптар блогынан (soap:Header) және ішінде хабар бар блоктан (soap:Body) тұрады.

20. Тақырыптар блогы хабарларды бағыттандыру және өңдеу функцияларын орындау үшін, сондай-ақ деректерді электрондық алмасу мониторингі үшін қажетті технологиялық ақпаратты қамтиды.

21. Ішінде хабар бар блокдеректерді электрондық алмасуға қатысушылар үшін маңызды қолданбалы не технологиялық ақпаратты қамтиды, бұған соның ішінде қателер туралы технологиялық хабарлар да жатады.

22. Хабар бір қосар немесе одан да көп салымды қамтуы мүмкін. Қосар салымдар Base64 (RFC 4648) сәйкес) форматында ішінде хабар бар блокқа енгізілуі немесе дербес М1МЕ-бөліктері түрінде ресімделуі мүмкін.

23. Қосар салымдарды дербес М1МЕ-бөліктері түрінде беру кезінде ішінде хабар бар блоктың ішінде XML-binary Optimized Packaging ерекшелігіне сәйкес М1МЕ-бөлігіне сілтеме жасалады.

24. М1МЕ-бөліктегі хабарлар айрықша түрде хабар беру процестерін оңтайландыру үшін пайдаланылады. Хабарды өңдеу XML-binary Optimized Packaging ерекшелігінің XOP өңдеу моделіне сай жүзеге асырылуға тиіс.

25. Егер қосар салымның мөлшері 2Мб-тан асатын болса, бұл жағдайда, қосар салымдарды М1МЕ-бөліктері түрінде ресімдеу ұсынылады.

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 – жалпы процесс рәсімі данасын сәйкестендіретін тақырып;

ж) int:ConversationID – жалпы процесс транзакциясы данасын сәйкестендіретін тақырып;

з) int:Integration – интеграцияланған жүйенің интеграциялық платформасының қызметтік тақырыбы.

30. WSA:To тақырыбы хабарды бағыттандыру рәсімін орындау кезінде пайдаланылады.

WSA:To тақырыбы орындалуға міндетті және алушының осы бөлімнің 3-кішібөлімінде келтірілген қағидаларға сәйкес жасалған логикалық мекенжайын қамтуға тиіс.

31. Жөнелтушіні сәйкестендіретін тақырыптарда логикалық мекенжайлар осы бөлімнің 3-кіші бөлімінде келтірілген осындай мекенжайлар қалыптастыру қағидаларына сәйкес көрсетіледі.

32. WSA:ReplyTo тақырыбы алушының жөнелтуші үшін хабар-жауапты қалыптастыру мүмкіндігін қамтамасыз етуіне арналған. Жөнелтушінің логикалық мекенжайы wsa:ReplyTo тақырыбының wsa:Address элементінде көрсетіледі.

33. WSA:From тақырыбы түпкі хабарды жөнелтуші туралы мәліметтер беруге арналған. Жөнелтушіні сәйкестендіретін логикалық мекенжай wsa:From тақырыбындағы wsa:Address элементінде көрсетіледі.

34. Егер wsa:From тақырыбы толтырылмаса, жөнелтуші wsa:ReplyTo тақырыбы бойынша сәйкестендіріледі.

35.WSA:FaultTo тақырыбы wsa:ReplyToөрісінде көрсетілгеннен өзгеше логикалық мекенжайға қателер туралы технологиялық хабарлар беру мүмкіндігін қамтамасыз етуге арналған. Қателер туралы технологиялық хабарларды қабылдау үшін жөнелтуші пайдаланатын логикалық мекенжай wsa:FaultTo тақырыбының wsa:Address элементінде көрсетіледі.

Егер wsa:FaultTo тақырыбы толтырылмаса, қателер туралы технологиялық хабарлар өз атына хабар-жауап(wsa:ReplyTo/wsa:Address)жіберілуге тиіс деректерді электрондық алмасуға қатысушыға жіберіледі.

36. WSA:MessageID тақырыбы хабарлардың жекелеген даналарын бірегей сәйкестендіруге арналған. WSA:MessageID тақырыбы толтырылуға міндетті.

Хабарларды сәйкестендірушілердің мәндері жаһандық тұрғыда бірегей болуға және RFC 4122 ерекшелігіне сай UUID білдіруге тиіс.

37. WSA:RelatesTo тақырыбы хабарлардың тізбегін ұйымдастыруға арналған.

WSA:RelatesTo тақырыбы түпкі хабардың wsa:MessageID тақырыбының мәніне ие болуға тиіс. Бұл ретте wsa:MessageID тақырыбы жаңа мәнмен толтырылуға тиіс.

38. WSA:Action тақырыбы телехабарларда берілетін деректер семантикасы туралы деректерді электрондық алмасуға қатысушыларды хабардар етуге арналған. WSA:Action тақырыбы толтырылуға міндетті.

39. INT:ProcedureID тақырыбы орындау барысында хабар жөнелтілген жалпы процесс рәсімі данасын бірегей сәйкестендіруге арналған. Тақырып жалпы процестерді іске асыру кезінде деректерді электрондық алмасу мониторингі мақсатында пайдаланылады.

INT:ProcedureID тақырыбы 3-кестеде келтірілген құрылымға сәйкес және №2 қосымшаға сай келетін деректер схемасымен құралымдалады.

3-кесте

INT:ProcedureID тақырыбының құрылымы

Элемент

Деректер үлгісі

Сипаттама

int:ProcedureID xs:string жалпы процесс рәсімі

данасын сәйкестендіруші

Тақырыптардың мәні "/" символымен бөлінген құрауыштардан тұратын жол болып табылады. Әрбір құрауыш RFC 4122 ерекшелігіне сәйкес UUID болып табылады.

int:ProcedureID тақырыбының жолдары мынадай қағидаларға сәйкес қалыптасады:

тақырыптың бастапқы мәнін (жолдың бірінші құрауышы) рәсімге бастамашы болатын жалпы процеске қатысушы береді;

егер жалпы процеске қатысушы енгізілген рәсімге бастамашылық жасаса, int:ProcedureID тақырыбының мәніне "/" символы және енгізілген рәсімді сәйкестендіретін UUID жаңа құрауышы қосылады;

бір рәсім шеңберінде (енгізілген рәсім) жалпы процеске қатысушылар арасында хабарларды электрондық алмасу кезінде мұндай қатысушылармен int:ProcedureID мәні өзгермейді.

40. int:ConversationID тақырыбы іске асыру барысында хабар жіберілген жалпы процесс транзакциясы рәсімі данасын бірегей сәйкестендіруге арналған.

int:ConversationID тақырыбы осы Қағидалардағы 4-кестеде көрсетілген құрылымға және № 2 қосымшаға сай тақырып деректерінің схемасына сәйкес қалыптасады.

4-кесте

int:ConversationID тақырыбының құрылымы

Элемент

Деректер түрі

Сипаттама

int:ConversationID xs:anyURI жалпы процесс транзакциясы

данасын сәйкестендендіргіш

Жалпы процесс транзакциясы данасын сәйкестендендіргіштің мәні бірегей болуға және RFC 4122ерекшелігіне сәйкес UUID білдіруге тиіс.

41. int:Integration интеграцияланған жүйе интеграциялық платформасының қызметтік тақырыбы интеграцияланған жүйенің интеграциялық платформасының шегінде хабарларды сәйкестендіруді қамтамасыз етеді және интеграцияланған жүйенің интеграциялық платформасы деңгейінде құрауыштармен қалыптасады (толтырылады).

42. int:Integration интеграцияланған жүйесінің қызметтік тақырыбы осы Қағидалардағы 5-кестеде келтірілген құрылымға және № 2 қосымшаға сай int:Integration тақырыбы деректеріне сәйкес қалыптасады.

5-кесте

int:Integrationтақырыбының құрылымы

Элемент	Деректердің түрі	Сипаттама	Еселігі
int:Integration	int:IntegrationType	тақырыптың айналмалы элементі
int:TrackID	xs:anyURI	хабардың технологиялық сәйкестендіруші сәйкестендіргісәйкестендірушішсәйкестендіруші идентификатор сообщения	1
int:AcceptTime	xs:dateTime	интеграцияланған жүйенің интеграциялық платформасының хабар қабылдау күні мен уақыты	1

43. Интеграцияланған жүйенің интеграциялық платформасының ішінде хабарларды сәйкестендіру үшін int:TrackID хабарды технологиялық сәйкестендіруші пайдаланылады.

Технологиялық сәйкестендіруші хабарға оны интеграцияланған жүйенің интеграциялық платформасы қабылдау кезінде беріледі.Технологиялық сәйкестендірушінің берілуі бір мәрте орындалады. Хабар интеграцияланған жүйенің интеграциялық платформасының құрауыштарымен берілген кезде технологиялық сәйкестендіруші өзгеруге тиіс емес.

Технологиялық сәйкестендірушінің мәні бірегей болып табылады және ол RFC 4122 сай UUID білдіреді.

44. INT:AcceptTime элементі интеграцияланған жүйенің интеграциялық платформасының хабар қабылдау күні мен уақытын қамтиды. Элементтің мәні хабар қабылдау кезінде қалыптасады және бұдан әрі хабар берілген кезде өзгермейді. Уақыт белдеуі көрсетіле отырып, уақыт әлемдік үйлестірілген уақыт форматында (UTC) көрсетілуге тиіс.

3. Деректерді электрондық алмасуға қатысушылардың логикалық мекенжайларын қалыптастыру

45. Деректерді электрондық алмасуға қатысушылардың логикалық мекенжайлары деректерді электрондық алмасуға қатысушыларға хабарды беру кезінде бағыттандыру рәсімдерін орындау үшін пайдаланылатын технологиялық сәйкестендірушілерді білдіреді.

46. Деректерді электрондық алмасуға қатысушылардың логикалық мекенжайларының форматы RFC 3986 ерекшелігіне сәйкес айқындалады және мынадай құрауыштардан тұрады:

а) "EAEU://"тіркелген кестесі;

б) "/"символымен бөлінген мекенжай құрауыштары.

47. Мекенжай құрауыштары:

а) сегмент сәйкестендіруші;

б) деректерді электрондық алмасуға қатысушылардың логикалық мекенжайлары кеңістігін сәйкестендіруші;

в) деректерді электрондық алмасуға қатысушыларды сәйкестендіруші болып табылады.

48. Сегменттердің сәйкестендірушісі6-кестеде келтірілген тізбеге сәйкес толтырылуға тиіс.

6-кесте

Интеграцияланған жүйе сегменттерінің сәйкестендірушілерінің тізбесі

Мақсаты

Доменнің қысқартылған атуы

Комиссияның интеграциялық сегменті ЕЕС

мүше мемлекеттердің ұлттық сегменттері ISO 3166-1 (alpha-2)стандартына сәйкес

49. Деректерді электрондық алмасуға қатысушылардың логикалық мекенжайлары кеңістігінің сәйкестендірушісін толтыру кезінде мынадай типтік мәндер пайдаланылуға тиіс:

а) CP (Common Process) - деректерді электрондық алмасуға қатысушылардың логикалық мекенжайларының кеңістігі;

б) CA (Competent Authority) – мүше мемлекеттердің мемлекеттік билік органдарын не олар уәкілеттік берген ұйымдарды, сондай-ақ Комиссияны сәйкестендіру үшін пайдаланылатын логикалық мекенжайлар кеңістігі;

в) SR (SeRvice)–интеграцияланған жүйенің интеграциялық платформасының, Комиссияның ақпарат жүйелерінің, интеграцияланған жүйенің кіші жүйесінің функционалдық және қамтамасыз ететін құрауыштарын сәйкестендіру үшін пайдаланылатын логикалық мекенжайлар кеңістігі.

50. СР кеңістігі жалпы процеске қатысушылардың логикалық мекенжайларын қалыптастыруға және есепке алуға арналған.

СР кеңістігі үшін жалпы процесс қатысушысының сәйкестендірушісі "/" символымен бөлінген мынадай құрауыштардан тұрады:

жалпы процестің коды;

жалпы процеске қатысушыны кодпен таңбалау;

мүше мемлекеттің мемлекеттік билік органын не ол уәкілеттік берген ұйымды сәйкестендіруші.

51. Жалпы процесс кодтарының мәндері және жалпы процеске қатысушыны кодтық таңбалау ақпараттық өзара іс-қимылды реттейтін технологиялық құжаттардың тізбесіне кіретін жалпы процестің интеграцияланған жүйесінің құралдарымен (бұдан әрі - ақпараттық өзара іс-қимыл қағидалары) іске асыру кезінде Комиссия Алқасы бекітетін ақпараттық өзара іс-қимыл қағидаларында келтіріледі.

52. Егер ақпараттық өзара іс-қимылды реттейтін технологиялық құжаттарда жалпы процестің аты аталған қатысушысының рөлін жалпы процестің бірнеше қатысушысы атқаруы мүмкін екендігі айқындалса, бұл жағдайларда,мүше мемлекеттің мемлекеттік билік органының не ол уәкілеттік берген ұйымның сәйкестендірушісі толтырылады. Қалған барлық жағдайларда аталған сәйкестендіруші толтырылмайды.

53. Мүше мемлекеттің мемлекеттік билік органдарының не олар уәкілеттік берген ұйымдардың сәйкестендірушілері Комиссия Алқасы белгілеген тәртіппен Комиссия уәкілетті органдармен бірлесіп жүргізетін мүше мемлекеттің мемлекеттік билік органдарының тізбесіне және олар уәкілеттік берген ұйымдардың тізбесіне сәйкес толтырылады.

54. Егер ақпараттық өзара іс-қимылды реттейтін технологиялық құжаттарда не Комиссия уәкілетті органдармен келісу бойынша қабылдайтын (бекітетін) өзге де нормативтік-техникалық құжаттарда өзгеше айқындалмаса, жалпы процестерді іске асыру кезінде СР кеңістігінің логикалық мекенжайлары жөнелтушілердің (алушылардың) адрестеуі үшін пайдаланылуға тиіс.

55. СА кеңістігі мүше мемлекеттердің нақты мемлекеттік билік органдарының не олар уәкілеттік берген ұйымдардың, сондай-ақ Комиссияның мекенжайына жіберуге арналған. Комиссияның және кез келген мүше мемлекеттің әрбір мемлекеттік билік органының не мұндай орган уәкілеттік берген ұйымның СА кеңістігінде логикалық мекенжайы болуға тиіс.

СР кеңістігінің логикалық мекенжайлары ақпараттық өзара іс-қимылды реттейтін технологиялық құжаттарда не Комиссияның уәкілетті органдармен келісуі бойынша қабылдайтын (бекітетін) өзге де нормативтік-техникалық құжаттарында айқындалмаған жағдайларда, жалпы процестерді іске асыру кезінде жөнелтушілердің (алушылардың) адрестеуі үшін пайдаланылуы мүмкін.

56. SR кеңістігі интеграцияланған жүйенің интеграциялық платформасында,Комиссияның ақпарат жүйелерінде, интеграцияланған жүйенің функционалдық және қамтамасыз ететін кіші жүйелерінде пайдаланылады.

Деректерді электрондық алмасуды іске асыру кезінде Ақпараттық шлюздерді бір мәнде сәйкестендіру мақсаты үшін SR кеңістігіндегі ақпараттық шлюздерге gate сәйкестендірушісі бекітіледі.

Деректерді электрондық алмасуға қатысушылардың сәйкестендірушілерін қалыптастырудың өзге де қағидалары және SR кеңістігінің логикалық мекенжайларын пайдалану тәртібі интеграцияланған жүйенің интеграциялық платформасын, Комиссияның ақпарат жүйелерін, интеграцияланған жүйенің функционалдық және қамтамасыз ететін кіші жүйелерін жобалау кезінде таңдалған техникалық шешімдермен айқындалады.

4. Қолданбалы хабарларды қалыптастыру ерекшеліктері

57. Қолданбалы хабар ішінде хабар бар блокта қолданбалы деңгейдегі деректер берілетін хабарды білдіреді.

58. Жалпы процесті іске асыру шеңберінде берілетін қолданбалы хабардың тақырыптар блогын қалыптастыру кезінде wsa:From және wsa:FaultTo тақырыптары қалыптастырылуға тиіс емес.

59. Жалпы процесті іске асыру шеңберінде берілетін қолданбалы хабардың wsa:Action тақырыбы"/" символымен бөлінген, мынадай құрауыштардан тұратын (URI) ресурсының бірдейлестірген сәйкестендірушісімен толтырылады:

а) "int://" тіркелген префиксі;

б) СР сәйкестендірушісі;

в) хабардың ішіндегісі туралы мәліметтердің құрауыштары.

60. Хабардың ішіндегісі туралы мәліметтердің құрауыштары мынадай тәртіппен көрсетіледі:

а) әрбір жалпы процесс үшін ақпараттық өзара іс-қимыл қағидаларында айқындалған жалпы процестің коды;

б) әрбір жалпы процесс үшін ақпараттық өзара іс-қимыл қағидаларында айқындалған жалпы процестің версиясы;

в) әрбір жалпы процесс үшін ақпараттық өзара іс-қимыл қағидаларында айқындалған рәсім коды;

г) жалпы процестің интеграцияланған жүйесінің құралдарымен (бұдан әрі - ақпараттық өзара іс-қимыл регламенті) іске асыру кезінде жалпы процеске қатысушылар арасында тиісті ақпараттық өзара іс-қимыл регламентінде айқындалған жалпы процесс транзакциясының коды;

д) тиісті ақпараттық өзара іс-қимыл регламентінде айқындалған жалпы процесс хабарының коды.

61. Жалпы процесті іске асыру шеңберінде берілетін қолданбалы хабарлар үшін wsa:MessageID және wsa:RelatesTo тақырыптарын пайдалану тәртібі жалпы процесс транзакциясын орындау тәртібіне байланысты және осы Қағидалардың VI бөлімінде келтірілген.

62. Жалпы процесті іске асыру шеңберінде берілетін қолданбалы хабар тақырыптары блогының өзге тақырыптары осы Қағидалардың IV бөлімінің 2-кіші бөлімінде келтірілген қағидаларға сәйкес толтырылуға тиіс.

63. Жалпы процесті іске асыру шеңберінде берілетін қолданбалы хабар ішінде хабар бар блогында ақпараттық өзара іс-қимылды реттейтін технологиялық құжаттармен құрамы айқындалатын қолданбалы деңгейдің деректері көрсетілуге тиіс.

Қолданбалы хабардың үлгісі № 3 қосымшада келтірілген.

5. Қызметтік хабарларды қалыптастырудың ерекшеліктері

64. Қызметтік хабарлар сыныбына:

а) қате туралы технологиялық хабарлар;

б) интеграцияланған жүйенің қызметтік хабарлары жатады.

65. Қате туралы технологиялық хабар хабарды өңдеуге және (немесе) беруге мүмкіндік болмайтын және қолданбалы деңгей деректерінің семантикасымен байланысты емес сыни қате туралы айғақтайды.

Қате туралы технологиялық хабарSOAP1.2. ерекшелігіне сәйкес ресімделген SOAP-хабар Fault ретінде көрінеді. Қате туралы технологиялық хабардың үлгісі осы Қағидаларға № 3 қосымшада келтірілген.

66. Егер бұл тақырып бастапқы хабарда болса не wsa:ReplyTo/wsa:Address мәнімен болса, егер wsa:FaultTo/wsa:Address тақырыбы бастапқы хабарда жоқ болса, технологиялық қате туралы хабардың wsa:To тақырыбы бастапқы хабардың wsa:FaultTo/wsa:Address тақырыбының мәнімен толтырылуға тиіс.

67. Қате туралы технологиялық хабар жөнелтушіні сәйкестендіру үшін wsa:From тақырыбы пайдаланылуға тиіс.

68. Қате туралы технологиялық хабардың wsa:RelatesTo тақырыбы xs:аnyURI үлгісіндегі int:RelatesAction атрибутын қамтуға тиіс. Аталған атрибутта осы қате туралы технологиялық хабар құралатын 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. Қате туралы технологиялық хабар тақырыбының өзге де тақырыптары осы Қағидалардың IV бөлімінің 2-кіші бөлімінде келтірілген қағидаларға сәйкес толтырылуға тиіс.

72. Ішінде қате туралы технологиялық хабар бар блок 7-кестеде ұсынылған элементтер жиынын қамтуға тиіс.

7-кесте

Ішінде қате туралы технологиялық хабар бар блок құрамы

Элемент	Деректердің түрі		Сипаттама	Еселігі
soap:Fault	soap:Fault		блоктың айналмалы элементі
soap:Code	soap:faultcode		айналмалы элемент	1
soap:Value	soap:faultcodeEnum		қателердің сыныбы	1
soap:Subсode	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

73. SOAP:Code/soap:Value элементі SOAP 1.2. ерекшелігінің талаптарына сәйкес толтырылуға тиіс.

74. SOAP:Code/soap:Subсode/soap:Value элементінде қатенің коды болуға тиіс.

Қателердің типтік кодтарының тізбесі және WS-Addressing 1.0 – Binding ерекшелігі кодтарын пайдалану қағидалары 8-кестеде ұсынылған.

8-кесте

Қателердің типтік кодтары

Қатенің сыныбы	Қатенің коды	Сипаттама және қолдану ерекшеліктері
soap:Sender	wsa:InvalidAddressingHeader	WS-Addressing 1.0–Binding ерекшелігінде айқындалған қағидаларға сәйкес мынадай шектеулермен пайдаланылады: Subsubcode мәні пайдаланылмайды wsa:DuplicateMessageID үлгісіндегі қате қалыптастырылмайды және жөнелтілмейді
soap:Sender	wsa:MessageAddressingHeaderRequired	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	қолданбалы деңгейде алынған деректерде дұрыс емес құрылымдар бар

75. SOAP:Text элементі қатенің мәтіндік сипаттамасын қамтуға тиіс.

SOAP:Text әрбір элементінде XML 1.0. ерекшелігіне сәйкес құралатын xml:lang тілдік сәйкестендірушіі болуға тиіс.

Егер қате туралы технологиялық хабарда soap:Textэлементтерінің жиыны бар болған жағдайда, элементердің әрқайсысында soap:Textэлементтерінің басқа да сәйкестендірушілерінен өзгеше xml:lang тілдік сәйкестендірушісі болуға тиіс.

Қате туралы технологиялық хабарда кем дегенде бір soap:Text элементі бар болуға тиіс, оның мазмұны орыс тілінде ұсынылған, ал хш1:lang тілдік сәйкестендірушісінде ru белгісі болуға тиіс.

76. SOAP:Detail міндетті емес элементі қатені тәптіштейтін ақпаратты қамтуға тиіс.

Қате туралы технологиялық хабарды қалыптастыру кезінде soap:Detail элементіне (тақырыптар блогын және ішіндегілерін қоса) өңдеу кезінде қате туындаған хабар енгізу ұсынылады. Бұл операция мынадай тәртіппен орындалады:

енгізілетін хабар XML 1.0ерекшелігінің қағидаларына сай CDATA тегтерімен көмкеріледі;

алғашқы қадамда алынған конструкция int:РгоblеmМеssage элементіне салынады;

екінші қадамда алынған конструкция soap:Detail элементіне салынады.

INT:ProblemMessage элементі тақырыбы деректерінің схемасы осы Қағидаларға № 2 қосымшада келтірілген.

77. Интеграцияланған жүйенің қызметтік хабарлары интеграцияланған жүйе құрауыштарының арасында деректерді беру үшін пайдаланылады.

Ішінде интеграцияланған жүйенің қызметтік хабары бар блокта интеграцияланған жүйе құрауыштарын әзірлеу кезінде құрамы айқындалатын деректер көрсетілуге тиіс.

Интеграцияланған жүйенің қызметтік хабарының wsa:Action элементі "/" символымен бөлінген мынадай құрауыштардан тұратын ресурстың біріздендірілген сәйкестендірушімен (URI) толтырылуға тиіс:

"int://" тіркелген префиксі;

SR сәйкестендірушіі;

интеграцияланған жүйе қызметтік хабарының ішіндегісін бірдейлестіретін бір немесе бірнеше құрауыш.

Интеграцияланған жүйе қызметтік хабары тақырыптар блогының өзге де тақырыптары осы Қағидалардың IV бөлімінің 2-кіші бөлімінде келтірілген қағидаларға сәйкес толтырылуға тиіс.

V. Хабарды электрондық алмасудың тәртібі

1. Хабар беру сценарийі

78. Интеграцияланған жүйенің сегменттері хабар берудің мынадай біріздендірілген сценарийін қолдауға тиіс:

а) жөнелтуші интеграцияланған жүйедегі өз сегментінің интеграцияланған шлюзіне (жөнелтушінің интеграцияланған шлюзі) берілетін хабарды құралымдайды.

б) жөнелтушінің интеграцияланған шлюзі алушы сегментінің интеграцияланған шлюзіне (алушының интеграцияланған шлюзі) интеграцияланған жүйенің интеграциялық платформасының инфрақұрылымы арқылы хабарды өңдеуді және хабарды беруді орындайды;

в) алушының интеграцияланған шлюзі хабарды өңдеуді және хабарды алушыға беруді орындайды;

г)алушы хабарды өңдеуді іске асырады.

79. Интеграцияланған жүйенің ұлттық сегменттерінде жөнелтуші (алушы) мен жөнелтушінің интеграцияланған шлюзі (алушының интеграцияланған шлюзі) арасында хабарлар беруді ведомствоаралық ақпараттық өзара іс-қимылдың ұлттық жүйесі электрондық түрде іске асырады.

80. Жалпы процестерді іске асыру кезінде мүше мемлекеттердің ұлттық сегменттерінде деректерді электрондық алмасуға қатысушылардың хабарларын қалыптастыру мен өңдеу осы Қағидаларды ескере отырып, ақпараттық өзара іс-қимылды реттейтін технологиялық құжаттардың негізінде орындалады.

81. Осы Қағидалардың V және VI бөлімдерінің ережелерінде ұлттық ерекшелікті ескерместен, деректерді электрондық алмасуға қатысушылар арасында деректерді электрондық алмасудың біріздендірілген тәртібі айқындалады.

Аталған бөлімдерде көзделген деректерді электрондық алмасу рәсімдерін ұлттық деңгейде деректерді электрондық алмасу рәсімдерімен ұштастыру қағидаларын мүше мемлекеттер өз бетінше айқындайды.

82. Осы Қағидаларды ескере отырып, ұлттық деңгейде ақпараттық өзара іс-қимыл процестерін регламенттеу үшін мүше мемлекеттерге мүше мемлекеттің тиісті ұлттық сегменті ішінде деректерді беру қағидаттарын айқындайтын нормативтік-техникалық құжаттар әзірлеу ұсынылады.

2. Ұлттық форматта хабарларды қалыптастыру

83. Мүше мемлекеттер мүше мемлекеттердің ұлттық сегменттері шеңберінде (бұдан әрі - ұлттық форматтағы хабарлар) ведомствоаралық ақпараттық өзара іс-қимыл үшін пайдаланылатын хабарлардың форматы мен құрылымына қатысты қағидалар мен талаптар белгілеуі мүмкін.

84. Мүше мемлекеттің ұлттық сегментінің интеграцияланған шлюзі ұлттық форматтағы хабарды құрылымы мен форматы осы Қағидалардың IV бөлімінде айқындалған хабарға (бұдан әрі - біріздендірілген құрылым хабары) өзгертуді орындайды.

85.Ұлттық форматтағы хабарды біріздендірілген құрылымның хабарына өзгерту кезінде мүше мемлекеттің ұлттық сегментінің интеграцияланған шлюзі пайдаланатын мәліметтердің қалыптастырылуы үшін жөнелтуші жауапкершілікті болады.

86.Ұлттық форматтардағы хабарларда біріздендірілген құрылымның хабарларының тақырыптарын толтыру үшін пайдаланылатын мәліметтерді беру схемасын мүше мемлекеттер өз бетінше айқындайды.

3. Интеграцияланған шлюздердің хабарлар беруі

87. Технологиялық деңгей деректерінің алмасу тәсілдерінің және форматтарының үйлесімділігін қамтамасыз ету үшін интеграцияланған шлюздер WS-I Basic Profile Version2.0 (WS-IBasicProfileVersion 2.0. FinalMaterial. 2010-11-09. http://www.ws-i.org/Profiles/BasicProfile-2.0.html) ерекшелігімен айқындалған қағидалардың сақталуын қамтамасыз етуге тиіс.

88. Интеграцияланған шлюздер деректерді алмасу схемасын іске асыруға тиіс, оның шеңберінде деректерді (аралас интеграцияланған шлюзге немесе ведомствоаралық ақпараттық өзара іс-қимыл жүйесіне) беру тізбегінде хабар кезекті торапқа дейін жеткізілуге тиіс не хабарды жөнелтушінің атына қате туралы технологиялық хабар жіберілуге тиіс.

89. Егер берілген хабардың өзі қате туралы технологиялық хабар болып табылса,бұл жағдайда интеграцияланған шлюз қате туралы технологиялық хабарды жібермеуге тиіс.

90. Мүше мемлекеттердің ұлттық сегменттерінің интеграцияланған шлюздеріндегі тосын жағдайларды жөндеуді оңайлату мақсаты үшін хабарларды өңдеу туралы диагностикалық ақпарат сақталады, ол № 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 өрісі жалпы процесc қатысушыcы жалпы процесс транзакциясын орындаудың алдыңғы кезеңінде алған wsa: MessageID хабары сәйкестендірушіcін қамтиды (1-сурет).

:бастамашы		:респондент
1 1 1 1		1 1 1 1
Транзакция 1		1 1
	Хабар-сұрату	1 1
1	(\уза:Ме55адеГО—'АААА-..Л \уза:Ке1а1:е&То - жоқ)	1
1 1 1 1	"Алынды" растау сигналы	1 1 1 1 1
1 1	(\у5а:Ме.55адеГО="ВВВВ-..Л \уза:К.е1а!е$То=" А АА А-...")	1 1 1
1 1 1 1	"Өңдеуге қабылданды" растау сигналы	1 1 1 1
1 к:	(\у за:Мезз ад еГО—' С СС С-..Л \у за: Ке1а{е$Т о=" А АА А-...")	1 1
1 1 1	Хабар-жауап	1 1 1
I 1	(\уза:МеззадеЮ-'БПБВ-..Л лУ5а:Ке1а1е5То=" АААА-	1 1 1 1 1
1 1		1 1 1
Транзакция 2		1 1
[ 1	Хабар-хабарлама	1 1
1 1	(\уза:Ме5за§еШ—’ХХХХ-...", \У5а:Ке1а1:е5То - жоқ)	1 1
1 1
		1 1

1-сурет. Жалпы процесс транзакциясында жалпы процесс хабарларын

байланыстыру үлгісі

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-суретте ұсынылған.

:бастамашы		:респондент
1 1	Хабар-сұрату		1
1
1 1 к--	"Алынды" растау сигналы"		1 1 -Л 1
1" "Өңдеуге қабылданды" растау сигналы 1 1			1 1 1 1
1 1 1 1-4	Хабар-жауап		1 I 1 1
			1
1 1 1 \| \|	"Алынды" растау сигналы		1 1 1 \|
1 и 1 1	"Өңдеуге қабылданды" сигналы		1 1

2-сурет. "Өзара міндеттемелер" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі

5. "Сұрақ/жауап" шаблоны бойынша жалпы процесс транзакциясы

125. "Сұрақ/жауап"шаблоны бойынша жалпы процесс транзакциясыреспонденттегі ақпаратқа сұрау салуды ұсыну жолымен және дереу ұсынылуы мүмкін (мысалы, деректер қорынан немесе статистикалық ақпараттан (каталогтан) деректердің тіркелген жиынын сұрату).

Жалпы процесс транзакциясына бастамашылық жасау ақпаратты сұрату нысаны болып табылатын жалпы процестің хабарын жіберу жолымен жүзеге асырылады.

Жауап үшін белгіленген уақыт өткенге дейін респондент сұрату ақпараты бар хабар-жауапты жөнелтуге тиіс.

Егер жауаптың уақыты өткен жағдайда, бастамашы "Қайталаудың саны" транзакциясы параметрімен қанша айқындалса, сонша рет жалпы процестің хабарын қайта жіберуге немесе қайталаулардың саны бітіп қалған жағдайда, қате туралы белгі беруге тиіс.

126. "Сұрақ/жауап" шаблоны бойынша жалпы процесс транзакциясын орындау процесінде хабарлар алмасудың мынадай дәйектілігі іске асырылады:

бастамашы респонденттің атына хабар-сұрату жібереді;

респондент сұратуды қабылдайды;

респондент қабылданған сұратуды өңдеуді қамтамасыз етеді және бастамашыға хабар-жауап жібереді;

бастамашы хабар-жауапты қабылдайды, бұл ретте транзакция аяқталған болып есептеледі;

егер жауап үшін белгіленген уақыт өткенге дейін бастамашы хабар-жауап алмаса, егер қайталаулардың саны бітіп қалмаса, ол транзакцияға қайта бастамашылық жасайды.

"Сұрақ/жауап" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі 3-суретте ұсынылған.

:бастамашы	Хабар-сұрату	:респондент
1	Хабар-сұрату	¹1^{1 1}
1 !		р1 1 1
I 1 1	Хабар-жауап	1 1 1 1
Г 1 1 1 \| 1

3-сурет. "Сұрақ/жауап" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі

6. "Сұрату/жауап"шаблоны бойынша жалпы процесс транзакциясы

127. "Сұрату/жауап" шаблоны бойынша жалпы процесс транзакциясы респондент тарапында тез қалыптастырылуға (жиналуға) тиісті, сондықтанда дереу ұсыныла алмайтын ақпарат сұратуды ұсыну жолымен орындалады.

Бастамашы транзакцияны респондентке хабар-сұрату жіберу жолымен жүзеге асырады.

Респондент жауап үшін белгіленген уақыт өткенге дейін хабар-жауап жіберуге тиіс.

Егер жауаптың уақыты өтсе, бастамашы "Қайталаудың саны" транзакциясы параметрінде қанша айқындалса, сонша рет транзакцияны қайта бастауға немесе қайталаулардың саны бітіп қалса, қате туралы белгі беруге тиіс.

128. "Сұрату/жауап"транзакциясы жеткізудің кепілдігін қамтамасыз етіп немесе қамтамасыз етпей орындалады.

129. Жеткізу кепілдігін қамтамасыз етпей "Сұрату/жауап"шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі "Сұрақ/жауап"шаблоны бойынша транзакцияны орындау дәйектілігіне ұқсас.

130.Жеткізудің кепілдігін қамтамасыз ете отырып, "Сұрату/жауап"шаблоны бойынша жалпы процесс транзакциясын орындау процесінде хабарлар алмасудың мынадай дәйектілігі іске асырылады:

бастамашы респонденттің атына хабар-сұрату жібереді және алынғанын растау уақыты ретінде айқындалған уақыт өткенге дейін сұратудың алынғаны расталуын күтеді;

респондент хабар-сұратуды қабылдайды және ақпаратты алушы ретінде (егер транзакция параметрлерімен алынғанын растау қажеттігі белгіленсе) бастамашыға "Алынды" растау сигналын жібереді;

бастамашы респонденттен қабылданған "Алынды" растау сигналын өңдегеннен кейін (егер транзакция параметрлерімен алынғанын растау қажеттігі белгіленсе) өңдеуді растау үшін белгіленген уақыт өткенге дейін хабар-сұратудағы ақпараттың өңдеуге қабылдануы расталуын күтеді;

ақпараттық өзара іс-қимыл регламентіне сәйкес респондент хабар-сұратуда қамтылған деректерге бақылау жүргізеді және бастамашыға "Өңдеуге қабылданды" растау сигналын жібере отырып, өзі алған ақпараттың өңдеуге қабылданғанын растайды;

бастамашы өзі респонденттен алған "Өңдеуге қабылданды" растау сигналын өңдегеннен кейін жауап алу уақыты ретінде айқындалған уақыт өткенге дейін жауаптың алынуын күтеді;

респондент қабылданған хабар-сұратуды өңдеуді қамтамасыз етеді және бастамашыға хабар-жауап жібереді;

бастамашы хабар-жауапты қабылдайды, бұл ретте транзакция аяқталған болып есептеледі;

егер алу үшін белгіленген уақыт өткенге дейін бастамашы растау сигналын немесе хабар-жауап алмаса, егер қайталаулардың саны бітіп қалмаса, ол транзакцияны қайта бастайды.

Жеткізудің кепілдігін қамтамасыз ете отырып, "Сұрату/жауап" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі 4-суретте ұсынылған.

:бастамашы		:респондент
Хабар-сұрату
"Алынды" растама белгісі
Белгіні қалыптастыру қажеттілігі транзакция параметрлерімен айқындалады
"Өңдеуге қабылданды" растама белгісі
Хабар-жауап

4-сурет. Жеткізудің кепілдігін қамтамасыз ете отырып, "Сұрату/жауап" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі

7. "Сұрату/растау" шаблоны бойынша жалпы процесс транзакциясы

131. Егер бастамашы расталуын ғана талап ететін ақпаратты (мысалы, мәртебелік ақпаратты сұрату)сұратса, "Сұрату/растау" шаблоны бойынша жалпы процесс транзакциясы орындалады.

Жалпы процесс транзакциясына бастамашы болуды бастамашы респонденттің растауы үшін ақпарат сұратуды білдіретін қолданбалы деңгей деректерімен хабар жіберу жолымен жүзеге асырады.

Егер жауаптың уақыты өтіп кетсе, жалпы процесс транзакциясының бастамашысы қайталаулардың келісілген санымен қанша рет айқындалса, сонша рет жалпы процесс транзакциясын қайта бастауға немесе қайталаулардың саны бітіп қалған болса, қате туралы белгі беруге тиіс.

132. Респондент алынғанын растау уақыты ретінде айқындалған уақыт өткенге дейін жалпы процесс транзакциясы бастамашысынан хабар алғаннан кейін "Алынды" растау сигналын жіберуін талап етуі мүмкін.

133. "Сұрату/растау" шаблоны бойынша жалпы процесс транзакциясы жеткізудің кепілдігін қамтамасыз етіп немесе қамтамасыз етпей орындалады.

134. Жеткізудің кепілдігін қамтамасыз етпей "Сұрату/растау" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі "Сұрақ/жауап" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігіне ұқсас.

135. Жеткізудің кепілдігін қамтамасыз етіп "Сұрату/растау" шаблоны бойынша жалпы процесс транзакциясын орындау процесінде хабарлар алмасудың мынадай дәйектілігі іске асырылады:

бастамашы респонденттің атына хабар-сұрату жібереді;

респондент хабар-сұратуды қабылдайды;

респондент қабылданған хабар-сұратуды өңдеуді қамтамасыз етеді және бастамашыға хабар-жауап жібереді;

респондентке "Алынды" растау сигналын жібере отырып, бастамашы хабар-жауапты қабылдайды және ақпаратты алушы ретінде хабар-жауапты растайды;

респондент бастамашыдан "Алынды" растау сигналын алғаннан кейін жалпы процесс транзакциясы аяқталған болып есептеледі;

егер жауапты күту уақыты ретінде айқындалған уақыт өткенге дейін бастамашы хабар-жауапты алмаса немесе алуды растау уақыты ретінде айқындалған уақыт өткенге дейін респондентке "Алынды" растау сигналын жинақтап, жібере алмаса, егер қайталаулардың саны бітіп қалмаса, ол жалпы процестің транзакциясын қайта бастайды.

Жеткізудің кепілдігін қамтамасыз етіп "Сұрату/растау" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі 5-суретте ұсынылған.

:бастамашы

:респондент

Хабар-сұрату

Хабар-ЖАУАП

" Алынды" растау сигналы

-*!

5-сурет. Жеткізудің кепілдігін қамтамасыз етіп"Сұрату/растау" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі

8. "Хабарлау"шаблоны бойынша жалпы процесс транзакциясы

136. "Хабарлау" шаблоны бойынша жалпы процесс транзакциясы респонденттен хабар-жауапты алмастан, бастамашының деректер жіберу жолымен орындалады.

Егер бастамашы қайтымсыз жай-күй туралы (мысалы, қаралып отырған өтінімнің мәртебесінің өзгеруі туралы)респондентті хабардар етуге тиіс болса, "Хабарлау" шаблоны бойынша жалпы процесс транзакциясы орындалады. Хабарлау ресми іс-қимыл болып табылатындықтан, алынғанын растау уақыты ретінде айқындалған уақыт өткенге дейін бастамашы респонденттен "Алынды" растау сигналын жіберуін талап етуге тиіс.

Егер алынғанын растау уақыты ретінде айқындалған уақыт өткенге дейін респондент аталған растау сигналын жібермесе, бастамашы қайталаудың келісілген қанша саны айқындалса, сонша рет жалпы процесс транзакциясын қайта бастауға тиіс.

137. "Хабарлау" шаблоны бойынша жалпы процесс транзакциясын орындау процесінде хабарлар алмасудың мынадай дәйектілігі іске асырылады:

бастамашы респонденттің атына қолданбалы деңгейдегі ақпаратты қамтитын хабар-хабарлама жібереді;

респондент бастамашыға "Алынды" растау сигналын жібере отырып, хабар-хабарламаны қабылдайды және ақпаратты алушы ретінде хабар-хабарламаның алынғанын растайды;

бастамашы респонденттің "Алынды" растау сигналын алғаннан кейін жалпы процестің транзакциясы аяқталған болып есептеледі.

"Хабарлау" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі 6-суретте ұсынылған.

:бастамашы		:респондент
1 1 1 1	Хабар-хабарлама	1 1 1
1 1		1
1 1 1 К 1 1	"Алынды" растау сигналы	1 1 1 1 1 1

6-сурет. "Хабарлау" шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі

9."Ақпаратты тарату" шаблоны бойынша жалпы процесс транзакциясы

138. "Ақпаратты тарату"шаблоны бойынша жалпы процесс транзакциясы респонденттен хабар-жауаптар немесе растау сигналдарын алмастан, бастамашының деректерді жіберуі жолымен орындалады. Бұл ретте респондент бастамашыға болғызбау сигналдарын не қате туралы технологиялық хабарларды қалыптастыруы және жіберуі мүмкін.

139."Ақпаратты тарату" шаблоны бойынша жалпы процесс транзакциясы бастамашының респонденттің атына қолданбалы деңгейдегі ақпаратты қамтитын хабар-хабарлама жіберу жолымен орындалады (7-сурет).

Мұндай хабар жөнелтілгеннен кейін жалпы процесс транзакциясы аяқталған болып есептеледі.

:бастамашы		:респондент
Хабар-хабарлама

7-сурет. "Ақпаратты тарату"шаблоны бойынша жалпы процесс транзакциясын орындаудың дәйектілігі

VII. Ақпараттық қауіпсіздікті қамтамасыз ету қағидаттары

140. Мүше мемлекеттер мен Комиссия мүше мемлекеттердің және Комиссияның нормативтік-құқықтық актілерінің және техникалық құжаттарының талаптарына сәйкес өз жауапкершіліктері аймағы шегінде мәліметтерді беру және өңдеу кезінде ақпараттық қауіпсіздікті өз бетінше қамтамасыз етеді.

141. Хабарларды трансшекаралық беру кезінде барлық деректерді электрондық алмасуға қатысушылар тиісті сегмент ішінде авторландыру рәсімінен өтуге тиіс.

Авторландыру рәсімі тиісті жалпы процестер шеңберінде тек деректерді электрондық алмасуға уәкілетті қатысушыларға интеграцияланған жүйенің аралас сегменттеріне хабарлар беруге құқық ұсынуды білдіреді.

Авторландыру рәсімін орындау тәсілі (сегменттің интеграцияланған шлюзі, ведомствоаралық ақпараттық өзара іс-қимыл жүйесі және т.б.деңгейінде) интеграцияланған жүйенің әрбір сегменті ішінде дербес айқындалады.

	Сыртқы және өзара сауданың интеграцияланған
	ақпараттық жүйесінде деректерді
	электрондық алмасу қағидаларына
	№ 1 ҚОСЫМША

Көліктік деңгейдегі сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінің интеграциялық шлюздері арасындағы деректерді электрондық алмасу хаттамасының
СИПАТТАМАСЫ

1. Осы құжатта пайдаланылатын ұғымдар мыналарды білдіреді:

"АР1" - Аррlication programming interface – сыртқы бағдарламалық өнімдерде пайдалануға арналған қосымшалармен (кітапханамен, сервиспен) бірге берілетін дайын сыныптардың, рәсімдердің, функциялардың, құрылымдардың және константтың жиынтығы;

"М1МЕ" - ішкі мәтіндік деректерді беру үшін ақпаратты кодтауға және форматтауға арнап ерекшелеу;

"МQMD" - көліктік хабарлардың негізгі деректемелерін қамтитын көліктік хабарлар тақырыбы;

"МQRFN2" - көліктік хабарлардың қосымша деректемелерін қамтитын көліктік хабарлар тақырыбы;

"арна" - кезек менеджерлерінің арасындағы хабарларды беруге арналған бір бағытты желілік қосылыс;

"кезек менеджері" - АР1 арқылы хабарлар кезегінің сервисін беретін бағдарламалық құрауыш;

"кезек" - кезек менеджері арқылы басқарылатын хабарлардың атаулы қоймасы;

"көліктік хабар" - көліктік хаттама талаптарына сәйкес ресімделген ақпарат элементтерінің жиынтығы.

2. Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінің интеграциялық шлюздерінің (бұдан әрі – интеграцияланған жүйе) өзара іс-қимылы хабарлардың кезегін ұйымдастыруға арналған құралдар ұсынатын (бұдан әрі – МQ бағдарламалық қамтамасыз ету) аралық бағдарламалық қамтамасыз ету арқылы жүзеге асырылады.

МQ бағдарламалық қамтамасыз етудің объектілерін атау қағидасы осы құжаттың 12-18-тармақтарында келтірілген.

3. Қолда бар кез келген бағдарламалық интерфейстерді МQ (МQI, АМ1, JМS және т. б.) бағдарламалық қамтамасыз етуге пайдалануға жол беріледі.

Осы құжатта МQ бағдарламалық қамтамасыз етудің қызметтік құрылымдары мен константын белгілеу үшін МQI бағдарламалық интерфейсіне сәйкес келетін атау пайдаланылады. Басқа АРI-интерфейстерді пайдаланған кезде құрылымдар мен констант атауының айырмашылығы болуы мүмкін.

4. Интеграциялық шлюздер көліктік деңгейде өзара көліктік хабарлармен МQ бағдарламалық қамтамасыз етудің осы құжаттың 8-11-тармақтарына сәйкес ресімделген форматында алмасады.

5. Көліктік хабар үшін 100 Мб шекті мөлшер белгіленеді. Егер көліктік хабарды ресімдеген кезде көліктік хабар мөлшері көрсетілген шекті мөлшерден асатын жағдайда, интеграциялық шлюз мұндай хабарды өңдеуді тоқтатуға тиіс.Бұл ретте интеграциялық шлюз жөнелтушіге "int: InternalError" кодының қателігі туралы технологиялық хабарды қалыптастыру мен жөнелту арқылы мұндай хабарды жеткізудің мүмкін еместігі туралы хабарлайды.

6. Интеграциялық шлюзді пайдаланушы ұйым, интеграциялық шлюзге кіретін хабардың кезегінде көліктік хабар пайда болған кезден бастап, сабақтас интеграциялық шлюзге кіретін хабардың кезегіне көліктік хабар орналасқан кезге дейін көліктік деңгейде деректер бергені үшін жауапты болады.

7. Көліктік хабар алмасудың штаттық режимінде бір интеграциялық шлюзденекінші интеграциялық шлюзге көлік хабарын жеткізудің және соңғы шлюздің хабарды өңдеуге қабылдауының мерзімі 4 сағаттан аспауға тиіс.

8. МQМD өрістерін толтырудың талаптары 1-кестеде келтірілген.

1-кестеде көрсетілмеген МQMD өрісі толтыру кезінде үнсіздік бойынша мәнге ие болуға тиіс (МQMD_DEFAULТ құрылымының мәндері пайдалануға тиіс).

9. Көліктік хабарламаға Еуразиялық экономикалық комиссия Алқасының...... № .......шешімімен бекітілген Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінің деректерімен электрондық алмасу қағидасының IV бөлімінің талаптарына сәйкес ресімделген, біріздендірілген құрылымның хабары енгізіледі.

10. Егер біріздендірілген құрылымның хабары МIМЕ-бөлігін қамтыса, онда <usr>папкасындағы МQRFН2 тақырыптар тобында қосар салымның бар болуын сәйкестендіру үшін "соntеntТуре" тақырыбы болуға тиіс, ол "Мultipart/related; Ьоundагу=<М1МЕ-блоктың сәйкестендіру шекарасы>;" жолдық мәніне ие болуға тиіс.

11. Егер біріздендірілген құрылымның хабары МIМЕ-бөлігінсіз SOАР-хабар форматында берілсе, онда <usr>папкасындағы МQRFН2 тақырыптар тобында "соntеntТуре" тақырыбы болуға тиіс, ол "аррliсаtion/sоар+хml"жолдық мәніне ие болуға тиіс.

12. Интеграциялық шлюздерде МQ бағдарламалық қамтамасыз етудің менеджерлер кезегі икемделуге тиіс, олардың атауы <Сегмент сәйкестендірушісі>IIS.QМ. шаблонын қанағаттандыруға тиіс.

13. Интеграцияланған жүйе сегментінің сәйкестендірушілері 2-кестеде келтірілген тізбеге сәйкес толтырылуға тиіс.

14. Кезек менеджерлері бір-бірімен "sеndег"/"гесеivег" типіндегі қос арнамен біріктірілуге тиіс, олардың атауы мынадай шаблондарға бағынады:

а) "sеndег" типіндегі арна үшін - IDLосаI/IDRеmote шаблонына, бұл жерде IDLосаI – жергілікті сегменттің сәйкестендірушісі, IDRеmote –соған қосылу орындалатын сегменттің сәйкестендірушісі. Мысалы, кезек менеджерлері арасындағы арнаның аты ЕЕС.IIS.QМ және ВY.IIS.QМ - ЕЕС/ВY;

б) "гесе1уег" типіндегі арна үшін - IDRеmote/IDLосаI шаблонына, бұл жерде IDRеmote – соның тарапынан қосылу орындалатын сегменттің сәйкестендірушісі, IDLосаI – жергілікті сегменттің сәйкестендірушісі. Мысалы, кезек менеджерлері арасындағы арнаның аты ЕЕС.IIS.QМ және КZ.IIS.QМ - КZ/ЕЕС.

15. Disconnect Interval (ажырату интервалы) параметріне арналған "sendег" типінде құрылатын арналарда хабар арналарының тұрақты жұмысын қамтамасыз ету үшін "0" мәні белгіленуге тиіс.

16. Сабақтас сегменттердегі интеграциялық шлюздерден хабарлар қабылдау үшін әрбір кезек менеджерінде GATEWAY.INT.IN. атымен хабарлардың жергілікті кезегі жасалуға тиіс.

17. Әрбір кезек менеджерінде сабақтас сегменттердің интеграциялық шлюздерінде GATEWAY.INT.IN. кезегіне арналған жойылған кезектерді айқындау (remote queue dfinition) жасалуға тиіс.

Жойылған кезектерді айқындаудың атауы IDRemote. QName шаблонына бағынуға тиіс, бұл жерде IDRemote – жойылған менеджер сегментінің коды, Qname - жойылған менеджердегі кезектің аты. Мысалы, GATEWAY.INT.IN. кезегі үшін ЕЕС.IIS.QМ кезек менеджерінде жойылған кезекті айқындаудың атауы - ЕЕС. GATEWAY.INT.IN.

18. Кезек менеджерлерін, хабар арналарын, кезектерді икемдеу көліктік хабарларды беруге мүмкіндік жасауға тиіс, олардың шекті мөлшері осы құжаттың 5-тармағында айқындалған.

	Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу қағидаларына
	№ 2 ҚОСЫМША

Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде хабарларды қалыптастыру кезінде пайдаланылатын мамандандырылған элементтер мен атрибуттар ДЕРЕКТЕРІНІҢ СХЕМАСЫ

<?xml version="1.0" encoding="UTF-8"?>

<xs:schemaxmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:int="urn:EEC:Interaction:v1.0" targetNamespace="urn:EEC:Interaction:v1.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>

</xs:element>

<xs:element name="AcceptTime" type="xs:dateTime">

<xs:annotation>

<xs:documentation>Интеграциялық шлюздің ЭС қабылдау күні мен уақыты</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>Fault</xs:documentation>Қалыптастырылған хабарды сәйкестендіру үшінwsa:RelatesTo элементінің құрамында пайдаланылатын атрибут

</xs:annotation>

</xs:attribute>

</xs:schema>

	Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу қағидаларына
	№ 3 ҚОСЫМША

ХАБАРЛАР МЫСАЛДАРЫ

Жөнелтуші қалыптастыратын қолданбалы хабар мысалы:

<?xml version="1.0" encoding="UTF-8"?>

<soap:Envelopexmlns: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:To>EAEU://EEC/CP/P.SP.03/P.ACT.001</wsa:To>

<wsa:ReplyTo>

<wsa:Address>EAEU://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:MessageID>urn: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>

Қате туралы технологиялық хабардың мысалы:

<?xmlversion="1.0" encoding="UTF-8"?>

<soap:Envelopexmlns: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:To>EAEU://RU/CP/P.SP.03/P.SP.03.ACT.002</wsa:To>

<wsa:From>

<wsa:Address>EAEU://EEC/SR/gate</wsa:Address>

</wsa:From>

<wsa:Action>http://www.w3.org/2005/08/addressing/soap/fault</wsa:Action>

<wsa:MessageID>urn: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:TrackID>urn:uuid:5fbc4b5a-2937-483e-91ea-45a056938a4e</int:TrackID>

<int:AcceptTime>2015-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:Value>int:InternalError</soap:Value>

</soap:Subcode>

</soap:Code>

<soap:Reason>

<soap:Textxml:lang="ru">Форматтың өзгеруінің ішкі қатесі</soap:Text>

</soap:Reason>

<soap:Detail>

<int:ProblemMessage><![CDATA[

<?xml version="1.0" encoding="UTF-8"?>

<soap:Envelopexmlns: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:To>EAEU://EEC/CP/P.SP.03/P.ACT.001</wsa:To>

<wsa:ReplyTo>

<wsa:Address>EAEU://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: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>

	Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу қағидаларына
	№ 4 ҚОСЫМША

Диагностикалық ақпаратты сақтау және оны сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінің ұлттық сегменттерінің интеграциялық шлюздерінен сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінің интеграциялық сегментіне беру тәртібіне қойылатын ТАЛАПТАР

1. Интеграциялық шлюз мынадай оқиғалар болған кезде:

а) интеграциялық шлюз хабарды алғанда;

б) интеграциялық шлюз хабарды қайта құрғанда;

в) интеграциялық шлюз басқа сегменттегі интеграциялық шлюзге немесе сабақтас жүйеге хабар жібергенде;

г) сенім білдірілген үшінші тарапқа хабар жібергенде;

д) сенім білдірілген үшінші тараптан хабар алғанда;

е) хабарды жеткізу кезінде тайм-аут туындағанда;

ж) құрылымды бақылауда және хабардың тақырыптарын толтыру қағидаларында қате туындағанда өңделетін хабарлар туралы диагностикалық ақпараттың сақталуын қамтамасыз етуге тиіс.

2. Интеграциялық шлюз Еуразиялық экономикалық комиссияның (бұдан әрі – Комиссия) интеграциялық сегментіне:

а) Комиссияның интеграциялық сегментінен сұрату алған кезде;

б) диагностикалық ақпаратты интеграциялық шлюз журналында сақтау кезінде өңделетін хабарлар туралы диагностикалық ақпарат беруді қамтамасыз етуге тиіс.

3. Диагностикалық ақпаратты сақтау кезінде диагностикалық ақпаратты синхрондаудың қызметтік хабарын интеграциялық шлюз мынадай талаптарға сәйкес қалыптастырады:

а) хабарды жөнелтушінің логикалық мекенжайын толтыру кезінде интеграцияланған жүйенің интеграциялық платформасының интеграциялық шлюзінің логикалық мекенжайы көрсетіледі;

б) хабарды алушының логикалық мекенжайын толтыру кезінде "EAEU://EEC/SR/JOURNAL/PUT" мәні көрсетіледі;

в) wsa:Action элементін толтыру кезінде "int://SR/UTIL/JOURNAL/SYNC/PUT" мәні көрсетіледі;

г) қызметтік хабардың ішінде хабар бар блогын сипаттау кезінде 1-кестеде келтірілген есім кеңістігі пайдаланылады. Қызметтік хабардың ішінде хабар бар блогы 2-кестеде келтірілген элементтерді қамтуға тиіс.

1-кесте

Құжаттың есімдер кеңістігі

Префикс	Мекенжай
journ	urn:EEC:Interaction:v1.0:Service:Util:Journal
xs	http://www.w3.org/2001/XMLSchema

2-кесте

Диагностикалық ақпаратты синхрондаудың қызметтік хабарының ішінде хабар бар блогының құрамы

Элемент							Дерек түрі	Сипаттама	Еселігі
putJournal								айналдыратын элемент
	journ:Journal							айналдыратын элемент	1
		journ:Rec						журналды жазуға арналған айналдырушы элемент	0..n
			journ:MessageDetail					хабарды егжей-тегжейлендіру	0..1
				journ:ProcessInfo				жалпы процесс туралы мәліметтер блогы–жалпы процестер үшін, басқа хабарлар үшін Action толтырылады	1
					journ:Code		xs:string	ақпараттық өзара іс-қимыл регламентіне сәйкес жалпы процесс коды	1
					journ:Version		xs:string	жалпы процесс версиясы	1
					journ:ProcedureCode		xs:string	ақпараттық өзара іс-қимыл регламентіне сәйкес рәсім коды	1
					journ:TransactionCode		xs:string	ақпараттық өзара іс-қимыл регламентіне сәйкес жалпы процесс транзакциясының коды	1
					journ:MessageCode		xs:string	ақпараттық өзара іс-қимыл регламентіне сәйкес хабардыңкоды	1
				journ:Action			xs:anyURI	Хабардың ішіндегісін сәйкестендіретін wsa:Actionтақырыбы	1
				journ:Routing				хабар маршруты туралы ақпарат	1
					journ:To		xs:anyURI	алушы туралы мәлімет қамтылғанwsa:To тақырыбы	1
						@Segment	xs:string	алушы сегменті	1
					journ:ReplyTo		xs:anyURI	хабар-жауап жіберілуге тиіс жөнелтушінің логикалық мекенжайы туралы мәлімет қамтылған wsa:ReplyTo/wsa:Addressтақырыбы	0..1
					journ:From		xs:anyURI	оған хабар-жауап жіберілуі мүмкін болмайтын жөнелтушінің логикалық мекенжайы туралы мәлімет қамтылған wsa:From/wsa:Address тақырыбы	0..1
					journ:FaultTo		xs:anyURI	оған қатесі бар хабар-жауап жіберілуге тиіс жөнелтушінің логикалық мекенжайы туралы мәлімет қамтылған wsa:FaultTo/wsa:Addressтақырыбы	0..1
					journ:FromSegment		xs:anyURI	хабардың сегмент-көзі (From немесе ReplyToмекенжайы негізінде толтырылады)	1
				journ:MessageID			xs:anyURI	хабардың сәйкестендірушісін қамтитын wsa:MessageIDтақырыбы	1
				journ:RelatesTo			xs:anyURI	хабардың сілтемелік сәйкестендірушісін қамтитын wsa:RelatesToтақырыбы	0..1
				journ:ConversationID			xs:anyURI	жалпы процесс рәсімі данасы сәйкестендірушісін қамтитын int: ConversationID тақырыбы	0..1
				journ:MessageType			xs:string	хабартүрі	1
				journ:Receipt				сенім білдірілген үшінші тараптың түбіртегі туралы ақпарат	0..1
					journ:DocumentRef		xs:string	электрондық құжаттың сәйкестендірушісі	1
					journ:ReceiptId		xs:string	сенім білдірілген үшінші тараптың түбіртегінің сәйкестендірушісі	1
					journ:IsValid		xs:boolean	электрондық құжаттағы электрондық цифрлық қол қоюды (электрондық қол қоюды) тексеру нәтижесі	1
					journ:ErrorCode		xs:string	электрондық құжаттағы электрондық цифрлық қол қоюды (электрондық қол қоюды) тексеру кезіндегі қате коды	0..1
					journ:ReasonText		xs:string	электрондық құжаттағы электрондық цифрлық қол қоюды (электрондық қол қоюды) тексеру кезіндегі қате себебі	0..1
			journ:OperationDt				xs:dateTime	операция күні	1
			journ:TrackID				xs:anyURI	хабардың технологиялық бірегей сәйкестендірушісі	1
			journ:AcceptTime				xs:dateTime	интеграциялық шлюздің хабарды қабылдау күні мен уақыты	1
			journ:Source				xs:string	хабардың жүйе-көзінің атауы	1
			journ:Receiver				xs:string	хабардың жүйе-қабылдауының атауы	1
			journ:Status				xs:string	өңдеу мәртебесі	1
			journ:Msg				xs:string	журналдау нүктесіндегі хабар	1
			journ:ErrorTxt				xs:string	өңдеу қатесі (бар болған кезде)	0..1
			journ:ErrorCode				xs:string	өңдеу қатесінің коды	0..1
			journ:IDRef				xs:string	жазбаны сілтемелік сәйкестендірушісі-Комиссияға жіберу кезінде міндетті	0..1
		journ:SourceSegment					xs:string	журналдың сегмент-көзі	1

4. Қалыптастырылған қызметтік хабар Комиссияның интеграциялық сегменті интеграциялық шлюзінің кіріс хабарлары кезегіне жіберілуге тиіс.

5. Комиссияның интеграциялық сегменті интеграцияланған жүйенің интеграцияланған платформасының интеграцияланған шлюзінен диагностикалық ақпарат сұратуға бастамашылық жасай алады.

6. Комиссияның интеграциялық сегментінің диагностикалық ақпарат сұратуы мынадай талаптарға сәйкес жүзеге асырылады:

а) интеграциялық шлюздің кіріс хабарларының кезегіне диагностикалық ақпарат сұратқан қызметтік хабар келіп түседі;

б) хабарды алушының логикалық мекенжайын толтыру кезінде "EEU://КОД_СЕГМЕНТА/SR/JOURNAL/GET"мәні көрсетіледі;

в) wsa:Actionэлементін толтыру кезінде "int://SR/UTIL/JOURNAL/SYNC/GET"мәні көрсетіледі;

г) қызметтік хабардың ішінде хабар бар блогы 3-кестеде келтірілген элементтерді қамтиды.

3-кесте

Диагностикалық ақпаратты сұратудың қызметтік хабарының ішінде хабар бар блогының құрамы

Элемент		Дерек түрі	Сипаттама	Еселік
getJournal			айналдыратын элемент
	journ:MessageID	xs:anyURI	хабар сәйкестендірушісі, ол табылуға тиіс.Не MessageID, не TrackID толтырылады	1
	journ:TrackID	xs:anyURI	хабардың технологиялық сәйкестендірушісі, ол табылуға тиіс. Не MessageID, не TrackID толтырылады	1
	journ:FindRelates	xs:boolean	байланысты хабарларды сұрату белгілері. MessageID бойынша сұрату кезінде өзекті	1

7. Интеграциялық шлюз диагностикалық ақпарат сұратқан қызметтік хабарды алған кезде диагностикалық ақпараттың жергілікті қоймасынан диагностикалық ақпарат іздестіруді мынадай талаптарға сәйкес орындайды:

а) егер сұратуда MessageIDэлементі толтырылса, MessageID ұқсас хабарлар туралы барлық ақпарат табылуға тиіс. Бұл ретте егер FindRelates элементіндегі жалау "true" мәнінде орнатылса, онда RelatesTo өрісі сұратудың MessageID элементіне тең журнал жазбалары табылуға тиіс;

б) егер сұратуда TrackIDэ лементі толтырылса, TrackIDұқсас хабарлар туралы барлық ақпарат табылуға тиіс.

8. Осы құжаттың 7-тармағында көзделген хабарлар туралы барлық табылған ақпарат осы құжаттың 3-тармағында сипатталған диагностикалық ақпаратты синхрондаудың қызметтік хабары түрінде жіберілуге тиіс. Қызметтік хабар тақырыбының RelatesTo өрісін толтыру кезінде диагностикалық ақпаратты сұрату туралы қызметтік хабар тақырыбының MessageID өрісінің мәні көрсетіледі.

	Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу қағидаларына
	№ 5 ҚОСЫМША

Растау сигналдары мен болғызбау сигналдары құрылымының және деректемелік құрамының СИПАТТАМАСЫ

1. Растау сигналдары мен болғызбау сигналдарының құрылымының және деректемелік құрамының сипаттамасы кезінде 1-кестеде келтірілген есімдер кеңістігі пайдаланылады.

1-кесте

Есімдер кеңістігі

Префикс	Мекенжай
xs	http://www.w3.org/2001/XMLSchema
sgn	urn:EEC:signal:v1.0

2. Растау сигналдары мен болғызбау сигналдарының құрылымының және деректемелік құрамының сипаттамасы кезінде 2-кестеде келтірілген деректердің базалық үлгілері пайдаланылады.

2-кесте

Деректердің базалық түрлері

Атауы	Сипаттама
sgn:EDocIdType	ISO/IEC 9834-8:2005 стандартына сәйкес UUID болып табылатын құжаттың сәйкестендірушісі. [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} шаблондары бар символдар жолы
sgn:DateTimeType	григориан күнтізбесі бойынша күн және ISO 8601 "Dataelementsandinterchangeformats – Informationinterchange – Representationofdatesandtypes" стандарты форматындағы уақыт
sgn:ErrorCodeType	бақылау қатесін кодпен таңбалау. 1-ден 255 символға дейінгі жол
sgn:StringType	мәтіндік нысандағы еркін ақпарат. Еркін ұзындықтағы жол.

3."Алынды" растау сигналының құрылымы мен деректемелік құрамы 3-кестеде келтірілген.

3-кесте

"Алынды" растау сигналының

құрылымы мен деректемелік құрамы

Элемент		Деректүрі	Сипаттама	Еселігі
sgn:DeliveryReceipt		sgn:DeliveryReceiptType	"Алынды" растау сигналының айналдыратын элементі
	sgn:SignalId	sgn:EDocIdType	сигнал сәйкестендірушісі	1
	sgn:DateTime	sgn:DateTimeType	"Алынды" растау сигналын қалыптастыру күні мен уақыты	1

4. "Өңдеуге қабылданды" растау сигналының құрылымы мен деректемелік құрамы 4-кестеде келтірілген.

4-кесте

"Өңдеуге қабылданды" растау сигналының

құрылымы мен деректемелік құрамы

Элемент		Дерек түрі	Сипаттама	Еселігі
sgn:ProcessingReceipt		sgn:ProcessingReceiptType	"Өңдеуге қабылданды" растау сигналының айналдыратын элементі
	sgn:SignalId	sgn:EDocIdType	сигнал сәйкестендірушісі	1
	sgn:DateTime	sgn:DateTimeType	"Өңдеуге қабылданды" растау сигналын қалыптастыру күні мен уақыты	1

5. "Қате" болғызбау сигналының құрылымы мен деректемелік құрамы 5-кестеде келтірілген.

5-кесте

"Қате" болғызбау сигналының

құрылымы мен деректемелік құрамы

Элемент			Дерек түрі	Сипаттама	Еселігі
sgn:ValidationError			sgn:ValidationErrorType	"Қате" болғызбау сигналының айналдыратын элементі
	sgn:SignalId		sgn:EDocIdType	"Қате" болғызбау сигналының сәйкестендірушісі	1
	sgn:DateTime		sgn:DateTimeType	"Қате" болғызбау сигналын қалыптастыру күні мен уақыты	1
	sgn:Error		sgn:ErrorType	айналдыратын элемент	1..*
		sgn:Code	sgn:ErrorCodeType	қатені кодтық таңбалау	1
		sgn:Description	sgn:StringType	қатені мәтіндік нысанда таңбалау	1
		sgn:Details	sgn:StringType	қате туралы егжей-тегжейлі етілген мәліметтер	0..1
		sgn:EDocId	sgn:EDocIdType	қате пайда болған құжаттың сәйкестендірушісі. Егер қате нақты құжатқа қатысты болса және құжаттың сәйкестендірушісін шығаруға қол жеткізілсе, толтырылады	0..1
		sgn:Reference	sgn:StringType	Қатені туындатқан элементті тұмшалауға мүмкіндік беретін символдар жолы	0..1

	Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу қағидаларына
	№ 6 ҚОСЫМША

Растау сигналдары мен болғызбау сигналдары ДЕРЕКТЕРІНІҢ СХЕМАЛАРЫ

<?xml version="1.0" encoding="UTF-8"?>

<!--

Растау сигналдары мен болғызбау сигналдарының құрылымы мен деректемелік құрамы

-->

<xs:schemaxmlns: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>

<xs: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:simpleType>

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

<xs:documentation>Мәтіндік нысандағы еркін ақпарат</xs: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>Болғызбау сигналының сәйкестендірушісі</xs: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>

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

ПРАВИЛА
электронного обмена данными в интегрированной информационной
системе внешней и взаимной торговли
I. Общие положения

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

ОПИСАНИЕ
структуры и реквизитного состава сигналов-подтверждений и
сигналов-исключений

Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу қағидаларын бекіту туралы

Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу ҚАҒИДАЛАРЫ

I. Жалпы ережелер

II. Деректерді электрондық алмасу рәсімдері

ІІІ. Деректерді электрондық алмасу рәсімдерін орындау жауапкершілігі

IV. Хабарлардың құрылымы мен форматы

VI. Жалпы процестерді іске асыру кезіндегі ақпараттық өзара іс-қимыл тәртібі

VII. Ақпараттық қауіпсіздікті қамтамасыз ету қағидаттары

ХАБАРЛАР МЫСАЛДАРЫ

Растау сигналдары мен болғызбау сигналдары құрылымының және деректемелік құрамының СИПАТТАМАСЫ

Растау сигналдары мен болғызбау сигналдары ДЕРЕКТЕРІНІҢ СХЕМАЛАРЫ

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

ПРАВИЛАэлектронного обмена данными в интегрированной информационнойсистеме внешней и взаимной торговлиI. Общие положения

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

ОПИСАНИЕструктуры и реквизитного состава сигналов-подтверждений исигналов-исключений

Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу қағидаларын бекіту туралы

Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректерді электрондық алмасу ҚАҒИДАЛАРЫ

I. Жалпы ережелер

II. Деректерді электрондық алмасу рәсімдері

ІІІ. Деректерді электрондық алмасу рәсімдерін орындау жауапкершілігі

IV. Хабарлардың құрылымы мен форматы

VI. Жалпы процестерді іске асыру кезіндегі ақпараттық өзара іс-қимыл тәртібі

VII. Ақпараттық қауіпсіздікті қамтамасыз ету қағидаттары

ХАБАРЛАР МЫСАЛДАРЫ

Растау сигналдары мен болғызбау сигналдары құрылымының және деректемелік құрамының СИПАТТАМАСЫ

Растау сигналдары мен болғызбау сигналдары ДЕРЕКТЕРІНІҢ СХЕМАЛАРЫ

ПРАВИЛА
электронного обмена данными в интегрированной информационной
системе внешней и взаимной торговли
I. Общие положения

ОПИСАНИЕ
структуры и реквизитного состава сигналов-подтверждений и
сигналов-исключений