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

(ред. от 14.07.2026)

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

от 20 января 2026 г. № 6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. В случае если связанные с сообщением файлы передаются отдельно, блок заголовков данного сообщения должен содержать дополнительный служебный заголовок mtd:Attachments.

(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)

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

(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)

Таблица 1

Элемент				Тип данных	Описание	Кратность
mtd:Attachments					оборачивающий элемент	1
(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)
mtd:Attachment				оборачивающий элемент	1..*	(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)
mtd:FileID	xs:string	идентификатор файла		1	(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)
mtd:FileName
xs:string	оригинальное имя файла	1		(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)
mtd:Hash xs:string
хеш-сумма файла	1	(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)				mtd:Size
xs:string размер файла в байтах
1	(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)				mtd:AdditionalData
оборачивающий элемент блока дополнительных сведений 0..1
(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)					один или несколько элементов блока	xs:any
содержимое блока дополнительных сведений 1..*
	35. Элемент mtd:Attachments является корневым элементом структуры данных метаинформации и содержит 1 или несколько экземпляров элемента mtd:Attachment по числу связанных с сообщением файлов.	(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)	36. Для идентификации и обработки файла, связанного с сообщением, используется заголовок mtd:Attachment, который содержит метаинформацию о данном файле.	(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)	37. Элемент mtd:FileID содержит уникальный идентификатор файла, связанного с сообщением. Чтобы избежать коллизий при передаче файлов с использованием S3-хранилища, рекомендуется формировать идентификатор файла следующим образом:	(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)

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

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

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

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

(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)

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

(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)

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

(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)

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

(в ред. решения Коллегии Евразийской экономической комиссии от 14.07.2026 № 85)

с использованием системы передачи данных на транспортном уровне

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

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

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

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. Данный заголовок должен содержать хеш-сумму SHA-256 передаваемого файла, закодированную в base64.

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

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

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

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

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

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

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

Наименование запроса	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 — идентификатор объекта в хранилище

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СХЕМА ДАННЫХ МЕТАИНФОРМАЦИИ СИСТЕМЫ ПЕРЕДАЧИ ДАННЫХ

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

---