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

Решение Коллегии Евразийской экономической комиссии от 20 января 2026 года № 6

В соответствии с пунктами 3 и 30 Протокола об информационно-коммуникационных технологиях и информационном взаимодействии в рамках Евразийского экономического союза (приложение № 3 к Договору о Евразийском экономическом союзе от 29 мая 2014 года) Коллегия Евразийской экономической комиссии решила:

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

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

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

Б. Сагинтаев

Утверждены Решением Коллегии Евразийской экономической комиссии от 20 января 2026 г. № 6

Правила
электронного обмена сообщениями и связанными с ними файлами с использованием интегрированной информационной системы Евразийского экономического союза

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

1. Настоящие Правила определяют основные принципы и механизмы электронного обмена сообщениями и связанными с ними файлами, в том числе размером более 100 Мб, с использованием интегрированной информационной системы Евразийского экономического союза (далее – интегрированная система).

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

3. Для целей настоящих Правил используются понятия, которые означают следующее:

"API S3" – протокол работы с данными в S3совместимом объектном хранилище;

"HTTP" (HyperText Transfer Protocol) – протокол передачи гипертекста, сетевой протокол прикладного уровня;

"SHA-256" (Secure Hash Algorithm 256) – один из алгоритмов криптографического хэширования из семейства криптографических алгоритмов SHA-2; используется для проверки целостности данных;

"S3-совместимое объектное хранилище" – хранилище, поддерживающее спецификацию S3 (далее – S3-хранилище);

"Simple Storage Service (S3)" – облачный сервис, позволяющий хранить большие объемы неструктурированных данных;

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

"блок содержимого" – часть сообщения в формате SOAP, содержащая значимую для участников электронного обмена данными прикладную либо технологическую информацию;

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

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

"метаинформация" – структурированная информация, которая описывает данные (файлы), но не является их частью. Это дополнительные сведения, которые используются для процессов обработки данных (файлов);

"сегмент" – национальный сегмент государства-члена или интеграционный сегмент Комиссии интегрированной системы;

"система передачи данных (СПД)" – компонент в составе интеграционного шлюза интегрированной системы, предназначенный для передачи данных, в том числе объемом более 100 Мб;

"файл" – именованная область данных на носителе информации;

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

Понятия "API", "SOAP", "URI", "XML", "интеграционный шлюз", "очередь", используемые в настоящих Правилах, применяются в значениях, определенных Правилами электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли, утвержденными Решением Коллегии Евразийской экономической комиссии от 27 января 2015 г. № 5.

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

4. Система передачи данных предназначена для обеспечения электронного обмена данными, в том числе объемом более 100 Мб.

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

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

6. Система передачи данных предназначена для:

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

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

в) передачи данных между компонентами интегрированной системы в рамках одного интеграционного сегмента;

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

д) обеспечения гарантированной доставки данных;

е) обеспечения целостности передаваемых данных;

ж) контроля времени жизни передаваемых данных;

з) журналирования процесса передачи данных.

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

8. Основной функцией S3хранилища является временное хранение файлов при передаче данных.

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

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

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

11. На транспортном уровне электронный обмен данными с использованием системы передачи данных осуществляется с использованием протоколов HTTP и API S3.

12. На технологическом уровне электронный обмен данными с использованием системы передачи данных осуществляется посредством передачи сообщений в формате SOAP. Описание структуры и формата сообщений приведено в разделе IV настоящих Правил.

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

III. Порядок взаимодействия систем передачи данных между собой
и с информационными системами

14. Система передачи данных взаимодействует с информационными системами и с иными системами передачи данных посредством вызова API по протоколу и S3протоколу.

15. Отправка данных информационной системой отправителя осуществляется следующим образом:

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

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

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

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

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

Рисунок 1 – Передача сообщения и встроенных в него файлов

Рисунок 2 – Передача сообщения и связанных с ним файлов

17. Система передачи данных отправителя выполняет следующие действия:

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

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

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

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

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

а) передать недостающие файлы;

б) заново передать файлы, для которых не совпала хеш-сумма;

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

19. Для дальнейшей передачи сообщения система передачи данных отправителя выполняет следующие действия:

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

б) передает сообщение в систему передачи данных получателя посредством вызова API по протоколу HTTP;

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

20. Система передачи данных получателя при получении от системы передачи данных отправителя сообщения выполняет следующие действия:

а) принимает сообщение и направляет код подтверждения получения сообщения в систему передачи данных отправителя;

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

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

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

сохраняет полученный файл в S3хранилище своего сегмента;

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

21. Система передачи данных отправителя, получив от системы передачи данных получателя подтверждение получения данных (сообщения и связанного(-ых) с ним файла(-ов)), выполняет следующие действия:

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

б) удаляет сообщение из очереди на отправку.

Рисунок 3 – Передача данных от системы передачи данных отправителя в систему передачи данных получателя

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

23. Информационная система получателя выполняет следующие действия:

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

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

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

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

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

24. При получении подтверждения система передачи данных получателя удаляет соответствующие файлы из S3хранилища сегмента получателя.

Схема передачи данных от системы передачи данных отправителя в систему передачи данных получателя показана на рисунке 4.

Рисунок 4 – Передача данных от СПД получателя к получателю

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

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

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

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

28. В настоящих Правилах при представлении структуры сообщений в табличной форме в графе "Кратность" таблицы 1 и таблицы 2 указываются обязательность элементов и максимальное количество экземпляров элемента:

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.

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

30. Блок заголовков определен Правилами электронного обмена данными.

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

32. Сообщение может содержать 1 двоичное вложение или более, в случае если связанные с сообщением файлы включены в сообщение. Двоичные вложения должны быть внедрены в блок содержимого сообщения в формате Base64 (согласно RFC 4648).

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

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

Таблица 1

Элемент				Тип данных	Описание	Кратность
int:Attachments					оборачивающий элемент	1
	int:Attachment				оборачивающий элемент		1..*
		int:FileID		xs:string	идентификатор файла		1
		int:FileName		xs:string	оригинальное имя файла		1
		int:Hash		xs:string	хеш-сумма файла		1
		int:Size		xs:string	размер файла в байтах		1
		int:AdditionalData			оборачивающий элемент блока дополнительных сведений		0..1
			один или несколько элементов блока	xs:any	содержимое блока дополнительных сведений		1..*

35. Элемент int:Attachments является корневым элементом структуры данных метаинформации и содержит 1 или несколько экземпляров элемента int:Attachment по числу связанных с сообщением файлов.

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

37. Элемент int:FileID содержит уникальный идентификатор файла, связанного с сообщением. Чтобы избежать коллизий при передаче файлов с использованием S3хранилища, рекомендуется формировать идентификатор файла следующим образом:

а) использовать UUID (universally unique identifier), рассчитанный в соответствии с ISO/IEC 9834-8 по версии 5 (name-based version + SHA256 hash);

б) в качестве идентификатора пространства имен (name space identifier) использовать идентификатор сообщения (wsa:MessageID), с которым связан файл;

в) в качестве имени (name) использовать контрольную сумму, определенную по файлу алгоритмом SHA-256.

38. Элемент int:FileName содержит оригинальное имя файла, включая расширение файла.

39. Элемент int:Hash содержит хеш-сумму файла (SHA-256), которая используется для проверки целостности загруженных по API S3 файлов в целях защиты от возможных случайных искажений при передаче.

40. Элемент int:Size содержит размер файла в байтах.

41. Элемент int:AdditionalData содержит дополнительную информацию, относящуюся к данному файлу, связанному с сообщением.

42. Структура элемента int:AdditionalData определяется нормативным правовым актом, утверждаемым Евразийской экономической комиссией.

43. Схема данных метаинформации системы передачи данных приведена в приложении № 3 к настоящим Правилам.

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

44. Взаимодействие систем передачи данных между собой и с внешними информационными системами осуществляется посредством API и API S3 с использованием протокола HTTP.

45. Для обеспечения совместимости способов обмена и форматов данных транспортного уровня необходимо обеспечивать соблюдение правил, определенных спецификацией RFC 2116.

46. HTTP-протокол (HyperText Transfer Protocol) – это протокол передачи данных, который определяет взаимодействие между 2 информационными системами, состоящее из обмена запросами (HTTPRequest) и ответами (HTTPResponse).

47. HTTP-запрос состоит из стартовой строки, HTTP-заголовка и тела сообщения.

48. HTTP-ответ состоит из кода состояния, HTTP-заголовка и тела ответного сообщения.

49. Стартовая строка должна содержать метод операции METHOD, адрес URI, который определяет путь к запрашиваемому ресурсу, и версию протокола VERSION. Формат стартовой строки:

METHOD URI HTTP/VERSION

Стартовая строка является обязательным элементом HTTP-запроса.

50. HTTP-заголовок – это набор пар имя-значение, разделенных двоеточием. В заголовках передается служебная информация. HTTP-заголовки должны соответствовать требованиям, которые определены стандартом RFC 822. HTTP-заголовки не являются обязательным элементом HTTP-запроса/ответа.

51. Тело сообщения – передаваемые данные, может содержать любые бинарные данные. Тело сообщения не является обязательным элементом HTTP-запроса/ответа.

52. Код состояния ответа определяет результат выполнения HTTP-запроса. Код состояния представляет собой трехзначное число в соответствии со стандартами RFC 2616 и является обязательным элементом HTTP-ответа.

53. Метод HTTP-запроса указывает на действие, которое требуется произвести с ресурсом. При электронном обмене данными интеграционными шлюзами между собой и с S3-хранилищем предполагается использование следующих методов:

GET – получение ресурса;

POST – передача данных или создание нового ресурса;

PUT – обновление данных или создание нового ресурса;

HEAD – получение информации о ресурсе без загрузки самого ресурса;

DELETE – удаление ресурса.

54. Для взаимодействия систем передачи данных между собой должны быть реализованы следующие методы:

а) передать сообщение – используется для передачи сообщения обмена данными от СПД отправителя в СПД получателя;

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

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

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

55. Для взаимодействия внешних информационных систем (информационных систем отправителя и получателя) с системой передачи данных в системе передачи данных должны быть реализованы следующие методы:

а) передать файл – используется информационная система отправителя для дальнейшего размещения передаваемых файлов в S3хранилище;

б) передать сообщение – используется информационная система отправителя для передачи сообщения для обмена данными;

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

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

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

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

Код состояния ответа определяет результат выполнения HTTP-запроса. Код состояния представляет собой трехзначное число в соответствии со стандартом RFC 2616 и является обязательным элементом HTTP-ответа.

При успешном выполнении запроса сервисами системы передачи данных должен быть передан ответ с кодом HTTP 2xx.

В случае возникновении ошибки при выполнении запроса должен быть передан ответ с кодом HTTP 4xx.

57. Реализация объектного хранилища должна поддерживать протокол S3 в соответствии со спецификацией Amazon S3 AWS.

58. Взаимодействие системы передачи данных с S3-совместимым объектным хранилищем осуществляется посредством API с использованием протокола HTTP и S3.

59. При взаимодействии с S3-хранилищем используется понятие "бакет" (от англ. bucket) – выделенная часть хранилища для пользовательских данных. Бакет является контейнером для хранения объектов данных.

Назначение бакетов – обеспечение разграничения доступа между сегментами. Для каждого сегмента определяется доступный ему бакет и перечень операций с данным бакетом, которые он может выполнить. Таким образом, ни один сегмент не сможет использовать бакет другого сегмента и получать данные, предназначенные для другого сегмента.

60. В S3-хранилище необходимо создать 6 бакетов по 1 для каждого национального сегмента и сегмента Комиссии, между которыми будет выполняться информационное взаимодействие.

61. Для наименования бакетов необходимо использовать идентификаторы сегментов в нижнем регистре с префиксом "eaeu-" (перечень идентификаторов сегментов приведен в таблице 6 раздела IV Правил электронного обмена данными).

Пример наименования: eaeu-eec – бакет для размещения данных, передаваемых в интеграционный сегмент Комиссии.

62. Назначение прав доступа к бакетам необходимо осуществить в соответствии со следующей логикой:

а) при обращении к S3-хранилищу своего сегмента СПД имеет полный доступ (на чтение и запись) ко всем бакетам;

б) при обращении к S3-хранилищу смежного сегмента:

СПД запрашивающего сегмента имеет доступ только на чтение к бакету, наименование которого совпадает с идентификатором запрашивающего сегмента;

СПД запрашивающего сегмента не имеет доступа (доступ запрещен) к бакетам, наименование которых не совпадает с идентификатором запрашивающего сегмента.

63. При размещении объектов (связанных с сообщением файлов) в S3-хранилище данные объекты следует размещать в бакете, наименование которого указывает на идентификатор сегмента – получателя сообщения.

64. Для взаимодействия информационных систем с S3-хранилищем должны использоваться следующие методы:

а) передать файл – используется для размещения в S3-хранилище файла, связанного с сообщением;

б) получить объект – используется для скачивания из S3-хранилища файла, связанного с сообщением;

в) получить метаданные объекта – используется для проверки наличия файла в S3-хранилище и контроля целостности файла (без получения самого файла);

г) удалить объекты – используется для удаления из S3-хранилища нескольких объектов (файлов, связанных с сообщением).

65. Для осуществления контроля целостности передаваемого объекта с использованием алгоритма SHA-256 в запросе на передачу файла в S3хранилище необходимо использовать заголовок x-amz-checksum-sha256. Данный заголовок должен содержать хеш-сумму SHA256 передаваемого файла, закодированную в base64.

66. При успешном выполнении запроса на передачу файла, получение объекта или метаданных объекта, удаление объекта должен быть передан ответ с кодом HTTP 200 и дополнительными параметрами:

Content-Length – длина контента, содержит размер исходного сообщения в 8-битных байтах;

x-amz-checksum-sha256 – хеш-сумма SHA-256 исходного сообщения, закодированная в Base64. Предназначена для проверки целостности. Данный заголовок будет присутствовать в ответе только в том случае, если хеш-сумма была загружена вместе с объектом.

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

400 – некорректный запрос;

403 – доступ к файлу запрещен;

404 – исходный файл не найден;

416 – диапазон не достижим.

Кроме кода ошибки должен быть возвращен элемент Error, описанный в таблице 2.

Таблица 2

Структура элемента Error

Элемент		Тип данных	Описание	Кратность
Error			оборачивающий элемент	1
	Code	string	код ошибки	1
	Message	string	текстовое описание ошибки	1
	RequestId	string	идентификатор запроса	1
	Resource	string	Идентификатор запрашиваемого ресурса (бакет и идентификатор объекта)	1

68. Описание HTTP-методов, URL-запросов и параметров запроса приведено в таблице 3.

Таблица 3

Описание API и API S3, используемых системой передачи данных

Наименование запроса	URL запроса	Входные параметры
Передать сообщение	spd::sendMessage: POST /gate/v1/message	отсутствуют
Передать подтверждение получения исходных данных	spd::acceptMessage PUT /gate/v1/message/{messageID}/accept	messageID – идентификатор сообщения, для которого получены исходные данные (связанные с сообщением файлы, при их наличии)
Передать ошибку получения исходного сообщения	spd::rejectMessage: PUT /gate/v1/message/{messageID}/reject	messageID – идентификатор сообщения, для которого не удалось получить исходные данные
Передать файл	s3::putObject: PUT /{segment}/{fileID}	segment – буквенный код сегмента, в который необходимо будет передать сообщение и связанный с ним файл; fileID – уникальный идентификатор передаваемого файла
Получить файл	s3::getObject: GET /{segment}/{fileID}	segment – буквенный код сегмента, запрашивающего файл (сегмент получателя); fileID – идентификатор запрашиваемого объекта в хранилище (файла, связанного с сообщением)
Получить метаданные объекта	s3::HeadObject: HEAD /{bucket}/{objectID}	bucket – наименование бакета, в котором размещен объект, чьи метаданные запрашиваются; objectID – идентификатор запрашиваемого объекта в хранилище
Удалить объект	s3::deleteObject: DELETE /{bucket}/{objectID}	bucket – наименование бакета, в котором размещен объект, предназначенный для удаления; objectID – идентификатор объекта в хранилище

ПРИЛОЖЕНИЕ № 1 к Правилам электронного обмена сообщениями и связанными с ними файлами с использованием интегрированной информационной системы Евразийского экономического союза

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

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

а) получение сообщения системой передачи данных;

б) преобразование сообщения системой передачи данных;

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

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

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

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

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

з) получение файла системой передачи данных;

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

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

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

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

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

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

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

ПРИЛОЖЕНИЕ № 2 к Правилам электронного обмена сообщениями и связанными с ними файлами с использованием интегрированной информационной системы Евразийского экономического союза

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

1. Система передачи данных должна обеспечивать мониторинг (сбор, анализ и отображение) прикладных параметров работоспособности системы передачи данных.

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

а) состояние системных ресурсов;

б) состояние S3-хранилища;

в) загруженность очередей;

г) количество и скорость обработки вызовов API;

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

3. Мониторинг работоспособности должен производиться по расписанию. Частота сбора параметров по расписанию должна быть настраиваемым параметром.

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

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

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

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

8. Для обмена сообщениями с информацией о данных мониторинга в системе передачи данных должен быть реализован отдельный API.

ПРИЛОЖЕНИЕ № 3 к Правилам электронного обмена сообщениями и связанными с ними файлами с использованием интегрированной информационной системы Евразийского экономического союза

Схема данных
метаинформации системы передачи данных

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:mtd="urn:EEC:M:Metadata:v1.0.0" targetNamespace="urn:EEC:M:Metadata:v1.0.0" elementFormDefault="qualified" version="1.0.0"> <xs:element name="Attachments"> <xs:annotation> <xs:documentation>Связанные с сообщением файлы</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="mtd:Attachment" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Attachment" type="mtd:AttachmentType"> <xs:annotation> <xs:documentation>Метаданные файла</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="AttachmentType"> <xs:annotation> <xs:documentation>Тип, описывающий метаданные файла</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="FileID" type="xs:string" minOccurs="1"> <xs:annotation> <xs:documentation>Уникальный идентификатор файла</xs:documentation> </xs:annotation> </xs:element> <xs:element name="FileName" type="xs:string" minOccurs="1"> <xs:annotation> <xs:documentation>Оригинальное имя файла</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Hash" type="xs:string" minOccurs="1"> <xs:annotation> <xs:documentation>Хеш-сумма файла</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Size" type="xs:integer" minOccurs="1"> <xs:annotation> <xs:documentation>Размер файла в байтах</xs:documentation> </xs:annotation> </xs:element> <xs:element name="AdditionalData" minOccurs="0"> <xs:annotation> <xs:documentation>Блок дополнительных сведений о файле в формате XML</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:any namespace="##any" processContents="lax" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:schema>

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

Еуразиялық экономикалық комиссия Алқасының 2026 жылғы 20 қаңтардағы № 6 шешімі

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

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

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

Еуразиялық экономикалық комиссия Алқасының Төрағасы

Б. Сағынтаев

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

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

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

1. Осы Қағидалар Еуразиялық экономикалық одақтың интеграцияланған ақпараттық жүйесін (бұдан әрі – интеграцияланған жүйе) пайдалана отырып, хабарлар мен олармен байланысты, оның ішінде көлемі 100 Мб асатын файлдармен электрондық алмасудың негізгі қағидаттары мен механизмдерін айқындайды.

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

3. Осы Қағидалардың мақсаттары үшін мыналарды білдіретін ұғымдар пайдаланылады:

"API S3" – S3-үйлесімді объектілік қоймадағы деректермен жұмыс істеу хаттамасы;

"HTTP" (HyperText Transfer Protocol) – гипермәтінді беру хаттамасы, қолданбалы деңгейдегі желілік хаттама;

"SHA-256" (Secure Hash Algorithm 256) – SHA-2 криптографиялық алгоритмдер тобынан алынған криптографиялық хэштеу алгоритмдерінің бірі; деректердің тұтастығын тексеру үшін қолданылады;

"S3-үйлесімді объектілік қойма" – S3 ерекшелігін қолдайтын қойма (бұдан әрі – S3-қойма);

"Simple Storage Service (S3)" – құрылымдалмаған деректердің ауқымды көлемін сақтауға мүмкіндік беретін бұлттық сервис;

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

"мазмұн блогы" – электрондық деректер алмасуға қатысушылар үшін маңызды қолданбалы не технологиялық ақпаратты қамтитын SOAP форматындағы хабардың бір бөлігі;

"хабар" – интеграциялық шлюздер арасында технологиялық деңгейде деректер алмасуға қызмет ететін SOAP форматындағы хабар. Мұндай хабарлардың құрылымы мен форматы осы Қағидалардың IV бөлімінде айқындалған;

"бастапқы деректер" – хабардан және қажет болған жағдайда хабарға ендірілуі немесе оған қосылуы мүмкін қосымша файлдардан тұратын алмасуға арналған деректер жиынтығы;

"метаақпарат" – деректерді (файлдарды) сипаттайтын, бірақ олардың бөлігі болып табылмайтын құрылымдалған ақпарат. Бұл деректерді (файлдарды) өңдеу процестері үшін пайдаланылатын қосымша мәліметтер;

"сегмент" – мүше мемлекеттің ұлттық сегменті немесе интеграцияланған жүйедегі Комиссиясының интеграциялық сегменті;

"деректер беру жүйесі (ДБЖ)" – деректерді, оның ішінде көлемі 100 Мб-тан асатындарын беруге арналған интеграцияланған жүйенің интеграциялық шлюзінің құрамындағы компонент;

"файл" – ақпарат тасығыштағы аталған деректер саласы;

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

Осы Қағидаларда пайдаланылатын "API", "SOAP", "URI", "XML", "интеграциялық шлюз", "кезек" деген ұғымдар Еуразиялық экономикалық комиссия Алқасының 2015 жылғы 27 қаңтардағы № 5 шешімімен бекітілген Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесіндегі деректермен электрондық алмасу қағидаларында айқындалған мәндерде қолданылады.

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

4. Деректерді беру жүйесі электрондық деректермен, оның ішінде көлемі 100 Мб-тан асатындармен алмасуды қамтамасыз етуге арналған.

Алмасуға арналған деректер деп алмасуға қатысушылар үшін маңызды қолданбалы немесе технологиялық ақпаратты қамтитын мәліметтер түсініледі. Қажет болса, мәліметтерге бір немесе бірнеше қосымша файлдар қосылуы мүмкін. Алмасу кезінде мәліметтер SOAP форматында электрондық хабар түрінде ресімделеді, бұл ретте қосымша файлдар хабарға енгізілуі немесе бөлек берілуі мүмкін. Электрондық хабардың құрылымы мен форматы осы Қағидалардың IV бөлімінде айқындалған.

5. Деректер беру жүйесі хабарлардың кезектерін ұйымдастыруға арналған құралдар ұсынатын бағдарламалық жасақтаманы алмастырмайды және онымен қатар жұмыс істейді.

6. Деректер беру жүйесі;

а) ақпараттық жүйелерден сұрау салуды және оған қоса берілетін деректерді қабылдауға;

б) ақпараттық жүйелер үшін кіріс деректеріне қол жеткізу үшін интерфейсті іске асыруға;

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

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

д) деректерді кепілдендірілген жеткізуді қамтамасыз етуге;

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

ж) берілетін деректердің өмір сүру уақытын бақылауға;

з) деректерді беру процесін журналға жазуға арналған.

7. Деректерді беру жүйесі пайдаланатын Ѕ3-қойма деректерді беру жүйесінің құрамына қисынды түрде кіреді, ол өз кезегінде типтік шлюздің бір бөлігі болып табылады.

8. S3-қойманың негізгі функциясы деректерді беру кезінде файлдарды уақытша сақтау болып табылады.

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

9. Деректерді беру жүйесі деректерді беру жүйесімен бірдей сегментте орналасқан ақпараттық жүйелермен, сондай-ақ өзге де сегменттерден деректерді беру жүйелерімен өзара әрекеттеседі. Мұндай өзара әрекеттесуді қамтамасыз ету үшін деректер беру жүйесінің API және API S3 пайдаланылады.

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

11. Көліктік деңгейінде деректерді беру жүйесі пайдаланыла отырып, деректермен электрондық алмасу HTTP және API S3 хаттамаларын пайдалану арқылы жүзеге асырылады.

12. Технологиялық деңгейде деректерді беру жүйесі пайдаланыла отырып, деректермен электрондық алмасу SOAP форматындағы хабарларды жіберу арқылы жүзеге асырылады. Хабарлардың құрылымы мен форматының сипаттамасы осы Қағидалардың IV бөлімінде келтірілген.

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

III. Деректерді беру жүйелерінің өзара және ақпараттық жүйелермен өзара іс-қимыл жасау тәртібі

14. Деректерді беру жүйесі ақпараттық жүйелермен және деректерді берудің өзге де жүйелерімен хаттама бойынша API шақыру және Ѕ3-хаттама арқылы арқылы өзара әрекеттеседі.

15. Жөнелтушінің ақпараттық жүйесімен деректерді жіберу мынадай жүзеге асырылады:

а) жөнелтушінің ақпараттық жүйесі алушыға арналған мәліметтерді қалыптастырады. Мәліметтерге бір немесе бірнеше қосымша файлдар қосылуы мүмкін;

б) деректерді алушыға беру үшін жөнелтушінің ақпараттық жүйесі мәліметтерді (және егер бар болса, файлдарды) SOAP форматындағы электрондық хабарлама түрінде ресімдейді. Бұл ретте файлдар хабарға тұтасымен екілік салымдар түрінде енгізілуі мүмкін немесе хабарға тек онымен байланысты файлдар туралы метаақпарат қосылады, ал файлдардың өзі бөлек беріледі;

в) файлдарды бөлек беру кезінде жөнелтушінің ақпараттық жүйесі файлдар үшін метаақпаратты қалыптастырады, оны хабарға арнайы тақырып түрінде қосады, содан кейін файлдарды файлдың сәйкестендіргіші мен адресат сегментін көрсете отырып, өз сегментінің деректер жүйесіне жібереді. Деректер жүйесі алынған әрбір файлды өз сегментінің Ѕ3-қоймасына орналастырады және жөнелтушінің ақпараттық жүйесіне файлды қабылдауды растау кодын, сондай-ақ Ѕ3-қоймадан алынған файл метаақпаратын қайтарады. Қалыптастырылған және алынған метаақпаратты салыстырғаннан кейін жөнелтушінің ақпараттық жүйесі хабарламаны қалыптастыруды аяқтайды;

г) жөнелтушінің ақпараттық жүйесі қалыптасқан хабарды өз сегментінің деректер беру жүйесіне жібереді.

16. 1-суретте қосымша файлдар болмаған, не хабарға екілік салым ретінде енгізілген жағдайдағы деректерді беру схемасы көрсетілген. 2-суретте деректерді бөлек беру схемасы көрсетілген: хабармен байланысты файлдар хабардың өзінен бөлек жіберіледі.

1-сурет – Хабарды және оған енгізілген файлдарды жіберу

2-сурет – Хабарды және онымен байланысты файлдарды беру

17. Жөнелтушінің деректерді беру жүйесі мынадай әрекеттерді орындайды:

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

б) алынған хабарда метаақпараттың – хабарға бөлек берілген қосымша файлдар қоса берілетінін көрсететін арнайы тақырыптың болуын тексереді;

в) хабарда осындай тақырып болған жағдайда, тақырыпта көрсетілген әрбір файл үшін ол өз сегментінің S3-қоймасына жүгінеді және файлдың болуын және қоймадағы файлдың хэш-сомасының тақырыпта көрсетілген хэш-соманың мәнімен сәйкестігін тексереді;

г) тексеру аяқталғаннан кейін жөнелтушінің деректер беру жүйесі жөнелтушінің ақпараттық жүйесіне хабармен байланысты файлдардың сәтті алынғанына растауды береді.

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

а) жетіспейтін файлдарды беруге;

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

в) файлдармен байланысты хабарды жөнелтуді қайта орындауға тиіс.

19. Хабарды одан әрі беру үшін жөнелтушінің деректер беру жүйесі мына әрекеттерді орындайды:

а) хабарды жеткізу кепілдігін қамтамасыз ету үшін хабарды жөнелту кезегіне қояды;

б) хабарды HTTP хаттамасы бойынша API шақыру арқылы алушының деректер беру жүйесіне береді;

в) алушының деректерді беру жүйесінен хабардың сәтті алғанын растауды, сондай-ақ хабармен байланысты барлық файлдардың (олар болған жағдайда) сәтті алынғанын растауды күтеді.

20. Алушының деректерді беру жүйесі хабар жөнелтушінің деректерді беру жүйесінен хабарды алған кезде мына әрекеттерді орындайды:

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

б) алынған хабарда хабарға қосымша файл(дар) қоса берілгенін көрсететін метаақпараты бар арнайы тақырыптың бар-жоқтығын тексереді;

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

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

алынған файлды өз сегментінің Ѕ3-қоймасына сақтайды;

хабармен байланысты барлық файлдар сәтті алынғаннан кейін, жөнелтушінің деректер беру жүйесіне файлдардың алынғанын растау жіберіледі.

21. Жөнелтушінің деректерді беру жүйесі алушының деректерді беру жүйесінен деректердің (хабарламаның және онымен байланысты (файл(дар)дың)) алынғанын растауды ала отырып, мына әрекеттерді орындайды:

а) егер файлдар хабармен байланысты болса, оларды өз сегментінің S3-қоймасынан жояды;

б) хабарды жөнелту кезегінен жояды.

3-сурет – Жөнелтушінің деректерді беру жүйесінен алушының деректерді беру жүйесіне деректерді беру

22. Алушының деректерді беру жүйесі хабарды алушының ақпараттық жүйесіне жібереді және деректердің (хабарлар мен онымен байланысты файлдардың (олар болған жағдайда)) алынғанын растауды күтеді.

23. Алушының ақпараттық жүйесі мына әрекеттерді орындайды:

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

б) алынған хабарда хабарға қосымша файл(дар) қоса берілгенін көрсететін метаақпараты бар арнайы тақырыптың бар-жоқтығын тексереді;

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

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

хабармен байланысты барлық файлдар сәтті алынғаннан кейін, ол өз сегментінің деректер жүйесіне файлдардың алынғанын растауды жібереді.

24. Растау алынған кезде алушының деректер беру жүйесі алушы сегментінің Ѕ3-қоймасынан тиісті файлдарды жояды.

Жөнелтушінің деректер беру жүйесінен алушының деректер беру жүйесіне деректерді беру схемасы 4-суретте көрсетілген.

4-сурет – Алушының ДБЖ-сынан алушыға деректер беру

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

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

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

IV. Деректер алмасу хабарларының құрылымы мен форматы

28. Осы Қағидаларда хабарлардың құрылымын кесте нысанында ұсынған кезде 1-кестенің және 2-кестенің "Еселігі" бағанында элементтердің міндеттілігі және элемент даналарының ең көп саны көрсетіледі:

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

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

30. Тақырыптар блогы Электрондық деректермен алмасу қағидаларымен анықталады.

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

32. Егер хабармен байланысты файлдар хабарға енгізілген жағдайда хабарда 1 немесе одан да көп екілік салым болуы мүмкін. Екілік салымдар хабардың мазмұн блогына Base64 форматында енгізілуі (RFC 4648 сәйкес) тиіс.

33. Егер хабармен байланысты файлдар бөлек берілген жағдайда, осы хабардың тақырыптық блогы қосымша Int:Attachments қызметтік тақырыбын қамтуға тиіс.

34. Int:Attachments қызметтік тақырыбы 1-кестеде келтірілген құрылымға сәйкес қалыптастырылады.

1-кесте

Элемент	Деректер типі	Сипаттамасы	Еселігі
int:Attachments		айналымды элемент	1
int:Attachment		айналымды элемент		1..*
int:FileID	xs:string	файлдың сәйкестендіргіші		1
int:FileName	xs:string	файлдың өзіндік аты		1
int:Hash	xs:string	файлдың хеш-сомасы		1
int:Size	xs:string	файлдың байтпен алынған мөлшері		1
int:AdditionalData		қосымша мәліметтер блогының айналымды элементі		0..1
блоктың бір немесе бірнеше элементі	xs:any	қосымша мәліметтер блогының мазмұны		1..*

35. Int:Attachments элементі метаақпарат деректер құрылымының түбірлік элементі болып табылады және хабармен байланысты файлдардың саны бойынша int:Attachment элементінің 1 немесе бірнеше данасын қамтиды.

36. Хабармен байланысты файлды сәйкестендіру және өңдеу үшін осы файл туралы метаақпаратты қамтитын Int:Attachment тақырыбы қолданылады.

37. Int:FileID элементі хабармен байланысты бірегей файл сәйкестендіргішін қамтиды. Ѕ3-қойманы пайдалана отырып файлдарды беру кезінде қайшылықтарды болдырмау үшін файлдың сәйкестендіргішін былайша қалыптастыру ұсынылады:

а) 5-нұсқа бойынша ISO/IEC 9834-8 сәйкес есептелген UUID (universally unique identifier) пайдалану (name-based version + SHA­256 hash);

б) аттар кеңістігінің сәйкестендіргіші (name space identifier) ретінде файл онымен байланысатын хабардың сәйкестендіргішін (wsa:MessageID) пайдалану;

в) атау (name) ретінде SHA-256 алгоритмімен файл бойынша анықталған бақылау сомасын пайдалану.

38. Int:FileName элементі файл кеңейтімін қоса алғанда, файлдың түпнұсқа атауын қамтиды.

39. Int: Нash элементі файлдың хэш сомасын (SHA-256) қамтиды, ол беру кезінде ықтимал кездейсоқ бұрмаланулардан қорғау мақсаттарында API S3 жүктелген файлдарының тұтастығын тексеру үшін пайдаланылады.

40. Int:Size элементі файлдың байтпен алынған мөлшерін қамтиды.

41. Int: additionaldata элементі хабармен байланысты осы файлға жататын қосымша ақпаратты қамтиды.

42. Int:AdditionalData элементінің құрылымы Еуразиялық экономикалық комиссия бекітетін нормативтік құқықтық актімен айқындалады.

43. Деректерді беру жүйесінің метаақпараты деректерінің схемасы осы Қағидаларға № 3 қосымшада келтірілген.

V. Көліктік деңгейде деректерді беру жүйесі пайдаланылатын деректермен электрондық алмасу хаттамасының сипаттамасы

44. Деректерді беру жүйелерінің өзара және сыртқы ақпараттық жүйелермен өзара әрекеттесуі HTTP хаттамасы пайдаланыла отырып, API және API S3 арқылы жүзеге асырылады.

45. Көліктік деңгейдегі деректерді алмасу тәсілдері мен форматтарының үйлесімділігін қамтамасыз ету үшін RFC 2116 ерекшелігімен айқындалған қағидалардың сақталуын қамтамасыз ету қажет.

46. HTTP-хаттамасы (HyperText Transfer Protocol) – бұл сұрау салулармен (HTTP­Request) және жауаптармен (HTTP­Response) алмасудан тұратын 2 ақпараттық жүйенің өзара әрекеттесуін анықтайтын деректер беру хаттамасы.

47. HTTP-сұрау салу бастапқы жолдан, HTTP-тақырыбынан және хабар тұрпатынан тұрады.

48. HTTP-жауап жай-күй кодынан, HTTP тақырыбынан және жауап хабарының тұрпатынан тұрады.

49. Бастапқы жол METHOD операциясының әдісін, сұрау салынатын ресурсқа жолды анықтайтын URI мекенжайын және VERSION хаттамасының нұсқасын қамтуға тиіс. Бастапқы жол форматы:

METHOD URI HTTP/VERSION

Бастапқы жол HTTP-сұрау салудың міндетті элементі болып табылады.

50. HTTP-тақырып – бұл қос нүктемен бөлінген атау-мән жұптарының жиынтығы. Тақырыптарда қызметтік ақпарат беріледі. HTTP-тақырыптары RFC 822 стандартымен анықталған талаптарға сәйкес болуға тиіс. HTTP-тақырыптары HTTP-сұрау салу/жауаптың міндетті элементі болып табылмайды.

51. Хабардың тұрпаты – берілетін деректер, кез келген бинарлық деректерді қамтуы мүмкін. Хабардың тұрпаты HTTP-сұрау салу/жауаптың міндетті элементі болып табылмайды.

52. Жауап күйінің коды HTTP-сұрау салудың орындалу нәтижесін анықтайды. Күй коды RFC 2616 стандарттарына сәйкес үш таңбалы санды білдіреді және HTTP-жауаптың міндетті элементі болып табылады.

53. HTTP-сұрау салу әдісі ресурспен жүргізілуі талап етілетін әрекетті көрсетеді. Бір-бірімен және S3-қоймамен интеграциялық шлюздермен деректерімен электрондық алмасу кезінде мынадай әдістерді пайдалану көзделеді:

GET – ресурсты алу;

POST – деректерді беру немесе жаңа ресурс құру;

PUT – деректерді жаңарту немесе жаңа ресурс құру;

HEAD – ресурстың өзін жүктеместен ресурс туралы ақпарат алу;

DELETE – ресурсты жою.

54. Деректерді беру жүйелерінің өзара әрекеттесуі үшін мынадай әдістер іске асырылуға тиіс:

а) хабарды беру – жөнелтушінің ДБЖ-дан алушының ДБЖ-ға деректер алмасу хабарын беру үшін пайдаланылады;

б) файлды алу – хабармен байланысты файлды алу үшін алушының деректер беру жүйесі пайдаланылады;

в) бастапқы деректердің алынғанын растауды беру – алушының деректер беру жүйесінің бастапқы деректердің (барлық хабармен байланысты файлдардың) сәтті жүктелгенін растауы үшін пайдаланылады;

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

55. Сыртқы ақпараттық жүйелердің (жөнелтруші мен алушының ақпараттық жүйелерінің) деректерді беру жүйесімен өзара әрекеттесуі үшін деректерді беру жүйесінде мынадай әдістер іске асырылуы тиіс:

а) файлды беру – берілетін файлдарды S3-қоймаға одан әрі орналастыру үшін жөнелтушінің ақпараттық жүйесі пайдаланылады;

б) хабарды беру – жөнелтушінің ақпараттық жүйесі деректерді алмасу үшін хабарды беру үшін пайдаланылады;

в) файлды алу – хабармен байланысты файлды алу үшін алушының ақпараттық жүйесі пайдаланылады;

г) бастапқы деректердің алынғанын растауды беру – бастапқы деректердің (барлық хабармен байланысты файлдардың) сәтті жүктелгенін растау алушының ақпараттық жүйесі үшін пайдаланылады;

д) бастапқы деректерді алу қатесін беру –бастапқы деректерді (хабармен байланысты файлдарды) жүктеудің орындалмағанын хабарлау үшін алушының ақпараттық жүйесі пайдаланылады.

56. Сұрау салулардың нәтижесі күй кодынан, жауап тақырыптарынан және жауап хабарының тұрпатынан тұратын HTTP-жауап болуға тиіс.

Жауап күйінің коды HTTP-сұрау салудың орындалу нәтижесін анықтайды. Күй коды RFC 2616 стандарттарына сәйкес үш таңбалы санды білдіреді және HTTP-жауаптың міндетті элементі болып табылады.

Деректерді беру жүйесінің сервистері сұрау салуды сәтті орындаған кезде HTTP 2xx коды бар жауап берілуге тиіс.

Сұрау салуды орындау кезінде қате туындаған жағдайда HTTP 4xx коды бар жауап берілуге тиіс.

57. Объектілік қойманы іске асыру Amazon S3 AWS ерекшелігіне сәйкес S3 хаттамасын қолдауға тиіс.

58. Деректер беру жүйесінің S3-үйлесімді объектілік қоймамен өзара әрекеттесуі HTTP және S3 хаттамасын пайдаланумен API арқылы жүзеге асырылады.

59. S3-қоймамен өзара әрекеттесу кезінде "бакет" ұғымы (ағылш. bucket) – қойманың пайдалану деректеріне арналып бөлінген бөлігі пайдаланылады. Бакет деректер объектілерін сақтауға арналған контейнер болып табылады.

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

60. S3-қоймасында әрбір ұлттық сегмент пен Комиссия сегменті үшін 1-ден 6 бакет жасау қажет, олардың арасында ақпараттық өзара іс-қимыл орындалады.

61. Бакеттерді атау үшін "eaeu-" префиксі бар төменгі тіркелімдегі сегменттердің сәйкестендіргіштерін пайдалану қажет (сегмент сәйкестендіргіштерінің тізбесі Деректермен электрондық алмасу қағидаларының IV бөлімінің 6-кестесінде келтірілген).

Атауының мысалы: eaeu-eec – Комиссияның интеграциялық сегментіне берілетін деректерді орналастыруға арналған бакет.

62. Бакеттерге қол жеткізу құқықтарын тағайындау мынадай қисынға сәйкес жүзеге асырылуы қажет:

а) өз сегментінің S3-қоймасына жүгінген кезде, ДБЖ барлық бакеттерге (оқуға және жазуға) толық қол жеткізе алады;

б) аралас сегменттің S3-қоймасына жүгінген кезде:

Сұрау салушы сегменттің ДБЖ тек бакетке оқуға қол жеткізе алады, оның атауы сұрау салушы сегменттің сәйкестендіргішімен сәйкес келеді;

Сұрау салушы сегменттің ДБЖ атауы сұрау салушы сегменттің сәйкестендіргішімен сәйкес келмейтін бакеттерге қол жеткізе алмайды (кіруге тыйым салынады).

63. Объектілерді (файлдардың хабарымен байланысты) S3-қоймаға орналастырған кезде, бұл объектілерді бакетке орналастыру қажет, оның атауы хабарды алушы сегменттің сәйкестендіргішін көрсетеді.

64. Ақпараттық жүйелердің S3-қоймамен өзара әрекеттесуі үшін мынадай әдістер пайдаланылуға тиіс:

а) файлды беру – хабармен байланысты файлды S3-қоймаға орналастыру үшін пайдаланылады;

б) объектіні алу – хабармен байланысты файлдың S3-қоймасынан жүктеп алу үшін пайдаланылады;

в) объектінің метадеректерін алу – S3-қоймада файлдың бар-жоғын тексеру және файлдың тұтастығын бақылау үшін (файлдың өзін алмастан) пайдаланылады;

г) объектілерді жою – S3-қоймадан бірнеше объектіні (хабармен байланысты файлдарды) жою үшін пайдаланылады.

65. SHA-256 алгоритмін пайдалана отырып, берілетін объектінің тұтастығын бақылауды жүзеге асыру үшін файлды S3-қоймаға беруге сұрау салуда x-amz-checksum-sha256 тақырыптарын пайдалану қажет. Бұл тақырып base64-те кодталған SHA256 берілетін файлдың хэш-сомасын қамтуға тиіс.

66. Файлды беруге, объектіні немесе объектінің метадеректерін алуға, объектіні жоюға сұрау салу сәтті орындалған кезде HTTP 200 кодымен және қосымша параметрлерімен жауап берілуге тиіс:

Content-Length – контенттің ұзындығы, 8 биттік байттағы бастапқы хабардың мөлшерін қамтиды;

x-amz-checksum-sha256 – Base64-те кодталған бастапқы хабардың SHA-256 хэш-сомасы. Тұтастықты тексеруге арналған. Бұл тақырып, егер хэш-сома объектімен бірге жүктелген жағдайда ғана жауаптың құрамында болады.

67. Файлды беруге, объектіні немесе объектінің метадеректерін алуға, объектіні жоюға сұрау салуды өңдеуде қате туындаған кезде қатенің кодын қамтитын жауап берілуге тиіс:

400 – қате сұрау салу;

403 – файлға қол жеткізуге тыйым салынады;

404 – бастапқы файл табылмады;

416 – диапазонға қол жеткізілмейді.

Қатенің кодынан басқа, 2-кестеде сипатталған Error элементі қайтарылуы тиіс.

2-кесте

Error элементінің құрылымы

Элемент	Деректер типі	Сипаттамасы	Еселігі
Error		айналымды элемент	1
Code	string	қатенің коды	1
Message	string	қатенің мәтіндік сипаттамасы	1
RequestId	string	сұрау салудың сәйкестендіргіші	1
Resource	string	Сұрау салынатын ресурстың сәйкестендіргіші (бакет және объектінің сәйкестендіргіші)	1

68. HTTP әдістерінің, URL сұрау салуларының және сұрау салу параметрлерінің сипаттамасы 3-кестеде келтірілген.

3-кесте

Деректер беру жүйесі пайдаланатын API және API S3 сипаттамасы

Сұрау салудың атауы	Сұрау салудың URL	Кіру параметрлері
Хабар беру	spd::sendMessage: POST /gate/v1/message	жоқ
Бастапқы деректердің алынғанын растауды беру	spd::acceptMessage PUT /gate/v1/message/{messageID}/accept	messageID – бастапқы деректер алынған хабардың сәйкестендіргіші (хабармен байланысты файлдар, олар болған кезде)
Бастапқы хабарды алу қатесін беру	spd::rejectMessage: PUT /gate/v1/message/{messageID}/reject	messageID – бастапқы деректерді ол үшін алу мүмкін болмаған хабардың сәйкестендіргіші
Файлды беру	s3::putObject: PUT /{segment}/{fileID}	segment – хабарды және онымен байланысты файлды беру қажет сегменттің әріптік коды; fileID – берілетін файлдың бірегей сәйкестендіргіші
Файлды алу	s3::getObject: GET /{segment}/{fileID}	segment – файлды сұрататын сегменттің әріптік коды (алушының сегменті); fileID – қоймадағы сұрау салынған объектінің (хабармен байланысты файлдың) сәйкестендіргіші
Объектінің метадеректерін алу	s3::HeadObject: HEAD /{bucket}/{objectID}	bucket – метадеректері сұралатын объект орналастырылған бакеттің атауы; objectID – қоймадағы сұрау салынатын объектінің сәйкестендіргіші
Объектіні жою	s3::deleteObject: DELETE /{bucket}/{objectID}	bucket – жоюға арналған объект орналастырылған бакеттің атауы; objectID – қоймадағы объектінің сәйкестендіргіші

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

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

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

а) деректерді беру жүйесі арқылы хабар алу;

б) деректерді беру жүйесімен хабарды түрлендіру;

в) деректерді беру жүйесінің басқа сегменттің деректерді беру жүйесіне немесе аралас жүйеге хабар жіберуі;

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

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

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

ж) хабар тақырыптарын толтырудың құрылымы мен қағидаларын бақылау қатесінің туындауы;

з) деректерді беру жүйесімен файлды алу;

и) файлға басқа сегменттің деректерді беру жүйесімен немесе аралас жүйемен қол жеткізу;

к) хабармен байланысты файлдардың тұтастығы мен толықтығын бақылау қатесінің туындауы.

2. Деректерді беру жүйесі өңделетін хабарлар және (немесе) олармен байланысты файлдар туралы диагностикалық ақпаратты Еуразиялық экономикалық комиссияның (бұдан әрі – Комиссия) интеграциялық сегментіне беруді қамтамасыз етуге тиіс:

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

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

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

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

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

Деректерді беру жүйесінің жұмыс қабілеттілігін мониторингтеуге қойылатын ТАЛАПТАР

1. Деректерді беру жүйесі деректерді беру жүйесінің жұмыс қабілеттілігінің қолданбалы параметрлерін мониторингтеуді (жинауды, талдауды және көрсетуді) қамтамасыз етуі тиіс.

2. Жұмыс қабілеттілігінің қадағаланатын параметрлері кем дегенде мыналарды қамтуы тиіс:

а) жүйелік ресурстардың жай-күйі;

б) S3-қойманың жай-күйі;

в) кезектердің жүктелуі;

г) API шақыруларын өңдеу саны мен жылдамдығы;

д) деректерді беру жүйесімен бастамашылық етілген автотестаттау нәтижелері.

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

4. Деректерді беру жүйесі өзара әрекеттесетін деректерді беру жүйелерінің жұмыс қабілеттілігі көрсеткіштерін жинауды және көрсетуді қамтамасыз етуге тиіс.

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

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

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

8. Мониторинг деректері туралы ақпаратпен хабарлар алмасу үшін деректерді беру жүйесінде жеке API іске асырылуы тиіс.

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

Деректерді беру жүйесінің метаақпарат
ДЕРЕКТЕРІНІҢ СХЕМАСЫ

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:mtd="urn:EEC:M:Metadata:v1.0.0" targetNamespace="urn:EEC:M:Metadata:v1.0.0" elementFormDefault="qualified" version="1.0.0"> <xs:element name="Attachments"> <xs:annotation> <xs:documentation>Хабармен байланысты файлдар</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="mtd:Attachment" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Attachment" type="mtd:AttachmentType"> <xs:annotation> <xs:documentation>Файлдың метадеректері</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="AttachmentType"> <xs:annotation> <xs:documentation>файлдың метадеректерін сипаттайтын тип,</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="FileID" type="xs:string" minOccurs="1"> <xs:annotation> <xs:documentation>Файлдың бірегей сәйкестендіргіші</xs:documentation> </xs:annotation> </xs:element> <xs:element name="FileName" type="xs:string" minOccurs="1"> <xs:annotation> <xs:documentation>Файлдың түпнұсқа аты</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Hash" type="xs:string" minOccurs="1"> <xs:annotation> <xs:documentation>Хеш-сумма файла</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Size" type="xs:integer" minOccurs="1"> <xs:annotation> <xs:documentation>Файлдың байтпен алынған мөлшері</xs:documentation> </xs:annotation> </xs:element> <xs:element name="AdditionalData" minOccurs="0"> <xs:annotation> <xs:documentation>XML форматындағы файл туралы қосымша мәліметтер блогы</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:any namespace="##any" processContents="lax" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:schema>