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

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 г. N 5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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 + SHA-256 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. Схема данных метаинформации системы передачи данных приведена в приложении N 3 к настоящим Правилам.

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 - доступ к файлу запрещен;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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